Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

Acee -

Inline.

> -----Original Message-----
> From: Acee Lindem (acee) <acee@cisco.com>
> Sent: Monday, July 13, 2020 9:04 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Roman Danyliw
> <rdd@cert.org>; The IESG <iesg@ietf.org>
> Cc: lsr-chairs@ietf.org; aretana.ietf@gmail.com; chopps@chopps.org; draft-
> ietf-lsr-isis-invalid-tlv@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)" <ginsberg@cisco.com>
> wrote:
> 
>     Roman -
> 
>     Thanx for the review.
>     Inline.
> 
>     > -----Original Message-----
>     > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Roman Danyliw via
>     > Datatracker
>     > Sent: Monday, July 13, 2020 7:40 AM
>     > To: The IESG <iesg@ietf.org>
>     > Cc: lsr-chairs@ietf.org; aretana.ietf@gmail.com; chopps@chopps.org;
> draft-
>     > ietf-lsr-isis-invalid-tlv@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. 😊

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