On Wed, Jun 17, 2020 at 06:26:47AM +0000, Les Ginsberg (ginsberg) wrote:
> Ben -
>
> Inline.
>
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@xxxxxxx>
> > Sent: Tuesday, June 16, 2020 7:22 PM
> > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
> > Cc: Scott Bradner <sob@xxxxxxxxx>; ops-dir@xxxxxxxx; draft-ietf-ospf-te-
> > link-attr-reuse.all@xxxxxxxx; lsr@xxxxxxxx; last-call@xxxxxxxx
> > Subject: Re: Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
> >
> > 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),
> >
> > On Sun, Jun 14, 2020 at 09:14:49PM +0000, 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?
> >
> > 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.
> >
>
> [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.
I agree, it is entirely up to the "user" (and we don't really define the
"user" anyway).
> 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.
It is beyond our *control*, yes, but not beyond our *advice*. That said, ...
> 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.
... 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
