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? Q2. Does your signature block: >> Richard Bennett >> Senior Research Fellow >> Information Technology and Innovation Foundation >> Washington, DC 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 > 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 > <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 > > 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 > Senior Research Fellow > Information Technology and Innovation Foundation > Washington, DC > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
