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). 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. Nits: * How are Preference Settings either a goal or a benefit? It seems out of place in the list. * at "leverage on latest" do you mean "leverage the latest"? * 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. * Something is missing at "and either based on" in the security considerations section. * Consider using RFC8174 instead of RFC2119 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
