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