Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Les Ginsberg (ginsberg)]

Scott -

I hear and respect your choice to end this thread.

One point of clarification - no response is required or expected.

The definition I mentioned ("to provide the opportunity for 
proprietary/experimental applications") is simply my POV. This was never 
discussed in the WG. While this might be easy for you and I to agree on, I 
don’t feel comfortable introducing a definition that was never discussed.

The difference between you and I seems to be that you feel the document is 
incomplete without such a statement - while I feel it is unnecessary to the 
document. Everyone should free to consider use cases for UDA in whatever manner 
they feel is best.

Despite our lack of agreement, I do appreciate the time and thoughtfulness you 
put into the review. Thanx for that.

   Les


> -Original Message-
> From: Scott O. Bradner 
> Sent: Sunday, June 14, 2020 4:15 PM
> To: Les Ginsberg (ginsberg) 
> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> d...@ietf.org; Benjamin Kaduk ; last-c...@ietf.org; ops-
> a...@ietf.org
> Subject: Re: [Last-Call] Opsdir telechat review of 
> draft-ietf-ospf-te-link-attr-
> reuse-14
> 
> inline
> 
> > On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Scott -
> >
> >
> >
> > Inline.
> >
> >
> >
> > > -Original Message-
> >
> > > From: Scott O. Bradner 
> >
> > > Sent: Sunday, June 14, 2020 3:16 PM
> >
> > > To: Les Ginsberg (ginsberg) 
> >
> > > Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-
> te-
> >
> > > link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org
> >
> > > Subject: Re: [Last-Call] Opsdir telechat review of 
> > > draft-ietf-ospf-te-link-
> attr-
> >
> > > reuse-14
> >
> > >
> >
> > > but why not spend the few bits to make it clear what its intended for -
> the
> >
> > > pushback on that simple request puzzles me
> >
> > > I do not understand the reluctance
> >
> >
> >
> > [Les:] With respect, answering my question with a counter question does
> not answer my question. 
> >
> > I have explained why I am reluctant -
> 
> 
> sorry but that did not explain your reluctance too me
> 
> > please explain what purpose your request serves. And why additional text
> is required for UDA when it is not needed for SA.
> 
> to mak eten document complete - the IDs introduce a field that they do not
> explain - that, to me, is a clear lack
> >
> >
> >
> > The "purpose" of UDA - to me - is to provide the opportunity for
> proprietary/experimental applications. But as UDAs are by definition outside
> the scope of standardization, it is not within the purview of the IETF or this
> document to place limitations on them. What I might judge to be an
> appropriate use case and what you might judge to be an appropriate use
> case might be different - and that should be OK. Which is why I don’t want to
> discuss "intent".
> >
> 
> I do not think I asked for "intent" but you just gave it to me "The "purpose"
> of UDA - to me - is to provide the opportunity for proprietary/experimental
> applications"
> 
> I do not see why it is so hard to say just that
> 
> in any case this does not seem like a productive discussion - you-all reject
> what seems like a logical and easy to implement request from me
> so I guess we will just hav etc agree to disagree
> 
> I'm done
> 
> Scott
> 
> >
> >
> > >
> >
> > > if it is so far outside of the area covered by the document why not simply
> >
> > > remove it?
> >
> > >
> >
> > [Les:] UDA was put in based on comments received from the WG. You
> would need to convince the WG that UDAs are not needed - not just me.
> >
> > That said, removing it now could introduce backwards compatibility issues
> with the existing deployments unless the syntax changes were limited - so
> this idea should be considered carefully before proceeding.
> >
> >
> >
> >   Les
> >
> >
> >
> > > Scott
> >
> > >
> >
> > > > On Jun 14, 2020, at 5:14 PM, Les Ginsberg (ginsberg)
> >
> > >  wrote:
> >
> > > >
> >
> > > > Scott -
> >
> > > >
> >
> > > > Allow me to inject myself here. As editor of the companion IS-IS
> document
> >
> > > (draft-ietf-isis-te-app) I have received similar comments - for example
> from
> >
> > > Ben (copied on this thread).
> >
> > > >
> >
> > > > I continue to be at a loss as to why you believe we have to say
> something
> >
> > > about User Defined Applications beyond what we have already said:
> >
> > > >
> >
> > > > "User Defined Application Identifier Bits have no relationship to
> >
> > > >   Standard Application Identifier Bits and are not managed by IANA or
> >
> > > >   any other standards body."
> >
> > > >
> >
> > > > If you do a search through both documents using "standard app" and
> "user
> >
> > > defined app" I think you will find equivalent statements about both.
> Which
> >
> > > means you are asking for some text regarding UDAs that doesn’t exist for
> >
> > > SAs.
> >
> > > > Why?
> >
> > > >
> >
> > > > The question of "UDA scope" - raised by both you and 

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Scott O. Bradner]

