RE: Review of draft-ietf-softwire-multicast-prefix-option-11

[Sheng Jiang <[e-mail]>]

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: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, January 10, 2017 2:44 PM
> To: Sheng Jiang; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]] Envoyé : mardi 10
> > janvier 2017 04:55 À : [e-mail] Cc : [e-mail];
> > [e-mail]; draft-ietf-softwire-multicast-
> > [e-mail] 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.
>