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 <sob@xxxxxxxxx>
> Sent: Sunday, June 14, 2020 4:15 PM
> To: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> Cc: lsr@xxxxxxxx; draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx; ops-
> dir@xxxxxxxx; Benjamin Kaduk <kaduk@xxxxxxx>; last-call@xxxxxxxx; ops-
> ads@xxxxxxxx
> 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)
> <ginsberg=40cisco.com@xxxxxxxxxxxxxx> wrote:
> >
> > Scott -
> >
> >
> >
> > Inline.
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: Scott O. Bradner <sob@xxxxxxxxx>
> >
> > > Sent: Sunday, June 14, 2020 3:16 PM
> >
> > > To: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> >
> > > Cc: ops-dir@xxxxxxxx; Benjamin Kaduk <kaduk@xxxxxxx>; draft-ietf-ospf-
> te-
> >
> > > link-attr-reuse.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
> >
> > > 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)
> >
> > > <ginsberg=40cisco.com@xxxxxxxxxxxxxx> 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 <noreply@xxxxxxxx>
> >
> > > >> Sent: Sunday, June 14, 2020 12:23 PM
> >
> > > >> To: ops-dir@xxxxxxxx
> >
> > > >> Cc: draft-ietf-ospf-te-link-attr-reuse.all@xxxxxxxx; lsr@xxxxxxxx; last-
> >
> > > >> call@xxxxxxxx
> >
> > > >> 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-call@xxxxxxxx
> >
> > > > https://www.ietf.org/mailman/listinfo/last-call
> >
> >
> >
> > --
> > last-call mailing list
> > last-call@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/last-call
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
