Hi Brian, Thanks for the review. I will follow up with the authors on this. I had a concern about the author list as well and I recorded it in the Shepherd writeup. The number of authors is high because the document is a merge of competing documents and we felt that going with the long author list is a better alternative than sending out separate documents with mostly redundant option definitions. In my reading of RFC7322, it is the IESG's call (as the stream-approving body) to see if this is acceptable? Am I reading it right?
Regards Suresh On 09/28/2014 09:00 PM, Brian E Carpenter wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-softwire-map-dhcp-08.txt > Reviewer: Brian Carpenter > Review Date: 2014-10-29 > IETF LC End Date: 2014-10-10 > IESG Telechat date: > > Summary: On the right track > -------- > > Major Issues: > ------------- > > [I-D.ietf-softwire-map], [I-D.ietf-softwire-map-t] and > [I-D.ietf-softwire-lw4over6] > are listed as Informative references. I find it hard to see how an > implementer can > implement the DHCPv6 options without consulting those documents, so IMHO they > need to be Normative references. > > For example, in section 4.5 we find > >> See [I-D.ietf-softwire-map], Section 5.1 for a description of MAP >> algorithm, explaining all of the parameters in detail. > > I have the same concern for [I-D.ietf-softwire-unified-cpe] when I see > >> [I-D.ietf-softwire-unified-cpe] >> describes client behaviour for the prioritization and handling of >> multiple mechanisms simultaneously. > > I don't see an implementer can develop a generic client without consulting > that > document too. > > In section 4.1: > >> Clients MUST NOT send an OPTION_S46_RULE option. > > What happens if they do? > >> o F-Flag: 1 bit field that specifies whether the rule is to be used >> for forwarding (FMR). If set, this rule is used as a FMR, if not >> set this rule is a BMR. Note: A BMR rule can also be an FMR rule >> by setting the F flag. The BMR rule is determined by a match of >> the Rule-IPv6-prefix against the CPE's prefix(es). > > The logic of the third sentence is so strange that I can't deconstruct it. > Maybe it just means "An FMR can also be used as a BMR." If so, please just say > it. If not, I'm baffled. > > Also, in the last sentence, is that an exact match or a longest match? > > Are the CPE's prefix(es) the one(s) it uses for its own address(es) > or the ones it can delegate to the customer network? > > (I suspect this paragraph is one of the cases that requires the drafts > mentioned above to be normative references. As written, it is virtually > impossible to understand.) > > In section 4.5: > > There are two references to "the softwire node". Does that mean the CE? > In fact, I think you need some scoping text in the Introduction. I assume that > "DHCPv6 client", "CE", "CPE" and "the softwire node" all mean the same thing; > if so, please be consistent on terminology. I also assume that these DHCPv6 > options must only be used by a DHCPv6 client which is also a C(P)E and > a softwire node. It would be nice to know that from the start. > > Minor issues: > ------------- > > To avoid a long discussion with the RFC Editor about the number of authors, > please consider having one author tagged as Editor and the rest as a list of > Contributors, as described in RFC 7322. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
