Subject: Re: My comments to the press about RFC 2474

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 12:57:41 -0700

DiffServ is a prioritization scheme, Brian, how can you say it's not? 
IntServ is a reservation scheme, and DiffServ attempts to provide 
desired PHBs in practice by sorting packets into priority queues and 
invoking appropriate Link Layer  facilities, which are in most cases 
priority-based, such as 802.11e traffic classes.

What on earth could the value of DSCPs be if they didn't map to traffic 
classes in the data link?

RB

  Brian E Carpenter <[email-masked]>  wrote:
 > Russ,

 > It has been consistently hard to explain that diffserv is not a
 > prioritisation scheme, even within the technical community, let
 > alone to the regulators and the media. I think your comments as
 > quoted are as good as we can expect from journalists.

 > It should be a matter of concern to all of us here that the US FCC
 > isn't confused into regulating the technology. It would set a bad
 > precedent for regulators in other countries. I am making no comment
 > as to whether they should regulate carrier's charging practices; that's
 > entirely a national matter that shouldn't concern the IETF in any way.

 > Regards
 > Brian Carpenter

 > On 2010-09-03 05:47, Russ Housley wrote:
 > > I want the whole community to be aware of the comments that I made to
 >> the press yesterday. Clearly, these comments do not represent IETF
 >> consensus in any way. They are my opinion, and the reporter was told to
 >> express them as my opinion.
 >>
 >> One thing that I said was not captured quite right. The article says:
 >> "With services that require certain speeds to operate smoothly, such as
 >> Internet telephony, calls are given precedence over TV, Housley said."
 >> I actually said that DiffServ can be used to make sure that traffic
 >> associated with applications that require timely delivery, like voice
 >> and video, to give preference over traffic associated with applications
 >> without those demands, like email.
 >>
 >> The whole article is copied below, and it is online here:
 >> http://www.nationaljournal.com/njonline/tc_20100902_7144.php
 >>
 >> Russ

-- 
Richard Bennett
Senior Research Fellow
Information Technology and Innovation Foundation
Washington, DC

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Sep 2010 08:06:37 +1200

Richard,

Diffserv deals with multiple different queuing disiplines, which may or may not be priority based. Please read RFC 2475 and if
you like, B.E. Carpenter and K. Nichols, Differentiated Services in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494.

    Brian

---

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 13:13:47 -0700

Thank you for replying Brian. I've not only read the requisite RFCs, 
I've also implemented DiffServ over 802.11e. My implementations, like 
those of everyone else who has done this, invoked the prioritization 
mechanisms in 802.11e. This is a very common case. Another common case 
implements DiffServ using 802.1d priorities.

If you want to say that DiffServ is not itself a priority scheme but 
rather a system for selecting the use of priority schemes at the Data 
Link (or comparable facilities,) you're making a distinction that's too 
fine for the press. As Russ is now invoking your message to support his 
view that payment for premium service is contrary to the wishes of IETF, 
that's a problem.

RB

On 9/3/2010 1:06 PM, Brian E Carpenter wrote:
>>   Brian E Carpenter<[email-masked]>   wrote:
>>> Russ,

---

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 13:40:18 -0700

This is what the press is saying:

"The head of the Internet's leading standards body said Thursday
that it is "misleading" for AT&T to claim that its push to
charge customers for high-priority service is technically justified.

"Internet Engineering Task Force chairman Russ Housley told
CNET that AT&T's arguments to federal regulators, which
cited networking standards to justify "paid prioritization" of
network traffic, were invalid.

""AT&T in their letter (to the Federal Communications
Commission) says the IETF envisioned this," Housley said.
"That's not my view.""

http://news.cnet.com/8301-13578_3-20015498-38.html

It's quite clear that Russ' remarks have been taken to mean
"the head of the IETF says payment for premium service was
never envisioned by the IETF" regardless of what he may or may
not have said.

RB

Read more: http://news.cnet.com/8301-13578_3-20015498-38.html#ixzz0yV7O8Ofv

On 9/3/2010 1:34 PM, Matthew Ford wrote:

On 3 Sep 2010, at 21:13, Richard Bennett wrote:

As Russ is now invoking your message to support his view that payment for premium service is contrary to the wishes of IETF, that's a problem.

No, it really isn't. That's not what Russ said.

Mat

---

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 13:49:29 -0700

The article goes on to say:

"We didn't foresee
AT&T throwing our name into this discussion," the IETF's
Housley said. He added: "This characterization of the IETF
standard and the use of the term 'paid prioritization' by
AT&T is misleading."

This certainly sounds like it's meant to convey the IETF view;
why say "our name" if you're not speaking for the group?

It seems to me that if Russ was misquoted, IETF needs to put
out a press release clarifying the organization's position. If
he was quoted correctly, there's a much larger problem.

RB

On 9/3/2010 1:40 PM, Richard Bennett wrote:

"The head of the Internet's leading standards body said Thursday
that it is "misleading" for AT&T to claim that its push to
charge customers for high-priority service is technically
justified.

"Internet Engineering Task Force chairman Russ Housley
told CNET that AT&T's arguments to federal regulators,
which cited networking standards to justify "paid
prioritization" of network traffic, were invalid.

It's quite clear that Russ' remarks have been taken to mean
"the head of the IETF says payment for premium service was
never envisioned by the IETF" regardless of what he may or
may not have said.

RB

Mat

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 14:34:23 -0700

Brian's paper on DiffServ confirms the fact that prioritization is
part of the standard. Here are the two relevant quotes:

"In the original design of IP [33], a byte known as the “type of
service (TOS) octet” was reserved in the header of every packet.
This was defined to contain two important fields: a three-bit
“precedence” value and three TOS bits. The precedence was intended
as a simple priority marker, where priority 0 got the worst
treatment and priority 7 got the best." (p. 1480)

"The Diffserv working group has taken the approach that a few
fundamental PHBs should be standardized early. These should derive
from some existing experience (primarily from limited deployment and
experimentation with use of the IP precedence field to select
forwarding behaviors) and might be implemented using a variety of
specific mechanisms. The PHBs standardized so far are as follows...

"• Class selector behaviors: here seven DSCP values run from 001 000
to 111 000 and are specified to select up to seven behaviors, each
of which has a higher probability of timely forwarding than its
predecessor. Experts will note that the default behavior plus
the class selectors exactly mirror the original eight IP
Precedence values." (p. 1487)

This is very straightforward.

RB

Richard,

Brian

RB

Russ,

Regards
Brian Carpenter

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Sep 2010 10:08:47 +1200

> implements DiffServ using 802.1d priorities.

Diffserv is about layer 3 queuing mechanisms. It isn't about mapping
to primitive layer 2 prioritisation.

We did keep backwards compatibility with IP Precedence in diffserv,
and I suppose one could implement those particular PHBs by mapping them
to layer 2 prioritisation. But the more subtle PHBs like EF and AF
simply cannot be mapped to preemptive priority queues without
destroying their defined semantics.

> fine for the press. 

No, I am not saying that. That is IMHO a faulty interpretation
of the intent of diffserv. In particular, I don't see how one can
read RFC 2597 and RFC 3246 and imagine that they can be mapped to
layer 2 priority.

> As Russ is now invoking your message to support his

He's not saying that. He's effectively saying what I'm saying: payment
models are outside the scope of the standards, which don't require any
particular payment model in order to perform their job.

   Brian

>> Diffserv deals with multiple different queuing disiplines, which may
>> or may not be priority based. Please read RFC 2475 and if
>> you like, B.E. Carpenter and K. Nichols, Differentiated Services in
>> the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494.
>>
>>      Brian
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Sep 2010 10:11:56 +1200

Er, exactly what in your quotation is incompatible with what
I wrote:

>>> Diffserv deals with multiple different queuing disiplines, which may or may not be priority based.

?

Regards
   Brian Carpenter

On 2010-09-04 09:34, Richard Bennett wrote:
>   Brian's paper on DiffServ confirms the fact that prioritization is part of the 
> standard. Here are the two relevant quotes:
> 
> "In the original design of IP [33], a byte known as the “type of service (TOS) 
> octet” was reserved in the header of every packet. This was defined to contain 
> two important fields: a three-bit “precedence” value and three TOS bits. The 
> precedence was intended as a simple priority marker, where priority 0 got the 
> worst treatment and priority 7 got the best." (p. 1480)
> 
> "The Diffserv working group has taken the approach that a few fundamental PHBs 
> should be standardized early. These should derive from some existing experience 
> (primarily from limited deployment and experimentation with use of the IP 
> precedence field to select forwarding behaviors) and might be implemented using 
> a variety of specific mechanisms. The PHBs standardized so far are as follows...
> 
> "• Class selector behaviors: here seven DSCP values run from 001 000 to 111 000 
> and are specified to select up to seven behaviors, each of which has a higher 
> probability of timely forwarding than its predecessor. *Experts will note that 
> the default behavior plus the class selectors exactly mirror the original eight 
> IP Precedence values.*" (p. 1487)
>

