Subject: RE: Allocating RFC numbers at time of approval

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 19 Sep 2005 20:10:41 +0300

Dave,

I am not sure how good a thing this is when it comes to other SDOs.
Looking at the example that we both know with the Bridge MIB, is it good
to allow the IEEE 802.1 WG in this case refer documents that may still
go through changes as results of IANA actions, or possible appeal
impact? 

I am all in favor of cutting red-tape and shortening time, but we need
to be careful - maybe making official a
'RFC_number_allocated_but_not_published status' is better, but would
this help?  

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B Harrington
> Sent: Monday, September 19, 2005 7:35 PM
> To: 'Allison Mankin'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Allocating RFC numbers at time of approval 
> 
> Hi,
> 
> That would help for those circumstances where a reference is 
> needed, yes.
> It would also presumably allow WGs to resolve the references 
> in subsequent documents, saving the RFC Editor the time to do this.
> 
> While this proposal helps some, it would be even better if we 
> could speed up the process of publishing the RFCs.
> 
> David Harrington
> [email-masked] 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Allison Mankin
> > Sent: Monday, September 19, 2005 12:03 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Allocating RFC numbers at time of approval
> > 
> > I've been thinking about this for some time, motivated by the fact 
> > that very big fraction (need to do the numbers) of TSV 
> documents have 
> > someone who requested expedited publication or someone who 
> sent mail 
> > of concern about delay in the RFC number, about delay in the RFC 
> > number appearing in the IANA registry.
> > 
> > I have in mind the following outline, chronologically (with details 
> > needing filling in...)
> > 
> > - IESG approves document, which may include some
> >    "Notes to the RFC Editor" - text changes resulting
> >     from the review or late Last Call
> > 
> > - IESG obtains the next technical publication designator
> >    for use ("RFC number") and holds it (or obtains it
> >    at the time below - this is an implementation detail,
> >    as is how the IESG/Secretariat actually take the
> >    actions in this outline).
> > 
> > - IANA performs IANA actions for the document, which
> >   are technically complex and have give and take, so
> >   they begin as early as the document is technically
> >   stable (before it's possible to put the number in
> >   the registry) - IANA places i-d placeholder.
> > 
> > - The two month timeout on appeals runs out (document approval
> >   is now final).
> > 
> > - technical publication designator can now be assigned to
> >   document and given to IANA for its registry information.
> > 
> > At this time:  an new internet-draft should be prepared with the 
> > string -
> draft-ietf-<wg>-<orginalrestofstring>-rfc####-00.txt
> > (or something like that).
> > 
> > Instead of the existing i-d headers, where the expiration 
> date quite 
> > bothers outsiders, because an approved draft may not be an RFC
> 
> > before its original (now meaningless to IETF) expiration:
> > 
> > OLD:
> > INTERNET-DRAFT
> > September 5, 2005
> > Expires: March 5, 2006
> > 
> > The new draft would use:
> > 
> > NEW:
> > RFC-TO-BE ####
> > Approved September 30, 2005
> > Expires at RFC Publication
> > 
> > This new i-d would not be as beautiful as the RFC 
> publication, but it 
> > would incorporate the text changes and would be technically 
> stable (we 
> > can consider this also as pushing back on all but the 
> biggest and most 
> > urgent of late technical fixes, asking them to be new documents).
> > 
> > The IANA would be given the RFC number at that two-month 
> date by the 
> > IESG and given more urgency about putting those numbers in the 
> > registry RIGHT AWAY.
> > 
> > As Brian says, support for this would have to come from a 
> reasonable 
> > swathe of people in the IETF, but if a lot of chairs like 
> it, that is 
> > a good start :)
> > 
> > 
> > 
> >     
> > 
> > 
> 
> 
> 
>

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 19 Sep 2005 14:32:06 -0400

Hi Dan,

Currently, we cannot give the IEEE 802.1 WG the RFC#s for BRIDGE WG
documents that have been approved. We can give them the I-D revision
that has been approved, but there is the danger that the I-D will
expire, and the I-D may not have all the IESG comments present or the
IANA assignments reflected.

I think the suggestion for a middle ground approach - an I-D that
includes any IESG-requested changes and the IANA assignments and the
assigned RFC#, published after the appeals process ends - seems to
meet some of the cross-SDO requirements better than the current
approach, although not as good as actually getting the RFC published.

And where another SDO needs only an **informative** reference to the
RFC, there is a very good chance they can cite the assigned RFC#
without a problem. They cannot cite an I-D that will expire and no
longer be available, without problems.

David Harrington
[email-masked]

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, September 19, 2005 1:11 PM
> To: [email-masked]; Allison Mankin; [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 19 Sep 2005 14:46:01 -0400

On Mon, 2005-09-19 at 14:32, David B Harrington wrote:
> expire, 

not a problem -- as best as I can tell, I-D's which have been placed
before the IESG don't actually expire until either they are published as
RFC's or the IESG declines to publish them. 

> and the I-D may not have all the IESG comments present or the

that's much more of a concern; however, the information is available -- 
IANA assignments appear in the IANA registry shortly after IESG approval
and IESG comments are available in the datatracker.

					- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Sep 2005 11:05:23 +0200

> RFC's or the IESG declines to publish them. 

Correct. The normal expiry timer is suspended.

> and IESG comments are available in the datatracker.

Specifically, the (optional) IESG Note and Note to the RFC Editor fields
in the writeup contain *all* changes approved by the IESG. Of course,
editorial changes will also happen.

In fact you can find all this except the future RFC number in the parking
area (http://rtg.ietf.org:8080/Test/parking).

     Brian