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

[<[e-mail]>]

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