---

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 15:36:22 -0700

Let's go back to your original comment, the one that Russ has quoted 
elsewhere. You said: "It has been consistently hard to explain that 
diffserv is not a prioritisation scheme, even within the technical 
community, let alone to the regulators and the media." Your 
clarification is that "DiffServ deals with multiple queuing disciplines, 
which may or may not be priority based" and you get into EF and AF that 
in most implementations will end up using dedicated facilities of some 
sort, although service providers may be able to use these dedicated 
facilities for generic traffic if there's no EF or AF to send.

I can see why it's hard to explain this subtle distinction. You're 
saying here on the list that DiffServ is a higher level abstraction than 
prioritization that neither requires nor precludes prioritization to 
implement premium services. That's fine, but if you want to say that 
DiffServ is *completely removed from the realm of prioritization,* you 
have to explain away the grandfathering of IP Precedence into the 
standard. I think that you mean to say that DiffServ is *more than* a 
prioritization scheme, it's a general architecture for Internet QoS."

But even that's not correct. In fact, DiffServ is an Internet QoS 
architecture that explicitly offers priority-based services by design, 
and may also offer other types of assured or expedited services, except 
nobody really knows how that might actually work in a real scenario (or 
maybe they do, and it's just us humble developers who don't.)

Russ said to the press that he considers AT&T's belief that the RFCs 
envisioned payment for premium services implemented over DiffServ or 
MPLS to be "invalid." I find this puzzling as there are numerous 
references to payment for premium services in the RFCs AT&T cites, such 
as RFC 2638:

"At the risk of belaboring an analogy, we are motivated to provide
services tiers in somewhat the same fashion as the airlines do with
first class, business class and coach class. The latter also has
tiering built in due to the various restrictions put on the purchase.
A part of the analogy we want to stress is that best effort traffic,
like coach class seats on an airplane, is still expected to make up
the bulk of internet traffic. Business and first class carry a small
number of passengers, but are quite important to the economics of the
airline industry. The various economic forces and realities combine
to dictate the relative allocation of the seats and to try to fill
the airplane. We don't expect that differentiated services will
comprise all the traffic on the internet, but we do expect that new
services will lead to a healthy economic and service environment."

Am I missing something when I find a gap in the dialog?

RB

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Sep 2010 10:53:35 +1200

Richard,

This will be my last message on these points, which were beaten to death
in the diffserv WG some years ago.

> assured or expedited services, except nobody really knows how that might actually work in a real scenario (or maybe they do, and it's just us humble developers who don't.) 

I can't speak for those who have implemented EF and AF queuing algorithms;
they will have to speak for themselves.

> Am I missing something when I find a gap in the dialog?

I don't see the gap. There are a few references to possible differential
payments in some of the informational documents concerning diffserv, and nobody
denies that differential pricing is possible. There are no elements in the
normative specifications of diffserv that serve in any way to support
accounting, pricing or charging. We can't control what choices the carriers
in one particular country such as the USA adopt; and it's not our business.

The fact that journalists don't read the bit at the beginning of each
RFC that defines its status is something that we've been used to for
many years.

Regards
   Brian

On 2010-09-04 10:36, Richard Bennett wrote:
>>> part of the
>>> service (TOS)
>>> fundamental PHBs
>>> to 111 000

---

From: Richard Bennett <[email-masked]>
Date: Fri, 03 Sep 2010 16:48:51 -0700

With respect, Brian, I don't think this is simply the failure of 
journalists to discern the distinction between Informational RFCs and 
Standards Track RFCs. Nobody has made the claim that the IETF produced a 
standard for accounting and billing for QoS or anything else. 
Informational RFCs are a perfectly fine record of what certain people in 
the IETF community may be "envisioning" at a given time, as long as 
people understand that "envisioning" is not the same as "requiring," 
which is basic English literacy.

