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
