Hi Suresh, Please see inline.
Cheers, Med De : Suresh Krishnan [mailto:[email protected]] Envoyé : jeudi 2 février 2017 15:00 À : BOUCADAIR Mohamed IMT/OLN Cc : The IESG; [email protected]; [email protected]; Ian Farrer; [email protected] Objet : Re: Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix-option-12: (with DISCUSS) Hi Med, On Feb 1, 2017, at 7:26 AM, [email protected]<mailto:[email protected]> wrote: Hi Suresh, Thank you for the review. Please see inline. Cheers, Med -----Message d'origine----- De : Suresh Krishnan [mailto:[email protected]] Envoyé : mercredi 1 février 2017 00:44 À : The IESG Cc : [email protected]<mailto:[email protected]>; softwire- [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Suresh Krishnan's Discuss on draft-ietf-softwire-multicast-prefix- option-12: (with DISCUSS) Suresh Krishnan has entered the following ballot position for draft-ietf-softwire-multicast-prefix-option-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast-prefix- option/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3: How can the ASM_mPrefix64 and SSM_mPrefix64 be (variable) as described in the packet format when the asm-length and the ssm-length MUST be set to 96? Not sure which of these is correct and which is wrong but one of these things (either the fixed length or the variable prefix) needs to be fixed. [Med] The text is correct. The "(variable)" mention in the figure is removed from my local copy. Sounds good. * Section 4: This section contains a bunch of must and may level requirements but contains the following "disclaimer" text. "This section is not normative but specifies a set of configuration guidelines." Not sure what the intent behind this is. Can you clarify? [Med] 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. That reasoning does not help me understand the impacts. What happens when these “guidelines” are not respected by the servers? [Med] If the server does not follow the guidelines, this will be detected by the client and behave accordingly (covered in Section 5). Let’s consider same sample examples: · If the server return an SSM prefix instead of an ASM one, this will be rejected by the IPv4/IPv6 mapping algorithm. · If multiple instance of the option having the same scope are returned to the client, the client will ignore the option. Will the mechanism in the draft still work? [Med] Yes…because the client (and underlying multicast library) is designed to catch these cases. Can such a server interoperate with a client that expects the server to follow these guidelines? [Med] The client DOES NOT expect to always be facing a server that follow the guidelines. The client is designed to cover both cases: “good” servers and badly configured ones. The configuration that is received from a well behaving server will be validated by the client (and underlying multicast library) while mis-configuration will be rejected. Thanks Suresh
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