inline

> On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Scott -
> 
>  
> 
> Inline.
> 
>  
> 
> > -Original Message-
> 
> > From: Scott O. Bradner 
> 
> > Sent: Sunday, June 14, 2020 3:16 PM
> 
> > To: Les Ginsberg (ginsberg) 
> 
> > Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-te-
> 
> > link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org
> 
> > Subject: Re: [Last-Call] Opsdir telechat review of 
> > draft-ietf-ospf-te-link-attr-
> 
> > reuse-14
> 
> >
> 
> > but why not spend the few bits to make it clear what its intended for - the
> 
> > pushback on that simple request puzzles me
> 
> > I do not understand the reluctance
> 
>  
> 
> [Les:] With respect, answering my question with a counter question does not 
> answer my question. 
> 
> I have explained why I am reluctant -


sorry but that did not explain your reluctance too me

> please explain what purpose your request serves. And why additional text is 
> required for UDA when it is not needed for SA.

to mak eten document complete - the IDs introduce a field that they do not 
explain - that, to me, is a clear lack
> 
>  
> 
> The "purpose" of UDA - to me - is to provide the opportunity for 
> proprietary/experimental applications. But as UDAs are by definition outside 
> the scope of standardization, it is not within the purview of the IETF or 
> this document to place limitations on them. What I might judge to be an 
> appropriate use case and what you might judge to be an appropriate use case 
> might be different - and that should be OK. Which is why I don’t want to 
> discuss "intent".
> 

I do not think I asked for "intent" but you just gave it to me "The "purpose" 
of UDA - to me - is to provide the opportunity for proprietary/experimental 
applications"

I do not see why it is so hard to say just that

in any case this does not seem like a productive discussion - you-all reject 
what seems like a logical and easy to implement request from me
so I guess we will just hav etc agree to disagree

I'm done

Scott

