Subject: RE: RFC queue documents stuck on a normative reference

From: [email-masked]
Date: Fri, 29 Jul 2005 18:31:16 +0300

Thomas & Brian,

If sending the diff text to the wg mailing list and giving a 
week (or so) comment time; along with buy-in from the shepherding
AD, was sufficient, then I think this is a good way to take care of
this.

I think I may even have use for this (as WG chair) so I'd be happy to
try this out.

thanks,
John

> -----Original Message-----
> From: ext Thomas Narten [mailto:[email-masked]]
> Sent: 29 July, 2005 17:24
> To: Loughney John (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: RFC queue documents stuck on a normative reference 
> 
> 
> > > Opinion: for something that has already been approved by the IESG,
> > > this would count as a substantive change - so I would 
> recommend a mini
> > > WG last call followed by a formal note to the AD, who 
> should run it
> > > past the IESG before a formal note is sent to the RFC Editor.
> > > 
> > > The reason I think it's substantive is that we tend to consider
> > > normative reference problems worthy of a DISCUSS during IESG
> > > evaluation. (Hmm. Not mentioned in 
> draft-iesg-discuss-criteria-00.txt)
> 
> I think the above is the correct general procedure.
> 
> > Which prompts the question - which will be faster - mini WG LC plus
> > potential IESG review and re-editing by the RFC Editor; or 
> just waiting
> > for the reference to clear ...
> 
> The key question impacting "delay time" is the extent of the
> changes. Converting a normative reference to an inforamtive is usually
> well-scoped and there is presumably a strong motivation for doing so.
> 
> Where a LC and revised document typically get into trouble is when
> there are many changes, and the implication that they need to be
> reviewed, with the review being non-trivial (and getting folk to
> re-review is problematical).
> 
> While "waiting for the reference to clear" may seem simplest, it has a
> real downside (besides the fact that many "almost done" documents drag
> out forever). The RFC Editor queue is rather backlogged these days. If
> one waits for another document, that document (when it finally gets
> approved) presumably enters the queue at the lowest priority and also
> sits in the queue for yet more time. This will delay the other blocked
> documents, since the entire set of documents (involved in normative
> reference relationships) get published together (i.e., at the same
> time).
> 
> > Having been involved in some 'interesting' AUTH48 situations, its
> > not clear that resubmitting the draft after much editing by the
> > RFC editor is a good idea.  Often, the author's source file and
> > what the RFC has edited has diverged significantly, so resumitting
> > the draft & losing all of the changes may create further delays 
> > since the RFC Editor will need to re-edit the document, thus
> > incuring yet another delay.
> 
> Agree with this. For a small number of changes, sending diffs (RFC
> Editor, not Unix style) minimizes the work for all. But a lot of this
> depends on whether the RFC editor has already invested cycles, etc. In
> general, it's probably good to check with ADs/RFC Editor on best way
> to proceed (once the text changes have been agreed to).
> 
> > (Thomas: nothing stays the same. RFC Editor Notes are now known as
> > Notes to the RFC Editor.)
> 
> Well, I certainly can't deny that the new wording is more
> precise/clear! :-)
> 
> Thomas
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 29 Jul 2005 11:40:19 -0400

> AD, was sufficient, then I think this is a good way to take care of

FWIW, I've done this a number of times. It was a judgement call
whether to run it by the IESG as well, but in general I think it's
better to do so than not. In most cases, I'd expect it to effectively
be an FYI.

Thomas