<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Franck -<div><br></div><div>Not quite true. I agree the IETF never explicitly considers things like business models when examining protocols. However, for a protocol to pass muster as an Internet protocol, it must address security, scale, <b>and privacy</b> issues. One could argue that security and privacy are moral/ethical judgements. This is one of the reasons the IETF is loath to tackle lawful intercept.<div><br></div><div>That said, I fully agree with your assertion that what people <u>do</u> with Internet protocols is out of scope for the IETF. If someone wants to charge for diffserv, great! If someone wants to charge for a SIP "call," great! If someone wants to give it away for free, even better! The point is that IETF protocols have generated great wealth (think HTTP and any large Internet Web-based firm) and have destroyed great wealth (think RTP and any voice communications carrier or legacy equipment manufacturer).</div><div><br></div><div>Could we say the IETF is Shumpeter's creative destruction of the mind? :-)<br><div><br><div><div>On Sep 2, 2010, at 11:49 PM, Franck Martin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>My take, is a bit different, but not too far off...<br><br>The IETF is a mechanism for individuals to propose and codify open interoperable Internet protocols, as such the IETF does not make a judgment on the moral/ethical quality of any proposal, but focus only on its technical merits and that it will not jeopardize any widely deployed current protocol.<br><br>So basically, I say it is fine to propose paid QOS specs to IETF and get some consensus on it via IETF, it does not mean people will use it. IETF define a common toolbox of compatible tools usable by all without prejudice, what people do with this toolbox is not IETF role to decide.<br><br>Franck Martin <br><a href="http://www.avonsys.com/">http://www.avonsys.com/</a> <br><a href="http://www.facebook.com/Avonsys">http://www.facebook.com/Avonsys</a> <br>twitter: FranckMartin Avonsys <br><br>Check your domain reputation: <a href="http://gurl.im/b69d4o">http://gurl.im/b69d4o</a> <br><br><br>----- Original Message -----<br>From: "Lucy Lynch" <<a href="mailto:lynch@isoc.org">lynch@isoc.org</a>><br>To: "Franck Martin" <<a href="mailto:franck@avonsys.com">franck@avonsys.com</a>><br>Cc: <a href="mailto:lynch@isoc.org">lynch@isoc.org</a>, <a href="mailto:chapter-delegates@elists.isoc.org">chapter-delegates@elists.isoc.org</a>, <a href="mailto:zittrain@cyber.law.harvard.edu">zittrain@cyber.law.harvard.edu</a>, "Russ Housley" <<a href="mailto:housley@vigilsec.com">housley@vigilsec.com</a>><br>Sent: Friday, 3 September, 2010 10:41:17 AM<br>Subject: Re: [Chapter-delegates] IETF position on Paid Prioritization<br><br>On Fri, 3 Sep 2010, Franck Martin wrote:<br><br><blockquote type="cite">Thanks Lucy,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Then I think the IETF statement could be more accurate when including <br></blockquote><blockquote type="cite">this information, otherwise it looks like soviet era press release ;)<br></blockquote><br>Maybe we should just point the press at: <a href="http://www.rfc-humor.com/">http://www.rfc-humor.com/</a><br>and see if they can figure out the jokes ;-)<br><br>As long time IETF participants, you and I both know that trying to explain <br>how the IETF sausage is made may be more confusing and not less. I had to <br>go look up the RFC you sited and then decode the type and the abstract in <br>order to post my last explanation and I know how this works!<br><br>If I google for: IETF RFC payment service - I get a lot of interesting <br>stuff but no real context. I think Russ it trying to point out that<br>selecting bits and pieces of IETF history without that context doesn't <br>rise to the level of support for the AT&T position. A deeper discussion<br>of IETF process and standards production might be useful if he gets <br>actually a reaction to his statement!<br><br>- Lucy<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Franck Martin<br></blockquote><blockquote type="cite"><a href="http://www.avonsys.com/">http://www.avonsys.com/</a><br></blockquote><blockquote type="cite"><a href="http://www.facebook.com/Avonsys">http://www.facebook.com/Avonsys</a><br></blockquote><blockquote type="cite">twitter: FranckMartin Avonsys<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Check your domain reputation: <a href="http://gurl.im/b69d4o">http://gurl.im/b69d4o</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">----- Original Message -----<br></blockquote><blockquote type="cite">From: "Lucy Lynch" <<a href="mailto:lynch@isoc.org">lynch@isoc.org</a>><br></blockquote><blockquote type="cite">To: <a href="mailto:zittrain@cyber.law.harvard.edu">zittrain@cyber.law.harvard.edu</a><br></blockquote><blockquote type="cite">Cc: <a href="mailto:chapter-delegates@elists.isoc.org">chapter-delegates@elists.isoc.org</a><br></blockquote><blockquote type="cite">Sent: Friday, 3 September, 2010 10:17:47 AM<br></blockquote><blockquote type="cite">Subject: Re: [Chapter-delegates] IETF position on Paid Prioritization<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Thu, 2 Sep 2010, <a href="mailto:zittrain@cyber.law.harvard.edu">zittrain@cyber.law.harvard.edu</a> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Can anyone tell me if this statement has been issued?  I don't see anything<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">on the IETF site, and there was no link in the original message.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">At GMT-4 05:56 PM 9/2/2010, Joly MacFie wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Aren't we talking apples and oranges here?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The pemium service is a diffserv, and thus not Internet per se at all?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The background on RFC 2638 can be found here:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="https://datatracker.ietf.org/doc/draft-nichols-diff-svc-arch/">https://datatracker.ietf.org/doc/draft-nichols-diff-svc-arch/</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">and say in part:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">"Abstract:<br></blockquote><blockquote type="cite">This document was originally submitted as an internet draft in November of<br></blockquote><blockquote type="cite">1997. As one of the documents predating the formation of the IETF's<br></blockquote><blockquote type="cite">Differentiated Services Working Group, many of the ideas presented here,<br></blockquote><blockquote type="cite">in concert with Dave Clark's subsequent presentation to the December 1997<br></blockquote><blockquote type="cite">meeting of the IETF Integrated Services Working Group, were key to the<br></blockquote><blockquote type="cite">work which led to RFCs 2474 and 2475 and the section on allocation remains<br></blockquote><blockquote type="cite">a timely proposal. For this reason, and to provide a reference, it is<br></blockquote><blockquote type="cite">being submitted in its original form. The forwarding path portion of this<br></blockquote><blockquote type="cite">document is intended as a record of where we were at in late 1997 and not<br></blockquote><blockquote type="cite">as an indication of future direction."<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So, this is an informational RFC based on an individual author draft<br></blockquote><blockquote type="cite">issued for historical reasons. This is not an IETF standard. The RFC<br></blockquote><blockquote type="cite">series includes many documents that form a part of our historical<br></blockquote><blockquote type="cite">record but are not recommended practice (BCP) or intended for deployment<br></blockquote><blockquote type="cite">at an IETF standard. Confusing, but true. See the RFC-Editor site for<br></blockquote><blockquote type="cite">more: <a href="http://www.rfc-editor.org/RFCoverview.html">http://www.rfc-editor.org/RFCoverview.html</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">- Lucy<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">j<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Thu, Sep 2, 2010 at 3:38 PM, Franck Martin <<a href="mailto:franck@avonsys.com">franck@avonsys.com</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The two RFCs mentioned in the article, indicate clearly pricing, as an<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">example:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://tools.ietf.org/html/rfc2638">http://tools.ietf.org/html/rfc2638</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2.2 Premium service<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In [2], a Premium service was presented that is fundamentally<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  different from the Internet's current best effort service. This<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  service is not meant to replace best effort but primarily to meet an<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  emerging demand for a commercial service that can share the network<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  with best effort traffic. This is desirable economically, since the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  same network can be used for both kinds of traffic. It is expected<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  that Premium traffic would be allocated a small percentage of the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  total network capacity, but that it would be priced much higher.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So who are you kidding, with this statement?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Franck Martin<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://www.avonsys.com/">http://www.avonsys.com/</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://www.facebook.com/Avonsys">http://www.facebook.com/Avonsys</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">twitter: FranckMartin Avonsys<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Check your domain reputation: <a href="http://gurl.im/b69d4o">http://gurl.im/b69d4o</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: "Anya Chambers" <<a href="mailto:chambers@isoc.org">chambers@isoc.org</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: <a href="mailto:chapter-delegates@elists.isoc.org">chapter-delegates@elists.isoc.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sent: Friday, 3 September, 2010 1:38:07 AM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: [Chapter-delegates] IETF position on Paid Prioritization<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Dear all<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">You may have seen some media coverage relating to AT&T and its interpretation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of a certain IETF standard,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for example: <a href="http://news.cnet.com/8301-13578_3-20015231-38.html">http://news.cnet.com/8301-13578_3-20015231-38.html</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In conjunction with Russ Housley we have prepared the below statement to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">clarify:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">IETF position on Paid Prioritization - Wednesday, September 1, 2010<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"The Internet Engineering Task Force (IETF) notes recent discussion in the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">U.S.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">media in connection with "paid prioritization" of Internet traffic<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and the associated RFC being discussed within the Internet's technical<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">community.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">AT&T's characterization of the IETF and its use of the term "paid<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">prioritization" is misleading. The IETF's prioritization technologies are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">tools that allow users to indicate how they would like their service<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">providers to handle Internet traffic. The IETF does not imply any specific<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">payment based on prioritization as a separate service."<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Chapter-delegates mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:Chapter-delegates@elists.isoc.org">Chapter-delegates@elists.isoc.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://elists.isoc.org/mailman/listinfo/chapter-delegates">https://elists.isoc.org/mailman/listinfo/chapter-delegates</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Chapter-delegates mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:Chapter-delegates@elists.isoc.org">Chapter-delegates@elists.isoc.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://elists.isoc.org/mailman/listinfo/chapter-delegates">https://elists.isoc.org/mailman/listinfo/chapter-delegates</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Chapter-delegates mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Chapter-delegates@elists.isoc.org">Chapter-delegates@elists.isoc.org</a><br></blockquote><blockquote type="cite"><a href="https://elists.isoc.org/mailman/listinfo/chapter-delegates">https://elists.isoc.org/mailman/listinfo/chapter-delegates</a><br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<br>Chapter-delegates mailing list<br><a href="mailto:Chapter-delegates@elists.isoc.org">Chapter-delegates@elists.isoc.org</a><br>https://elists.isoc.org/mailman/listinfo/chapter-delegates<br></div></blockquote></div><br></div></div></div></body></html>