Subject: RE: [newtrk] web-based lists of RFCs

From: <[email-masked]>
Date: Thu, 7 Jul 2005 06:59:57 +0300

Pekka,

> I excluded the RFC editor's queue intentionally, for two 
> reasons:
> 
>    1) the users of roadmap (and similar) documents should be able to 
> use the latest, approved draft in the meantime, before the RFC is 
> published.

Except if you an external SDO and need a stable reference, then you
are out of luck.  The users of the roadmap who can use it in draft
form are generally IETFers, who can easily go to the WG chairs, ADs
and authors and ask them the status. For folks outside of the IETF,
this doesn't work.

>    2) the delay of in the RFC publication (after approval) can 
> typically be optimized by not including normative references to 
> work-in-progress.  In the case you cite, the document has been sitting 
> idle basically because is had to wait for the completion of other 
> work.

Well, in the past, I have had drafts languish in the queue for a number of 
reasons - waiting on IANA, document status not listed correctly so that
noone knows who actually has the action point, etc., etc.  Its very normal
that drafts excede their 6 months when in the queue.  Again, if you are
not an IETFer and you are handed a document that says that it expired in
March 2005 - what are you to think?
 
> For the TCP roadmap, there had been discussion whether to include 
> references to work-in-progress, but such attempts were wisely rejected 
> by sufficient justification that we want to document the state as it 
> is now, not which we hope it to be in a year or two.  In some cases, 
> this may or may not be possible. [For node requirements, I recall that 
> security ADs requested these changes; maybe it would have been 
> possible to convince them of the timeliness requirements, if there 
> were any, maybe not.]
> 
> However, I've noticed that 2) incurs another "penalty" for the waiting 
> drafts.  When, at last, all the normative references have entered the 
> RFC editor's queue, it will take the usual ~2-4 months (or 
> thereabouts) for the referred documents to pop out.  On the other 
> hand, if the handling of documents which are required by the other 
> documents was more or less automatically expedited, we might be able 
> to cut off a couple of months from the publication of a 
> document which 
> has normative references to works in progress.
>
> Whether such an automatic expedition process might or might not have 
> unfortunate steering effects on the work flow is another debate, 
> though.  (The IESG, as it is, has the ability to request expedited 
> processing of drafts in RFC-editor's queue.)

As far as I understand, this is not a normal procedure and the RFC Editor
has pushed back against this.  In principle, expedited document processing
is not encouraged.

I really think we need to be more aware of the real users of our documents,
the one's we never meet, otherwise our documents will only be relevant to
ourselves.

John

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Jul 2005 12:24:59 +0300 (EEST)

> and authors and ask them the status. For folks outside of the IETF,

True, though if an SDO has a specific need for the draft, it could 
send a note through the liaison process indicating that (and the 
preferable timelines).  I'm not sure if that's the case here.

> March 2005 - what are you to think?

I doubt may people would even notice the expiration date.  Personally, 
I wouldn't be too worried about it as long as the date isn't long 
since in the past (e.g, >1 year).

> the one's we never meet, otherwise our documents will only be relevant to

No disagreement here, of course,. but how can we active that?  Note 
that it's not enough to find the real users of the documents, we'd 
also need to find why they need the documents.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jul 2005 09:25:30 -0400

--On Thursday, 07 July, 2005 12:24 +0300 Pekka Savola
<[email-masked]> wrote:

>> I really think we need to be more aware of the real users of
>> our documents, the one's we never meet, otherwise our
>> documents will only be relevant to ourselves.
> 
> No disagreement here, of course,. but how can we active that?
> Note that it's not enough to find the real users of the
> documents, we'd also need to find why they need the documents.

Of course, the original ISD proposal addressed that issue.  It
might be no coincidence that the issue of how users of IETF
standards who are not IETF insiders find out the approval and
relationship of documents was one of the drivers there.

     john

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jul 2005 20:18:02 +0200

> relationship of documents was one of the drivers there.

No argument there. The question now seems to be whether this
needs a formally defined document series such as the ISD proposal
of record, or a less formal web structure. The substantive content
would be much the same, I think.

    Brian

.