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

["Acee Lindem (acee)" <[e-mail]>]

On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:

    Acee -

    Inline.

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