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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 2 Dec 2007 17:34:14 -0800

Only issue I would raise here is don't expire the ID if this situation arises...

If there is an IESG action and an ID folk can read that is going to work for most people.

Don't publish the rfc before the appeals counter expires, there lies all sorts of bad stuff and confusion.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Russ Housley [mailto:[email-masked]]
Sent:	Saturday, December 01, 2007 05:58 PM Pacific Standard Time
To:	Alexey Melnikov; [email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	Re: Should the RFC Editor publish an RFC in less than 2 months?

Alexey:

The latter.  If the Auth48 completes before the 60 day appeal timer 
has expired, then the RFC Editor will hold off on publication until 
the 60 days have gone by.

Russ

P.S. A document that I wrote was the first document to get snagged in 
this situation.  I guess it is only fair....  It got published yesterday.

At 06:54 PM 12/1/2007, Alexey Melnikov wrote:
>Russ,
>
>IETF Chair wrote:
>
>>While we figure out what policy we want, I have asked the RFC Editor to
>>not publish any IESG approved documents until their appeal timer has
>>expired.  I also challenged the RFC Editor to move things along so fast
>>that this matters.  I suspect they can.  Which means that the whole IETF
>>community needs to help the leadership figure out the appropriate policy
>>before the rapid processing of Internet-Draft documents into RFCs becomes
>>the norm.
>>
>I would like to ask a clarifying question: does this mean that RFC 
>editors are not going to start editing the document until after 2 
>months since approval of a document, or does it mean that RFC 
>editors start editing right away, can issue AUTH48 request, but will 
>delay publication until after 2 months?
>
>I think the latter is better, because (a) appeals are not that 
>frequent and (b) AUTH48 usually takes way longer than 2 days ;-).
>
>Regards,
>Alexey
>
>P.S. I apologize in advance for asking the question before reading 
>the whole thread. Maybe it was already asked.
>
>
>

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

---

From: Robert Elz <[email-masked]>
Date: Mon, 03 Dec 2007 16:49:41 +0700

Date:        Sun, 2 Dec 2007 17:34:14 -0800
    From:        "Hallam-Baker, Phillip" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Only issue I would raise here is don't expire the ID if this situation
  | arises...

That did not really need to be said - once submitted for IESG action,
I-Ds go into a limbo state where they hand around until something happens,
either the IESG rejects them, or the RFC is published, during that interval
(however long it is, and it has been many years in a few extreme cases)
the I-D simply remains available for reference.

That, and that the RFC editor allocates the RFC number as one if its
first actions after receiving approval to publish (I believe) has led
me to read this entire discussion with something bordering on incredulity.

Everyone (almost everyone) seems to be assuming that getting  the RFC
published as quickly as possible is the aim.   Why?   What does actual
appearance of the file in the directories really change?   Sure, it makes
access a little easier, but that's it (and I guess that now, we could have
a temporary placeholder installed, a file called rfcNNNN.2b or something,
containing the URL of the I-D that will become the RFC when the editing
process is finished - I personally doubt it is necessary, but it could be
done).

Certainly having the RFC editor reduce the publication delays is a laudable
goal, if it RFCs are getting published at a rate slower than the IETF is
producing them (over a lengthy period), then we'd have a problem - but if
the RFC editor can publish faster than the IETF can produce, then the editor
simply has to stall - whether that occurs at the point where everything that
has been produced by the IETF is published, or when nothing produced by the
IETF is greater than 2 months old really makes no difference at all.

Where we want to avoid delays is in everything that happens before the RFC
is approved for publication - once that happens its text is (minor editing
aside) known, its citation is known, everything that matters is known,
and how long the final step takes isn't that important.

  | Don't publish the rfc before the appeals counter expires, there lies all
  | sorts of bad stuff and confusion.

I agree.   Certainly if there is an appeal then until the appeal is
resolved, or it is ascertained that the result of the appeal won't
affect what is published (the fact, or the content) then publication
needs to be stalled.   Waiting the prescribed period for appeals (however
long that is, which is a different discussion entirely) before publication
doesn't hurt anything, and avoids all kinds of changes being needed to how
the RFC archives are maintained.

What's more, doing this requires no changes to anything at all - we just
ask the RFC editor not to get "too" efficient - to use common sense and
not publish anything within the appeals window (however long that is
updated as it changes) and everything will be happy.

What's more, given that essentially no RFCs have ever been (before now)
ready to publish that quick anyway, this isn't going to seem any different
to what we have had (ever since appeals have existed anyway) - everything
will just continue as it always has, and would have, without complaint,
had this issue not been raised.

kre

---

From: Norbert Bollow <[email-masked]>
Date: Mon, 3 Dec 2007 12:24:45 +0100 (CET)

> sorts of bad stuff and confusion.

+1

Greetings,
Norbert.

-- 
Norbert Bollow <[email-masked]>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Dec 2007 09:04:38 +1300

On 2007-12-03 22:49, Robert Elz wrote:
...
> appearance of the file in the directories really change?   

It's the instant of formal publication, and that changes at least
two things:

1. It allows other SDOs that require a normative citation to proceed
with *their* publication process, in order to meet their own deadlines.
This has been a much more frequent situation than appeals in recent
years (with ITU-T and 3GPP being the SDOs mainly concerned, iirc).

2. It triggers action by product developers and writers of RFPs,
especially those not actively involved in the IETF. The RFC name
is powerful enough that there really is an impact - people *do*
wait until the RFC comes out, or hear about things for the first
time then.

> Sure, it makes

The RFC Editor hates to reveal RFC numbers until publication is
a certainty. There is an unofficial list of approved but not published
drafts, however, at http://rtg.ietf.org:8080/Test/parking
(assuming it still works - I'm off line and can't check).

     Brian

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Dec 2007 15:23:54 +0700

Date:        Tue, 04 Dec 2007 09:04:38 +1300
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | It's the instant of formal publication, and that changes at least
  | two things:
  | 
  | 1. It allows other SDOs that require a normative citation to proceed
  | with *their* publication process, in order to meet their own deadlines.

And do you really believe that some other SDO wants to proceed with their
own activities, only to be told a few weeks later that the RFC has been
wathdrawn after a successful appeal?    Don't you expect that they're really
after some kind of stability?    If they really need the actual RFC, don't
you think that is because they want the stability that gives - and in that
case, shouldn't we be making sure that RFC publication actualy means what
it has meant in the past - and not be just a temporary parking place until
an appeal (rarely, for sure, but possible) causes it to be removed?

For general citations, just having the data is enough.   Don't you ever
cite papers (your own, or others) that you know are to be published in
some journal or proceedings, before he actual paper copy arrives on your
desk?

  | 2. It triggers action by product developers and writers of RFPs,
  | especially those not actively involved in the IETF.

Same as above.   If you're issuing an RFP, wouldn't you look a bit
silly if you demanded conformance to an RFC that didn't actually exist
at the time the responses were due?

  | The RFC Editor hates to reveal RFC numbers until publication is
  | a certainty.

Yes, Joel Halpern, in a private message, also pointed that out - I wasn't
as clear as I should have been.  What I meant (should have said) was that
at some point in the RFC process (now, past, and no necessary reason to
change this in the future - though it could be done) the RFC number is
allocated.  That's certainly before AUTH48, as when the authors get their
copy to review, the RFC number is there.   There's no reason any of that
should change, or be delayed - the RFC number will still be available
as soon as the RFC Editor is ready to make it available, and if that gets
closer and closer to the IESG's approval action, that's just fine.  There
is a variable length delay (and potential termination) of the publication
process now, between number allocation and actual publication - the only
question is whether it makes sense for there to be some minimum delay to
make sure that appeals are no longer possible.

If the RFC Editor really wants to hold the number secret until the
actual publication is certain, then that means altering current practice,
as it is certainly possible for an RFC to be withdrawn during AUTH48.
What's more, even ignoring that, if publication is made as soon as possible,
the effect would be that occasionally (infrequently for sure) an RFC will
get published, only to be removed later after an appeal- and I'd think that's
something the RFC Editor would like even less than the occasional "this RFC
was never published" gap in the numbering scheme, because of an allocation
that ended up unused.

kre