>  
> 
> >
> 
> > if it is so far outside of the area covered by the document why not simply
> 
> > remove it?
> 
> >
> 
> [Les:] UDA was put in based on comments received from the WG. You would need 
> to convince the WG that UDAs are not needed - not just me.
> 
> That said, removing it now could introduce backwards compatibility issues 
> with the existing deployments unless the syntax changes were limited - so 
> this idea should be considered carefully before proceeding.
> 
>  
> 
>   Les
> 
>  
> 
> > Scott
> 
> >
> 
> > > On Jun 14, 2020, at 5:14 PM, Les Ginsberg (ginsberg)
> 
> >  wrote:
> 
> > >
> 
> > > Scott -
> 
> > >
> 
> > > Allow me to inject myself here. As editor of the companion IS-IS document
> 
> > (draft-ietf-isis-te-app) I have received similar comments - for example from
> 
> > Ben (copied on this thread).
> 
> > >
> 
> > > I continue to be at a loss as to why you believe we have to say something
> 
> > about User Defined Applications beyond what we have already said:
> 
> > >
> 
> > > "User Defined Application Identifier Bits have no relationship to
> 
> > >   Standard Application Identifier Bits and are not managed by IANA or
> 
> > >   any other standards body."
> 
> > >
> 
> > > If you do a search through both documents using "standard app" and "user
> 
> > defined app" I think you will find equivalent statements about both. Which
> 
> > means you are asking for some text regarding UDAs that doesn’t exist for
> 
> > SAs.
> 
> > > Why?
> 
> > >
> 
> > > The question of "UDA scope" - raised by both you and Ben - I think is an
> 
> > example of something that isn’t needed.
> 
> > >
> 
> > > Link attributes have been advertised for years - and the ability to define
> 
> > the appropriate scope (area or domain) has been supported by
> 
> > implementations for many years. While we are changing the format of how
> 
> > link attributes are advertised, we aren't altering the scopes supported.
> 
> > >
> 
> > > Standard applications can be (and have been) supported area wide and/or
> 
> > domain wide - and no restriction/specification of what scopes
> 
> > SHOULD/MUST be supported is present in either document other than to
> 
> > specify the type of LSAs in which the advertisements may appear. And since
> 
> > the new TLV introduced to carry application specific advertisements carries
> 
> > both SA and UDA bit masks in the same TLV, clearly the available scopes are
> 
> > the same for both types of applications.
> 
> > >
> 
> > > For me, the fact that UDA is outside the scope of standardization means
> 
> > the less said about how UDAs might be used the better.
> 
> > >
> 
> > > Do we have common ground here?
> 
> > >
> 
> > >   Les
> 
> > >
> 
> > >
> 
> > >> -Original Message-
> 
> > >> From: Scott Bradner via Datatracker 
> 
> > >> Sent: Sunday, June 14, 2020 12:23 PM
> 
> > >> To: ops-...@ietf.org
> 
> > >> Cc: 

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Les Ginsberg (ginsberg)]

Scott -



Inline.



> -Original Message-

> From: Scott O. Bradner 

> Sent: Sunday, June 14, 2020 3:16 PM

> To: Les Ginsberg (ginsberg) 

> Cc: ops-...@ietf.org; Benjamin Kaduk ; draft-ietf-ospf-te-

> link-attr-reuse@ietf.org; last-c...@ietf.org; lsr@ietf.org

> Subject: Re: [Last-Call] Opsdir telechat review of 
> draft-ietf-ospf-te-link-attr-

> reuse-14

>

> but why not spend the few bits to make it clear what its intended for - the

> pushback on that simple request puzzles me

> I do not understand the reluctance



[Les:] With respect, answering my question with a counter question does not 
answer my question. 

I have explained why I am reluctant - please explain what purpose your request 
serves. And why additional text is required for UDA when it is not needed for 
SA.



The "purpose" of UDA - to me - is to provide the opportunity for 
proprietary/experimental applications. But as UDAs are by definition outside 
the scope of standardization, it is not within the purview of the IETF or this 
document to place limitations on them. What I might judge to be an appropriate 
use case and what you might judge to be an appropriate use case might be 
different - and that should be OK. Which is why I don’t want to discuss 
"intent".



>

> if it is so far outside of the area covered by the document why not simply

> remove it?

>

[Les:] UDA was put in based on comments received from the WG. You would need to 
convince the WG that UDAs are not needed - not just me.

That said, removing it now could introduce backwards compatibility issues with 
the existing deployments unless the syntax changes were limited - so this idea 
should be considered carefully before proceeding.



  Les



> Scott

>

> > On Jun 14, 2020, at 5:14 PM, Les Ginsberg (ginsberg)

> mailto:ginsberg=40cisco@dmarc.ietf.org>>
>  wrote:

> >

> > Scott -

> >

> > Allow me to inject myself here. As editor of the companion IS-IS document

> (draft-ietf-isis-te-app) I have received similar comments - for example from

> Ben (copied on this thread).

> >

> > I continue to be at a loss as to why you believe we have to say something

> about User Defined Applications beyond what we have already said:

> >

> > "User Defined Application Identifier Bits have no relationship to

> >   Standard Application Identifier Bits and are not managed by IANA or

> >   any other standards body."

> >

> > If you do a search through both documents using "standard app" and "user

> defined app" I think you will find equivalent statements about both. Which

