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
