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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Nov 2004 09:23:16 -0500

Thanks for the comments, Brian. Responses inline.

Brian E Carpenter wrote:

>> 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.

Fair point, thanks. I'll fix that.

>
> ...
>
>>    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.

I don't think so. There is a disparity between perception of what an RFC
is, and the reality. That's the difficulty here. I think it is fair to
say that the perception is that RFCs are the output of the IETF,
independent of whatever the actual percentages are.

>
>> 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.

Yes, I'll do that, thanks.

>
> 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.

I think we have a disconnect here. The key point of the draft is that
the brand of RFCs is "products of the IETF", and that the value is
derived from that. This is distinctly different a branding of "high
quality documents". I don't think anyone thinks that every document
produced by the IETF is a great document. Indeed, "great" is highly
subjective.

>
>> 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.

I think it covers at least the first four. I would not include the
special rules documents (april fools, IAB documents), or direct
rfc-editor documents.

>
>>    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.

Over time, the branding becomes associated with the acronym, not what it
stands for. This is a well-known effect. Some good examples are MCI and
AT&T. MCI stands for "Microwave Communications Incorporated"; they don't
do a lot of microwave work anymore. AT&T - American Telephone and
Telegraph - when was the last time you made a telegraph call with AT&T??
However, even though the acronyms have long since become meaningless,
the acronym itself - the combination of letters - has tremendous brand.

The same is true here. Even though many folks know RFC stands for
Request for Comment, that has ceased becoming a meaningful expansion of
the acronym a long time ago. Now, to the customers of these documents,
RFC means "the documents produced by 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)".

I'm not proposing changing what we've already done; the aim here is for
a policy that would apply to documents going forward. So, there is a
question about what to call those documents. RFC(R) is cute but probably
not what I would choose :) I'm sure we can come up with a variety of
reasonable acronyms and expansions.

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

Perhaps in the past; I think the idea here is to define quite clearly
what has to happen to get the RFC moniker.

>
> 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.

This feels to me like setting up a parallel IETF with its own review and
process, but whose documents end up in the same document series - and
without any clear distinction. In what way is that a good thing?

In terms of brand dilution - again, we are not in sync here. My
proposition is that branding is intimately tied to the fact that the
documents are products of the IETF, and the various things that this
brings - open process, technical review, community input, etc. I don't
think anyone believes that every document can or should be perfect, for
anyones definition. The value comes from the process and community
behind the specification. An enterprise or provider asks for an RFC not
because its the most technically astute solution to the problem; they
choose it because it solves a problem and its "the standard" - it was
produced by the IETF and this means that others are likely to implement
it too.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2004 20:41:35 +0100

> independent of whatever the actual percentages are.

But *whose* perception? As more and more people look objectively
at the RFC repository, and get confused about the status of
RFCs, e.g. by imagining that RFC 793 specifies TCP, or that RFC 821
is more important than RFC 2821, the "brand" will dilute itself
as the number of people consuming RFCs expands. The IETF itself
is not a very powerful brand either, outside the geek community,
and the perception that RFCs are IETF output is subsidiary
to the perception of the IETF.

So I think your view of the current brand value is optimistic.

> derived from that.

See my comment above. But my point is that non-IETF informational
publications such as RFC 1094 have manifestly had great value, have
helped the brand, and have led to real IETF work later.

> This is distinctly different a branding of "high

Well, yes, but so is everything about branding.
> special rules documents (april fools, IAB documents), or direct

What's wrong with IAB documents? The IAB is part of the IETF, as far
as I know.
> the acronym itself - the combination of letters - has tremendous brand.

RFC is a generic acronym, e.g. http://dev.perl.org/perl6/rfc/
I think once we look outside the RFC virtual hotel, we will find
that the brand is already not so tremendous.
> RFC means "the documents produced by the IETF".

Or not, depending on who you ask.
> reasonable acronyms and expansions.

