Hi Les, Roman,
On 7/14/20, 7:15 AM, "Roman Danyliw" <[email protected]> wrote:
Hi Les and Acee!
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <[email protected]>
> Sent: Monday, July 13, 2020 11:43 PM
> To: Acee Lindem (acee) <[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)
>
> 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!
This works for me.
Thanks,
Acee
Regards,
Roman
> Les
>
>
> > -----Original Message-----
> > From: Acee Lindem (acee) <[email protected]>
> > Sent: Monday, July 13, 2020 9:38 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)
> >
> >
> >
> > 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
