Last Call Review of draft-ietf-dmm-mag-multihoming-03

Request Review of draft-ietf-dmm-mag-multihoming
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-06-16
Requested 2017-06-02
Other Reviews Intdir Early review of -02 by Sheng Jiang (diff)
Secdir Last Call review of -03 by Hilarie Orman (diff)
Genart Telechat review of -04 by Robert Sparks (diff)
Review State Completed
Reviewer Robert Sparks
Review review-ietf-dmm-mag-multihoming-03-genart-lc-sparks-2017-06-14
Posted at
Reviewed rev. 03 (document currently at 07)
Review result Not Ready
Draft last updated 2017-06-14
Review completed: 2017-06-14


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


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 and 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'

    - "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


* 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
* Consider using RFC8174 instead of RFC2119