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 <richard@xxxxxxxxxxx> 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 > 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: > > 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: > > 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... > > ------------------ > 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 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... > > The statement is misleading as RFC 2474 neither *implies any specific > payment* > 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 > clear on the relationship of technical standards to commercial arrangements. > > 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. > > 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." > > 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 > > [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. > > As I see it, Russ attempted to correct misrepresentations about > IETF documents that had appeared in the press. I applaud him > for doing so. > > 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. > > Ack > Brian > > RB > > On 9/7/2010 3:52 PM, Russ Housley wrote: > > Richard: > > 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." > > 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 > > -- > Richard Bennett > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > -- > Richard Bennett > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf