Subject: [newtrk] Re: I-D ACTION:draft-rosenberg-mankin-newtrk-rfc-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Nov 2004 17:30:59 +0100

> 4.1  Decrease in Provider Demand for RFCs
> 
>    When service providers look to build out a network,

I don't think it is correct to restrict this to "providers".
It applies to enterprise customers just as much. This occurs in
several places.

...
>    If RFCs lost their brand, service providers would not ask for them in
>    advance of detailed examination, and their consideration would, in
>    fact, be equal to any other series of documents not produced by a
>    standards organization - virtually nil.  The bar would be raised much
>    higher for such a document to be considered, and as such, more good
>    work would go unnoticed, reducing overall demand for IETF
>    specifications.

Hmm. Given that probably not more than 33% of existing RFCs are IETF-approved
specifications, it seems to me that the brand is fairly dilute already.

> 5.  Why is this a problem now?
> 
>    The disconnect between the perception of an RFC and its actual
>    meaning is not new.  This fact has existed for as long as the
>    industry perceived RFCs to just be the product of the IETF standards
>    process - perhaps the last 5-10 years. 

You might refer to RFC 1796, Not All RFCs are Standards, C. Huitema,
J. Postel, S. Crocker, April 1995. It gives the arguments for the status quo.

At the end of section 5, I think you should give examples of where it
worked well - NFS is a clear example - informational publication of a
non-IETF spec served a good purpose, and now the IETF is the maintainer
of NFS. There are certainly other examples.

And conversely, how about a couple of examples where RFC publication
by IETF process has damaged the brand? We certainly all have our
favourite examples.

> 7.  Recommendation
> 
>    Our proposal is that the term "RFC" only be given to documents which
>    are produced as part of the process described in Section 6.1 of RFC
>    2026.  This includes working group documents and documents developed
>    outside of a working group.  It includes experimental and
>    informational documents, in addition to standards track. All of
>    these documents are still published through the Internet standards
>    process, providing review, comment, an open process and a structure
>    for appeals.

I don't think this includes all the 5 categories listed in RFC 3932
as *not* being handled solely by the RFC editor.

>    Documents published by the RFC editor, but did not go
>    through this process, should be given a different title and be part
>    of a different document series.  These documents are still important
>    and still deserve publication.  However, the name they are given
>    should be different.

Here's the problem. The correct name for those documents is
Request for Comments. It's a lousy name for the ones that have been
reviewed in the IETF. We'd end up with the world on its head, "RFC"
for the ones that least call for comments. Unless we call
the others RFC(R) for "Request for Comments (Really)".

Also, cases like NFS suggest to me that the boundary between the
categories is fuzzy - in the end it's a judgement call.

I've gone both ways on this but I've finally concluded that we
are probably better off to *not* make the change.

I would prefer to focus on the RFC Editor judgement call -
i.e. I think we (for some definition of "we") should create a
review team for RFC Editor submissions, that would subject
them to an IESG-like but independent review. The RFC Ed does
have an editorial committee, I believe - but it isn't reviewing
in public, as the IESG now does (through the tracker). I think that
by going public with the review process, we could get RFC Editor
submissions to a quality level where brand dilution would be much
less of a risk.

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 3 Nov 2004 19:54:29 -0600

I'm violently agreeing with Brian here.

> the others RFC(R) for "Request for Comments (Really)".

I've talked with Harald on more than one occasion about how the IETF 
might crawl out of the RFCs-that-aren't-requests-for-comments, 
RFPs-that-reference-RFCs and 
RFCs-that-aren't-Standards-or-even-standards-track tarpits.

I honestly couldn't think of a way - the obvious candidates (getting 
community consensus to deprecate the name, publishing so many RFCs 
that we'd be forced to come up with an indexing scheme besides 
increasing integers) seemed unlikely to achieve community consensus.

Maybe we can ask the question one more time. Punting the "what should 
the IETF output be called really?" isn't going to help us out of this 
Escher print, though.

Spencer 

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 04 Nov 2004 10:56:10 +0100

> specifications, it seems to me that the brand is fairly dilute already.

this doesn't ring true with me.....

the rfc-index.xml includes the name of the internet-draft that resulted in 
the rfc. Can someone do the homework to count how many of them have 
resulted from "draft-ietf", thus establishing at least a lower limit on how 
many resulted from IETF work?

(a lot of personal-named documents are really IETF work, so it's a lower 
limit, not an exact count. If we also conted the things that have been on 
the standards track as "IETF" documents, we'd be closer.)

            Harald

.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 08 Nov 2004 10:25:27 -0500

Harald Tveit Alvestrand wrote:

> the rfc-index.xml includes the name of the internet-draft that resulted 
> in the rfc. Can someone do the homework to count how many of them have 
> resulted from "draft-ietf", thus establishing at least a lower limit on 
> how many resulted from IETF work?

Of the 1358 RFCs that have a draft name listed, 966 are ietf-* names, 
which figures out at 71%.

	Tony Hansen
	[email-masked]
.