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

From: Scott Bradner via Datatracker <[email-masked]>
Date: Sun, 14 Jun 2020 12:22:34 -0700

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 14 Jun 2020 21:14:49 +0000

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 <[email-masked]>
> Sent: Sunday, June 14, 2020 12:23 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; last-
> [email-masked]
> Subject: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
> 
> Reviewer: Scott Bradner
> Review result: Ready
>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 14 Jun 2020 18:15:47 -0400

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) <ginsberg=[email-masked]> wrote:
> 
> Scott -
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 14 Jun 2020 22:50:46 +0000

Scott -

Inline.

> From: Scott O. Bradner <[email-masked]>

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

> To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>

> Cc: [email-masked]; Benjamin Kaduk <[email-masked]>; draft-ietf-ospf-te-

> [email-masked]; [email-masked]; [email-masked]

> 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

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

> <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>> wrote:

> > 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:

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

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

> >> From: Scott Bradner via Datatracker <[email-masked]<mailto:[email-masked]>>

> >> To: [email-masked]<mailto:[email-masked]>

> >> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; last-

> >> [email-masked]<mailto:[email-masked]>

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

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

> would

> >> be

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

> > [email-masked]<mailto:[email-masked]>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 14 Jun 2020 19:14:59 -0400

inline

> On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Scott -
> 
>  
> 
> Inline.
> 
>  
> 
> 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 purv…

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

> > <ginsberg=[email-masked]> wrote:
> 
> > >
> 
> > > Scott -
> 
> > >
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 15 Jun 2020 01:43:32 +0000

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

