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

[Jari Arkko <[e-mail]>]

Paul & Med: Thanks for the reviews & fixes. Looks like the changes are in the newest version.

Jari

On 23 Aug 2016, at 17:55, Paul Kyzivat <[e-mail]> wrote:

> 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
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art