> means you are asking for some text regarding UDAs that doesn’t exist for

> SAs.

> > Why?

> >

> > The question of "UDA scope" - raised by both you and Ben - I think is an

> example of something that isn’t needed.

> >

> > Link attributes have been advertised for years - and the ability to define

> the appropriate scope (area or domain) has been supported by

> implementations for many years. While we are changing the format of how

> link attributes are advertised, we aren't altering the scopes supported.

> >

> > Standard applications can be (and have been) supported area wide and/or

> domain wide - and no restriction/specification of what scopes

> SHOULD/MUST be supported is present in either document other than to

> specify the type of LSAs in which the advertisements may appear. And since

> the new TLV introduced to carry application specific advertisements carries

> both SA and UDA bit masks in the same TLV, clearly the available scopes are

> the same for both types of applications.

> >

> > For me, the fact that UDA is outside the scope of standardization means

> the less said about how UDAs might be used the better.

> >

> > Do we have common ground here?

> >

> >   Les

> >

> >

> >> -Original Message-

> >> From: Scott Bradner via Datatracker 
> >> mailto:nore...@ietf.org>>

> >> Sent: Sunday, June 14, 2020 12:23 PM

> >> To: ops-...@ietf.org

> >> Cc: 
> >> draft-ietf-ospf-te-link-attr-reuse@ietf.org;
> >>  lsr@ietf.org; last-

> >> c...@ietf.org

> >> Subject: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

> >>

> >> Reviewer: Scott Bradner

> >> Review result: Ready

> >>

> >> I have reviewed the latest version of this document and my earlier issues

> >> have

> >> been resolved at least well enough for teh document to be considered

> ready

> >> for

> >> publication.

> >>

> >> that said I still do not see where "User Defined Application Identifier" is

> >> actually cleanly defined - one can read carefully and determine but it

> would

> >> be

> >> easier on the reader to just say that it is a field that can be used to

> >> indicate the use of one or more non-standard applications within some

> scope

> >> (network, subnet, link, organization, ... not sure what scopes are

> meaningful

> 

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Scott O. Bradner]

but why not spend the few bits to make it clear what its intended for - the 
pushback on that simple request puzzles me
I do not understand the reluctance

if it is so far outside of the area covered by the document why not simply 
remove it?

Scott

> On Jun 14, 2020, at 5:14 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Scott -
> 
> Allow me to inject myself here. As editor of the companion IS-IS document 
> (draft-ietf-isis-te-app) I have received similar comments - for example from 
> Ben (copied on this thread).
> 
> I continue to be at a loss as to why you believe we have to say something 
> about User Defined Applications beyond what we have already said:
> 
> "User Defined Application Identifier Bits have no relationship to
>   Standard Application Identifier Bits and are not managed by IANA or
>   any other standards body."
> 
> If you do a search through both documents using "standard app" and "user 
> defined app" I think you will find equivalent statements about both. Which 
> means you are asking for some text regarding UDAs that doesn’t exist for SAs.
> Why? 
> 
> The question of "UDA scope" - raised by both you and Ben - I think is an 
> example of something that isn’t needed.
> 
> Link attributes have been advertised for years - and the ability to define 
> the appropriate scope (area or domain) has been supported by implementations 
> for many years. While we are changing the format of how link attributes are 
> advertised, we aren't altering the scopes supported.
> 
> Standard applications can be (and have been) supported area wide and/or 
> domain wide - and no restriction/specification of what scopes SHOULD/MUST be 
> supported is present in either document other than to specify the type of 
> LSAs in which the advertisements may appear. And since the new TLV introduced 
> to carry application specific advertisements carries both SA and UDA bit 
> masks in the same TLV, clearly the available scopes are the same for both 
> types of applications.
> 
> For me, the fact that UDA is outside the scope of standardization means the 
> less said about how UDAs might be used the better.
> 
> Do we have common ground here?
> 
>   Les
> 
> 
>> -Original Message-
>> From: Scott Bradner via Datatracker 
>> Sent: Sunday, June 14, 2020 12:23 PM
>> To: ops-...@ietf.org
>> Cc: draft-ietf-ospf-te-link-attr-reuse@ietf.org; lsr@ietf.org; last-
>> c...@ietf.org
>> Subject: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
>> 
>> Reviewer: Scott Bradner
>> Review result: Ready
>> 
>> I have reviewed the latest version of this document and my earlier issues
>> have
>> been resolved at least well enough for teh document to be considered ready
>> for
>> publication.
>> 
>> that said I still do not see where "User Defined Application Identifier" is
>> actually cleanly defined - one can read carefully and determine but it would
>> be
>> easier on the reader to just say that it is a field that can be used to
>> indicate the use of one or more non-standard applications within some scope
>> (network, subnet, link, organization, ... not sure what scopes are meaningful
>> here but it does not seem that a User Defined Application Identifier would
>> be a
>> global (between network operators) value
>> 
>> Scott
>> 
> 
> -- 
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

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

Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Les Ginsberg (ginsberg)]