> Sent: Sunday, June 14, 2020 4:15 PM
> Cc: [email-masked]; [email-masked]; ops-
> [email-masked]; Benjamin Kaduk <[email-masked]>; [email-masked]; ops-
> [email-masked]
> > On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg)
> > 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".
> >
> 
> 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"
> 
> 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
> > [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
> >
> > >
> >

---

From: Peter Psenak <[email-masked]>
Date: Mon, 15 Jun 2020 11:14:53 +0200

Hi Scott.

there is a following text in the OSPF draft:

   "On top of advertising the link attributes for standardized
    applications, link attributes can be advertised for the purpose of
    applications that are not standardized.  We call such an
    application a "User Defined Application" or "UDA".  These
    applications are not subject to standardization and are outside of
    the scope of this specification."

Feel free to propose an additional text if you feel above is not sufficient.

thanks,
Peter

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 15 Jun 2020 06:16:31 -0400

that looks just fine to me - thanks

Scott

> On Jun 15, 2020, at 5:14 AM, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Scott.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Jun 2020 19:22:14 -0700

Hi Les, Scott, Peter,

I appreciate the text about "not subject to standardization and are outside
of the scope of this specification".  That said (inline),

> 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…

We give instructions to IANA for how to managed the Standard Application
Identifier Bits.  Is it fair to give guidance to the entity assigning User
Defined Application Identifier Bits (whomever that may be) about things
they might want to consider while doing so?  A "several ways to not shoot
yourself in the foot" guide, as it were, even though such a guide is
inherently incomplete.  If there is nothing useful to say and the key
factors are pretty inherent in how IS-IS/OSPF work, that's fine.  But the
"warnings about potential 'gotcha's" directed at the party assigning UAI
bits is the main topic I was trying to get at in my remarks on the
analogous part of the IS-IS document.

Sorry for having made my point so circuitously.

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Jun 2020 06:26:47 +0000

Ben -

Inline.

> From: Benjamin Kaduk <[email-masked]>
> Sent: Tuesday, June 16, 2020 7:22 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: Scott Bradner <[email-masked]>; [email-masked]; draft-ietf-ospf-te-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
> 
> Hi Les, Scott, Peter,
> 

[Les:] There is no standards body assigning UDA bits. As we say above:

" not managed by IANA or  any other standards body."

As the applications are "User Defined" I would assume the "user" will have to decide what bits they want to use and how to insure they don’t conflict with other applications the same user defines.

The point of "User Defined" (as we keep saying) is that the user has complete control. There is no requirement that two different users have any compatibility at all.
If multiple users want interoperability, then they should use a standardized application.
Of course, there is nothing to stop two users from cooperating, but now we are in the "wild-wild-west" where people create ad-hoc definitions w/o any standardization.
For whatever reason, they rejected IETF/IANA and decided to manage their own ID space. This is beyond our control.

There is no intent, for example, to have IANA manage UDA space on behalf of "Experimental Applications".
We have simply provided an encoding syntax for UDAs to be advertised in the same link attribute sub-TLVs that include SA. What users put into UDABM and what applications are supported by UDABM is out of scope.

I really don’t think there is anything meaningful to say.

   Les

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 17 Jun 2020 12:08:50 +0000

Hi Les,

Would you be opposed to adding text similar to the OSPF paragraph below to the ISIS draft?

I think that the OSPF draft does a better job of first introducing UDAs.  Having just looked at the ISIS draft, it does seem to somewhat assume that the reader will just know what they are ...

I understand that this should resolve Scott's concerns.

Regards,
Rob

> From: last-call <[email-masked]> On Behalf Of Scott O. Bradner
> Sent: 15 June 2020 11:17
> To: Peter Psenak <ppsenak=[email-masked]>
> [email-masked]; [email-masked]
> Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> link-attr-reuse-14
> 
> > On Jun 15, 2020, at 5:14 AM, Peter Psenak
> <ppsenak=[email-masked]> wrote:
> >
> > Hi Scott.
> >
> ready for
> would be
> would be a

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Jun 2020 14:56:48 +0000

Rob -

IS-IS draft currently states:

(OSPF has this text also.)

I am happy enough to include an additional statement similar to the OSPF text below in Section 4.

Scott can speak for himself of course - but not clear to me that this really satisfies him since his comment was on the OSPF draft that already had this text.

And not clear that this would make Ben (copied) any more comfortable since his concern (clarified in his most recent post) is about discussing allocation of the UDA bit space.

But I will add the text - it makes the two drafts closer in content - which has been an ongoing goal during the review process.

Thanx.

   Les

> From: Rob Wilton (rwilton) <[email-masked]>
> Sent: Wednesday, June 17, 2020 5:09 AM
> To: Peter Psenak <ppsenak=[email-masked]>; Les Ginsberg
> (ginsberg) <[email-masked]>
> [email-masked]; [email-masked]; Scott O. Bradner <[email-masked]>
> Subject: RE: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-
> reuse-14
> 
> Hi Les,
> 
> I think that the OSPF draft does a better job of first introducing UDAs.  Having
> just looked at the ISIS draft, it does seem to somewhat assume that the
> reader will just know what they are ...
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 17 Jun 2020 15:34:24 +0000

Les,

Thanks for being accommodating.

Regards,
Rob

> From: Les Ginsberg (ginsberg) <[email-masked]>
> Sent: 17 June 2020 15:57
> To: Rob Wilton (rwilton) <[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>; Benjamin Kaduk <[email-masked]>
> Subject: RE: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> link-attr-reuse-14
> 
> Rob -
> 
> Scott can speak for himself of course - but not clear to me that this
> really satisfies him since his comment was on the OSPF draft that already
> had this text.
> 
> And not clear that this would make Ben (copied) any more comfortable since
> his concern (clarified in his most recent post) is about discussing
> allocation of the UDA bit space.
> 
> But I will add the text - it makes the two drafts closer in content -
> which has been an ongoing goal during the review process.
> 
> Thanx.
> 
>    Les
> 
> 
> > Would you be opposed to adding text similar to the OSPF paragraph below
> to
> > the ISIS draft?
> >

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 17 Jun 2020 11:52:54 -0400

I'm fine if both documents have the text

thanks

Scott

> On Jun 17, 2020, at 10:56 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Rob -
>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 17 Jun 2020 13:10:08 -0400

just to be clear - the test I mean is

Scott

> On Jun 17, 2020, at 11:52 AM, Scott O. Bradner <[email-masked]> wrote:
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Jun 2020 17:40:10 +0000

draft-ietf-isis-te-app-17 has been posted with this change.

   Les

> Sent: Wednesday, June 17, 2020 8:53 AM
> Cc: Rob Wilton (rwilton) <[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>; Benjamin Kaduk
> <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> > On Jun 17, 2020, at 10:56 AM, Les Ginsberg (ginsberg)
> > Scott can speak for himself of course - but not clear to me that this really
> satisfies him since his comment was on the OSPF draft that already had this
> text.
> >
> > And not clear that this would make Ben (copied) any more comfortable
> since his concern (clarified in his most recent post) is about discussing
> > But I will add the text - it makes the two drafts closer in content - which has
> been an ongoing goal during the review process.
> >
> > Thanx.
> >
> >   Les
> >
> >
> >> Would you be opposed to adding text similar to the OSPF paragraph
> below to
> >> the ISIS draft?
> >>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Jun 2020 11:21:30 -0700

> As the applications are "User Defined" I would assume the "user" will have to decide what bits they want to use and how to insure they don’t conflict with other applications the same user defines.

I agree, it is entirely up to the "user" (and we don't really define the
"user" anyway).

> For whatever reason, they rejected IETF/IANA and decided to manage their own ID space. This is beyond our control.

It is beyond our *control*, yes, but not beyond our *advice*.  That said, ...

> I really don’t think there is anything meaningful to say.

... it sounds like you think the only obvious advice to give in this
situation ("don't try to use assignments that conflict in a setup where
they would run into each other") is sufficiently obvious so as to not need
saying.  Which is fine, but is not the point that was coming across to me
from your previous messages on this topic.

So, if it's "sufficiently obvious to go without saying", then it sounds
like we're in agreement about what else to do (nothing).

Thanks again for your patience with this discussion and helping to keep the
documents in sync.

-Ben