Re: Should the RFC Editor publish an RFC in less than 2 months?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "John C Klensin" <john-ietf@xxxxxxx>

--On Saturday, 01 December, 2007 13:59 +0100 Frank Ellermann
<nobody@xxxxxxxxxxxxxxxxx> wrote:

Tom Petch wrote:

a 60 day hold seems rather a good idea.

Indeed, unless somebody transforms John's proposal "6 weeks"
in an ION and/or 2026 update, or whatever red tape cutting
this needs.  If appeals are drafted by a kind of community
this needs time (e.g. to figure out who read the relevant
"procdoc" RFCs... ;-)

Frank, while figuring out what we are doing and documenting it
would certainly be a good idea, my suggestion was carefully
written to be feasible without any action as formal as opening
2026.

The metapoint that John may have assumed (because I know he knows it, because he's pointed this out to me many times) is that every time we stick very specific stuff in process BCPs, we regret it.

I had the privilege of working on a minor process revision to RFC 3777 (NomCom process) earlier this year, and that was a dream, because all the dates were deadline-driven - we wanted to START earlier, and there was very little stopping us from STARTING earlier.

When we get very specific, we find ourselves publishing "what we really meant was" BCPs that fix previous BCPs, with nice long publication delays while we either run under broken rules or ignore them and hope no one appeals.

And THAT is why John is right about not "opening 2026", which is actually a codename for "reopening every process discussion we've had since 2027 was published". Someday we might "open 2026", but it shouldn't be for this reason.

Thanks,

Spencer


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]