Thanks Med, No more comments Roni > -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxx > [mailto:mohamed.boucadair@xxxxxxxxxx] > Sent: יום ב 09 ינואר 2017 14:24 > To: Roni Even; Roni Even; gen-art@xxxxxxxx > Cc: softwires@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-softwire-multicast-prefix- > option.all@xxxxxxxx > 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.even@xxxxxxxxxx] Envoyé : lundi 9 janvier > > 2017 11:36 À : BOUCADAIR Mohamed IMT/OLN; Roni Even; gen- > art@xxxxxxxx > > Cc : softwires@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-softwire-multicast- > > prefix-option.all@xxxxxxxx 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@xxxxxxxx] On Behalf Of > > mohamed.boucadair@xxxxxxxxxx > > Sent: יום ב 09 ינואר 2017 09:43 > > To: Roni Even; gen-art@xxxxxxxx > > Cc: softwires@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-softwire-multicast- > > prefix-option.all@xxxxxxxx > > 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.even@xxxxxxxxxxxxxxxxx] > > > Envoyé : lundi 9 janvier 2017 07:52 > > > À : gen-art@xxxxxxxx > > > Cc : softwires@xxxxxxxx; ietf@xxxxxxxx; > > > draft-ietf-softwire-multicast- prefix-option.all@xxxxxxxx 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@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/gen-art