Re: [Softwires] Review of draft-ietf-softwire-multicast-prefix-option-11

[Sheng Jiang <[e-mail]>]

Looks good for me, thanks. Sheng

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, January 10, 2017 3:17 PM
> To: Sheng Jiang; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]] Envoyé : mardi 10
> > janvier 2017 07:48 À : BOUCADAIR Mohamed IMT/OLN; [e-mail]
> Cc
> > : [e-mail]; [e-mail]; draft-ietf-softwire-multicast-
> > [e-mail] 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: [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.
> > >