Re: secdir review of draft-ietf-simple-msrp-sessmatch
Hi Ted, Thanks for your message and your consideration of the points I raised. Given the scope of changes below, my first suggestion is that the author team actually go ahead with a draft incorporating these changes, so that we can discuss based on the actual text. I also suspect that a second last call will be necessary as a result. the plan is to give the authors some time to discuss with all of you who sent comments on the draft so that the authors understand how to address them. Depending on the nature of the changes needed, we may need to IETF LC it again (as you suggest above) or even let the WG have an additional look at it. But for now, thanks for following this up. Cheers, Gonzalo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: Nomcom 2010-2011: Timeline and Nominations Update
-Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of NomCom Chair Sent: Friday, September 03, 2010 10:49 AM To: IETF Announcement list Subject: Nomcom 2010-2011: Timeline and Nominations Update Hi Folks, The call for nominations has been open now for just under a week and this is a good time for an update. Nominations: The nominations are arriving at a good pace and remember nominations remain open until October 1. Full details on the call may be found in https://datatracker.ietf.org/ann/nomcom/2468/ 2010-2011 NomCom Timeline: -- * Nominations period: August 27 - October 1, 2010 * Feedback collection: Starts September 7, 2010 (projected date) * Questionnaire responses deadline: October 8, 2010 * Deliberations: October 1 - November 6, 2010 * Final deliberations and Interviews: November 7 - December 17, 2010 o 3rd IETF: November 7-12, 2010 * Write-ups and other preparations: December 20 - January 7, 2010 * Send to confirming bodies: January 10, 2010 * Announce confirmed candidates: o 1st IETF: March 27 - April 1, 2011 Questionnaires -- Nominees are requested to fill out the questionnaires related to their nomination and return them no later than October 8. The IESG questionnaire is already on the NomCom wiki. For the IAB, IAOC and IETF-Chair positions, the NomCom members have been updating the questionnaires and these will be available on the wiki in the next few days. I will notify the IAB/IAOC/Chair nominees directly when their respective questionnaires are available. Open List: -- As you already know, NomCom 2010-2011 will follow the policy for Open Disclosure of Willing Nominees described in RFC 5680. The first posting of the open list should be available in the next few days, followed by regular updates. I will send another announcement once it is publicly available along with a request for feedback on the nominees. Feedback Collection: Once the open list is available, the entire community will be invited to provide feedback. I will send a further announcement requesting feedback on the nominees, describing how to submit feedback, and how to view the open list of nominees. As this is dependent on the availability of the first posting of the open list of willing nominees, I am moving the projected start date for feedback from September 3 to September 7. Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tools logins -- Aaaargh!
Hi Dale, On 2010-08-31 18:08 Worley, Dale R (Dale) said: There is probably a better place to complain about this, but... There are various IETF tools web pages. But I have a devil of a time using them because they do not identify themselves usefully when asking for a login. There are multiple login databases in the whole IETF tools suite, and experienced users know which database controls access to which tool. But for us unwashed masses, there is no way to guess which web pages demand which password because they are named inconsistently. Let me propose: * Each password database has a *single* name which is the only name that it is ever referred to by, such as IETF tools login and IETF datatracker login. * Each login prompt gives the *single* name of the password database that it is driven by. Thanks for the suggestion, it's good. However... I went ahead and changed the AuthName directive in the Apache config files to specify IETF tools login instead of IETF a moment ago. I then tested logging in, and couldn't, and then realised that since the tools servers are using digest authentication, the digest will change when the realm changes and all the passwords in current use (2508 at the moment) will be invalidated. So I had to revert it back to the old setting :-( We've had as a goal for some time to move to having the same login/pw for both the datatracker and the tools pages; I think we'll have to try to move forward with that plan in order to handle the situation, rather than the quick fix proposed above. Best, Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
There is a fundamental problem with the way that Internet services are sold. At present I have two companies that would like to sell me 'higher speed' Internet service but I have absolutely no way to evaluate their claims. In particular I have no way to know if changing provider or paying my current provider more would make my existing applications run any faster or better. What I do know is that my Vonage service was fine when I first subscribed but is now unusable. I have no way to know if changing provider would change that. If I could be sure that one of the carriers did not have a vested interest in sabotaging my VOIP service from competing providers, that would be reason enough to switch. One would like to sell me higher speed but will not raise their 250Gb monthly bandwidth cap even if I pay more for the service. I am quite willing to pay for higher bandwidth Internet. But at the moment I have no idea what the value proposition that is being presented to me in those offers. And if I don't know I am pretty sure that Mrs B. Muggins has not got a clue. So in my view the problem here is that when I pay for an X Mb/sec connection at the moment I have no real way of knowing whether that is really X Mb/sec all the time or X/n Mb/sec when I am using a service that competes with my carrier. There are two ways that this can get sorted. The first is that the carriers can work out a way to address the issue and explain to the customer what they are really offering. The second is regulation. I really don't see why a regulation need amount to anything more than the fairness in pricing rules that have been applied to other industries who have proved to be unable to get it together on their own. If I pay for X Mb/sec thats what I should get. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Roll] Last Call: draft-ietf-roll-rpl-11.txt (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard
Thank you for your review. Pekka == Pekka Savola pek...@netcore.fi writes: Pekka In S 11 on Packet Forwarding: Pekka1. This specification only covers how a successor is Pekka selected from the DODAG Version that matches the Pekka RPLInstanceID marked in the IPv6 header of the packet being Pekka forwarded. [...] Pekka ... How is RPLInstanceID marked in the IPv6 header of the Pekka packet being forwarded? Are you modifying IPv6 packet Pekka forwarding and processing algorithms here (must look into the Pekka packets)? That would be a major change. (You're really Pekka referring to the hop-by-hop header processing here.) So, this is a signficant but as yet unsolved problem. No details of the RPL protocol itself depend upon how in, the end, the packets are marked. At the beginning, many of us thought that the FlowLabel was the right thing to use. And it works very well as long as the RPL network does not need to interact with other networks. Applications that run on RPL nodes that need a non-default behaviour need to be aware of what RPLinstanceID to pick (and this is a provionsing issue), and thus it will in fact be the application setting the flow label, not an intermediate node. Pekka It is a bit strange to see that S 17 on manageability does Pekka not mention security management, because one of the key Pekka problems there (as argued in the draft as well) is how do you Pekka manually configure and maintain shared keys on all these Pekka devices. I agree that it is a concern --- most of the deployment scenarios (which are in a series of RFCs published by the WG last fall) are installed by a single contractor into a single commercial-building/house/factor/power-transmission-system They initialize all the devices in the test lab, and then deploy them. I think this is because 90% of the participants in the group think that link-layer security provided by Zigbee is going to solve all of their problems.I am very skeptical about this. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
On Sep 2, 2010, at 8:45 PM, Phillip Hallam-Baker wrote: There is a fundamental problem with the way that Internet services are sold. At present I have two companies that would like to sell me 'higher speed' Internet service but I have absolutely no way to evaluate their claims. In particular I have no way to know if changing provider or paying my current provider more would make my existing applications run any faster or better. What I do know is that my Vonage service was fine when I first subscribed but is now unusable. I have no way to know if changing provider would change that. If I could be sure that one of the carriers did not have a vested interest in sabotaging my VOIP service from competing providers, that would be reason enough to switch. One would like to sell me higher speed but will not raise their 250Gb monthly bandwidth cap even if I pay more for the service. I am quite willing to pay for higher bandwidth Internet. But at the moment I have no idea what the value proposition that is being presented to me in those offers. And if I don't know I am pretty sure that Mrs B. Muggins has not got a clue. So in my view the problem here is that when I pay for an X Mb/sec connection at the moment I have no real way of knowing whether that is really X Mb/sec all the time or X/n Mb/sec when I am using a service that competes with my carrier. This sounds like there is potential for crowd sourcing here. For example, I can tell you nothing about Vonage, but a fair amount about Cox Cable Internet. What you want to know is known, just not (yet) in a way you can easily access. Would a Yelp type model be appropriate ? Regards Marshall There are two ways that this can get sorted. The first is that the carriers can work out a way to address the issue and explain to the customer what they are really offering. The second is regulation. I really don't see why a regulation need amount to anything more than the fairness in pricing rules that have been applied to other industries who have proved to be unable to get it together on their own. If I pay for X Mb/sec thats what I should get. ___ 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
Re: My comments to the press about RFC 2474
On Fri, 3 Sep 2010, Marshall Eubanks wrote: On Sep 2, 2010, at 8:45 PM, Phillip Hallam-Baker wrote: So in my view the problem here is that when I pay for an X Mb/sec connection at the moment I have no real way of knowing whether that is really X Mb/sec all the time or X/n Mb/sec when I am using a service that competes with my carrier. This sounds like there is potential for crowd sourcing here. For example, I can tell you nothing about Vonage, but a fair amount about Cox Cable Internet. What you want to know is known, just not (yet) in a way you can easily access. Would a Yelp type model be appropriate ? It might tell you something about customer service and might tell you if there is a pattern of promising more than is delivered, but the last mile of the connection is highly variable. Depending on the carrier technologies, there may be distance issues and/or issues re. folks the link is shared with, etc. The only way to know is to make parallel installations and test them using carefully constructed methodologies to try to factor out other variables like origin server load, backbone load, etc. Then there is all the automatic stuff most users aren't aware of which uses up bandwidth and is almost impossible to identify. Close to a no win situation for consumer class services. I know from repeated experience that my installed speed will be downrated from the promised speed. It has never not happened with multiple providers and locations. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
Another article has come out on the same topic: http://news.cnet.com/8301-13578_3-20015498-38.html#ixzz0yTtFP7M7 On 9/2/2010 1:47 PM, 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
--On Friday, September 03, 2010 12:08 -0400 Marshall Eubanks t...@americafree.tv wrote: This sounds like there is potential for crowd sourcing here. For example, I can tell you nothing about Vonage, but a fair amount about Cox Cable Internet. What you want to know is known, just not (yet) in a way you can easily access. Would a Yelp type model be appropriate ? With the understanding that getting accurate and consistent measurements is really hard (David Morris's note pointed out some of the issues), have a look at http://www.testmy.net/ . (Disclaimer: I not only have no affiliation with them other than a sign-in to keep data, I haven't bother to find out who they really are.) john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
Marshall Eubanks t...@americafree.tv wrote: On Sep 2, 2010, at 8:45 PM, Phillip Hallam-Baker wrote: So in my view the problem here is that when I pay for an X Mb/sec connection at the moment I have no real way of knowing whether that is really X Mb/sec all the time or X/n Mb/sec when I am using a service that competes with my carrier. This sounds like there is potential for crowd sourcing here. In my case, I would be willing to pay a bit more to get rid of the 250G bandwidth cap, but not only won't my provider offer that, there's no other provider available which will offer service to my house that is comparable at all. I have nowhere else to go, and I think that is the typical situation for most households in the US. Even if the industry manages to get it together in terms of making clear what level of service they offer, I don't know that there's any way out of this conundrun other than legislation. P.S. My neighborhood is about as far from being a tech backwater as it is possible to be in the world. Yet I still have only one viable option for high speed Internet. It's a business law problem, not a technology problem. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: My comments to the press about RFC 2474
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Ofer Inbar [...@a.org] P.S. My neighborhood is about as far from being a tech backwater as it is possible to be in the world. Yet I still have only one viable option for high speed Internet. It's a business law problem, not a technology problem. ___ It's a traditional monopoly problem. Market-based mechanisms don't work if there isn't vigorous competition. The traditional solution is common carrier regulation of natural monopolies. At the least, we need to define data carriage as a common carrier business, where the carrier must provide service on a non-discriminatory basis at published rates. (Whatever happened to the dream of multiple WiMax providers?) Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: My comments to the press about RFC 2474
LTE for a start.. From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Ofer Inbar [...@a.org] P.S. My neighborhood is about as far from being a tech backwater as it is possible to be in the world. Yet I still have only one viable option for high speed Internet. It's a business law problem, not a technology problem. ___ It's a traditional monopoly problem. Market-based mechanisms don't work if there isn't vigorous competition. The traditional solution is common carrier regulation of natural monopolies. At the least, we need to define data carriage as a common carrier business, where the carrier must provide service on a non-discriminatory basis at published rates. (Whatever happened to the dream of multiple WiMax providers?) Dale ___ 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
Re: My comments to the press about RFC 2474
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 brian.e.carpen...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
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 On 2010-09-04 07:57, Richard Bennett wrote: 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 brian.e.carpen...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: My comments to the press about RFC 2474
Well first .. I do want to congratulate Russ for actually injecting a bit of sanity into the ongoing NN debate and I think we all know he was speaking as a individual. I'm personally +1 on his comments. The problem we collectively have is that there is very little or no technical clue in the NN discussion, a problem some of us that inhabit the orbit of the 495 DC beltway see quite often. Brian is equally correct in noting that being quoted out of context is par for the course in DC circles, however it is vitally important that those of us who can, point out to our National Regulatory Authorities the reality of how the Internet actually operates and what we are doing to address ongoing issues of network management and congestion control. This is extremely important in the ongoing discussions among NRA's on how to transition classic PSTN and Emergency services from Analog POTS to a IP world, something the IETF is technically involved with on multiple levels. http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-09-2517A1.pdf Silence is not a option. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Thursday, September 02, 2010 1:48 PM To: IETF Subject: My comments to the press about RFC 2474 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 = How Neutral Is The Internet?: Existing Limits Are In The Spotlight As ATT And A Consumer Advocacy Group Squabble Over Net Traffic by Eliza Krigman Thursday, Sept. 2, 2010 Whether the Internet is truly a democratic forum was called into question this week in a dispute about Internet traffic management between ATT and the consumer advocacy group Free Press. The feud boiled down to what it means to have paid prioritization, a phenomenon viewed as anathema by advocates of Internet openness, and to what extent preferential treatment of content already takes place. The issue is at the very heart of a broader debate about what regulatory steps are necessary, if any, to ensure the Internet remains an engine of economic growth and a platform of equal value to people across the socioeconomic spectrum. ATT, in a letter filed with the Federal Communications Commission on Monday, argued that paid prioritization of Internet traffic, contrary to claims made by Free Press, is already a common practice of Web management and consistent with protocols set by the Internet Engineering Task Force. Largely unknown to people outside the technology field, IETF is a professional organization composed of engineers that develop standards for the Internet; for over two decades, it has played an integral role in the management of the Internet. The current chair of the IETF, Russ Housley, disagrees with ATT's assessment. ATT's characterization is misleading, Housley said. IETF prioritization technology is geared toward letting network users indicate how they want network providers to handle their traffic, and there is no implication in the IETF about payment based on any prioritization. Dedicated lines of service, according to ATT, are examples of current paid prioritization schemes, a concept Free Press flatly disagrees with. ATT constructed bogus interpretations of 'paid prioritization' that reflect no arguments or statements made by the FCC or any proponents of net neutrality, said S. Derek Turner, research director of Free Press. The group calls paid prioritization an anti-consumer practice where third-party content owners can pay an Internet service provider to cut to the front of the line in Web traffic. It's a practice that would lead to a pay-to-play scenario where only big business could afford the premium channels needed to compete, net neutrality advocates say, thereby squeezing the little guys out of the market. But ATT dismisses those assertions, saying Free Press' acceptance of dedicated lines of service as a management practice is hypocritical given its stance against paid prioritization. We understand why Free Press is upset with our letter, said Michael Balmoris, spokesman for ATT. We outed them by shedding light on their inconsistencies. After all, for years Free Press has used empty rhetoric and faux-technical mumbo jumbo
Re: My comments to the press about RFC 2474
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: 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 On 2010-09-04 07:57, Richard Bennett wrote: 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 Carpenterbrian.e.carpen...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
This is what the press is saying: "The head of the Internet's leading standards body said Thursday that it is "misleading" for ATT 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 ATT's arguments to federal regulators, which cited networking standards to justify "paid prioritization" of network traffic, were invalid. ""ATT 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 -- 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
Re: My comments to the press about RFC 2474
The article goes on to say: "We didn't foresee ATT 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 ATT 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: This is what the press is saying: "The head of the Internet's leading standards body said Thursday that it is "misleading" for ATT 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 ATT's arguments to federal regulators, which cited networking standards to justify "paid prioritization" of network traffic, were invalid. ""ATT 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 -- 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 -- 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
Re: My comments to the press about RFC 2474
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 On 9/3/2010 1:06 PM, Brian E Carpenter wrote: 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 On 2010-09-04 07:57, Richard Bennett wrote: 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 brian.e.carpen...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
On 2010-09-04 08:13, Richard Bennett wrote: 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. 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. 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. 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 view that payment for premium service is contrary to the wishes of IETF, that's a problem. 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 RB On 9/3/2010 1:06 PM, Brian E Carpenter wrote: 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 On 2010-09-04 07:57, Richard Bennett wrote: 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 Carpenterbrian.e.carpen...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
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) This is very straightforward. RB On 9/3/2010 1:06 PM, Brian E Carpenter wrote: 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 On 2010-09-04 07:57, Richard Bennett wrote: 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 brian.e.carpen...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
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 ATT'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 ATT 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 On 9/3/2010 3:11 PM, Brian E Carpenter wrote: 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) This is very straightforward. RB On 9/3/2010 1:06 PM, Brian E Carpenter wrote: 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 On 2010-09-04 07:57, Richard Bennett wrote: 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
Re: My comments to the press about RFC 2474
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: 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 ATT'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 ATT 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 On 9/3/2010 3:11 PM, Brian E Carpenter wrote: 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
Re: My comments to the press about RFC 2474
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 ATT 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 ATT 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 ATT 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. ATT'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 ATT 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 On 9/3/2010 3:53 PM, Brian E Carpenter wrote: 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: 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
Re: My comments to the press about RFC 2474
At 3:25 PM -0400 9/3/10, Ofer Inbar wrote: I have nowhere else to go, and I think that is the typical situation for most households in the US. Even if the industry manages to get it together in terms of making clear what level of service they offer, I don't know that there's any way out of this conundrun other than legislation. Internet providers say the high cost of running wire or fibre to the house or neighborhood is prohibitive. Telephone service used to be considered a regulated monopoly, and I have wondered if this model could work with outside plant, as a separate facility from Internet service. The idea being that a regulated or even municipal entity builds and maintains the outside plant, with any Internet provider able to use it to offer service. That way all details of the service are open to competition. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- But, something that only exists in thought is even better, as you can read for yourself in my favorite book of (English) verse and drawings, The Space-Child's Mother Goose (Verses by Frederick Winsor, Illustrations by Marian Parry, Simon and Schuster, 1958, unfortunately out of print): I have a pet hen whose name is Probable. She lays eggs in concept, being a sophist bird. But not in reality at all; those would be inferior eggs; for thought is superior to reality. --unknown ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2010-2011: Timeline and Nominations Update
Hi Folks, The call for nominations has been open now for just under a week and this is a good time for an update. Nominations: The nominations are arriving at a good pace and remember nominations remain open until October 1. Full details on the call may be found in https://datatracker.ietf.org/ann/nomcom/2468/ 2010-2011 NomCom Timeline: -- * Nominations period: August 27 - October 1, 2010 * Feedback collection: Starts September 7, 2010 (projected date) * Questionnaire responses deadline: October 8, 2010 * Deliberations: October 1 - November 6, 2010 * Final deliberations and Interviews: November 7 - December 17, 2010 o 3rd IETF: November 7-12, 2010 * Write-ups and other preparations: December 20 - January 7, 2010 * Send to confirming bodies: January 10, 2010 * Announce confirmed candidates: o 1st IETF: March 27 - April 1, 2011 Questionnaires -- Nominees are requested to fill out the questionnaires related to their nomination and return them no later than October 8. The IESG questionnaire is already on the NomCom wiki. For the IAB, IAOC and IETF-Chair positions, the NomCom members have been updating the questionnaires and these will be available on the wiki in the next few days. I will notify the IAB/IAOC/Chair nominees directly when their respective questionnaires are available. Open List: -- As you already know, NomCom 2010-2011 will follow the policy for Open Disclosure of Willing Nominees described in RFC 5680. The first posting of the open list should be available in the next few days, followed by regular updates. I will send another announcement once it is publicly available along with a request for feedback on the nominees. Feedback Collection: Once the open list is available, the entire community will be invited to provide feedback. I will send a further announcement requesting feedback on the nominees, describing how to submit feedback, and how to view the open list of nominees. As this is dependent on the availability of the first posting of the open list of willing nominees, I am moving the projected start date for feedback from September 3 to September 7. Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-ch...@ietf.org twa...@juniper.net ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Spatial Composition of Metrics' to Proposed Standard
The IESG has approved the following document: - 'Spatial Composition of Metrics' draft-ietf-ippm-spatial-composition-16.txt as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-spatial-composition/ Technical Summary This memo utilizes IP Performance Metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. Working Group Summary The normal WG process was followed and the document has been discussed for several years. The document as it is now, reflects WG consensus, with nothing special worth noticing. Personnel Henk Uijterwaal (h...@ripe.net) is the document shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
