Hi Brian, Thank you.
Congxiao > -----原始邮件----- > 发件人: "Brian E Carpenter" <[email protected]> > 发送时间: 2014年10月3日 星期五 > 收件人: "包丛笑" <[email protected]> > 抄送: "Suresh Krishnan" <[email protected]>, > "[email protected]" > <[email protected]>, [email protected] > 主题: Re: Fwd: [Gen-art] Gen-ART Last Call review of > draft-ietf-softwire-map-dhcp-08 > > Hi Congxiao, > > Thankyou for the replies. I think all those changes are good (just > have someone check the English). > > For the references it is your choice. Ted did not agree with me! > > Regards > Brian > > On 03/10/2014 15:46, 包丛笑 wrote: > > 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
