Subject: RFC 2026 interpretation question

From: John C Klensin <[email-masked]>
Date: Wed, 01 Oct 2008 19:39:30 -0400

Hi.

Since RFC 5321 (2821bis) has apparently just been posted, I went
back to review what 2026 says about the Draft -> Full Standard
waiting period.

What is says is that (Section 6.2)

	A specification shall remain at the Draft Standard level
	for at least four (4) months, or until at least one IETF
	meeting has occurred, whichever comes later.

That is fairly clear except it doesn't really identify the time
at which the clock starts running.  The previous section appears
to answer that question, but it sort of hits the jackpot.  What
it says is:

   6.1.3  Publication

   If a standards action is approved, notification is sent to
   the RFC Editor and copied to the IETF with instructions to
   publish the specification as an RFC.  The specification
   shall at that point be removed from the Internet-Drafts
   directory.

   An official summary of standards actions completed and
   pending shall appear in each issue of the Internet Society's
   newsletter.  This shall constitute the "publication of
   record" for Internet standards actions.

   The RFC Editor shall publish periodically an "Internet
   Official Protocol Standards" RFC [1], summarizing the status
   of all Internet protocol and service specifications.

So, we no longer remove documents from the I-D directory when
the Protocol Action notice is issued and the RFC Editor
notified.  We don't have the Internet Society Newsletter
contemplated by the second paragraph, so it can't be the
"publication of record".  And we have dropped STD0001 as a
frequently-updated publication.

So, one question is when does the clock start?  The other
question, to which 2026 does not appear to address itself at
all, is whether a Last Call can be initiated within that
four-month period or whether it has to wait until the four
months is up.

Plausible candidates for clock-starting would appear to be:

	(1) When the IESG signs off and the Protocol Action
	Notice is issued.  The IESG signed off on this on 22
	July and the Notice was issued on 24 July (not enough
	different to be worth worrying about).   If that is the
	relevant date, then, since the IETF met the following
	week, it would be possible to process 2821ter/5321bis
	to Full Standard any time after 24 November and I should
	optimally get an I-D posted sometime this month (early
	this month if it is possible to start a four-week Last
	Call around the 24th of October).
	
(2) The publication date of record for the RFC.  That date could
be the RFC Index date, in which case we have a month, not a day,
and it isn't clear whether that month is included in the four or
not.  Or it could be the date of the actual announcement, which
is today, since that just appeared, date-stamped "01 October,
2008 16:15 -0700".   That would imply an earliest processing
date of 1 February, an earliest Last Call date (see above) of 1
January and that I should have a draft up in December or perhaps
around the time of IETF 73.

Opinions (or an IESG decision) welcome, as would be an
indication of whether I really need to write an I-D that
modifies 2026 to resolve this question and whether the IESG
would be prepared to process such an I-D.

     john

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 01 Oct 2008 17:44:47 -0700

> would be prepared to process such an I-D.

First question is:  Why have any delay at all?  I presume the answer has to do 
with broader community exposure -- review and maybe experience, although 4 
months is not enough for serious experience.

If indeed that reason is right, it seems that distribution doesn't happen until 
the RFC is officially announced.  Until that moment, the document is subject to 
some change.  So that's when broader public exposure starts.

I'd rather argue for "as soon as the working group approves it", particularly 
for going from Draft to Full, but I can't think of logic that makes it compelling.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Oct 2008 07:40:54 -0400

> First question is:  Why have any delay at all?  I presume the answer has
> to do with broader community exposure -- review and maybe experience,
> although 4 months is not enough for serious experience.
> 
> If indeed that reason is right, it seems that distribution doesn't
> happen until the RFC is officially announced.  Until that moment, the
> document is subject to some change.  So that's when broader public
> exposure starts.

concur.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Oct 2008 10:17:41 -0400

--On Wednesday, 01 October, 2008 17:44 -0700 Dave CROCKER
<[email-masked]> wrote:

> First question is:  Why have any delay at all?  I presume the
> answer has to do with broader community exposure -- review and
> maybe experience, although 4 months is not enough for serious
> experience.
> 
> If indeed that reason is right, it seems that distribution
> doesn't happen until the RFC is officially announced.  Until
> that moment, the document is subject to some change.  So
> that's when broader public exposure starts.
> 
> I'd rather argue for "as soon as the working group approves
> it", particularly for going from Draft to Full, but I can't
> think of logic that makes it compelling.

Dave,

