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. Les > -----Original Message----- > From: Acee Lindem (acee) <[email protected]> > Sent: Monday, July 13, 2020 9:38 AM > To: Les Ginsberg (ginsberg) <[email protected]>; Roman Danyliw > <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; draft- > [email protected]; [email protected] > 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)" <[email protected]> > wrote: > > Acee - > > Inline. > > > -----Original Message----- > > From: Acee Lindem (acee) <[email protected]> > > Sent: Monday, July 13, 2020 9:04 AM > > To: Les Ginsberg (ginsberg) <[email protected]>; Roman Danyliw > > <[email protected]>; The IESG <[email protected]> > > Cc: [email protected]; [email protected]; [email protected]; > draft- > > [email protected]; [email protected] > > 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)" <[email protected]> > > wrote: > > > > Roman - > > > > Thanx for the review. > > Inline. > > > > > -----Original Message----- > > > From: Lsr <[email protected]> On Behalf Of Roman Danyliw via > > > Datatracker > > > Sent: Monday, July 13, 2020 7:40 AM > > > To: The IESG <[email protected]> > > > Cc: [email protected]; [email protected]; > [email protected]; > > draft- > > > [email protected]; [email protected] > > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
