Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
On Wed, Jun 17, 2020 at 06:26:47AM +, Les Ginsberg (ginsberg) wrote:
> Ben -
>
> Inline.
>
> > -Original Message-
> > From: Benjamin Kaduk
> > Sent: Tuesday, June 16, 2020 7:22 PM
> > To: Les Ginsberg (ginsberg)
> > Cc: Scott Bradner ; ops-...@ietf.org; draft-ietf-ospf-te-
> > link-attr-reuse@ietf.org; lsr@ietf.org; last-c...@ietf.org
> > 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 +, 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
___
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
Ben - Inline. > -Original Message- > From: Benjamin Kaduk > Sent: Tuesday, June 16, 2020 7:22 PM > To: Les Ginsberg (ginsberg) > Cc: Scott Bradner ; ops-...@ietf.org; draft-ietf-ospf-te- > link-attr-reuse@ietf.org; lsr@ietf.org; last-c...@ietf.org > 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 +, 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. 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 > Sorry for having made my point so circuitously. > > -Ben ___ 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
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 +, 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. Sorry for having made my point so circuitously. -Ben ___ 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
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 On 14/06/2020 21:22, Scott Bradner via Datatracker wrote: 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
Re: [Lsr] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14
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
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
