Looks good for me, thanks. Sheng > -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxx > [mailto:mohamed.boucadair@xxxxxxxxxx] > Sent: Tuesday, January 10, 2017 3:17 PM > To: Sheng Jiang; ops-dir@xxxxxxxx > Cc: softwires@xxxxxxxx; ietf@xxxxxxxx; > draft-ietf-softwire-multicast-prefix-option.all@xxxxxxxx > Subject: RE: Review of draft-ietf-softwire-multicast-prefix-option-11 > > Re-, > > OK, thanks. > > If you prefer one sentence, then I can reword it to: > > Such side effect conflicts with the recommendation to support the > Well-Known DNS Name heuristic discovery-based method for unicast-only > environments (Section 6 of [RFC7051]). > > Cheers, > Med > > > -----Message d'origine----- > > De : Sheng Jiang [mailto:jiangsheng@xxxxxxxxxx] Envoyé : mardi 10 > > janvier 2017 07:48 À : BOUCADAIR Mohamed IMT/OLN; ops-dir@xxxxxxxx > Cc > > : softwires@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-softwire-multicast- > > prefix-option.all@xxxxxxxx Objet : RE: Review of > > draft-ietf-softwire-multicast-prefix-option-11 > > > > Hi, Med, > > > > Thanks for reply. The content looks clear now. Reword into one sentence. > > > > Such side effect conflicts with the recommendation documented in > > Section 6 of [RFC7051], in which > > ^^^^^^^ > > to support the Well-Known DNS Name heuristic discovery-based > > method > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > for unicast-only environments is recommended. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Cheers, > > > > Sheng > > > > > -----Original Message----- > > > From: mohamed.boucadair@xxxxxxxxxx > > > [mailto:mohamed.boucadair@xxxxxxxxxx] > > > Sent: Tuesday, January 10, 2017 2:44 PM > > > To: Sheng Jiang; ops-dir@xxxxxxxx > > > Cc: softwires@xxxxxxxx; ietf@xxxxxxxx; > > > draft-ietf-softwire-multicast-prefix-option.all@xxxxxxxx > > > Subject: RE: Review of > > > draft-ietf-softwire-multicast-prefix-option-11 > > > > > > Hi Sheng, > > > > > > Thank you for the review. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Sheng Jiang [mailto:jiangsheng@xxxxxxxxxx] Envoyé : mardi 10 > > > > janvier 2017 04:55 À : ops-dir@xxxxxxxx Cc : softwires@xxxxxxxx; > > > > ietf@xxxxxxxx; draft-ietf-softwire-multicast- > > > > prefix-option.all@xxxxxxxx Objet : Review of > > > > draft-ietf-softwire-multicast-prefix-option-11 > > > > > > > > Reviewer: Sheng Jiang > > > > Review result: Has Nits > > > > > > > > Summary: This draft is almost ready for publication as a standard > > > > track RFC. > > > > > > > > Major issues: > > > > > > > > Minor issues: > > > > > > > > “the specification of a DHCPv6 option that could be used to discover > > > > unicast PREFIX64s in environments where multicast is not enabled. > > > > Such side effect conflicts with the recommendation documented in > > > > Section 6 of [RFC7051].” > > > > > > > > It is unclear how the Section 6 of RFC7051 relevant with the > > > > content above. It would be necessary to quote particular content > > > > of RFC7051 and give necessary analysis. > > > > > > > > > > [Med] What about: > > > > > > OLD: > > > > > > Note that it was tempting to define three distinct DHCPv6 options, > > > but that approach was not adopted because it has a side effect: the > > > specification of a DHCPv6 option that could be used to discover > > > unicast PREFIX64s in environments where multicast is not enabled. > > > Such side effect conflicts with the recommendation documented in > > > Section 6 of [RFC7051]. > > > > > > NEW: > > > Note that it was tempting to define three distinct DHCPv6 options, > > > but that approach was not adopted because it has a side effect: the > > > specification of a DHCPv6 option that could be used to discover > > > unicast PREFIX64s in environments where multicast is not enabled. > > > Such side effect conflicts with the recommendation documented in > > > Section 6 of [RFC7051]. As a reminder, that recommendation is to > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > to support the Well-Known DNS Name heuristic discovery-based > > > method > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > ^^ > > > for unicast-only environments. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > Better? > > > > > > > Nits: > > > > > > > > “the Pv4 multicast address is inserted in the last 32 bits of the > > > > IPv4-embedded IPv6 > > > > multicast address.” > > > > > > > > Pv4//IPv4 > > > [Med] Fixed. > > >