On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote:

    Acee -

    Inline.

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


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to