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. 😊 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
