[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Michael Jones <[e-mail]>]

My experience has been that the IETF has expeditious specification development processes, especially as compared to some of its competitors.  As concrete evidence, I have authored five working group RFCs that went from first individual draft submission to completed standards-track RFC in less than a year:

  *   https://datatracker.ietf.org/doc/rfc7638/ 10 months, 2015
  *   https://datatracker.ietf.org/doc/rfc7797/ 9 months, 2016
  *   https://datatracker.ietf.org/doc/rfc8943/ 8 months, 2020
  *   https://datatracker.ietf.org/doc/rfc9278/ 9 months, 2022
  *   https://datatracker.ietf.org/doc/rfc9596/ 11 months, 2024



There’s a bunch more that went through the whole process in less than two years.



Yes, as pointed out by Paul, self-delay is always an option:

People complained about the IESG being slow and last IETF numbers were presented that showed it wasn't the IESG but far more authors in AUTH48 delaying themselves.



But in my experience, if you stay on task progressing your draft, the IETF specification process is responsive and timely, while still providing valuable working group, IETF, and IESG reviews to improve the specification along the way.



                                                       Sincerely,

                                                       -- Mike



-----Original Message-----
From: Randy Bush <[e-mail]>
Sent: Friday, November 29, 2024 12:54 PM
To: Paul Wouters <paul.wouters=[e-mail]>
Cc: IETF SAAG <[e-mail]>
Subject: [saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt



< rant >



>> A draft may be stable.  The spec in the draft is not.  Authors may

>> choose to update that spec at any time.  Therefore, if implementers

>> are looking for spec stability, drafts are the wrong

>

> As long as the code points are references by versioned drafts, this is

> not an issue. We are looking at the few cases where this was done

> using an unversioned draft and working with IANA to resolve those.



it is not about control, our delicate egos, blah blah blah



standards are for the *users* so that we have vendor/implementation choice.  the screw from vendor A must fit the nut from vendor B.

this would seem to require long lived immutable documents.  to create them is why we go through the review process from hell.  as eliot points out, internet-drafts do not make that bar, period.

neither does github.



the ietf's politically dominated and vendor driven process seems to have become so farblunget that doing work 'outside' (aka in the real

world) becomes more and more attractive.  and this 'discussion' sure makes that tension clear.



doing work inside the ietf should be attractive and productive, not like pushing a rock uphill while being second guessed.



randy, hearing the ghosts of jon, bob braden, joyce, ...



_______________________________________________

saag mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>