I’ll point out that option 2 frees us from having to run an annual exception process to renew the code points. I mean, if the draft is being actively worked then of course keep it in draft, but don’t just version-bump it ad infinitum (it wasn’t clear to me if that was what you meant by “continue to refresh”).
Thanks, —John > On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > John - > > I would be inclined to agree with you - but...to my knowledge (happy to be > corrected...) - > > There has been no interoperability testing. > It is really only possible to do interoperability testing on centralized mode > at present, since distributed mode requires standardization/multi-vendor > implementation of at least one algorithm - which hasn’t happened yet. > So, a significant portion of the protocol extensions remain untested. And > since enthusiasm for this work has waned - perhaps only temporarily - it > seems unlikely that these gaps will be closed in the immediate future. > Moving to standards track RFC with these gaps seems unwise and to some degree > "irresponsible". > > I think there are then three viable paths: > > 1)Continue to refresh the draft until such time as the gaps are closed or it > becomes clear the work is more permanently not of interest > 2)Capture the current contents as an Experimental RFC - noting the remaining > work. > 3)Capture the current contents as a Historic RFC - noting the remaining work. > > I am not in favor of #3. > I would be OK with #1 or #2. > > Les > > >> -----Original Message----- >> From: Lsr <[email protected]> On Behalf Of John E Drake >> Sent: Tuesday, June 14, 2022 11:23 AM >> To: Les Ginsberg (ginsberg) <[email protected]>; John >> Scudder <[email protected]> >> Cc: Tony Li <[email protected]>; tom petch <[email protected]>; Acee >> Lindem (acee) <[email protected]>; [email protected] >> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic- >> flooding >> >> Hi, >> >> I don't understand why we don't just go through the normal Standards track >> process. I am sure there are any number of Standards track RFCs which are >> published and which are neither widely implemented nor widely deployed, >> but which may become so in the future. >> >> As Peter noted in the context of another draft, we are starting to see >> extreme growth in the size of IGPs which to me indicates that the subject >> draft will be perceived as timely in the not too distant future. >> >> Yours Irrespectively, >> >> John >> >> >> Juniper Business Use Only >> >>> -----Original Message----- >>> From: Lsr <[email protected]> On Behalf Of Les Ginsberg (ginsberg) >>> Sent: Tuesday, June 14, 2022 12:19 PM >>> To: John Scudder <[email protected]> >>> Cc: Tony Li <[email protected]>; tom petch <[email protected]>; Acee >> Lindem >>> (acee) <[email protected]>; [email protected] >>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr- >> dynamic- >>> flooding >>> >>> [External Email. Be cautious of content] >>> >>> >>> John - >>> >>> Thanx for the information. >>> >>> I think what is relevant as regards the dynamic-flooding draft is that we >> may be >>> prematurely burying it. >>> It is true, as Tony has stated, that the marketplace has not shown an active >>> interest in deploying this technology - but I am not yet convinced that >>> this is >> the >>> final disposition. As the scale of IGP networks increases and the use of >>> fast- >>> flooding is deployed, it may be that interest in dynamic-flooding is >>> revived. >>> >>> Publishing the draft as Experimental leaves open the possibilities. >>> It could still be moved to Historic somewhere down the road if there >> continues >>> to be no deployment interest. >>> >>> I suppose it is also possible (as your post indicates) that we move it to >> historic >>> now and find a way to move it from historic if/when the need arises - but I >>> frankly find such an approach very odd. >>> >>> I do not know why we are in a rush to "bury this". I think Acee has raised a >> valid >>> point - given that there was broad consensus on the protocol extensions >>> themselves - that it would be good to formally preserve the draft content. I >> think >>> Experimental is the best way to do that. >>> >>> Les >>> >>>> -----Original Message----- >>>> From: John Scudder <[email protected]> >>>> Sent: Tuesday, June 14, 2022 7:46 AM >>>> To: Les Ginsberg (ginsberg) <[email protected]> >>>> Cc: Tony Li <[email protected]>; tom petch <[email protected]>; Acee >>>> Lindem (acee) <[email protected]>; [email protected] >>>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - >>>> draft-ietf-lsr-dynamic- flooding >>>> >>>> Hi Les and all, >>>> >>>>> On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg) >>>> <[email protected]> wrote: >>>>> >>>>> 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. >>>> >>>> It so happens I recently became aware that this publication track is >>>> explicitly considered to be OK. >>>> >> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta >>>> tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh- >>> l3RWY9vSXdEA8b >>>> >>> >> Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSw >> HRw >>> YyGo$ >>>> historic-2014-07-20/ sez >>>> >>>> "An RFC may be published directly as Historic, with no earlier status >>>> to change (see, for example, RFC 4870). This is usually done to >>>> document ideas that were considered and discarded, or protocols that >>>> were already historic when it was decided to document them. Those >>>> publications are handled as are any other RFCs.” >>>> >>>> $0.02, >>>> >>>> —John >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! >> !NEt >>> 6yMaO-gk!GYT66d5pSskUh- >>> >> l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv >> ppQ >>> pFMmp2bSwFi578Bc$ >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!F8g1L3YtAdGXyvqeiCcjcQaq2Oh1U_NaDrdGJE9Z7udh4p9iK4I6BFT_2TlVi8_gNEdU9ghhVsI564bNBcUqX29MegiE$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
