Dear Paul, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] > Envoyé : mardi 23 août 2016 00:15 > À : draft-ietf-softwire-unified-cpe....@ietf.org > 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
