Hi Les, Roman, On 7/14/20, 7:15 AM, "Roman Danyliw" <r...@cert.org> wrote:
Hi Les and Acee! > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Sent: Monday, July 13, 2020 11:43 PM > To: Acee Lindem (acee) <a...@cisco.com>; Roman Danyliw <r...@cert.org>; > The IESG <i...@ietf.org> > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft- > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > Subject: RE: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv- > 02: (with COMMENT) > > Roman (and Acee) - > > After a suggestion from Ben, I have reworded the sentence to read: > > " When new protocol behaviors are specified that are not backwards > compatible, it is RECOMMENDED that implementations provide controls > for their enablement. This serves to prevent interoperability issues > and allow for non-disruptive introduction of the new functionality > into an existing network." > > Let me know if this resolves the concerns. I appreciate the quick response. No need to further debate the definition of "controls". The proposal above resolves my concerns. Thank you! This works for me. Thanks, Acee Regards, Roman > Les > > > > -----Original Message----- > > From: Acee Lindem (acee) <a...@cisco.com> > > Sent: Monday, July 13, 2020 9:38 AM > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Roman Danyliw > > <r...@cert.org>; The IESG <i...@ietf.org> > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; > > draft- ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > Subject: Re: [Lsr] Roman Danyliw's No Objection on > > draft-ietf-lsr-isis-invalid- > > tlv-02: (with COMMENT) > > > > > > > > On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> > > wrote: > > > > Acee - > > > > Inline. > > > > > -----Original Message----- > > > From: Acee Lindem (acee) <a...@cisco.com> > > > Sent: Monday, July 13, 2020 9:04 AM > > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Roman Danyliw > > > <r...@cert.org>; The IESG <i...@ietf.org> > > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; > > cho...@chopps.org; > > draft- > > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > > Subject: Re: [Lsr] Roman Danyliw's No Objection on > > draft-ietf-lsr-isis- > > invalid- > > > tlv-02: (with COMMENT) > > > > > > Hi Les, > > > > > > On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> > > > wrote: > > > > > > Roman - > > > > > > Thanx for the review. > > > Inline. > > > > > > > -----Original Message----- > > > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Roman Danyliw via > > > > Datatracker > > > > Sent: Monday, July 13, 2020 7:40 AM > > > > To: The IESG <i...@ietf.org> > > > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; > cho...@chopps.org; > > > draft- > > > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > > > Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis- > > invalid- > > > tlv- > > > > 02: (with COMMENT) > > > > > > > > Roman Danyliw has entered the following ballot position for > > > > draft-ietf-lsr-isis-invalid-tlv-02: No Objection > > > > > > > > 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-lsr-isis-invalid-tlv/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > I'm glad to see language clarifying error handling. Thanks for the > work > > on > > > it. > > > > > > > > Section 3.2. Per “It is RECOMMENDED that implementations provide > > > controls > > > > for > > > > the enablement of behaviors that are not backward compatible”, I > > want > > > to > > > > double > > > > check that I’m understanding this sentence correctly. RFC5304 > > provides > > > > normative guidance that isn’t backward compatible with ISO10589. > > > RFC6233 > > > > provide guidance that isn’t backward compatible with either > RFC5304 > > or > > > > ISO10589. Is the initial sentence effectively saying that > > implementations > > > > should support deployments in configurations that are not backward > > > > compatible > > > > (i.e., those using the newer TLVs)? As these changes are covering > > > security > > > > matters, I read “controls” in the cyber mitigation sense -- they > > prevent an > > > > action, not enable one. > > > > > > [Les:] The recommendation is for implementations to provide control > > as to > > > when the new (non-backwards compatible) behavior is used. > > > Without that, an implementation which adds support for (to use one > > > example) sending the Purge Originator TLV in the presence of MD5 > > > authentication would simply start sending it and risk the PDU not being > > > accepted by implementations which had not yet added the support. > > > > > > One way of reading this is that "including the POI TLV in purges w MD5 > > > authentication" is "enablement" of a new feature. Another way of > > reading it > > > might be "disablement" of the use of a new feature. > > > This seems to me to be a semantical distinction. > > > > > > The recommendation to use "controls" also does not specify what the > > > default behavior should be - that is up to the implementation. > > > > > > Since there was some confusion, maybe "configurable specification" > > would > > > be clearer than "controls". > > > > > [Les:] I will certainly wait for Roman's input, but to me the term "controls" > > means there is a way to control whether a particular behavior is > > used/not used. (An "on/off" switch comes to mind.) > > Frankly, I don’t know what the term "configuration specification" means. > > Maybe if I worked with YANG more I would know. 😊 > > > > But I suggested "configurable specification"... I think this is clear > > and more formal than "configuration knob". > > > > Thanks, > > Acee > > > > I am open to an alternate term if there really is confusion - but > > for me you haven't added clarity with your suggestion. > > > > Les > > > > > Thanks, > > > Acee > > > > > > Les > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Lsr mailing list > > > > Lsr@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr