ietf
[Top] [All Lists]

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

2017-01-10 01:17:47
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(_at_)huawei(_dot_)com]
Envoyé : mardi 10 janvier 2017 07:48
À : BOUCADAIR Mohamed IMT/OLN; ops-dir(_at_)ietf(_dot_)org
Cc : softwires(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
draft-ietf-softwire-multicast-
prefix-option(_dot_)all(_at_)ietf(_dot_)org
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(_dot_)boucadair(_at_)orange(_dot_)com
[mailto:mohamed(_dot_)boucadair(_at_)orange(_dot_)com]
Sent: Tuesday, January 10, 2017 2:44 PM
To: Sheng Jiang; ops-dir(_at_)ietf(_dot_)org
Cc: softwires(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-softwire-multicast-prefix-option(_dot_)all(_at_)ietf(_dot_)org
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(_at_)huawei(_dot_)com] Envoyé : mardi 
10
janvier 2017 04:55 À : ops-dir(_at_)ietf(_dot_)org Cc : 
softwires(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; draft-ietf-softwire-multicast-
prefix-option(_dot_)all(_at_)ietf(_dot_)org 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.