Thanks Med,
No more comments
Roni
-----Original Message-----
From: mohamed(_dot_)boucadair(_at_)orange(_dot_)com
[mailto:mohamed(_dot_)boucadair(_at_)orange(_dot_)com]
Sent: יום ב 09 ינואר 2017 14:24
To: Roni Even; Roni Even; gen-art(_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: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-option-
11
Re-,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Roni Even [mailto:roni(_dot_)even(_at_)huawei(_dot_)com] Envoyé :
lundi 9 janvier
2017 11:36 À : BOUCADAIR Mohamed IMT/OLN; Roni Even; gen-
art(_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: [Gen-art] Review of
draft-ietf-softwire-multicast-prefix-
option-11
Hi Med,
Inline
Roni
-----Original Message-----
From: Gen-art [mailto:gen-art-bounces(_at_)ietf(_dot_)org] On Behalf Of
mohamed(_dot_)boucadair(_at_)orange(_dot_)com
Sent: יום ב 09 ינואר 2017 09:43
To: Roni Even; gen-art(_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: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-
option-11
Dear Roni,
Thank you for the review.
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Roni Even [mailto:roni(_dot_)even(_at_)mail01(_dot_)huawei(_dot_)com]
Envoyé : lundi 9 janvier 2017 07:52
À : gen-art(_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: Roni Even
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call
comments you may receive.
Document: draft-ietf-softwire-multicast-prefix-option-11
Reviewer: Roni Even
Review Date:2017-1-9
IETF LC End Date: 2017–1-12
IESG Telechat date:
Summary: This draft is almost ready for publication as a standard
track RFC.
Major issues:
Minor issues:
1. In section 4 first paragraph say “DHCP servers supporting
OPTION_V6_PREFIX64 should be configured with U_PREFIX64 and at
least
one multicast PREFIX64 (i.e., ASM_PREFIX64 and/or SSM_PREFIX64).”
From the rest of the section I understand that for SSM deployments
both
U_PREFIX64 and SSM_PREFIX64 MUST be configured.
[Med] Yes. If you prefer, I can change the text to make this more clear:
OLD:
DHCP servers supporting OPTION_V6_PREFIX64 should be configured with
U_PREFIX64 and at least one multicast PREFIX64 (i.e., ASM_PREFIX64
and/or SSM_PREFIX64).
NEW:
DHCP servers supporting OPTION_V6_PREFIX64 must be configured with
ASM_PREFIX64 or SSM_PREFIX64, and may be configured with both.
U_PREFIX64 must also be configured when SSM_PREFIX64 is provided.
U_PREFIX64 may be configured when only ASM_PREFIX64 is provided.
Roni: OK
[Med] I implemented the change in my local copy.
What is the reason for “should” in the first paragraph? Are there
cases where ASM_PREFIX64 or ASM_PREFIX64 and SSM_PREFIX64 are
specified and there is no need to specify U_PREFIX64, maybe these
cases should be described.
[Med] The presence of the unicast address is mandatory for the SSM
case because it is required to form an IPv6 address from an IPv4
address to subscribe to a multicast content from a particular source.
For the ASM case, the configuration of the U_PREFIX64 is not mandatory
in the following cases: (1) a local mapping algorithm is enabled by
the function that grafts the IPv4 multicast host side with an IPv6
multicast tree or
(2) in deployments that make use of the WKP (64:ff9b::/96, RFC6052).
I can add this NEW text:
Note that U_PREFIX64 is not mandatory for the ASM case if, for
example, a local address mapping algorithm is supported or the Well-
Know Prefix (64:ff9b::/96) is used.
Roni:OK
[Med] I made the change in my local copy.
Nits/editorial comments:
1. RFC2119 keywords in the document are sometime capitalized and
sometime not. I think it will be good to have consistency and if
they do not intend to have RFC2119 semantics some other words should
be used
[Med] I guess you are referring to Section 4. We are not using
normative language on purpose because of previous comments we
received
from some DHC experts (T. Lemon). The use of normative text for the
server behavior would mean that we are updating RFC 3315, which we do
not want to do. This is why we are defining this section as configuration
guidelines.
Roni: maybe add to section 4 text saying that this section is not
normative and serves as guidelines, since this is a standard track
document and usage of RFC2119 keywords may be confusing
[Med] Works for me. I added this NEW text to Section 4:
"This section is not normative but specifies a set of configuration
guidelines."
_______________________________________________
Gen-art mailing list
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art