Hi, My answers are in the lines:
> -----原始邮件----- > 发件人: "Suresh Krishnan" <[email protected]> > 发送时间: 2014年10月1日 星期三 > 收件人: "[email protected]" > <[email protected]> > 抄送: > 主题: Fwd: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08 > > Hi Folks, > Please take a look at this review and respond. Ted already responded > partially to the review. Continue with a response to the open points. > > Thanks > Suresh > > -------- Forwarded Message -------- > Subject: [Gen-art] Gen-ART Last Call review of > draft-ietf-softwire-map-dhcp-08 > Date: Mon, 29 Sep 2014 14:00:34 +1300 > From: Brian E Carpenter <[email protected]> > Organization: University of Auckland > To: [email protected], General Area Review > Team <[email protected]> > > 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. Agree to list [I-D.ietf-softwire-map], [I-D.ietf-softwire-map-t] and [I-D.ietf-softwire-lw4over6] as normative references. > In section 4.1: > > > Clients MUST NOT send an OPTION_S46_RULE option. > > What happens if they do? We may add a sentence states that “It is an invalid option, if received by server, discard.” > > > 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. Suggest add a sentence states that “For the mesh scenario, set the Fflag (It means that BMR is also FMR). For the hubs&spokes scenario, do not set the Fflag (It means that there is no FMR).” > > Also, in the last sentence, is that an exact match or a longest match? It is the exact match to get the EA-bits. Refer to “Figure 3: MAP IPv6 Address Format” in [I-D.ietf-softwire-map]. > 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. Agree to unify the terminology. We may add a “Terminology section” similar to the ones in [I-D.ietf-softwire-map] (Section 3). Regards Congxiao > 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
