Tony - So you are suggesting that we publish something that was never actually published as an RFC as a "historic RFC"?
The logic of that escapes me. These days expired drafts are never lost, so if someone wants to resurrect this draft it is certainly possible to do so even if it languishes as expired for years. But I thought the intent of Acee's question was to see if publishing this as Experimental serves a useful purpose i.e., even if the feature is not being actively deployed the protocol extensions seem like they could be useful someday and we would prefer not to have them disappear from the official protocol definition. ?? Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Tony Li > Sent: Monday, June 13, 2022 11:12 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: tom petch <[email protected]>; Acee Lindem (acee) > <[email protected]>; [email protected] > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic- > flooding > > > Les, > > The market looked at the technology and decided that it was not interested. > If that’s not the definition of ‘obsolete’, I don’t know what is. > > Tony > > > > On Jun 13, 2022, at 10:27 AM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > > Tony - > > > > "Historic" is for > > > > " A specification that has been superseded by a more recent > > specification or is for any other reason considered to be obsolete..." > > > > Hard to see how that applies here. > > > > Although I appreciate Tom's concern, the fact that we may not be clear on > how to transition from Experimental to Standard (for example) seems to me > to be a problem to be solved outside of the context of this specific draft - > not > something that should prevent us from using Experimental. > > > > In regards to the state of the draft, here is my summary: > > > > 1)There are multiple implementations of the draft > > 2)I am not aware that interoperability of the implementations has been > demonstrated > > 3)To the extent that interoperability could be demonstrated, I think only > centralized mode could be validated at this time > > 4)Interoperability of distributed mode requires standardization of one or > more algorithms - which means the drafts defining those algorithms first > have to progress > > > > To me, that makes "Experimental" the right track as further work is > required before we can say that all aspects of the draft are mature enough to > consider Standards track. > > > > Les > > > > > >> -----Original Message----- > >> From: Lsr <[email protected]> On Behalf Of Tony Li > >> Sent: Monday, June 13, 2022 10:12 AM > >> To: tom petch <[email protected]> > >> Cc: Acee Lindem (acee) <[email protected]>; [email protected] > >> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr- > dynamic- > >> flooding > >> > >> > >> Tom, > >> > >> In this particular case, I believe the choices are Experimental or > >> Historic. > I’m > >> fine with either. > >> > >> T > >> > >> > >>> On Jun 13, 2022, at 8:43 AM, tom petch <[email protected]> wrote: > >>> > >>> From: Lsr <[email protected]> on behalf of Acee Lindem (acee) > >> <[email protected]> > >>> Sent: 10 June 2022 15:10 > >>> > >>> Initially, there was a lot interest and energy in reducing the flooding > >> overhead in dense drafts. Now, it seems the interest and energy has > waned. > >> IMO, this draft contains some very valuable extensions to the IGPs. I > >> discussed this with the editors and one suggestion was to go ahead and > >> publish the draft as “Experimental”. However, before doing this I’d like to > get > >> the WG’s opinion on making it experimental rather standards track. > >> Additionally, I know there were some prototype implementations. Have > any > >> of those been productized? > >>> > >>> <tp> > >>> The trouble with experimental is what happens next? Does it stay > >> experimental for ever or is there some assessment at some point when it > >> becomes Standards Track? What are the criteria? I am not aware of an > RFC > >> describing such a process and the IPPM WG seemed uncertain what to do > >> with RFC8321 and RFC8889 when such an issue arose. > >>> > >>> The shepherd report for 8321 said > >>> 'the measurement utility of this extension still is to be demonstrated at > >>> a > >> variety of scales > >>> in a plurality of network conditions' > >>> as the justification for experimental but did not state how that might > later > >> be demonstrated. > >>> > >>> Tom Petch > >>> > >>> Thanks, > >>> Acee > >>> > >>> > >>> _______________________________________________ > >>> Lsr mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/lsr > >> > >> _______________________________________________ > >> Lsr mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
