Hello, Thanks for the review; please find below clarifications and answers. We will update the document accordingly. Regards, > -----Message d'origine----- > De : Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] > Envoyé : mercredi 14 juin 2017 21:26 > À : gen-art@xxxxxxxx > Cc : ietf@xxxxxxxx; dmm@xxxxxxxx; draft-ietf-dmm-mag-multihoming.all@xxxxxxxx > Objet : Genart last call review of draft-ietf-dmm-mag-multihoming-03 > > Reviewer: Robert Sparks > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area Review Team > (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF > Chair. Please treat these comments just like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dmm-mag-multihoming-03 > Reviewer: Robert Sparks > Review Date: 2017-06-14 > IETF LC End Date: 2017-06-16 > IESG Telechat date: Not scheduled for a telechat > > Summary: Not Ready > > This document has several issues that need to be addressed before publication as > a proposed standard. > > 1) The document defines some wire syntax, but does not define (or refine) the > protocol for using these bits of wire syntax. For instance, the document does not > discuss if/when the MAG Identifier Option is necessary. It does not discuss when > the new error code it defines should be sent, nor what a recipient should do if it > receives that error code (I would have expected discussion similar to some of the > paragraphs in sections 5.4.1.2 and 6.9.1.2 of RFC5213). > > For instance, the document does not discuss if/when the MAG Identifier Option is necessary. The following text covers that aspect: "The MAG Multipath-Binding option is a new mobility header option defined for use with Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between the local mobility anchor and the mobile access gateway. This mobility header option is used for requesting multipath support. It indicates that the mobile access gateway is requesting the local mobility anchor to register the current care-of address associated with the request as one of the many care-addresses through which the mobile access gateway can be reached. It is also for carrying the information related to the access network associated with the care-of The MAG Multipath-Binding option has an alignment requirement of 8n+2. Its format is as shown in Figure 3:” > It does not discuss when the new error code it defines should be sent, nor what a recipient should do if it receives that error code (I would have expected discussion similar to some of the paragraphs in sections 5.4.1.2 and 6.9.1.2 of RFC5213). Reasons for the LMA to send error code are as follows - The LMA does not support multiple care-of-address registration - a binding entry with the requested Care-of-address already exist We will clarify this point and expecting MAG behavior as well. > 2) There are sentence fragments that indicate information was lost at some point in > editing. > > - "In the continuation of c, a Proxy" : what should have been where the 'c' > is? > > - "or at When operating" : This looks a clause (and the end of a sentence) > was lost after 'or at'. 'When operating' is clearly starting a new > sentence. > > >From version1: In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based multi homed achitecture could be defined. We can delete this sentence as the next sentence covers this point. > Nits: > > * How are Preference Settings either a goal or a benefit? It seems out of > place in the list. > One may prefer one access network over other. Example: Use Wi-Fi when its available and do not use LTE. One can extend this further and provide preference settings that allow Voice traffic to go only over LTE. > * at "leverage on latest" do you mean "leverage the latest"? > OLD: The motivation to update [RFC4908] with proxy Mobile IPv6 is to leverage on latest mobility working group achievements, namely: NEW: The motivation for this work is to extend Proxy Mobile IPv6 protocol with multihoming extensions [RFC4908] and realize the following capabilities: > * at "allowing to make appropriate traffic steering decision", _what_ are you > allowing to make a decision (who is the actor)? > > * 'For example, the operator may have policy which binds traffic for > Application "X" needs to interface with Label "Y".' does not make sense. > Is the word "needs" extraneous? > > * The last sentence in the definition of the Binding-Identifier appears to be > describing the Interface Label. > Interface label is a descriptive string. Binding identifier is an identifier for the binding. Each Binding is tied to an interface on the MAG. This 8-bit field is used for carrying the binding identifier. It uniquely identifies a specific binding of the mobile node, to which this request can be associated. Each binding identifier is represented as an unsigned integer. The permitted values are 1 through 254. The BID value of 0 and 255 are reserved. The mobile access gateway assigns a unique value for each of its interfaces and includes them in the message. > * Something is missing at "and either based on" in the security considerations > section. > OLD: This essentially allows the mobile node's IP traffic to be routed through any of the tunnel paths and either based on a static or a dynamically negotiated flow policy. NEW: This essentially allows the mobile node's IP traffic to be routed through any of the tunnel paths, based on a static or a dynamically negotiated flow policy. > * Consider using RFC8174 instead of RFC2119 > OK _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.