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

[Paul Kyzivat <[e-mail]>]

Med,

Thanks. Those changes seem fine.

	Paul

On 8/23/16 3:47 AM, [e-mail] wrote:
> 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
>