Subject: Re: [Softwires] RtgDir review: draft-ietf-softwire-unified-cpe-04
From: <[email-masked]>
To: John Scudder <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 23 Aug 2016 07:47:15 +0000
List-Id: softwires wg discussion list <softwires.ietf.org>

Dear John,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : John Scudder [mailto:[email-masked]]
> Envoyé : mardi 16 août 2016 17:22
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]
> 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.