Dear John, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : John Scudder [mailto:[email protected]] > Envoyé : mardi 16 août 2016 17:22 > À : [email protected] > Cc : [email protected]; [email protected]; > [email protected] > Objet : RtgDir review: draft-ietf-softwire-unified-cpe-04 > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, > please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-softwire-unified-cpe-04 > Reviewer: John Scudder > Review Date: August 16, 2016 > IETF LC End Date: August 25, 2016 > Intended Status: Standards Track > > Summary: > > • This document is basically ready for publication, but has nits that > should be considered prior to publication. > > > Comments: > > The draft is well-written, clear, readable and concise without being > terse. As a nonexpert, I felt it provided sufficient explanation and > context for me to understand without having to spend a great deal of time > chasing references. > [Med] Thank you. > > Major Issues: > > No major issues found. > > > Minor Issues: > > Section 1.3 says: > > 4. When a match is found, the client SHOULD configure the resulting > S46 mechanism. Configuration for other S46 mechanisms MUST be > discarded. > > It was not obvious to me why the SHOULD is not a MUST. Under what > circumstances would it be valid for an implementer to disregard the > SHOULD? I find it is often a helpful exercise to explain such exceptions > in a MAY clause. If there are no exceptions, then it's a MUST. > [Med] It seems that you have a point here. > > Nits: > > - You use the term "BR/AFTR" but don't define what BR means. A definition > would help. (AFTR is defined in section 1.) > [Med] Fixed. > - Likewise you haven't defined "CE". It's a pretty common term, but I > would think it still needs a definition, or better still you could rewrite > to remove the acronym (you only use it once). [Med] Fixed. > > - Likewise "DHCPv6 ORO message". It's reasonably obvious from context, and > not difficult to look up, but would still benefit from being expanded in > line instead of using the acronym. [Med] Fixed. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
