Skip to main content

Last Call Review of draft-ietf-dmm-mag-multihoming-03
review-ietf-dmm-mag-multihoming-03-genart-lc-sparks-2017-06-14-00

Request Review of draft-ietf-dmm-mag-multihoming
Requested revision 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
Authors Pierrick Seite , Alper E. Yegin , Sri Gundavelli
I-D last updated 2017-06-14
Completed reviews Intdir Early review of -02 by Sheng Jiang (diff)
Genart Last Call review of -03 by Robert Sparks (diff)
Secdir Last Call review of -03 by Hilarie Orman (diff)
Genart Telechat review of -04 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-dmm-mag-multihoming by General Area Review Team (Gen-ART) Assigned
Reviewed revision 03 (document currently at 07)
Result Not ready
Completed 2017-06-14
review-ietf-dmm-mag-multihoming-03-genart-lc-sparks-2017-06-14-00
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