This debate was also not started by AT&T throwing the name of IETF in to 
the regulatory stew as Russ was quoted as saying to CNET's Declan 
McCullagh. ("We didn't foresee AT&T throwing our name into this 
discussion," the IETF's Housley said. He added: "This characterization 
of the IETF standard and the use of the term 'paid prioritization' by 
AT&T is misleading.")

The immediate debate was started by a letter filed with the FCC by a 
group called National Organizations on Aug. 2nd addressing DiffServ and 
IntServ. This letter drew a reply from Free Press invoking the name of 
IETF and interpreting DiffServ. AT&T's letter offering their view of 
DiffServ was a reply to the Free Press letter, which said:

"Second, it is nonsensical to portray DiffServ as something that a 
third-party content provider could pay an ISP to use for 
paid-prioritization. Either an ISP respects DiffServ flags as outlined 
by IETF and chosen by the application or they do not -- and if they do 
not, then it isn’t DiffServ. By way of analogy, an individual customer 
cannot pay a restaurant to obey the health code -- they either do or 
they don’t. If an ISP is using DiffServ, but not respecting application 
flags, then that is not the standard as outlined by the IETF. Similar to 
how Comcast was improperly using RST packets to block BitTorrent, such a 
nonstandard use of DiffServ would be entirely new, improper, and not at 
all in line with that outlined by the IETF."

So there was a chain of "throwings of the name of IETF into this 
discussion" before AT&T jumped into to it. It would have been pretty 
damn hard for them to address the arguments that had already been made 
by Free Press without referring to IETF, so Russ' remark is, well, not 
very well informed. Perhaps he's not a professional FCC-watcher.

So what we have at the FCC at the moment is a number of people arguing 
about the meaning of RFCs because they think the RFCs (even the 
Informational ones) hold the key to understanding the spirit of the 
Internet. I think this is wonderful, because it's much more productive 
-- potentially -- than a bunch of law professors invoking end-to-end 
arguments as the First Commandment, a binding law that bans anything 
beyond best efforts as far as the eye can see.

I can see how technical people would find this whole process 
distasteful. Journalists don't understand what they're told, they don't 
ask the right questions, and they don't repeat the right comments. 
Regulators are even worse. It's no wonder that Dave Clark used his time 
addressing the FCC after me at the Harvard hearing on Comcast in 2008 to 
talk about economics. These are hard questions for the network 
engineering community to resolve, and even harder for regulators. No 
doubt about it.

But you can't blame people for trying, and you can't say "go regulate 
the Internet however you want but keep the IETF's name out of it." That 
would lead to a result you really don't want to see.

RB

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 4 Sep 2010 17:00:40 +0000

>particular payment model in order to perform their job.

+1 to that.  It seems the press struggles to understand that the IETF does
technical standards and not business models.

- Jason

---

From: Richard Bennett <[email-masked]>
Date: Sat, 04 Sep 2010 15:01:39 -0700

It seems to me that Russ should have said something like this:

"IETF develops technical standards. Our DiffServ standard enables 
applications to communicate their requirements for specialized treatment 
to edge networks and for networks to aggregate packets requiring similar 
treatment at network-to-network boundaries. We've generally expected 
that specialized treatment will be coupled by network operators with 
charging plans, but we're not in the business of standardizing business 
models. AT&T's interpretation of the early DiffServ RFCs is 
fundamentally correct - closer to correct than the Free Press 
interpretation - but those documents are what we call "Informational 
RFCs" and not "Standards." Informational RFCs reflect the views of the 
authors and not any broader consensus within IETF. IETF neither supports 
nor opposes differential charging for differential treatment of traffic 
flows. We deal with technical issues, not business models."

The statement that he did make: "This characterization of the IETF 
standard and the use of the term 'paid prioritization' by AT&T is 
misleading" is itself misleading and implies, to those familiar with the 
context of AT&T remarks as a response to claims made by Free Press, that 
Russ & the IETF support the Free Press side of the debate between these 
two parties. Check the headline:  "IETF: AT&T's Net neutrality claim is 
'misleading'". Does that make IETFers comfortable?

If IETF wants to walk the fine line between the sides in the regulatory 
debate, which will have technical implications before it's over, it 
needs to communicate a lot more clearly with the press than it has.

RB

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 4 Sep 2010 18:51:10 -0400

<sigh> Enough.. can we go back to travel tips now?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Bennett
Sent: Saturday, September 04, 2010 6:02 PM
To: Livingood, Jason
Cc: [email-masked]
Subject: Re: My comments to the press about RFC 2474

RB

---

From: Richard Bennett <[email-masked]>
Date: Sat, 04 Sep 2010 16:02:51 -0700

I don't think that burying IETF's collective head in the sand is a 
very good option, Richard.

The IETF chairman is on the public record with a misleading statement 
that reflects neither the IETF consensus nor the content of the DiffServ 
RFCs. The FCC has launched a specific inquiry into DiffServ and other 
"managed flow" services (including charging), and these remarks as they 
currently exist in two media outlets,  will be part of the record in 
that inquiry.

I think Russ and IETF need to make some clarifying remarks. From Russ' 
rather terse remarks here, he seems to feel he was misquoted. A 
clarifying statement can correct that; pretending nothing is happening 
will not.

RB

On 9/4/2010 3:51 PM, Richard Shockey wrote:
> Russ&  the IETF support the Free Press side of the debate between these

---

From: Matthew Ford <[email-masked]>
Date: Fri, 3 Sep 2010 21:34:02 +0100

Mat

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 7 Sep 2010 13:52:45 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Livingood, Jason [[email-masked]]

It seems the press struggles to understand that the IETF does
technical standards and not business models.
_______________________________________________

The press doesn't understand what technical standards are or why they are needed.  Indeed, the press barely understands that technology is anything other than magic.  "I press the button and the light comes on."

Dale

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Sep 2010 18:52:05 -0400

Richard:

> MPLS to be "invalid."

This is not what I said.  I said 'misleading.'

The letter from AT&T jumbles some things together.  AT&T makes many
correct points, but in my opinion, a reader will get a distorted
impression from the parts of the letter where things get jumbled.

Adding to this situation, it is clear to me that the term "paid
prioritization" does not have the same meaning to all readers.  If you
read the AT&T letter with one definition in your head, then you get one
overall message, and if you read the letter with the other in your head,
then you get a different overall message.  I tried to make this point.

This was captured pretty clearly in the article by Eliza Krigman:
| The feud boiled down to what it means to have "paid
| prioritization," ...

As I said on Friday, I made the point that DiffServ can be used to make
sure that traffic associated with applications that require timely
delivery, like voice and video, to give preference over traffic
associated with applications without those demands, like email.

Unfortunately, it is not simple, and I said so.  I used an example in my
discussion with Declan McCullagh.  I think that Declan captured this
point in his article, except that he said 'high priority', when I
actually said 'requiring timely delivery':
| The disagreement arises from what happens if Video Site No. 1 and
| Video Site No. 2 both mark their streams as high priority. "If two
| sources of video are marking their stuff the same, then that's where
| the ugliness of this debate begins," Housley says. "The RFC doesn't
| talk about that...If they put the same tags, they'd expect the same
| service from the same provider."

Clearly, if the two video sources have purchased different amounts of
bandwidth, then the example breaks down.  However, that is not the point
in this debate.

Russ

---

From: Richard Bennett <[email-masked]>
Date: Tue, 07 Sep 2010 16:26:14 -0700

I think you should have shared the message from our public relations
agency that started this incident, Russ. Here's what it said:

------------------

IETF Chair speaks on Paid Prioritization - Thursday, September 2,
2010

"I note the recent discussion in the U.S. media in connection with
'paid

prioritization' of Internet traffic and the claim that RFC 2474

'expressly contemplating paid prioritization.'  This
characterization of

the IETF standard and the use of the term 'paid prioritization' by
AT&T

is misleading.  The IETF's prioritization technologies allow users
to

indicate how they would like their service providers to handle their

Internet traffic. The IETF does not imply any specific payment based
on

prioritization as a separate service."

Melissa Kahaly

Assistant Vice President

<http://www.fd.com/>

88 Pine Street, 32nd Floor

New York, NY, 10005

T +1 (212) 850-5709

F +1 (212) 850-5790

M +1 (732) 245-8491

www.fd.com
<http://www.fd.com/>

A member of FTI Consulting Inc.

-----------------

This clearly isn't Russ Housley speaking as an individual, this is
the IETF Chair making an official statement.

The statement is misleading as RFC 2474 neither implies any
specific payment nor denies any specific payment. RFC
2475, RFC 2638, and RFC 3006 are plenty clear on the relationship of
technical standards to commercial arrangements.

And yes, the Architecture RFCs are classified as "Informational" but
that doesn't stop the Proposed Standards from referencing their
"requirements" as RFC 3246 does:

"In addition, traffic conditioning at the ingress to a DS-domain
MUST ensure that only packets having DSCPs that correspond to an EF
PHB when they enter the DS-domain are marked with a DSCP that
corresponds to EF inside the DS-domain. Such behavior is as
required by the Differentiated Services architecture [4]. It
protects against denial-of-service and theft-of-service attacks
which exploit DSCPs that are not identified in any Traffic
Conditioning Specification provisioned at an ingress interface, but
which map to EF inside the DS-domain."

[Footnote 4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December
1998.

I don't have any desire to limit Russ Housley's free speech rights,
but it's clear from all the evidence that he approached the press as
the Chairman of IETF with a statement to make about the argument
between AT&T and Free Press, and it's the statement in the
official capacity that bothers me. I wouldn't take up the IETF's
time with a personal disagreement between Russ' interpretation of
DiffServ and anyone else's, but this issue is clearly far beyond
that.

Finally, the term "paid-prioritization" wasn't coined by AT&T,
it comes from the statement by Free Press that AT&T was
criticizing. In Free Press' usage it means any departure from FIFO
behavior for a fee.

RB

On 9/7/2010 3:52 PM, Russ Housley wrote:

Richard:

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Sep 2010 11:43:37 +1200

Sigh. It's hard to resist tendentious messages. I have two
questions for Mr Bennett.

Q1.

> message from our public relations agency

To whom or what does "our" refer in this phrase?

>> Information Technology and Innovation Foundation
imply that you are making a statement on behalf that foundation?

Regards
   Brian Carpenter (writing only for himself)

On 2010-09-08 11:26, Richard Bennett wrote:
>   I think you should have shared the message from our public relations agency 
> that started this incident, Russ. Here's what it said:
> ------------------
> IETF Chair speaks on Paid Prioritization - Thursday, September 2, 2010
> 
> "I note the recent discussion in the U.S. media in connection with 'paid
> 'expressly contemplating paid prioritization.'  This characterization of
> the IETF standard and the use of the term 'paid prioritization' by AT&T
> is misleading.  The IETF's prioritization technologies allow users to
> Internet traffic. The IETF does not imply any specific payment based on
> www.fd.com <http://www.fd.com/>
> 
> This clearly isn't Russ Housley speaking as an individual, this is the IETF 
> Chair making an official statement.
> 
> The statement is misleading as RFC 2474 neither *implies any specific payment* 
> nor *denies any specific payment*. RFC 2475, RFC 2638, and RFC 3006 are plenty 
> clear on the relationship of technical standards to commercial arrangements.
> 
> And yes, the Architecture RFCs are classified as "Informational" but that 
> doesn't stop the Proposed Standards from referencing their "requirements" as RFC 
> 3246 does:
> 
> "In addition, traffic conditioning at the ingress to a DS-domain MUST ensure 
> that only packets having DSCPs that correspond to an EF PHB when they enter the 
> DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. 
> *Such behavior is as required by the Differentiated Services architecture* [4 
> <http://tools.ietf.org/html/rfc3246#ref-4>]. It protects against 
> denial-of-service and theft-of-service attacks which exploit DSCPs that are not 
> identified in any Traffic Conditioning Specification provisioned at an ingress 
> interface, but which map to EF inside the DS-domain."
> 
> [Footnote 4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. 
> Weiss, "An Architecture for Differentiated Services", RFC 2475 
> <http://tools.ietf.org/html/rfc2475>, December 1998.
> 
> I don't have any desire to limit Russ Housley's free speech rights, but it's 
> clear from all the evidence that he approached the press as the Chairman of IETF 
> with a statement to make about the argument between AT&T and Free Press, and 
> it's the statement in the official capacity that bothers me. I wouldn't take up 
> the IETF's time with a personal disagreement between Russ' interpretation of 
> DiffServ and anyone else's, but this issue is clearly far beyond that.
> 
> Finally, the term "paid-prioritization" wasn't coined by AT&T, it comes from the 
> statement by Free Press that AT&T was criticizing. In Free Press' usage it means 
> any departure from FIFO behavior for a fee.
> 
> RB
> 
> ------------------------------------------------------------------------
>

---

From: Richard Bennett <[email-masked]>
Date: Tue, 07 Sep 2010 17:02:29 -0700

Russ says he believes the PR firm works for the Internet Society.

I speak for myself, hence the use of my name. If you read the press 
release I copied to the list, you'll note that it doesn't mention Russ's 
name at all, but it does mention his role at IETF.

I hope that answers your questions, Brian.

RB

On 9/7/2010 4:43 PM, Brian E Carpenter wrote:
>> www.fd.com<http://www.fd.com/>
>>

-- 
Richard Bennett

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 7 Sep 2010 20:03:14 -0400

On Sep 7, 2010, at 7:26 PM, Richard Bennett wrote:

> I think you should have shared the message from our public relations agency that started this incident, Russ. Here's what it said:
> ------------------
> This clearly isn't Russ Housley speaking as an individual, this is the IETF Chair making an official statement. 
> 

In the article at issue, it says

The current chair of the IETF, Russ Housley, disagrees with AT&T's assessment.

That seems pretty clearly like a personal (not official) statement to me. But that's just MHO.

Regards
Marshall 

> The statement is misleading as RFC 2474 neither implies any specific payment nor denies any specific payment. RFC 2475, RFC 2638, and RFC 3006 are plenty clear on the relationship of technical standards to commercial arrangements. 
> 
> And yes, the Architecture RFCs are classified as "Informational" but that doesn't stop the Proposed Standards from referencing their "requirements" as RFC 3246 does:
> 
> "In addition, traffic conditioning at the ingress to a DS-domain MUST ensure that only packets having DSCPs that correspond to an EF PHB when they enter the DS-domain are marked with a DSCP that corresponds to EF inside the DS-domain. Such behavior is as required by the Differentiated Services architecture [4]. It protects against denial-of-service and theft-of-service attacks which exploit DSCPs that are not identified in any Traffic     Conditioning Specification provisioned at an ingress interface, but which map to EF inside the DS-domain." 
> 
> [Footnote 4] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
> 
> I don't have any desire to limit Russ Housley's free speech rights, but it's clear from all the evidence that he approached the press as the Chairman of IETF with a statement to make about the argument between AT&T and Free Press, and it's the statement in the official capacity that bothers me. I wouldn't take up the IETF's time with a personal disagreement between Russ' interpretation of DiffServ and anyone else's, but this issue is clearly far beyond that.
> 
> Finally, the term "paid-prioritization" wasn't coined by AT&T, it comes from the statement by Free Press that AT&T was criticizing. In Free Press' usage it means any departure from FIFO behavior for a fee.
> 
> RB
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 7 Sep 2010 20:05:23 -0400

On Sep 7, 2010, at 8:02 PM, Richard Bennett wrote:

> I speak for myself, hence the use of my name. If you read the press release I copied to the list, you'll note that it doesn't mention Russ's name at all, but it does mention his role at IETF.
> 

Can you give a link for that press release ?

http://www.fd.com/news/index.php does not have it, and my usual news search resources do not reveal it.

Regards
Marshall

---

From: Richard Bennett <[email-masked]>
Date: Tue, 07 Sep 2010 17:08:18 -0700

Sorry, I don't have a link as I received it by email. If you doubt its 
veracity, I'm sure Russ can confirm, as he already has done for me 
personally.

RB

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 7 Sep 2010 20:17:38 -0400

On Sep 7, 2010, at 8:08 PM, Richard Bennett wrote:

> Sorry, I don't have a link as I received it by email. If you doubt its veracity, I'm sure Russ can confirm, as he already has done for me personally.
> 

I don't doubt its veracity, I doubt whether or not it is from a press release. A press release is, by its nature, released to the public.

Regards
Marshall

---

From: Richard Bennett <[email-masked]>
Date: Tue, 07 Sep 2010 17:38:34 -0700

It's for Russ to say how widely the Internet Society's press release 
was disseminated; all I know is that one of the reporters who covered 
these remarks received it and the other didn't.

RB

-- 
Richard Bennett

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Sep 2010 14:03:40 +1200

> that started this incident, Russ. Here's what it said:

As Marshall indicated, this seems to have no public existence
outside of the present thread. However, let's assume it has gone
through some "dark side" media channels...

The word "official" is really overloaded. Nothing the IETF does
is official; all our standards are voluntary standards; they
all fall under a "DISCLAIMS ALL WARRANTIES" boilerplate.

So, we can discuss whether Russ was quoted in his capacity as
IETF Chair; and if so, I have no problems with that, because...

> nor *denies any specific payment*. 

I really do not see any respect in which the quote from Russ is
in any way misleading. Your statement about RFC 2474 is true.
So is Russ' statement. They are simultaneously true. Russ is
simply stating what I said the other day: the IETF says nothing
about business practices or prices; RFC 2474 is an example of
saying nothing.

> RFC 2475, RFC 2638, and RFC 3006 are plenty 

For 2475, see my comment below. 2638 is a "for the record"
publication of some pre-IETF work; it is not an IETF document.
3006 is irrelevant - it relates to intserv, not diffserv.

> interface, but which map to EF inside the DS-domain."

I really don't understand why you are picking this particular
nit, but you are picking it all wrong. Unfortunately this RFC
predates the practice of separating normative and informative
references, but the normative statement in the above is the
sentence containing MUST. You do not need to read RFC 2475
to understand the normative statement. Therefore, RFC 2475 is
not a normative reference. The sentence starting "Such behavior"
is explicative, not normative.

Not that it matters, anyway. Nowehere in the diffserv documents
is there any substantive discussion of pricing. The most I
can find is this single sentence in 2475:

"Service differentiation is desired to accommodate
heterogeneous application requirements and user expectations,
and to permit differentiated pricing of Internet service."

Full disclosure: I was co-chair of the diffserv WG, so
I know both the intent and the content of the documents
quite well. And as co-chair, I whacked down any attempt
to discuss pricing whenever it came up in discussion.
Excuse me shouting, but is it hard to understand that
WE DON'T TALK ABOUT PRICING IN THE IETF?
http://en.wikipedia.org/wiki/Sherman_Act

> DiffServ and anyone else's, but this issue is clearly far beyond that.

As I see it, Russ attempted to correct misrepresentations about
IETF documents that had appeared in the press. I applaud him
for doing so.

> any departure from FIFO behavior for a fee.

Ack
   Brian

---

From: Richard Bennett <[email-masked]>
Date: Tue, 07 Sep 2010 19:30:25 -0700

I'm making a very simple request, Brian: I want a new press release
to go out that corrects the one that most assuredly did go out last
week.

If you want to analyze this situation as you would an RFC, think of
it this way: some RFCs have errata. We don't rely on word of mouth
to correct them, we do in writing and on the record. Here are the
two errors that concern me:

Error number 1: The press release didn't even include Russ' name,
only his title: "IETF Chair speaks on Paid Prioritization." That
clearly identifies the statement as coming from IETF.

Error number 2: The press release was at best one-sided: it falsely
accused AT&T of making a claim they did not make regarding
"specific payment based on prioritization as a separate service."
AT&T did not say that IETF *requires* payment for DiffServ, they
rebutted a counter-claim by another party to effect that charging
*is not allowed* by RFC 2474. AT&T's actual claim was not
misleading, but the unnamed IETF Chairman's characterization of it
was misleading. He set up a strawman and attacked it. The truth is
that AT&T claim was correct on the facts, and the other claims
were wrong on the facts. RFC neither requires nor precludes
charging, and in fact says: "A packet initially marked for the
Default behavior MAY be re-marked with another codepoint as it
passes a boundary into a DS domain so that it will be forwarded
using a different PHB within that domain, possibly subject to
some negotiated agreement between the peering domains."

It doesn't seem to me that an awful lot of hair-splitting is
necessary to determine the correct course of action. A pair of
errors were made in a press release that went out under our
collective names. They need to be corrected with a new, truthful
press release which is public and on the record.

RB

On 9/7/2010 7:03 PM, Brian E Carpenter wrote:

------------------

Melissa Kahaly
Assistant Vice President
<http://www.fd.com/>

Ack
Brian

RB

Richard:

Russ

--
Richard Bennett

--
Richard Bennett

---

From: Theodore Tso <[email-masked]>
Date: Wed, 8 Sep 2010 06:58:27 -0400

On Sep 7, 2010, at 10:30 PM, Richard Bennett wrote:

> I'm making a very simple request, Brian: I want a new press release to go out that corrects the one that most assuredly did go out last week.

There are many things I'd want, starting with a $10 million dollars in my bank account.  I think we've all heard want you want.  The fact that you want something doesn't mean that you (or I) should automatically get it.

I find myself in agreement with Russ and Brian; I think his statements are fine on the face of it.

I find AT&T's statements that "paid prioritization of Internet traffic... is already a common practice of Web management" to be very misleading (certainly not on the wired internet, and it's not done at the Web layer), and that prefixes their claim, "... and consistent with protocols set with the IETF."

I, personally, don't think we need to do anything beyond what Russ has already done, and I support his actions.

-- Ted

---

From: Richard Bennett <[email-masked]>
Date: Wed, 08 Sep 2010 04:07:01 -0700

You can read AT&T's letter to the FCC here: 
http://fjallfoss.fcc.gov/ecfs/document/view?id=7020910396

I think you'll find that the phrases you quote below are not in the 
letter, so it's not clear that your comments are in any way relevant to 
the issue under discussion, Ted.

RB

-- 
Richard Bennett

---

From: Theodore Tso <[email-masked]>
Date: Wed, 8 Sep 2010 07:25:57 -0400

On Sep 8, 2010, at 7:07 AM, Richard Bennett wrote:

> You can read AT&T's letter to the FCC here: http://fjallfoss.fcc.gov/ecfs/document/view?id=7020910396

OK, I find the section heading, "Paid Prioritization Expressly Contemplated by the IETF" to be highly misleading.

> I think you'll find that the phrases you quote below are not in the letter, so it's not clear that your comments are in any way relevant to the issue under discussion, Ted.

We don't know what AT&T said to the reporter, do we?   And what we seem to be arguing about is a press release, not a formal submission to the FCC stating an official position of the IETF (something which the IETF generally doesn't do).

In any case, I still don't think we need to do anything, and if it's OK for you to state wants, I'll state a want.  I want you to drop this.  :-)

-- Ted

---

From: Eric Burger <[email-masked]>
Date: Wed, 8 Sep 2010 11:03:27 -0400

Can we please, please, please kill Informational RFC's?  Pre-WWW, having publicly available documentation of hard-to-get proprietary protocols was certainly useful.  However, in today's environment of thousands of Internet-connected publication venues, why would we possibly ask ourselves to shoot ourselves in the foot by continuing the practice of Informational RFC publication?

On Sep 3, 2010, at 7:48 PM, Richard Bennett wrote:

> With respect, Brian, I don't think this is simply the failure of journalists to discern the distinction between Informational RFCs and Standards Track RFCs. Nobody has made the claim that the IETF produced a standard for accounting and billing for QoS or anything else. Informational RFCs are a perfectly fine record of what certain people in the IETF community may be "envisioning" at a given time, as long as people understand that "envisioning" is not the same as "requiring," which is basic English literacy.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Sep 2010 08:35:37 -0700

At 11:03 AM -0400 9/8/10, Eric Burger wrote:
>Can we please, please, please kill Informational RFC's?

Please, no.

>Pre-WWW, having publicly available documentation of hard-to-get proprietary protocols was certainly useful.  However, in today's environment of thousands of Internet-connected publication venues, why would we possibly ask ourselves to shoot ourselves in the foot by continuing the practice of Informational RFC publication?

Because their value is much higher than the harm caused by a few insufficiently-clued readers.

When we had this discussion ten years ago, there were many stories of marketing departments flogging Informational and Experimental RFCs as "standards". When we had it five years ago, there were fewer. These days, we rarely hear it, and essentially never from major companies. Our outreach efforts have mostly worked!

We have seen *huge* interoperability benefits in the past few years from publishing Informational RFCs that would never get IETF consensus, at least in the Security Area (and I suspect in other areas as well). Let's not throw that away because the occasional ideologue wants to latch on to an Informational or Experimental RFC as a reason to support his position.

--Paul Hoffman, Director
--VPN Consortium

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 8 Sep 2010 18:10:37 +0200

On 8 sep 2010, at 17:03, Eric Burger wrote:

> in today's environment of thousands of Internet-connected publication venues, why would we possibly ask ourselves to shoot ourselves in the foot by continuing the practice of Informational RFC publication?

Link rot.

> On Sep 3, 2010, at 7:48 PM, Richard Bennett wrote:

It is bad form to repeat the entire previous speaker's message, especially AFTER you've made your point and this text is now certainly no longer needed to support that point.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 01:32:04 -0400

I see no reason for any further clarification.

If AT&T want a retraction then they should request one directly. I do
not see why this is a concern of either Mr Bennett or his employer.

The statement made appears perfectly accurate and fair as far as I am
concerned.

The IETF has taken no stance on this issue nor does Russ take any
stance in his statement. The AT&T policy office should not have
claimed IETF endorsement as they did, it was entirely correct for the
chair to rebut that statement.

It does not appear to me that the purpose of Mr Bennett's hectoring
tactics is to correct the record. These do not appear to me to be
tactics likely to win friends or influence people who will not be
bullied.

On Tue, Sep 7, 2010 at 10:30 PM, Richard Bennett <[email-masked]> wrote:
> I'm making a very simple request, Brian: I want a new press release to go
> out that corrects the one that most assuredly did go out last week.
>
> If you want to analyze this situation as you would an RFC, think of it this
> way: some RFCs have errata. We don't rely on word of mouth to correct them,
> we do in writing and on the record. Here are the two errors that concern me:
>
> Error number 1: The press release didn't even include Russ' name, only his
> title: "IETF Chair speaks on Paid Prioritization." That clearly identifies
> the statement as coming from IETF.
>
> Error number 2: The press release was at best one-sided: it falsely accused
> AT&T of making a claim they did not make regarding "specific payment based
> on prioritization as a separate service." AT&T did not say that IETF
> *requires* payment for DiffServ, they rebutted a counter-claim by another
> party to effect that charging *is not allowed* by RFC 2474. AT&T's actual
> claim was not misleading, but the unnamed IETF Chairman's characterization
> of it was misleading. He set up a strawman and attacked it. The truth is
> that AT&T claim was correct on the facts, and the other claims were wrong on
> the facts. RFC neither requires nor precludes charging, and in fact says: "A
> packet initially marked for the Default behavior MAY be re-marked with
> another codepoint as it passes a boundary into a DS domain so that it will
> be forwarded using a different PHB within that domain, possibly subject to
> It doesn't seem to me that an awful lot of hair-splitting is necessary to
> determine the correct course of action. A pair of errors were made in a
> press release that went out under our collective names. They need to be
> corrected with a new, truthful press release which is public and on the
> record.
>
> RB
>
>
>
> agency

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 09:13:02 -0400

And let us imagine that the IETF was bullied into making a second
statement as Mr Bennett demands, how would he use it? Would it be used
in a good faith effort to clarify or would it be used to claim that
the IETF had repudiated its earlier claim that it does not take sides
in this dispute and that it has endorsed the position Mr Bennett is
paid to promote.

While Mr Bennett is careful to keep saying 'we' it is a very long time
since he was an active participant here. The organization that he
works for, the ITIF is a DC thunk tank. Like all thunk tanks it exists
to cause people to accept the thinking that has already been thunk for
them by the people paying their bills under the guise of being an
objective research organization.

It is one thing to engage in these hair-splitting discussions and
having people bandy about the word 'truthful' as if it was personal
property etc. if they are made in good faith. But the tactics used go
way beyond what is acceptable for a paid advocate for a particular
position.

In this case, his activity here appears to me to be entirely
counter-productive. All he is doing is to draw more attention to a
claim that the AT&T policy office would almost certainly wish was
forgotten as quickly as possible.

---

From: Jorge Amodio <[email-masked]>
Date: Wed, 8 Sep 2010 11:30:42 -0500

> Can we please, please, please kill Informational RFC's?

I don't think it makes any sense to do so, the media, and even many in
the networking industry don't even understand the ones that are
standards, why we would expect a right on the money interpretation for
the rest ?

There will be always a gap between the people that generate the news
and the ones that report them. There is not a reliable protocol yet to
transmit what the IETF Chair said and what ended being printed.

The IETF is not an obscure organization that requires a badge or
credentials for participation and that is only focused on creating
"standard" RFCs, if there is a good idea, best practice or an
interesting thought that the community consider useful to put in an
Informational RFC, it really helps to make the process much
transparent, more people will be willing to participate and we keep an
historic record of what worked and what no.

Even the April Fool's which are also informational are part of the
culture and tradition of the IETF ...

My .02
Jorge

---

From: Gene Gaines <[email-masked]>
Date: Wed, 8 Sep 2010 12:56:26 -0400

+1 to all by Phillip Hallam-Baker.

Gene Gaines

On Wed, Sep 8, 2010 at 9:13 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> > OK, I find the section heading, "Paid Prioritization Expressly
> Contemplated by the IETF" to be highly misleading.
> >
> letter, so it's not clear that your comments are in any way relevant to the
> issue under discussion, Ted.
> >
> > We don't know what AT&T said to the reporter, do we?   And what we seem
> to be arguing about is a press release, not a formal submission to the FCC
> stating an official position of the IETF (something which the IETF generally
> doesn't do).
> >
> > In any case, I still don't think we need to do anything, and if it's OK
> for you to state wants, I'll state a want.  I want you to drop this.  :-)
> >
> > -- Ted
> >

---

From: Eric Burger <[email-masked]>
Date: Wed, 8 Sep 2010 14:03:47 -0400

On the one hand, what people seem to be missing is at&t's PR was in response to an even more over-the-top filling by Free Press. On the other hand, that alone does not justify twisting what the IETF work product is. On the third hand, if one actually reads the at&t blog, at least 65% of it is (shudder) sensible.

No one has clean hands here.

--
Eric, who claims "employment" at Georgetown, which means this message absolutely, positively, does not reflect the views, opinions, comments, or thoughts of Georgetown University. Or at&t. Or Free Press. Or ITIF. Or Peter Pan.
And if you missed it, in this message, I am neither representing ISOC, IAOC, ACM, IEEE, nor IEEE-USA.
Just silly me.

On Sep 8, 2010, at 12:56 PM, Gene Gaines wrote:

> On Wed, Sep 8, 2010 at 9:13 AM, Phillip Hallam-Baker <[email-masked]> wrote:

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Sep 2010 12:52:25 -0700

Eric,

> Can we please, please, please kill Informational RFC's?  Pre-WWW, having publicly available documentation of hard-to-get proprietary protocols was certainly useful.  However, in today's environment…

No, I completely disagree.

My personal recent favorite information RFC is RFC 5211.  This would have never been published by the IETF (IESG, IRTF, or IAB tracks) and provided an important service for the community.

Bob

---

From: Eric Burger <[email-masked]>
Date: Wed, 8 Sep 2010 16:05:03 -0400

I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be publishing!  I can see the press release now: "IETF publishes IPv6 transition plan."   NO ONE OUTSIDE THE IETF has a clue the RFC Editor is NOT the IETF.  "RFC = IETF" is the *reality*, no matter how much we say it is not.

For that matter, would the world notice if the press release made the accurate statement, "The RFC Editor, who publishes all IETF protocols, publishes IPv6 transition plan"?  What rational person would not make the leap that the IETF published the document?

For that matter, I'm waiting for the ISPs to say, "We're RFC 5211 compliant - we tested one IPv6 node before December 2009!" Or, "We're RFC 5211 compliant - commercial service is available in West Podunk, Elbonia, before December 2011!"

There are lots and lots of venues this document could have been published in, such as the IPv6 Forum, NANOG, INET, IEEE, ACM, etc.  For that matter, it could have gone in Wikipedia.  The world did not need the IETF^H^H^H^H RFC Editor to publish it, too.  Ten years ago I might have agreed that publishing as an RFC could be useful. However, with a huge plurality of respected, non-protocol-publishing venues, all searchable on the web and archived forever (thanks archive.org!), all a publication like this does is dilute the IETF brand when we actually do publish a protocol or BCP.

---

From: Richard Bennett <[email-masked]>
Date: Wed, 08 Sep 2010 13:22:35 -0700

That's the point I've been trying to make. If you read the AT&T letter 
in context, as a response to the Free Press letter that was completely 
bizarre, you'll conclude that the AT&T letter was fundamentally 
accurate. So the decision by the ISOC press relations people and the 
ISOC policy people to use Russ as a propaganda weapon against the 
corrective remarks from AT&T was simply twisted.

If ISOC is going to trot Russ out to the press every time somebody files 
a comment with the FCC they don't like, he's going to be pretty busy. If 
he's only going to be used against the most egregious uses of IETF's 
name, he should have been used against the Free Press letter that 
started this whole fiasco. By attacking AT&T and giving Free Press a 
pass, ISOC chose to take sides. I think it's wrong for IETF to do that, 
regardless of what the shiny little poli sci majors who do policy for 
ISOC may think.

Read the Free Press letter here: 
http://fjallfoss.fcc.gov/ecfs/document/view?id=7020652588

And contrary to the claims of some people, I'm not being paid by anyone 
to engage in this discussion, it's something I've chosen to do as a 
member of the IETF community who thinks the actions taken by ISOC in 
this matter are harmful to the Internet.

RB

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 8 Sep 2010 16:30:12 -0400

> Eric Burger
> Sent: Wednesday, September 08, 2010 4:05 PM
> To: Bob Hinden
> Cc: IETF Discussion
> Subject: Re: The Evils of Informational RFC's
> 
> I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT
> be publishing!  I can see the press release now: "IETF publishes IPv6
> transition plan."   NO ONE OUTSIDE THE IETF has a clue the RFC Editor
> is NOT the IETF.  "RFC = IETF" is the *reality*, no matter how much we
> say it is not.
> 

Eric,

The following text appears on page 1 of RFC 5211:

IESG Note

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and notes that the decision to publish is not based on IETF
   review apart from IESG review for conflict with IETF work.  RFC
   Editor has chosen to publish this document at its discretion.  See
   RFC 3932 for more information.

The IESG note should be clear to anyone who actually reads the RFC. 

                                                     Ron

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 17:08:36 -0400

s/Informational RFCs/independent stream/

If what you're after is RFC == IETF, shouldn't we be eliminating the  
independent submission process instead of informational RFCs in  
general.  Things like RFC 3693 or draft-ietf-geopriv-arch, which don't  
specify a protocol, but describe an architecture, seem to properly be  
Informational, but still reflect IETF consensus.

On Sep 8, 2010, at 4:05 PM, Eric Burger wrote:

> I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should  
> NOT be publishing!  I can see the press release now: "IETF publishes  
> IPv6 transition plan."   NO ONE OUTSIDE THE IETF has a clue the RFC  
> Editor is NOT the IETF.  "RFC = IETF" is the *reality*, no matter  
> how much we say it is not.
>
> For that matter, would the world notice if the press release made  
> the accurate statement, "The RFC Editor, who publishes all IETF  
> protocols, publishes IPv6 transition plan"?  What rational person  
> would not make the leap that the IETF published the document?
>
> For that matter, I'm waiting for the ISPs to say, "We're RFC 5211  
> compliant - we tested one IPv6 node before December 2009!" Or,  
> "We're RFC 5211 compliant - commercial service is available in West  
> Podunk, Elbonia, before December 2011!"
>
> There are lots and lots of venues this document could have been  
> published in, such as the IPv6 Forum, NANOG, INET, IEEE, ACM, etc.   
> For that matter, it could have gone in Wikipedia.  The world did not  
> need the IETF^H^H^H^H RFC Editor to publish it, too.  Ten years ago  
> I might have agreed that publishing as an RFC could be useful.  
> However, with a huge plurality of respected, non-protocol-publishing  
> venues, all searchable on the web and archived forever (thanks  
> archive.org!), all a publication like this does is dilute the IETF  
> brand when we actually do publish a protocol or BCP.
>
>>> Can we please, please, please kill Informational RFC's?  Pre-WWW,  
>>> having publicly available documentation of hard-to-get proprietary  
>>> protocols was certainly useful.  However, in today's environment  
>>> of thousands of Internet-connected publication venues, why would  
>>> we possibly ask ourselves to shoot ourselves in the foot by  
>>> continuing the practice of Informational RFC publication?
>>
>> My personal recent favorite information RFC is RFC 5211.  This  
>> would have never been published by the IETF (IESG, IRTF, or IAB  
>> tracks) and provided an important service for the community.
>>
>> Bob
>>
>>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Sep 2010 14:17:38 -0700

Eric,

> I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be publishing!  I can see the press release now: "IETF publishes IPv6 transition plan."   NO ONE OUTSIDE THE IETF has a clue…

The IETF did not publish it, the RFC-Editor published it.  

> For that matter, would the world notice if the press release made the accurate statement, "The RFC Editor, who publishes all IETF protocols, publishes IPv6 transition plan"?  What rational person w…

Anyone who actually read the document.  If we are going to worry about what people think who don't read our documents, we should stop now.  

Bob

---

From: Jorge Amodio <[email-masked]>
Date: Wed, 8 Sep 2010 16:26:02 -0500

I don't see what it is wrong with rfc5211, besides the IESG note
pointed by Ronald nowhere the text says that the transition plan is
IETF's plan or even that IT IS the plan.

It is an informational piece of text, and I guess anybody who can read
understands what is says starting with the abstract that says "one
possible plan" which infers that there could be many possible plans
and many others impossible.

> For that matter, would the world notice if the press release made the accurate statement, "The RFC Editor, who publishes all IETF protocols, publishes IPv6 transition plan"?

Press release by whom ? have you seen any about this particular
subject already ?

There is no "West Podunk, Elbonia", so don't worry the possible
transition plan will not affect you ...

J

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Sep 2010 09:43:47 +1200

> Informational, but still reflect IETF consensus.

Er, this whole discussion is hardly new, and is the reason that both
RFC 1796 and RFC 5741 were produced.

I think we all understand why there need to be non-normative IETF
documents; RFC 2475 is a good example. Therefore, RFC /= normative.

We also have good reasons for publishing IAB and IRTF documents, which
by their very nature cannot be normative. Therefore, RFC /= IETF.

Finally, we are an open community encouraging a diversity of views, and
it's sometimes necessary (and often desirable) to publish material from
the community that meets none of the above criteria. Hence the
Independent stream of RFCs. As everyone should know, the independence
of the Independent stream is now guaranteed by a much more robust
process than before (RFC 4846 and RFC 5620). Since RFC 4846 gives a
complete explanation of why the Independent series exists, I won't
repeat it here.

Incidentally it took me quite a while to accept the last point.
My own initial reaction to the Independent Submission stream was that
it enabled end runs. However, there are solid mechanisms in place to
prevent that. I think arguments given in RFC 4846 are convincing.

In any case, you can't put this toothpaste back in the tube.

  Brian (all IMHO, but I am a member of both the RSAG and the
         ISEB, which are explained at
         http://www.rfc-editor.org/RFCeditor.html)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Sep 2010 09:43:47 +1200

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Sep 2010 09:43:47 +1200

---

From: Richard Bennett <[email-masked]>
Date: Wed, 08 Sep 2010 15:07:32 -0700

Interested parties will note that I've stopped responding to Mr. 
Hallam-Baker's trolls. This doesn't mean I agree with anything he says, 
obviously. I've made a request of Russ Housley and the IETF community on 
my own behalf. That's it.

RB

On 9/8/2010 3:02 PM, Phillip Hallam-Baker wrote:
> You are a staff member of ITIF according to their web site. I presume
> you are paid.
>
> ITIF is paid to present a certain point of view in the FCC rule making process.
>
> Therefore you have an interest that you really should have disclosed
> before making all these rather unpleasant statements on and off the
> list.
>
>
> Participants in the IETF are not always speaking for their employer.
> But that does not mean that we can claim to be a disinterested party.
> To make an affirmative claim of being disinterested in those
> circumstances is contemptible.

---

From: Richard Bennett <[email-masked]>
Date: Wed, 08 Sep 2010 15:12:33 -0700

It seems to me that one of the issues here is that architecture models 
are published as Informational when they're clearly not in the same 
level of authority as most Informational RFCs. An architecture document 
is meant to guide future work on standards track RFCs, and has been 
regarded historically as more or less binding.

The easy fix is to create an "Architectural" category within the 
standards track. There's obviously a big difference between RFC 2475 and 
IP for Avian Carriers.

RB

--

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 19:25:44 -0400

> complete explanation of why the Independent series exists, I won't

Echoing somewhat Eric's original point -- we have the web now.  There  
are a multitude of fora in which material that doesn't meet the above  
criteria can be published.  Why does it need to be part of the RFC  
series, other than the fact that we've always done it?

I fail to find any of the justifications in RFC 4846 all that  
persuasive.  Choosing a few examples:

    o  Discussion of Internet-related technologies that are not part of
       the IETF agenda.
    o  Critiques and discussions of alternatives to IETF Standards-Track
       protocols.  The potential for such critiques provides an  
important
       check on the IETF's standards processes and should be seen in  
that
       light.
    o  Informational discussions of technologies, options, or experience
       with protocols.
    o  Technical contributions (e.g., RFC 1810 [RFC1810]).

These discussions happen all the time, all over the Internet.  My  
favorite recent example:
<http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars 
One venue more or less for these discussions isn't going to make a  
huge difference, and using the RFC stream for them simply causes  
confusion as to what's a "real" RFC.

    o  Informational publication of vendor-specific protocols.

Nowadays, vendors have web sites that describe their protocols.  See,  
for example:
<http://code.google.com/apis/gears/geolocation_network_protocol.html>

--Richard

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 8 Sep 2010 19:30:53 -0400

+1 to everything Brian says. There are very many good reasons to have
Informational RFCs, whether they're an independent submission, an RFC
that represents IETF consensus but doesn't define protocol elements,
or from one of the other streams, such as the IAB or IRTF.  And
speaking as someone who works at an operator and evaluates vendor
equipment, believe me, the customers know the difference between
standards-track and non-standards-track RFCs, and what it means to be
compliant to a particular RFC.

Cheers,
Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Sep 2010 11:37:10 +1200

> series, other than the fact that we've always done it?

In one word: archival.

In several words: systematic archival rather than the vagueness
of transient URLs and search engine caches.

Obviously, that presupposes a judgment that the document is
worthy of archival, which is why there is an editor and an
editorial board.

  Brian

>       protocols.  The potential for such critiques provides an important
>       check on the IETF's standards processes and should be seen in that
>       light.
> <http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars>
> 
> One venue more or less for these discussions isn't going to make a huge
> difference, and using the RFC stream for them simply causes confusion as
> to what's a "real" RFC.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Sep 2010 00:46:45 +0100

FWIW, I'm not at all confused by the various RFC streams
and see no negatives and some positives in their existence.
So let's keep it as-is please.

Stephen.

PS: I know of no "evil" RFCs but would welcome contrary
opinions (not including rfc3514's version of evil). Maybe
there are, recently, one or more companies espousing
equivalent levels of evil to those envisaged in rfc3514,
but who knows.

---

From: David Morris <[email-masked]>
Date: Wed, 8 Sep 2010 18:22:20 -0700 (PDT)

> of transient URLs and search engine caches.

+1

 ...   for all that was wrong with it, the original Netscape Cookie 
       spec is no longer available from its original source.
       Some effort was required in the current http-state wg to
       pin down an acceptable stable reference. 

In addition, for some portion of the IETF community, the RFC process is
how they document their ideas, experiments, etc. Having this work product
collected in a familiar location adds value to the IETF. I suspect it
also improves the RFC authoring skills of the contributors.

Dave Morris

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Sep 2010 10:49:16 +0900

Please, no. 

The RFC Series is not a collection of standards. It is community memory, and in it we have white papers that have been seminal such as RFC 970, problem statements, requirements documents, and analyses of a wide variety, all of which are informational. 

Let me give you two specific examples:

http://www.ietf.org/rfc/rfc2804.txt
2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format:
     TXT=18934 bytes) (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc3924.txt
3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker,
     B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status:
     INFORMATIONAL)

The former gives a view on the topic of lawful interception, and requests that anyone that develops an interception technology publish it so that it can be reviewed openly within the community. The latter does exactly that.

The collected experience in the RFC series is at least as valuable as the protocol descriptions in it.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 9 Sep 2010 09:02:00 +0200

> Anyone who actually read the document.  If we are going to worry about what people think who don't read our documents, we should stop now.  

Also see RFC 5741 work on which was inspired on exactly this sort of discussion.

Quoting from that:

   For non-IETF stream documents, a reference to Section 2 of this RFC
   is added with the following sentence:

      "Documents approved for publication by the [stream approver --
      currently, one of: "IAB", "IRSG", or "RFC Editor"] are not a
      candidate for any level of Internet Standard; see Section 2 of RFC
      5741."

   For IETF stream documents, a similar reference is added for BCP and
   Standards Track documents:

      "Further information on [BCPs or Internet Standards] is available
      in Section 2 of RFC 5741 ."

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Richard Bennett <[email-masked]>
Date: Thu, 9 Sep 2010 02:28:29 -0700

That's probably because RFC 2549 was the transitional document.

Richard Bennett

On Sep 8, 2010, at 7:34 PM, Kevin Fall <[email-masked]> wrote:

> 
> On Sep 8, 2010, at Sep 83:12 PMPDT, Richard Bennett wrote:
> 
>> It seems to me that one of the issues here is that architecture models are published as Informational when they're clearly not in the same level of authority as most Informational RFCs. An architecture document is meant to guide future work on standards track RFCs, and has been regarded historically as more or less binding.
>> 
>> The easy fix is to create an "Architectural" category within the standards track. There's obviously a big difference between RFC 2475 and IP for Avian Carriers.
>> 
> 
> But not so obvious between 'IP for Avian Carriers' and RFC4838...  :)
> 
> - K

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 9 Sep 2010 08:06:55 -0400

And add to that one that Mr Burger should vaguely recall  :-) 

http://www.rfc-editor.org/rfc/rfc3482.txt

Number Portability in the Global Switched Telephone Network (GSTN):
                              An Overview

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred
Baker
Sent: Wednesday, September 08, 2010 9:49 PM
To: Eric Burger
Cc: IETF Discussion
Subject: Re: The Evils of Informational RFC's

Please, no. 

The RFC Series is not a collection of standards. It is community memory, and
in it we have white papers that have been seminal such as RFC 970, problem
statements, requirements documents, and analyses of a wide variety, all of
which are informational. 

The former gives a view on the topic of lawful interception, and requests
that anyone that develops an interception technology publish it so that it
can be reviewed openly within the community. The latter does exactly that.

The collected experience in the RFC series is at least as valuable as the
protocol descriptions in it.

On Sep 9, 2010, at 12:03 AM, Eric Burger wrote:

> Can we please, please, please kill Informational RFC's?  Pre-WWW, having
publicly available documentation of hard-to-get proprietary protocols was
certainly useful.  However, in today's environment of thousands of
Internet-connected publication venues, why would we possibly ask ourselves
to shoot ourselves in the foot by continuing the practice of Informational
RFC publication?
journalists to discern the distinction between Informational RFCs and
Standards Track RFCs. Nobody has made the claim that the IETF produced a
standard for accounting and billing for QoS or anything else. Informational
RFCs are a perfectly fine record of what certain people in the IETF
community may be "envisioning" at a given time, as long as people understand
that "envisioning" is not the same as "requiring," which is basic English
literacy.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:53:37 -0400

> Can we please, please, please kill Informational RFC's?  Pre-WWW, having publicly available documentation of hard-to-get proprietary protocols was certainly useful.  However, in today's environment…

No.

This is not a problem caused by a casual misunderstanding. It is a
problem caused by one D.C. corporate lobbyist intentionally misreading
one document and then another D.C. corporate advocate insisting that
this misrepresentation was correct.

I don't think that there is anything that can be done to prevent
people from engaging in such activities other than the expectation of
damaging press if they force a rebuttal.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 18:02:24 -0400

On Wed, Sep 8, 2010 at 4:22 PM, Richard Bennett <[email-masked]> wrote:
>  That's the point I've been trying to make. If you read the AT&T letter in
> context, as a response to the Free Press letter that was completely bizarre,
> you'll conclude that the AT&T letter was fundamentally accurate. So the
> decision by the ISOC press relations people and the ISOC policy people to
> use Russ as a propaganda weapon against the corrective remarks from AT&T was
> simply twisted.
>
> If ISOC is going to trot Russ out to the press every time somebody files a
> comment with the FCC they don't like, he's going to be pretty busy. If he's
> only going to be used against the most egregious uses of IETF's name, he
> should have been used against the Free Press letter that started this whole
> fiasco. By attacking AT&T and giving Free Press a pass, ISOC chose to take
> sides. I think it's wrong for IETF to do that, regardless of what the shiny
> little poli sci majors who do policy for ISOC may think.
>
> And contrary to the claims of some people, I'm not being paid by anyone to
> engage in this discussion, it's something I've chosen to do as a member of
> the IETF community who thinks the actions taken by ISOC in this matter are
> harmful to the Internet.
>
> RB
>
>> On the one hand, what people seem to be missing is at&t's PR was in
>> response to an even more over-the-top filling by Free Press. On the other
>> hand, that alone does not justify twisting what the IETF work product is. On
>> the third hand, if one actually reads the at&t blog, at least 65% of it is
>> (shudder) sensible.
>>
>> Eric, who claims "employment" at Georgetown, which means this message
>> absolutely, positively, does not reflect the views, opinions, comments, or
>> thoughts of Georgetown University. Or at&t. Or Free Press. Or ITIF. Or Peter
>> Pan.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 08 Sep 2010 16:21:06 -0700

> Can we please, please, please kill Informational RFC's?
...
>    why would we possibly ask ourselves to
> shoot ourselves in the foot by continuing the practice of Informational RFC
> publication?

wow.  it's oddly fun to see you run off the rails like this.

must be a form of schadenfreude...

d/

ps.  in other words, -10.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 19:33:30 -0400

For the record, I do not consider pointing out a documented employer
interest after one has been explicitly denied to be a 'troll'.

If you are demanding issue of a press release on a subject, the fact
that your employer is a paid promoter of specific policy outcomes on
that issue is a fact that warrants disclosure.

On Wed, Sep 8, 2010 at 6:07 PM, Richard Bennett <[email-masked]> wrote:
> obviously. I've made a request of Russ Housley and the IETF community on my
> own behalf. That's it.
>
> RB
>

---

From: Kevin Fall <[email-masked]>
Date: Wed, 8 Sep 2010 19:34:06 -0700

- K

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 10:49:33 -0400

That is actually a pretty good example of an Informational RFC that
was necessary as part of the standards process even if it was not
standard itself.

The IETF had no control over the infrastructure being described so it
was not creating a standard. But the development of an IP based
alternative required a description of the existing legacy system that
simply did not exist at the time. Referencing the standards on which
the legacy system was purportedly based would not be an acceptable
substitute even if the documents were freely available.

---

From: Bob Braden <[email-masked]>
Date: Thu, 09 Sep 2010 12:37:06 -0700

> regarded historically as more or less binding.

"...guide future work on standards track RFCs" -- yes.

"...historically as more or less binding" -- no.

Bob Braden

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Sep 2010 16:27:04 -0400

>>>>> "Bob" == Bob Braden <[email-masked]> writes:

    Bob> On 9/8/2010 3:12 PM, Richard Bennett wrote:
    >> It seems to me that one of the issues here is that architecture
    >> models are published as Informational when they're clearly not in
    >> the same level of authority as most Informational RFCs. An
    >> architecture document is meant to guide future work on standards
    >> track RFCs, and has been regarded historically as more or less
    >> binding.

    Bob> "...guide future work on standards track RFCs" -- yes.

    Bob> "...historically as more or less binding" -- no.
Bob, this was certainly an issue that came up when I was on the IESG.
At that time, we definitely felt that there were some architectural
decisions that the community as a whole had bought into.  We believed
that departing from such a decision was something that the community as
a whole needed to revisit.  For example, when a WG was chartered to work
on an architecture after the architecture document was approved, it
seemed fairly clear that the community had expressed a desire to have a
chance to look at that architecture.  Other times, however, it seemed to
us that a requirements document or architecture document represented the
thinking within a single working group. There, it didn't seem like
departing from this guidance required as much community review.

I'm summarizing a fair bit of discussions, but enough different
prospectives and examples were brought into the discussion that I feel
confident that while we don't know how large the sample size was, it was
more than just that IESG who believed there are times when architecture
documents are intended to bind.

I know I've often found the informational RFC label inadequate to
describe this sort of distinction and found that this distinction is
important to capture.

--Sam

---

From: Russ Housley <[email-masked]>
Date: Thu, 09 Sep 2010 16:55:11 -0400

> describe this sort of distinction and found that this distinction is

This is one of the reasons that the updated boilerplate indicates
whether the document represents IETF consensus.

Russ

---

From: Yoav Nir <[email-masked]>
Date: Fri, 10 Sep 2010 00:16:06 +0300

> That seems pretty clearly like a personal (not official) statement to me. But that's just MHO.

I don't agree with the rest of what Richard says, but in this, I believe he is correct. 

In the IETF mailing lists we can play this game of "with AD hat on, I'm saying this, but as an individual I'm saying that".

In communicating to the press there is never a distinction between your position and yourself as an individual. You are never going to see in the paper, "The current president of the US, Barack Obama, disagrees with AT&T's assessment." If Mr. Obama speaks to the press about AT&T's statement, it is the government's stance. Similarly, a message by Russ Housley, is taken to be the opinion of the IETF. (not that I'm saying that Russ is to the Internet what Obama is to the US).

Now, whether the press release represents the IETF's opinion or not, I agree with what it says.

Yoav

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Sep 2010 15:25:21 +0300

I do think informational RFCs (both IETF and non-IETF) are valuable.

I would suggest though that their value is mostly NOT about ease of 
access, archival, those great ASCII graphics, or any other practical 
matter. The value is in our assessment of them being worthy of being 
published as RFCs. (Our = the IETF community, IESG and other reviews, 
RFC Editor board decisions, etc) I generally treat all information as 
suspect, even full standard RFCs (horror!) but I still think that across 
a number of different information sources even a vendor's protocol spec 
as an independent submission is pretty reliable.

So yes, lets keep on publishing informational, experimental, and 
individual and independent submission RFCs. They are not the primary 
source of technical information in Internet technology, but for me at 
least they do provide a lot of value.

Sam: about the binding Informational documents. I also do recognize that 
we sometimes make choices, say, about architectures or requirements and 
that we should stick with those decisions in future work. However, I 
would like to make two comments on this. First, many decisions of this 
sort are soft rather than hard. As an example, we often compromise on a 
requirement in order to reach a feasible solution. I'm not sure we want 
to bind ourselves to decisions of this type in any formal sense. Second, 
I think it is easier to think of the bindingness in terms of the history 
of the document and the practical situation than as a binary attribute 
of the document class.

Jari

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 10 Sep 2010 09:08:22 -0700

> I fail to find any of the justifications in RFC 4846 all that persuasive.
> Choosing a few examples:
...
> Nowadays, vendors have web sites that describe their protocols.

These are frequent lines of argumentation against publishing anything other than 
formal IETF documents.  What they represent is a misunderstanding of the 
established role of the RFC series.  Publishing formal IETF documents is only 
part of the benefit provided to the community for the last 40 years.

Take a look back over that record.  Its structure and publication arc describe a 
culture, not just a set of technologies.

A healthy community culture is difficult to engineer and fragile to maintain. 
Typically, it's creation is an unintended consequence and it is destroyed 
similarly.  Mess with it not just at your own peril, but at the peril of that 
community.

There is no crisis or even problem that is creating different circumstances than 
we have had over the last 40 years.  We have flourished, not just survived, with 
this horribly flawed publishing model.  Note, for example, that alternative 
publishing might be more convenient now, but it is not new. In other words, it 
ain't broke, so let's stop calling for repair.

We would spend our time better by focusing on creating our own specifications 
more efficiently and with better and quicker community uptake.  Worrying about 
non-IETF Informational IETFs distracts from that.

d/
-- 

   Dave Crocker