inline > On Jun 14, 2020, at 6:50 PM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > Scott - > > > > Inline. > > > > > -----Original Message----- > > > From: Scott O. Bradner <[email protected]> > > > Sent: Sunday, June 14, 2020 3:16 PM > > > To: Les Ginsberg (ginsberg) <[email protected]> > > > Cc: [email protected]; Benjamin Kaduk <[email protected]>; draft-ietf-ospf-te- > > > [email protected]; [email protected]; [email protected] > > > 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) > > > <[email protected]> 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 <[email protected]> > > > >> Sent: Sunday, June 14, 2020 12:23 PM > > > >> To: [email protected] > > > >> Cc: [email protected]; [email protected]; last- > > > >> [email protected] > > > >> 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > -- > last-call mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/last-call _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
