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 <pkyzi...@alum.mit.edu> wrote: > Med, > > Thanks. Those changes seem fine. > > Paul > > On 8/23/16 3:47 AM, mohamed.boucad...@orange.com wrote: >> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
