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

2020-07-14 Thread Acee Lindem (acee)
Hi Les, Roman, 

On 7/14/20, 7:15 AM, "Roman Danyliw"  wrote:

Hi Les and Acee!

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, July 13, 2020 11:43 PM
> To: Acee Lindem (acee) ; Roman Danyliw ;
> The IESG 
> 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)
> 
> 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) 
> > Sent: Monday, July 13, 2020 9:38 AM
> > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > ; The IESG 
> > 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)
> >
> >
> >
> > On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" 
> > wrote:
> >
> > Acee -
> >
> > Inline.
> >
> > > -Original Message-
> > > From: Acee Lindem (acee) 
> > > Sent: Monday, July 13, 2020 9:04 AM
> > > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > > ; The IESG 
> >     > 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)" 

> > > wrote:
> > >
> > > Roman -
> > >
> > > Thanx for the review.
> > > Inline.
> > >
> > >     > -Original Message-
> >     > > From: Lsr  On Behalf Of Roman Danyliw 
via
> > > > Datatracker
    > > > > Sent: Monday, July 13, 2020 7:40 AM
> > > > To: The IESG 
> > > > 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/
> > > >
> > > >
> > >  

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

2020-07-14 Thread Roman Danyliw
Hi Les and Acee!

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, July 13, 2020 11:43 PM
> To: Acee Lindem (acee) ; Roman Danyliw ;
> The IESG 
> 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)
> 
> 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!

Regards,
Roman

>Les
> 
> 
> > -Original Message-
> > From: Acee Lindem (acee) 
> > Sent: Monday, July 13, 2020 9:38 AM
> > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > ; The IESG 
> > 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)
> >
> >
> >
> > On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" 
> > wrote:
> >
> > Acee -
> >
> > Inline.
> >
> > > -Original Message-
> > > From: Acee Lindem (acee) 
> > > Sent: Monday, July 13, 2020 9:04 AM
> >     > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > > ; The IESG 
> >     > 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)" 
> > > wrote:
> > >
> > > Roman -
> > >
> > > Thanx for the review.
> > >     Inline.
> > >
> > >     > -Original Message-----
> > >     > From: Lsr  On Behalf Of Roman Danyliw via
> > > > Datatracker
> > > > Sent: Monday, July 13, 2020 7:40 AM
> > > > To: The IESG 
> > > > 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.
> > &g

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

2020-07-13 Thread Les Ginsberg (ginsberg)
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.

   Les


> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Monday, July 13, 2020 9:38 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG 
> 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)
> 
> 
> 
> On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" 
> wrote:
> 
> Acee -
> 
> Inline.
> 
> > -Original Message-
> > From: Acee Lindem (acee) 
> > Sent: Monday, July 13, 2020 9:04 AM
> > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > ; The IESG 
> > 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)" 
> > wrote:
> >
> > Roman -
> >
> > Thanx for the review.
> > Inline.
> >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Roman Danyliw via
> > > Datatracker
> > > Sent: Monday, July 13, 2020 7:40 AM
> >     > To: The IESG 
>     > > 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:] T

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

2020-07-13 Thread Acee Lindem (acee)


On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)"  wrote:

Acee -

Inline.

> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Monday, July 13, 2020 9:04 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG 
> 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)" 
> wrote:
> 
> Roman -
> 
> Thanx for the review.
> Inline.
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Roman Danyliw via
> > Datatracker
> > Sent: Monday, July 13, 2020 7:40 AM
> > To: The IESG 
> > 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 wo

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

2020-07-13 Thread Les Ginsberg (ginsberg)
Acee -

Inline.

> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Monday, July 13, 2020 9:04 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG 
> 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)" 
> wrote:
> 
> Roman -
> 
> Thanx for the review.
> Inline.
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Roman Danyliw via
> > Datatracker
> > Sent: Monday, July 13, 2020 7:40 AM
> > To: The IESG 
> > 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. 

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


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

2020-07-13 Thread Acee Lindem (acee)
Hi Les, 

On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)"  wrote:

Roman -

Thanx for the review.
Inline.

> -Original Message-
> From: Lsr  On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Monday, July 13, 2020 7:40 AM
> To: The IESG 
> 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


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

2020-07-13 Thread Les Ginsberg (ginsberg)
Roman -

Thanx for the review.
Inline.

> -Original Message-
> From: Lsr  On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Monday, July 13, 2020 7:40 AM
> To: The IESG 
> 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.

   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


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

2020-07-13 Thread Roman Danyliw via Datatracker
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.



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