Of course. My point is that we aren't dealing here with a Coca-Cola (R)
or a Linux (TM). We're dealing with a fairly weak brand here, not one that
the IPR lawyers would call a "famous name." That's why, in the end, I
am not so excited about this issue.

[Conversely, I very much like the ISD idea, because that is a real step
to reduce confusion among the consumers of RFCs.]

    Brian
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 9 Nov 2004 15:48:17 -0500

I have agreed with Mr. Carpenter in the past and hope to do so again.

Today, without actually disagreeing, I note that "RFC" as a brand had 
sufficient value to reduce the brand value of STD close to zero...

Maybe no one cares about any of this stuff, but if anyone actually 
does, I believe that more acquisition types care about RFCs than about 
IETFs, or about most protocols :-)

.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 10 Nov 2004 07:28:42 -0800

I am in complete agreement with Brain Carpenter and Spencer Dawkins on this 
draft.

I disagree with the basic premise of the draft that it is now important to 
protect RFC as a brand for the IETF.  If this was ever to be done it should 
have been done when the IETF made the decision to publish it's work as 
RFCs.  To do it now will in my opinion create little value and possibly 
more confusion.  For example, many of the core IP protocols such as IP(v4), 
TCP, ICMP, etc., were not produced by the IETF.

I think it is worth looking at ways of making clearer that an RFC is 
produced by the IETF.  For example:

   s/Network Working Group/Internet Engineering Task Force/
   s/Internet standards track protocol/IETF Internet standards track protocol/
   s/Standards Track/IETF Standards Track/

I think the broader issues relating to what is a standard are better dealt 
with the ISD approach.

Bob

.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 2004 13:28:36 -0500

Bob Hinden wrote:

> I am in complete agreement with Brain Carpenter and Spencer Dawkins on 
> this draft.
> 
> I disagree with the basic premise of the draft that it is now important 
> to protect RFC as a brand for the IETF.  If this was ever to be done it 
> should have been done when the IETF made the decision to publish it's 
> work as RFCs.  To do it now will in my opinion create little value and 
> possibly more confusion.  For example, many of the core IP protocols 
> such as IP(v4), TCP, ICMP, etc., were not produced by the IETF.

But things were different back then. Just because a process was wrong or 
not in place in the past, doesn't mean its not right now. The draft does 
point out a few things that have changed, which make this problem more 
pressing now.

As such, let me ask this - do you think it makes sense to do assuming 
the IETF were to start its existence from this moment of time?

>   s/Standards Track/IETF Standards Track/

Having the up front boiler plate definitely helps, but I think it needs 
to go farther than that. I think the moniker itself needs to provide 
this context.

Thanks,
Jonathan R.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 10 Nov 2004 11:26:44 -0800

Jonathan,

>point out a few things that have changed, which make this problem more 

I, of course, disagree that this is a pressing problem now.

>As such, let me ask this - do you think it makes sense to do assuming the 
>IETF were to start its existence from this moment of time?

No.  If we were to be starting now it would be a big win to use the exiting 
RFC series containing the protocols that are in wide use in the Internet.

Bob

>Having the up front boiler plate definitely helps, but I think it needs to 
>go farther than that. I think the moniker itself needs to provide this context.
>
>Thanks,
>Jonathan R.
>
>--

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2004 13:30:15 -0500

--On Tuesday, 09 November, 2004 15:48 -0500 Spencer Dawkins
<[email-masked]> wrote:

> Today, without actually disagreeing, I note that "RFC" as a
> brand had sufficient value to reduce the brand value of STD
> close to zero...

I would suggest that was not the problem.  _We_ didn't really
use STDs, so could not expect anyone else to do so.  And, when
people looked for "STD" documents, they couldn't find any.
There may be some important points here, but they almost
certainly do not include "enough RFC brand value to reduce the
value of STDs to zero".  And, even if that were the case, it
would argue at least as strongly for getting all
non-standards-track documents out of the RFC series as it would
for non-IETF ones.

   john

.