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

Hi Les and Acee!

> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Sent: Monday, July 13, 2020 11:43 PM
> To: Acee Lindem (acee) <acee@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)
> 
> 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!

Regards,
Roman

>    Les
> 
> 
> > -----Original Message-----
> > From: Acee Lindem (acee) <acee@cisco.com>
> > Sent: Monday, July 13, 2020 9:38 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)
> >
> >
> >
> > On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
> > wrote:
> >
> >     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. 😊
> >
> > 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
> >