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

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