Proxy Mobile IPv6 Extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-10-06
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-08-14
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-05-20
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-30
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-03-30
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-03-30
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-30
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-30
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-27
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-26
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-03-26
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-03-24
|
06 | (System) | RFC Editor state changed to EDIT |
2020-03-24
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-03-24
|
06 | (System) | Announcement was received by RFC Editor |
2020-03-23
|
06 | (System) | IANA Action state changed to In Progress |
2020-03-23
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-03-23
|
06 | Cindy Morgan | IESG has approved the document |
2020-03-23
|
06 | Cindy Morgan | Closed "Approve" ballot |
2020-03-23
|
06 | Cindy Morgan | Ballot approval text was generated |
2020-03-23
|
06 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-03-20
|
06 | Benjamin Kaduk | [Ballot comment] Thanks for this well-written document! It is clearly written, and when multiple approaches exist, does well at laying out the different options and … [Ballot comment] Thanks for this well-written document! It is clearly written, and when multiple approaches exist, does well at laying out the different options and their pros/cons, as befits an Experimental document. Also, several times I have started to write a comment only to realize that it is answered by the following text :) |
2020-03-20
|
06 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss |
2020-03-19
|
06 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss and adding section 3.6. I know that the text there is inline with RFC6275 and therefore I'm clearing … [Ballot comment] Thanks for addressing my discuss and adding section 3.6. I know that the text there is inline with RFC6275 and therefore I'm clearing my discuss. However I just notice that its says " The node MAY continue to send these messages at this slower rate indefinitely." I think allowing to send something indefinitely is always a bad idea. This is a MAY but given there is no alternative provided, I guess it's not unlikely that people will implement it this way. It's always better to have a defined termination condition. This could be something like "SHOULD stop sending after X and log an error" where X is a super high value in e.g. days. This would implicitly also allow to send indefinitely because it's a SHOULD but would make it less likely people implement that. I personal would however even recommend a MUST. In any case, as RFC6275 has exactly the same sentence, so I'm not blocking on this, but maybe still worth reconsidering... --------- Old comments: I fully understand why the authors decided to not make changes but keeping these as for the record: 4) As section 3.6 talks mainly about implementation details, I suggest to move this section into the appendix. 7) One overall editorial comment which might be too late to address: I would have found it more easy to read if you would have first introduced the new messages and then used the concrete message names in the description in section 3. |
2020-03-19
|
06 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2020-03-08
|
06 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the … [Ballot comment] Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the text is really easy to read. Thank you also for fixing my previous DISCUSS as well as replying by email to my comments. I have kept the original DISCUSS & COMMENT below. Please also address the points raised by Carlos during the INT directorate review. Thank you again Carlos ! https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/ Happy that my comments have helped to improve the document Regards, -éric == OLD DISCUSS == -- Section 4.3 & 4.4 & 4.5 -- Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or in bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The definition of the "Prefix length" field should be specific about the unit (bits/bytes) and be aligned with the definition of "Anchored prefix" (as this one seems to assert that the prefix length must be a multiple of 8). == COMMENTS == A generic question, can a MN be attached to multiple MAAR at the same time? I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR at any time. -- Section 3.1 -- Should the length of the prefix assigned to the MN be specified? Adding a /64 would make things clearer without using too much of text. For my own curiosity, the text is about "IPv6 global prefix", but, would ULA also work ? -- Section 3.6 -- This section is so different than the previous ones in section 3, that I would have created a section on its own. This section also uses EUI-64 for the link-local address; and, this is no more advised for privacy reason. Not really important in the DMM context though. Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;-) The text of this section is really difficult to parse. After 2 readings I am not even sure that I got it... I was about to open a DISCUSS for the point 2) but I am unsure whether I am reading the text correctly. 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than the one for mn1mar2, why is there a need for different interface? Multiple routers can exist on the same link. 2) For packets sourced by MN1 with prefix1 how can we ensure that they are sent to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned draft-ietf-intarea-provisioning-domains. -- Section 4.2 -- Bit 31 is not described, it is probably reserved but you should really described it. With this PBA packet format, all flags / bits are used and assigned for an experimental document. Isn't it a waste of bits? I will really appreciate an answer on this question. == NITS == -- Section 3 (and possibly others) -- The CMD and MAAR acronyms are expanded multiple times. This makes the reading easier for newcomers of course. |
2020-03-08
|
06 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2020-03-08
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-03-08
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-03-08
|
06 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-06.txt |
2020-03-08
|
06 | (System) | New version approved |
2020-03-08
|
06 | (System) | Request for posting confirmation emailed to previous authors: Carlos Bernardos , Juan Zuniga , Antonio de la Oliva , Fabio Giust , Alain Mourad |
2020-03-08
|
06 | Carlos Jesús Bernardos | Uploaded new revision |
2020-03-05
|
05 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-03-05
|
05 | Cindy Morgan | Changed consensus to Yes from Unknown |
2020-03-04
|
05 | Roman Danyliw | [Ballot comment] I support Mirja Kühlewind's and Ben Kaduk's DISCUSS position. ** Section 6. Per “The CMD SHOULD use a pacing approach to limit this … [Ballot comment] I support Mirja Kühlewind's and Ben Kaduk's DISCUSS position. ** Section 6. Per “The CMD SHOULD use a pacing approach to limit this amplification risk”, could you address Vincent Roca’s SECDIR Review (thank you!) question “should that pacing be on the In the incoming queue (i.e., by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit output traffic), or both?” ** Section 6. To provide normative language: s/This requires security associations to exist between the involved MAARs/ Hence, security associations are REQUIRED to exist between the involved MAARs/ Editorial Nit: ** Section 6. s/there may exist multiple previous (e.g., k) MAARs exist/ there may exist multiple previous (e.g., k) MAARs/ |
2020-03-04
|
05 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-03-04
|
05 | Benjamin Kaduk | [Ballot discuss] I have a very boring Discuss point and a somewhat boring point, and expect to change my ballot to Yes once they're resolved. … [Ballot discuss] I have a very boring Discuss point and a somewhat boring point, and expect to change my ballot to Yes once they're resolved. In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid bursts when the CMD is fanning out PBUs, but in Section 6 we say that pacing "SHOULD" be used; please resolve the inconsistency (preferrably with "MUST" as Mirja requests). Please also include some discussion of privacy considerations (I give some suggestions in the COMMENT). |
2020-03-04
|
05 | Benjamin Kaduk | [Ballot comment] Thanks for this well-written document! It is clearly written, and when multiple approaches exist, does well at laying out the different options and … [Ballot comment] Thanks for this well-written document! It is clearly written, and when multiple approaches exist, does well at laying out the different options and their pros/cons, as befits an Experimental document. Also, several times I have started to write a comment only to realize that it is answered by the following text :) Section 1 The Distributed Mobility Management (DMM) paradigm aims at minimizing the impact of currently standardized mobility management solutions which are centralized (at least to a considerable extent). I'd consider saying a little more about which aspects of their operation are centralized. Perhaps the following paragraph suffices, though. Following this idea, in our proposal, the central anchor is moved to the edge of the network, being deployed in the default gateway of the mobile node. That is, the first elements that provide IP (side note: Using the singular "central anchor" poses an interesting rhetorical question: is the (formerly) single central anchor being duplicated and spread amongst all access routers, or does there remain a single central anchor (per MN), just one that moves around along with the MN.) anchors to retrieve the MN's previous location(s). Also, a key- aspect of network-based DMM, is that a prefix pool belongs exclusively to each MAAR, in the sense that those prefixes are assigned by the MAAR to the MNs attached to it, and they are routable at that MAAR. It might be worth some statement relating this "ownership" of prefixes to actual mobility events -- e.g., they are assigned to MNs attached to it at that time, but remain with those MNs as mobility occurs, but always remain routable at that MAAR as well as towards the MN itself. We consider partially distributed schemes, where the data plane only is distributed among access routers similar to MAGs, whereas the nit: I suggest s/the data plane only/only the data plane/ control plane is kept centralized towards a cardinal node used as information store, but relieved from any route management and MN's data forwarding task. What's the scope of "single" here -- per deployment, per prefix, per MAAR, ...? P-MAAR (Previous MAAR). When a MN moves to a new point of attachment a new MAAR might be allocated as its anchor point for future IPv6 prefixes. The MAAR that served the MN prior to new attachment becomes the P-MAAR. It is still the anchor point for the IPv6 prefixes it had allocated to the MN in the past and serves as the (side note? Do we expect those previous allocations to eventually "time out" as sessions using them terminate? Or are the allocations more permanent, with intent to reuse if/when the MN returns to that MAAR?) Section 3 interest and eventually take the appropriate action. The procedure adopted for the query and the messages exchange sequence might vary to optimize the update latency and/or the signaling overhead. Here nit: wrong pluralization in "messages exchange sequence" Section 3.1 3. Since this is an initial registration, the CMD stores a permanent BCE containing as primary fields the MN-ID, Pref1 and MAAR1's address as a Proxy-CoA. [how permanent is "permanent"?] Section 3.2 1. When the MN moves from its current point of attachment and attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it stores a temporary BCE, and it sends a plain PBU to the CMD for registration. It's not clear to me at this point how MAAR2 has enough information to determine that this will be a "plain" PBU vs. the the PBU used for initial registration. (That said, it's also not clear to me that the send PBU actually differs on the wire, so maybe this is just a rhetorical question. Er, a question of rhetoric, that is.) 4. The CMD, after receiving the PBA, updates the BCE populating an instance of the P-MAAR list. The P-MAAR list is an additional field on the BCE that contains an element for each P-MAAR involved in the MN's mobility session. The list element contains the P-MAAR's global address and the prefix it has delegated (see Appendix B for further details). Also, the CMD sends a PBA to the new S-MAAR, containing the previous Proxy-CoA and the prefix anchored to it embedded into a new mobility option called Previous MAAR Option (defined in Section 4.5), so that, upon PBA arrival, a bi-directional tunnel can be established between the two MAARs and new routes are set appropriately to recover the IP flow(s) carrying Pref1. To check my understanding: there will only be one Previous MAAR Option present and it will describe only a single MAAR, which implies that if there are multiple P-MAARs, traffic directed to an arbitrary prefix based at one of them is expected to traverse multiple tunnels from P-MAAR to P-MAAR before making its way to the S-MAAR and the MN? [Hmm, looks like my understanding is wrong. I'd consider making "previous Proxy-CoA" and "the prefix anchored to it" plural to give the reader a hint as to what's coming, though I can understand if there is desire to keep the initial mobility example simple and only gradually introduce the complexity in question.] For MN's next movements the process is repeated except the number of P-MAARs involved increases (accordingly to the number of prefixes that the MN wishes to maintain). Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR prior to handover) and in the P-MAARs list. They reply with a PBA to the CMD, which aggregates them into a single one to notify the S-MAAR, that finally can establish the tunnels with the P-MAARs. I'm not sure I understand the cardinality of P-CoA -- is it one, the single S-MAAR prior to handover, or many, all P-MAARs in the list? When there are multiple previous MAARs, e.g., k MAARs, a single PBU received by the CMD triggers k outgoing packets from a single incoming packet. This may lead to packet bursts originated from the CMD, albeit to different targets. Pacing mechanisms MAY be introduced to avoid bursts on the outgoing link. I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable than "MAY" to me, here. Section 3.3 The handover latency experienced in the approach shown before can be reduced if the P-MAARs are allowed to signal directly their information to the new S-MAAR. This procedure reflects what was described in Section 3.2 up to the moment the P-MAAR receives the PBU with the P-MAAR option. At that point a P-MAAR is aware of the new nit(?): I think this is the S-MAAR option, not the P-MAAR option? S-MAAR including the prefix it is anchoring. This latter PBA does not need to include new options, as the prefix is embedded in the HNP option and the P-MAAR's address is taken from the message's source address. The CMD is relieved from forwarding the PBA to the S-MAAR, (side note: this assumes there's no NAT or tunneling or similar between MAARs, which seems like a plausible assumption, at least for now.) Section 3.4 side. When P-MAARs complete the update, they send a PBA to the CMD to indicate that the operation is concluded and the information is updated in all network nodes. This procedure is obtained from the Is there anything useful to say about behavior on timeout at the CMD (failing to reive a PBA from one or more P-MAARs)? Section 3.5 The de-registration mechanism devised for PMIPv6 cannot be used as is in this solution. The reason for this is that each MAAR handles an nit: s/as is/as-is/ Indeed, when a previous MAAR initiates a de-registration procedure, because the MN is no longer present on the MAAR's access link, it removes the routing state for that (those) prefix(es), that would be deleted by the CMD as well, hence defeating any prefix continuity attempt. The simplest approach to overcome this limitation is to nit(?): s/when/if/. At least, this makes more sense to me if I do that ... maybe I'm just confused. serving MAAR to de-register the whole MN session. This can be achieved by first removing any layer-2 detachment event, so that de- registration is triggered only when the session lifetime expires, I see that RFC 5213 has some mechanisms for lifetime management, but didn't get to look closely enough to understand how clear the necessary lifetime management will be in the DMM case when there are multiple prefixes registered to a given MN at different MAARs. (Also, 5213 doesn't seem to use the "session lifetime" phrase verbatim.) Section 3.6 requiring special support from the mobile node's IP stack. This document defines the Distributed Logical Interface (DLIF), which is a software construct that allows to easily hide the change of associated anchors from the mobile node. A software construct in the MAAR, right? How common is "HMAC" as an abbreviation for "hardware MAC address"? It's also an abbreviation for Hash-based Message Authentication Code, which confuses my poor security-focused brain, though I acknowledge that this does not necessarily extend to most of the target audience for this document... and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? role of anchoring MAAR for the attached (served) MNs. Each MAAR has one single physical wireless interface. Have we defined "anchoring MAAR" yet? Also, I assume that the "single physical interface" is just "as depicted in this example" and not a protocol requirement :) As introduced before, each MN always "sees" multiple logical routers -- one per P-MAAR -- independently of its currently serving MAAR. [same P-MAAR vs. S-MAAR split as above] by the serving MAAR (MAAR2) configuring an additional distributed logical interface: mn1mar1, which behaves exactly as the logical interface configured by MAAR1 when MN1 was attached to it. This nit(?): "exactly" is asking for pedants to try and poke holes in the claimed perfection. deprecated). The goal is to deprecate the prefixes delegated by these MAARs (which will be no longer serving the MN). Note that on- nit(?): s/which will be no longer/so that they will no longer be/, IIUC Section 4.1 The intdir reviewer's comments regarding the flag bits seem apropos (I presume they were allocated by other extensions to 5213, but we should say something about it). A new flag (D) is included in the Proxy Binding Update to indicate that the Proxy Binding Update is coming from a Mobility Anchor and "D" is for "DMM", I trust? It could be worth mentioning. Is the D bit set for the PBUs sent from CMD to P-MAAR as well? (I see that the PBA description uses a slightly different formulation to cover the 'D' bit; is there a reason to diverge?) Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand. MAARs that *receive* PBUs must be P-MAARs, right? Section 4.2 MAAR (D) The D is set to indicate that the sender of the message supports operating as a Mobility Anchor and Access Router. When a MAG that does not support the extensions described in this document receives a message with the D-Flag set, it MUST ignore the message and an error MUST be returned. Is the CMD considered a MAAR for this purpose? contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand. What about the CMD? Section 4.3, 4.4 Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Anchored Prefix A sixteen-byte field containing the mobile node's IPv6 Anchored Prefix. Only the first Prefix Length bytes are valid for the Anchored Prefix. The rest of the bytes MUST be ignored. Is the prefix length bits or bytes? Section 4.4 Is this also used to convey "local" prefixes in the PBA from CMD to S-MAAR? (If not, how does the S-MAAR know to advertise them from its DLIF?) Section 4.5 What's the alignment requirement? (There's no need to put in a Reserved octet to keep things word aligned?) Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. [...] Home Network Prefix A sixteen-byte field containing the mobile node's IPv6 Home Network Prefix. Only the first Prefix Length bytes are valid for the mobile node's IPv6 Home Network Prefix. The rest of the bytes MUST be ignored. [is the prefix length bits or bytes?] Section 4.6 Is there an alignment requirement for this option? This new option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between the CMD and When is this option used in a PBA? Section 4.7 A new DLIF Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between MAARs. This option is used for exchanging the MAARs but not CMDs? When is this used in the PBU? Section 4.8 A new DLIF Link-layer Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between MAARs. This option is used for exchanging the MAARs but not CMDs? When is this used in the PBU? Section 6 Unfortunately it seems that RFC 5213 does not include any privacy considerations discussion. While the privacy properties of this protocol bear similarities to those of RFC 5213, it seems that there are also some significant differences, so I do think it is important to produce some documentation of privacy considerations for this document. The main factor would, of cousre, be tracking which entities obtain updates/information about the location of the MN, what those entities are expected to do with that data, and how trusted they are to be proper custodians of it. Other factors may exist as well, including the potential for side-channel information leakage, e.g., due to traffic analysis. There might also be a reverse situation where exposing the link-layer address(es) of a P-MAAR have privacy considerations, though I don't have anything particular in mind at the moment. security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended that the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgment, exchanged between the MAARs are protected using IPsec using the established security association between them. This This is essentially unchanged from 5213, just with different names for the endpoints, right, and so the existing guidance/experiences apply? I think we should also say something about all MAARs and the CMD being trusted parties. We should also say something about the authorization model (I assume it's just "all trusted parties are trusted to perform all operations relevant to their role", but that's still useful to say). When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a single PBU to multiple previous MAARs. In situations of many fast handovers (e.g., with vehicular networks), there may exist multiple previous (e.g., k) MAARs exist. In this situation, the CMD creates k nit: remove the redundant "exist" When the CMD acts as MAAR locator, mobility signaling (PBAs) is exchanged between P-MAARs and current S-MAAR. This requires security associations to exist between the involved MAARs (in addition to the ones needed with the CMD). Is this relevant because of scaling/resource-consumption concerns or keying/trust ones? Appendix A.5 not implement existing mobility protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when the needed mobility management Hmm, separate administrative domains makes the risk of NAT relatively higher (per previous comment about NAT). intervention. The partially distributed DMM solution can be deployed across different domains with trust agreements if the CMDs of the operators are enabled to transfer context from one node to another. It would probably be worth expounding a bit more about this scenario and the necessary trust/authorization relationships, in the security considerations. |
2020-03-04
|
05 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-03-04
|
05 | Adam Roach | [Ballot comment] Thanks for the work on this document. I have only one editorial suggestion. Section 3.6: > to-point link) with MN1, exposing itself as … [Ballot comment] Thanks for the work on this document. I have only one editorial suggestion. Section 3.6: > to-point link) with MN1, exposing itself as a (logical) router with a > specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., Please use a MAC address from the range reserved for documentation purposes by section 2.1.1 of RFC 7042. |
2020-03-04
|
05 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-03-04
|
05 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-03-04
|
05 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-03-03
|
05 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-03-03
|
05 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-03-03
|
05 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-03-02
|
05 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the … [Ballot discuss] Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the text is really easy to read. I have a block DISCUSS below but it should be trivial to fix. Please also address the points raised by Carlos during the INT directorate review. Thank you again Carlos ! https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/ I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 4.3 & 4.4 & 4.5 -- Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or in bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The definition of the "Prefix length" field should be specific about the unit (bits/bytes) and be aligned with the definition of "Anchored prefix" (as this one seems to assert that the prefix length must be a multiple of 8). |
2020-03-02
|
05 | Éric Vyncke | [Ballot comment] == COMMENTS == A generic question, can a MN be attached to multiple MAAR at the same time? I.e., once over WiFi and … [Ballot comment] == COMMENTS == A generic question, can a MN be attached to multiple MAAR at the same time? I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR at any time. -- Section 3.1 -- Should the length of the prefix assigned to the MN be specified? Adding a /64 would make things clearer without using too much of text. For my own curiosity, the text is about "IPv6 global prefix", but, would ULA also work ? -- Section 3.6 -- This section is so different than the previous ones in section 3, that I would have created a section on its own. This section also uses EUI-64 for the link-local address; and, this is no more advised for privacy reason. Not really important in the DMM context though. Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;-) The text of this section is really difficult to parse. After 2 readings I am not even sure that I got it... I was about to open a DISCUSS for the point 2) but I am unsure whether I am reading the text correctly. 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than the one for mn1mar2, why is there a need for different interface? Multiple routers can exist on the same link. 2) For packets sourced by MN1 with prefix1 how can we ensure that they are sent to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned draft-ietf-intarea-provisioning-domains. -- Section 4.2 -- Bit 31 is not described, it is probably reserved but you should really described it. With this PBA packet format, all flags / bits are used and assigned for an experimental document. Isn't it a waste of bits? I will really appreciate an answer on this question. == NITS == -- Section 3 (and possibly others) -- The CMD and MAAR acronyms are expanded multiple times. This makes the reading easier for newcomers of course. |
2020-03-02
|
05 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2020-03-02
|
05 | Mirja Kühlewind | [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is … [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is fine. However, you should also indicate that the rest of the specified retransmission mechanism should be used as well. That means exponential backoff as well as a max number of retries. Further I think it would also be important to overall rate-limit the traffic e.g. as specified in RFC6275: "The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second." In addition the same mechanisms should probably be also required for any (new) message sent by the P/S-MAAR in other modes. Finally in the security consideration section I see this: "The CMD SHOULD use a pacing approach to limit this amplification risk." Which is good! But why is that a SHOULD and not a MUST? Update: This discuss is inline with the comments provided by the TSV-ART review (thanks Jörg!) which lead to an update that don't seem fully addressed. So please review that feedback as well and continue discussion with the TSV-ART reviewer if needed. |
2020-03-02
|
05 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2020-02-28
|
05 | Carlos Pignataro | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Pignataro. Review has been revised by Carlos Pignataro. |
2020-02-28
|
05 | Carlos Pignataro | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2020-02-28
|
05 | Mirja Kühlewind | [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is … [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is fine. However, you should also indicate that the rest of the specified retransmission mechanism should be used as well. That means exponential backoff as well as a max number of retries. Further I think it would also be important to overall rate-limit the traffic e.g. as specified in RFC6275: "The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second." In addition the same mechanisms should probably be also required for any (new) message sent by the P/S-MAAR in other modes. Finally in the security consideration section I see this: "The CMD SHOULD use a pacing approach to limit this amplification risk." Which is good! But why is that a SHOULD and not a MUST? |
2020-02-28
|
05 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2020-02-28
|
05 | Mirja Kühlewind | [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is … [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is fine. However, you should also indicate that the rest of the specified retransmission mechanism should be used as well. That means exponential backoff as well as a max number of retries. Further I think it would also be important to overall rate-limit the traffic e.g. as specified in RFC6275: "The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second." In addition the same mechanisms should probably be also required for any (new) message send by the P/S-MAAR in other modes. Finally in the security consideration section I see this: "The CMD SHOULD use a pacing approach to limit this amplification risk." Which is good! But why is that a SHOULD and not a MUST? |
2020-02-28
|
05 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2020-02-28
|
05 | Mirja Kühlewind | [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is … [Ballot discuss] Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is fine. However, you should also indicate that the rest of the specified retransmission mechanism should be used as well. That means exponential backoff as well as a max number of retries. Further I think it would also be important to overall rate-limit the traffic e.g. as specified in RFC6275: "The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second." In addition the same mechanisms should probably be also required for any (new) message send by the P/S-MAAR in other modes. Finally on in the security consideration section I see this: "The CMD SHOULD use a pacing approach to limit this amplification risk." Which is good! But why is that a SHOULD and not a MUST? |
2020-02-28
|
05 | Mirja Kühlewind | [Ballot comment] Editorial comments/nits: 1)Sec 1: "Following this idea, in our proposal, the central anchor is..." Maybe remove "in our proposal" as this is not … [Ballot comment] Editorial comments/nits: 1)Sec 1: "Following this idea, in our proposal, the central anchor is..." Maybe remove "in our proposal" as this is not a proposal only anymore when published. 2) Sec 2: "The following terms used in this document are defined in the DMM Deployment Models and Architectural Considerations document [I-D.ietf-dmm-deployment-models]:" As there doesn't seem to be any plan to actually publish draft-ietf-dmm-deployment-models anymore, maybe move the respective definitions into this document. 3) Sec 3: "Note that a MN MAY move across different MAARs" This should be lower case "may". 4) As section 3.6 talks mainly about implementation details, I suggest to move this section into the appendix. 5) In the appendix you always talk about "our solution". This is rather uncommon for an RFC. I recommend to chance to e.g. "the solution specified in this document". 6) Are both appendices A and B are still needed? 7) One overall editorial comment which might be too late to address: I would have found it more easy to read if you would have first introduced the new messages and then used the concrete message names in the description in section 3. |
2020-02-28
|
05 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2020-02-27
|
05 | Vincent Roca | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Vincent Roca. Sent review to list. |
2020-02-20
|
05 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Vincent Roca |
2020-02-20
|
05 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Vincent Roca |
2020-02-19
|
05 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2020-02-19
|
05 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2020-02-19
|
05 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-02-18
|
05 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-02-18
|
05 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2020-02-18
|
05 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Fred Baker |
2020-02-14
|
05 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup::External Party |
2020-02-14
|
05 | Cindy Morgan | Placed on agenda for telechat - 2020-03-05 |
2020-02-14
|
05 | Suresh Krishnan | Ballot has been issued |
2020-02-14
|
05 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2020-02-14
|
05 | Suresh Krishnan | Created "Approve" ballot |
2020-02-14
|
05 | Suresh Krishnan | Ballot writeup was changed |
2020-02-14
|
05 | Suresh Krishnan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. Write-up for draft-ietf-dmm-pmipv6-dlif-05 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Experimental. This is appropriate given the experimental nature of the work. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a new mechanism for realizing distributed mobility management system based on Proxy Mobile IPv6 protocol. Working Group Summary This document has been in development, first as an individual submission in the DMM WG and later as a working group document. The document has gone through around 5 revisions. Document Quality The document is well-written and technically correct in our opinion. The document had some amount of reviews and inputs by the working group and also by some of the mobility experts in the WG. Furthermore, some of the authors have very good understanding of the Proxy Mobile IPv6 protocol and therefore we believe the quality of the document is good. Personnel Dapeng(Max) Liu is the document shepherd. Suresh Krishnan is the current responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I read the document, understood the content and have also discussed with the authors. I believe this version of the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. As this document’s focus is on Proxy Mobile IPv6 protocol, and is a product of DMM WG, we tend to think the reviews from the WG are sufficient. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document describes a useful extension and is well-written. We do not have any concerns forwarding this document to IESG for reviews. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The following IPR disclosures were made against this document. https://datatracker.ietf.org/ipr/3477/ https://datatracker.ietf.org/ipr/3478/ https://datatracker.ietf.org/ipr/1724/ WG is aware of this disclosure, but no one in the WG has expressed any concerns. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is rough consensus behind this document and no objections have been raised. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no issues reported by the tool. All the reported issues have been addressed in the prior versions. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document defines some new flags to the Proxy Mobile IPv6 defined PBU and PBA messages. The impacted registries and the actions are identified in the IANA section of the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new registries defined. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language. |
2019-11-02
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-11-02
|
05 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-05.txt |
2019-11-02
|
05 | (System) | New version approved |
2019-11-02
|
05 | (System) | Request for posting confirmation emailed to previous authors: Fabio Giust , Carlos Bernardos , Alain Mourad , Juan Zuniga , Antonio de la Oliva |
2019-11-02
|
05 | Carlos Jesús Bernardos | Uploaded new revision |
2019-10-25
|
04 | Suresh Krishnan | Expecting an updated shepherd writeup. |
2019-10-25
|
04 | Suresh Krishnan | IESG state changed to Waiting for Writeup::External Party from Waiting for Writeup::Point Raised - writeup needed |
2019-10-25
|
04 | Suresh Krishnan | Expecting an updated shepherd writeup. |
2019-10-25
|
04 | Suresh Krishnan | IESG state changed to Waiting for Writeup::Point Raised - writeup needed from Waiting for Writeup |
2019-10-21
|
04 | Vincent Roca | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Vincent Roca. Sent review to list. |
2019-10-18
|
04 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Zitao Wang was marked no-response |
2019-10-18
|
04 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Zitao Wang was marked no-response |
2019-10-14
|
04 | Joerg Ott | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Joerg Ott. Sent review to list. |
2019-10-14
|
04 | Ines Robles | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list. |
2019-10-14
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-10-09
|
04 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-10-09
|
04 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dmm-pmipv6-dlif-04. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dmm-pmipv6-dlif-04. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Mobility Options registry on the Mobile IPv6 parameters registry page located at: https://www.iana.org/assignments/mobility-parameters/ six, new mobility options are to be registered as follows: Value: [ TBD-at-Registration ] Description: Anchored Prefix Option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Local Prefix Option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Previous MAAR Option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: Serving MAAR Option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: DLIF Link-local Address Option Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: DLIF Link-layer Address Option Reference: [ RFC-to-be ] The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-10-04
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2019-10-04
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2019-10-03
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2019-10-03
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2019-10-02
|
04 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Joerg Ott |
2019-10-02
|
04 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Joerg Ott |
2019-10-02
|
04 | Gorry Fairhurst | Assignment of request for Last Call review by TSVART to Gorry Fairhurst was rejected |
2019-10-01
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
2019-10-01
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
2019-10-01
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
2019-10-01
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
2019-10-01
|
04 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Gorry Fairhurst |
2019-10-01
|
04 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Gorry Fairhurst |
2019-09-30
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-09-30
|
04 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-10-14): From: The IESG To: IETF-Announce CC: draft-ietf-dmm-pmipv6-dlif@ietf.org, max.ldp@alibaba-inc.com, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng … The following Last Call announcement was sent out (ends 2019-10-14): From: The IESG To: IETF-Announce CC: draft-ietf-dmm-pmipv6-dlif@ietf.org, max.ldp@alibaba-inc.com, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , suresh@kaloom.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Proxy Mobile IPv6 extensions for Distributed Mobility Management) to Experimental RFC The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'Proxy Mobile IPv6 extensions for Distributed Mobility Management' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as a local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1724/ https://datatracker.ietf.org/ipr/3477/ https://datatracker.ietf.org/ipr/3478/ |
2019-09-30
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-09-30
|
04 | Amy Vezza | Last call announcement was changed |
2019-09-29
|
04 | Suresh Krishnan | Last call was requested |
2019-09-29
|
04 | Suresh Krishnan | Ballot approval text was generated |
2019-09-29
|
04 | Suresh Krishnan | Ballot writeup was generated |
2019-09-29
|
04 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2019-09-29
|
04 | Suresh Krishnan | Last call announcement was generated |
2019-06-12
|
04 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2019-04-20
|
04 | Sri Gundavelli | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 1) The type of RFC being requested is Experimental. 2) This document describes experimental solution of proxy mobile IP extensions to support distributed mobility management. 3) The type of RFC is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines proxy mobile IP extension to support distributed mobility management. Working Group Summary This document has been reviewed and agreed by the working group. Document Quality The solution describes in this document has been implemented by DEMOs. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Dapeng(Max) Liu Responsible Area Director: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This document specifies proxy mobile IP extension to support distributed mobility management. This version of the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is 3 IPR disclosure references to this document: https://datatracker.ietf.org/ipr/3030/ Working group discussion and conclusion: [TBD] (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has reached consensus in the working group and there is no objection to move forward. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Idnits has been checked, issues found has been solved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document defines new mobility options for proxy mobile IP that require IANA to have new registry and those request have been described in the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language. |
2019-04-20
|
04 | Sri Gundavelli | Responsible AD changed to Suresh Krishnan |
2019-04-20
|
04 | Sri Gundavelli | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-04-20
|
04 | Sri Gundavelli | IESG state changed to Publication Requested from I-D Exists |
2019-04-20
|
04 | Sri Gundavelli | IESG process started in state Publication Requested |
2019-04-20
|
04 | Sri Gundavelli | Intended Status changed to Experimental from None |
2019-04-19
|
04 | Sri Gundavelli | Chair review pending |
2019-04-19
|
04 | Sri Gundavelli | Tag Other - see Comment Log set. |
2019-04-19
|
04 | Sri Gundavelli | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2019-04-19
|
04 | Sri Gundavelli | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 1) The type of RFC being requested is Experimental. 2) This document describes experimental solution of proxy mobile IP extensions to support distributed mobility management. 3) The type of RFC is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines proxy mobile IP extension to support distributed mobility management. Working Group Summary This document has been reviewed and agreed by the working group. Document Quality The solution describes in this document has been implemented by DEMOs. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Dapeng(Max) Liu Responsible Area Director: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This document specifies proxy mobile IP extension to support distributed mobility management. This version of the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is 3 IPR disclosure references to this document: https://datatracker.ietf.org/ipr/3030/ Working group discussion and conclusion: [TBD] (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has reached consensus in the working group and there is no objection to move forward. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Idnits has been checked, issues found has been solved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document defines new mobility options for proxy mobile IP that require IANA to have new registry and those request have been described in the document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language. |
2019-03-24
|
04 | Dapeng Liu | Notification list changed to Dapeng Liu <max.ldp@alibaba-inc.com> |
2019-03-24
|
04 | Dapeng Liu | Document shepherd changed to Dapeng Liu |
2019-03-18
|
Jenny Bui | Posted related IPR disclosure: InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-dmm-pmipv6-dlif | |
2019-03-18
|
Jenny Bui | Posted related IPR disclosure: InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-dmm-pmipv6-dlif | |
2019-01-29
|
04 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-04.txt |
2019-01-29
|
04 | (System) | New version approved |
2019-01-29
|
04 | (System) | Request for posting confirmation emailed to previous authors: Fabio Giust , Carlos Bernardos , Alain Mourad , Juan Zuniga , Antonio de la Oliva |
2019-01-29
|
04 | Carlos Jesús Bernardos | Uploaded new revision |
2018-10-20
|
03 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-03.txt |
2018-10-20
|
03 | (System) | New version approved |
2018-10-20
|
03 | (System) | Request for posting confirmation emailed to previous authors: Fabio Giust , Carlos Bernardos , Alain Mourad , Juan Zuniga , Antonio de la Oliva |
2018-10-20
|
03 | Carlos Jesús Bernardos | Uploaded new revision |
2018-08-29
|
02 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-02.txt |
2018-08-29
|
02 | (System) | New version approved |
2018-08-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Antonio de la Oliva , Carlos Bernardos , Fabio Giust , dmm-chairs@ietf.org, Alain Mourad , Juan … Request for posting confirmation emailed to previous authors: Antonio de la Oliva , Carlos Bernardos , Fabio Giust , dmm-chairs@ietf.org, Alain Mourad , Juan Zuniga |
2018-08-29
|
02 | Carlos Jesús Bernardos | Uploaded new revision |
2018-06-29
|
01 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-01.txt |
2018-06-29
|
01 | (System) | New version approved |
2018-06-29
|
01 | (System) | Request for posting confirmation emailed to previous authors: Fabio Giust , Carlos Bernardos , Alain Mourad , Juan Zuniga , Antonio de la Oliva |
2018-06-29
|
01 | Carlos Jesús Bernardos | Uploaded new revision |
2018-04-19
|
00 | Sri Gundavelli | 2. Advertising proxy3. Discussion of issues arising with SRP ReplicationClose for refreshment breakSession …2. Advertising proxy3. Discussion of issues arising with SRP ReplicationClose for refreshment breakSession 2 agenda: the second hourThursday July 27, 17:00-18:00 local time, or in UTC Friday 00:00-01:30 WelcomeVery short admin, as most people will have been in the previous session.
Not yet adopted1. Preventing friendly conflicts: TSR, and possible update to Multicast DNS2. Future work options around DNSSD infrastructure3. Thoughts on multicast stream discovery
|
2018-04-19
|
00 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-pmipv6-dlif-00.txt |
2018-04-19
|
00 | (System) | WG -00 approved |
2018-04-18
|
00 | Carlos Jesús Bernardos | Set submitter to ""Carlos J. Bernardos" ", replaces to draft-bernardos-dmm-pmipv6-dlif and sent approval email to group chairs: dmm-chairs@ietf.org |
2018-04-18
|
00 | Carlos Jesús Bernardos | Uploaded new revision |