Re: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-unified-cpe-04

[<[e-mail]>]

Dear Paul, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Paul Kyzivat [mailto:[e-mail]]
> Envoyé : mardi 23 août 2016 00:15
> À : [e-mail]
> Cc : General Area Review Team
> Objet : Gen-ART Last Call review of draft-ietf-softwire-unified-cpe-04
> 
> 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 wait for direction from your document
> shepherd or AD before posting a new version of the draft. For more
> information, please see the FAQ at <​
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-softwire-unified-cpe-04
> Reviewer: Paul Kyzivat
> Review Date:
> IETF LC End Date: 2016-08-25
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the
> review.
> 
> Issues:
> 
> Major: 0
> Minor: 2
> Nits:  1
> 
> (1) MINOR: Section 1.2:
> 
> This defines the "S46 Priority Option". On first reading I didn't
> realize that this was intended to be a DHCPv6 option. On rereading, I
> found "This document describes a DHCPv6 based prioritisation method",
> which in retrospect does specify this.
> 
> I suggest a few changes to make this clearer to a first-time reader:
> 
> a) Mention it clearly in the abstract:
> 
>     ... this memo specifies a DHCPv6 option whereby ...
> 
> b) Change heading of section 1.2 to "S46 Priority DHCPv6 Option"
> 
> c) Change heading of section 1.4 to "DHCPv6 Server Behavior"
> 

[Med] Fixed. Thank you.

> 
> (2) MINOR: Section 1.3:
> 
> In the following:
> 
>     In the event that the client receives OPTION_V6_S46_PRIORITY with the
>     following errors, it MUST be discarded:
> 
>     o  No s46-option-code field is included.
>     o  Multiple s46-option-code fields with the same value are included.
> 
> This generates an obligation on the client to check whether a value is
> replicated in the list. It should still be possible to use the list in
> this case, so is it really important that the list be discarded rather
> than used?

[Med] The point here is to force the server to correct its configuration so that no duplicate values are returned.

> 
> And if the list is empty then following the procedures (and hence
> finding no match) will produce the same functional result as ignoring
> the option.
> 
> It seems like simply saying nothing about these "errors" would produce
> comparable results while being simpler.
> 
> 
> 3) NIT: Section 1.4:
> 
> Use of terminology "option foo" seems strangely informal here. I suggest
> something like:
> 
>     As a convenience to the reader, we mention here that the server
>     will send a particular option code only if configured with specific
>     values for that option code and if the client requested it.

[Med] Your wording is OK. FWIW, the initial text is from the Guidelines documented in https://tools.ietf.org/html/rfc7227#section-21.2