Scott -

Allow me to inject myself here. As editor of the companion IS-IS document 
(draft-ietf-isis-te-app) I have received similar comments - for example from 
Ben (copied on this thread).

I continue to be at a loss as to why you believe we have to say something about 
User Defined Applications beyond what we have already said:

"User Defined Application Identifier Bits have no relationship to
   Standard Application Identifier Bits and are not managed by IANA or
   any other standards body."

If you do a search through both documents using "standard app" and "user 
defined app" I think you will find equivalent statements about both. Which 
means you are asking for some text regarding UDAs that doesn’t exist for SAs.
Why? 

The question of "UDA scope" - raised by both you and Ben - I think is an 
example of something that isn’t needed.

Link attributes have been advertised for years - and the ability to define the 
appropriate scope (area or domain) has been supported by implementations for 
many years. While we are changing the format of how link attributes are 
advertised, we aren't altering the scopes supported.

Standard applications can be (and have been) supported area wide and/or domain 
wide - and no restriction/specification of what scopes SHOULD/MUST be supported 
is present in either document other than to specify the type of LSAs in which 
the advertisements may appear. And since the new TLV introduced to carry 
application specific advertisements carries both SA and UDA bit masks in the 
same TLV, clearly the available scopes are the same for both types of 
applications.

For me, the fact that UDA is outside the scope of standardization means the 
less said about how UDAs might be used the better.

Do we have common ground here?

   Les


> -Original Message-
> From: Scott Bradner via Datatracker 
> Sent: Sunday, June 14, 2020 12:23 PM
> To: ops-...@ietf.org
> Cc: draft-ietf-ospf-te-link-attr-reuse@ietf.org; lsr@ietf.org; last-
> c...@ietf.org
> Subject: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
> 
> Reviewer: Scott Bradner
> Review result: Ready
> 
> I have reviewed the latest version of this document and my earlier issues
> have
> been resolved at least well enough for teh document to be considered ready
> for
> publication.
> 
> that said I still do not see where "User Defined Application Identifier" is
> actually cleanly defined - one can read carefully and determine but it would
> be
> easier on the reader to just say that it is a field that can be used to
> indicate the use of one or more non-standard applications within some scope
> (network, subnet, link, organization, ... not sure what scopes are meaningful
> here but it does not seem that a User Defined Application Identifier would
> be a
> global (between network operators) value
> 
> Scott
> 

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

[Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Scott Bradner via Datatracker]

Reviewer: Scott Bradner
Review result: Ready

I have reviewed the latest version of this document and my earlier issues have
been resolved at least well enough for teh document to be considered ready for
publication.

that said I still do not see where "User Defined Application Identifier" is
actually cleanly defined - one can read carefully and determine but it would be
easier on the reader to just say that it is a field that can be used to
indicate the use of one or more non-standard applications within some scope
(network, subnet, link, organization, ... not sure what scopes are meaningful
here but it does not seem that a User Defined Application Identifier would be a
global (between network operators) value

Scott


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