Hi Med, > On Feb 1, 2017, at 7:26 AM, [email protected] wrote: > > Hi Suresh, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Suresh Krishnan [mailto:[email protected] >> <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? Will the mechanism in the draft still work? Can such a server interoperate with a client that expects the server to follow these guidelines? Thanks Suresh
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
