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.
>