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