"No delay requirement at all" would, at the discretion of the
WG, essentially collapse the three-stage process into one, plus
bureaucracy. In principle, a WG (or individual submitter) could
generate a document, claim interoperability and wide deployment,
and get the IESG to vote on it three times, perhaps in the same
week.

As the author in recent (and not-so-recent) years of proposals
that would essentially replace the categorical three-step system
with descriptions of the community's confidence in a document
and that would require the IESG to move older documents directly
to Full Standard if independent implementations,
interoperability, and wide deployment and use could be
demonstrated, I think you can assume that I view changes that
would streamline things with some sympathy.

However, every single simplification proposal introduced since
2026 was published has had something in common with all the
others: inability to achieve sufficient community consensus that
the IESG would approve and process the change.

Whatever one might like in a world more optimized to our
individual desires (and yours and mine might or might not
agree), I believe it is useful to get a specific answer to a
question that 2026 leaves open, without opening the debate about
what 2026 should say in areas where it is, for better or worse,
perfectly clear.  In this particular case, I also have a very
specific issue with a pair of documents that represent
specifications whose broad deployment and utility are, I
believe, incontestable and vague text in 2026 that can be
interpreted to make a calendar quarter's difference or more.
Scott Bradner has reminded me that the IESG has discussed and
answered the question (in favor of the Protocol Action
announcement date) several times, but never written the answer
down.

I hope it is possible to get IESG and the community to agree on
a definitive answer to that question and move forward without
having to queue it behind another attempt to explore the
no-consensus ratholes of reforming the standards process or
rewriting 2026.  The way to do that, IMO, is to fix the starting
point definition (which probably requires fixing the description
of publication announcements) and treat changes to the waiting
period or other changes to the basics of the standards process
as a given for this purpose and separate issues for other ones.

Put differently, do you believe that it is useful to get this
"starting point" glitch fixed or do you feel a need to block it
until we can reopen and resolve a large collection of issues
about which we have never been able to establish consensus in
the past?  I think the correct answer to that question is
obvious, YMMD of course.

      john

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Oct 2008 09:22:38 -0700

John C Klensin wrote:
> the past?  

John,

My posting was intended to respond only to the specific and immediate question 
of when the inter-status minimum clock starts ticking that you original asked.

The only ambiguity I intended to offer was a personal preference for a 
different, specific choice, but an inability to generate logic that justified it.

Like you, I would much rather have strategic changes pursued seriously and 
adopted constructively, but that wasn't your original question and I didn't 
intend to raise it.

d/

-- 

   Dave Crocker

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Oct 2008 07:49:04 +0200

trying to see a reeasonable thing to do rather than trying to decode the 
WG's mind-of-the-time....

I don't think the writers of 2026 anticipated that people would consider 
the time delay between IESG approval and RFC publication to be significant.

To my mind, a reasonable time to make the clock start from is the date 
of the RFC Editor's announcement of RFC availability; it's an easily 
documented date (albeit not published in a permanent medium), and 
reflected (at month granularity) in the document itself, which IS a 
permanent publication.

And to my mind, it "remains at the Draft Standard" level until a new 
standards action is taken by the IESG, so the only action that cannot be 
taken until 4 months has passed is the IESG approval of the next version.

This is of course slightly inconsistent with the above, but with all the 
worries people have had with post-IESG-approval changes, it seems 
unreasonable to argue that a standard's final form is 100% set before 
the RFC comes out.

The idea of the IESG apprving a document after 3 months and trying to 
instruct the RFC Editor that publication delay must be at least one 
month seems to me to be "not worth the trouble to go there".

                     Harald

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Oct 2008 13:52:45 -0400

> at which the clock starts running.

Actually, I would assert that the term "specification" can only apply
to an RFC. Until we have the actual RFC in hand, it may be unclear
what the specification is, since there may be very last minute
changes. E.g., assignment of IANA code points.

FWIW, when I was an AD, the argument for moving to draft (typically
after a document was reissued at proposed) needing to wait 6 months
from RFC publication came from the following (quoting 2026):

     4.1.2  Draft Standard
 
     A specification from which at least two independent and
     interoperable implementations from different code bases have been
     developed, and for which sufficient successful operational
     experience has been obtained, may be elevated to the "Draft
     Standard" level.

The key thing is that the code should have been developed from the
actual specifications (and not the drafts that led to them), because
the primary thing being checked was clarity of the text in the final
RFC.

Thomas