Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
--On Friday, September 23, 2011 17:54 -0700 SM s...@resistor.net wrote: At 13:40 23-09-2011, Brian E Carpenter wrote: What makes you think that the Independent stream would publish such an RFC, which on the face of it would be a complete end-run around the IETF process, and fly in the face of the IAB position? There is an Editorial Board which can decide whether the draft is acceptable in that stream. In my opinion there will be more end-runs until ARIN gets what it wants. Well, yes, but... (1) The IESG gets to review all documents that the Independent Stream intends to publish to verify that the document doesn't interfere with IETF work. The Independent Stream can, in principle, publish over IESG objections (perhaps with some notes about that) but, like Brian, I'd be at least mildly astonished to see that done in a case like this. (2) Independent Stream publication wouldn't accomplish the presumed purpose of creating this draft because, while such publication might be good for starting a discussion or providing information to the community, it doesn't get allocations made-- the intent here is pretty clearly to get an allocation. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
--On Friday, September 23, 2011 21:20 -0400 Keith Moore mo...@network-heretics.com wrote: I already made one Last Call comment, but I neglected to state unambiguously whether I supported the proposal. I do support this proposal. I think that this question needs to be viewed as a choice between two risks: 1) the risks associated with this proposal 2) the risks associated with reuse of RFC 1918 address space by ISPs, and/or reuse of public IPv4 address space by ISPs ... It needs to be understood that at this point, there is no path that will avoid widespread breakage of much existing IPv4-based software, including some software that is widely used. Upgrades to that software will be needed in order to continue using such software on a widespread basis. And that helps identify a third risk. How relevant it is depends on one's perspective and understanding of reality but that risk is: 3) People will conclude that these various kludges are actually medium-term solutions and will put resources into them that would have gone into deploying IPv6 instead. As soon as you say folks are going to need to go to the trouble and expense of developing and deploying replacements for a lot of installed-base IPv4 software, the resources involved become significant and there are tradeoffs with other ways in which those resources could be invested. Remembering that an ISP who wants to avoid the use of public IPv4 addresses on its backbone/infrastructure has the option of simply converting that infrastructure to IPv6, tunneling public-address IPv4 packets (both its own and those of its customers) over that IPv6 infrastructure using a tunneling approach of its choice. Longer-term, that approach makes the ISP far more IPv6-ready, while more private/shared IPv4 space is just another dead end. Without commenting on the merits of this particular proposal relative to other ways to squeeze a few more addresses out of the IPv4 space, it seems to me that a lot of the presumed value is ultimately a cost tradeoff. If the squeezing technique buys extra addresses and time at very low cost, then it is worth considering (and comparing to other squeezing-out proposals). If it requires changing enough deployed software and infrastructure to start approaching IPv6 deployment costs, it seems to me to be bad strategy and worse economics. john Furthermore, even with such upgrades, the reliability of IPv4-based applications can generally be expected to decrease over time. There is no path to permit IPv4-based applications to continue to be used reliably, at Internet scale, over the existing Internet infrastructure. Keith ___ 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: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sun, Sep 25, 2011 at 3:42 PM, John C Klensin john-i...@jck.com wrote: snip snip And that helps identify a third risk. How relevant it is depends on one's perspective and understanding of reality but that risk is: 3) People will conclude that these various kludges are actually medium-term solutions and will put resources into them that would have gone into deploying IPv6 instead. As soon as you say folks are going to need to go to the trouble and expense of developing and deploying replacements for a lot of installed-base IPv4 software, the resources involved become significant and there are tradeoffs with other ways in which those resources could be invested. It is quite likely that resources will be used on prolonging IPv4 if there is a way of doing that, like putting this last netblock into use. That just put IPv6 even further off and cause even more trouble down the road. However, if this proposal goes through and that last netblock are assigned to use, how long will it take before anyone ask the following question: Why haven't that last netblock been put to use by the RIR earlier and with that given us more time to prepare for IPv6? -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
--On Friday, September 23, 2011 11:04 +0300 Bob Hinden bob.hin...@gmail.com wrote: I also claim that for the third item there is no necessity for the I* chairs to be a voting member, nor for the fourth. That said, I am sensitive to the argument that if I* chairs are members they may actually pay more attention (human nature and such) and that being effective at those item without being a member is tough. I theory I can agree, but in practice I think the more separation there is the more likelihood for organizational problems. ... Bob, Of course. But that is just a corollary to an old principle that, if one wants a really efficient government, with minimal chances of organizational problems, the most efficient form is an absolute dictatorship (or an absolute monarchy) with one person in charge of, and responsible for, everything. As long as that person is competent and has the bandwidth, things are nothing if not efficient and, some aesthetic and moral issues aside, the only major disadvantages are that there is a single point of failure for the entire system and recruiting appropriate dictators (or monarchs) has a long history of being problematic. We have chosen, I think for really good reasons, to avoid that sort of model. That --almost inherently-- means that there will be some inefficiency and some risk of organizational problems. Frankly, I'd rather have that risk in the IASA, than having it affect the ability of the IAB and IESG to do substantive (standards and external relationship) work. That doesn't mean I want an inefficient and organizationally-troubled IASA, only that, if there is pain, I think that the IASA --which, should it become necessary, is also more easily reorganized without significant disruption to the IETF's work than the IESG or IAB-- is the right place to feel, and deal with, that pain. For that reason, I'd much prefer to to have IASA leaders saying well this might be bad for the IASA, but we've thought about it and these are ways to make the best of a bad situation rather than what often seem to be variations on a theme of the IASA (IAOC, Trust) are so much more important than anything else that, if something has to suffer inefficiency or organizational problems, it should obviously be the IAB and IESG. I don't think you really intend to say that, but it is what some of your (and other) comments come out sounding like. YMMD. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
linguistic and cultural support
Dear all, We, nicknamed JEDIs (Jefsey disciples), have often tried to make the IETF understand and respect the implications of linguistic, cultural, political, economical diversities on protocol definition. Jefsey obtained the RFC 4645, 4646, 4647 consensus he wanted. We also obtained the IDNA2008 consensus which was necessary to warranty the internet stability, its capacity to support any diversity by subsidiarity, and the emergence of the IUI. We still have a problem with the IETF/Unicode relations, the WG/PRECIS, the IDNA IAB work, the ICANN/VIP work on variants, extension of the punycode algorithm to support French and and the orthotypography (scripting syntax) of most of the other languages, etc. May be this quote will help some of our colleagues to understand better why the IETF is to influence those who design, use and manage the internet for it to offer users with a better multilinguistic support. “We live in a global world,”... “We have to understand that world if we … are going to be able to not only defend this country, but to extend our relationships to others so that we can work together to defend the world that we live in.” “The reality is that we have to reflect the nation we live in and we have to reflect the world we are a part of. “Languages are the key to understanding that world.”... It’s also critical to the effectiveness of current U.S. military operations. ... If we are going to advance stability in some of the countries we are fighting in today, we have to be able to understand what motivates those countries, what motivates their people, and to understand their culture, beliefs, faiths, ideologies, hatreds and loves. “So it is crucial to our national security to be able to have a strong language ability”. - Leon E. Panetta (8/23/2011). US Defense Secretary. Mr. Panetta speaks on behalf of the USA, but I believe that if his understanding may be late, it is also true for every other nation. Multilinguistics, as Jefsey defined it from our IETF experience, is the cybernetics of the linguistic diversity. How languages and cultures can be adequately be supported and result in positive synergetic feed backs. Its key recipe seems to be first based upon a true network linguistic neutrality. One does not need to have more than one language to be a multilingist, one just need to understand and/or research how to better support linguistic and cultural diversity. As Mr. Panetta stated, it is critical to stability and effectiveness in our global world. Portzamparc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 25, 2011, at 9:42 AM, John C Klensin wrote: Remembering that an ISP who wants to avoid the use of public IPv4 addresses on its backbone/infrastructure has the option of simply converting that infrastructure to IPv6, tunneling public-address IPv4 packets (both its own and those of its customers) over that IPv6 infrastructure using a tunneling approach of its choice. Longer-term, that approach makes the ISP far more IPv6-ready, while more private/shared IPv4 space is just another dead end. Yes, but even if it does this (and I agree that it's a strategy well worth considering) that ISP is going to need IPv4 addresses to assign to its customers until the customers migrate to IPv6. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
--On Sunday, September 25, 2011 13:25 -0400 Keith Moore mo...@network-heretics.com wrote: Remembering that an ISP who wants to avoid the use of public IPv4 addresses on its backbone/infrastructure has the option of simply converting that infrastructure to IPv6, tunneling public-address IPv4 packets (both its own and those of its customers) over that IPv6 infrastructure using a tunneling approach of its choice. Longer-term, that approach makes the ISP far more IPv6-ready, while more private/shared IPv4 space is just another dead end. Yes, but even if it does this (and I agree that it's a strategy well worth considering) that ISP is going to need IPv4 addresses to assign to its customers until the customers migrate to IPv6. So? I was sort of assuming that an ISP who was aggressive about converting their internal infrastructure would be freeing up public IPv4 addresses for endpoint and boundary use in fairly large quantities. Renumbering shouldn't be a lot harder than, well, renumbering. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sep 25, 2011, at 2:34 PM, John C Klensin wrote: --On Sunday, September 25, 2011 13:25 -0400 Keith Moore mo...@network-heretics.com wrote: Remembering that an ISP who wants to avoid the use of public IPv4 addresses on its backbone/infrastructure has the option of simply converting that infrastructure to IPv6, tunneling public-address IPv4 packets (both its own and those of its customers) over that IPv6 infrastructure using a tunneling approach of its choice. Longer-term, that approach makes the ISP far more IPv6-ready, while more private/shared IPv4 space is just another dead end. Yes, but even if it does this (and I agree that it's a strategy well worth considering) that ISP is going to need IPv4 addresses to assign to its customers until the customers migrate to IPv6. So? I was sort of assuming that an ISP who was aggressive about converting their internal infrastructure would be freeing up public IPv4 addresses for endpoint and boundary use in fairly large quantities. Renumbering shouldn't be a lot harder than, well, renumbering. My assumption is that most ISPs are already using RFC 1918 for internal infrastructure whenever possible in order to free up more public IPv4 addresses to assign to customers. At least, I hope that's the case. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sat, Sep 24, 2011 at 5:24 AM, Ronald Bonica rbon...@juniper.net wrote: Folks, This allocation cannot be made without IETF consensus. Publication on the Independent Stream does not reflect IETF consensus. Therefore, publication on the Independent Stream wouldn't enable the allocation. Sorry, or maybe I'm not really sorry, but I can not see it as a good thing for the internet at whole to allocate the prefix right now. Notice that right now part. Let people try out all of the scenario we have available, we don't need to add yet another part into the huge mess we've already got us into. Are already too many ways to get from v4 to v6 as it is In a few years _when_ we've got IPv6 more into mainstream, I'm quite sure we will see a technical (and only technical) reason for allocating that last remaining piece of IPv4 netblock we've got left. There is already too many burning fire out there right now, we don't need to add more wood (ipv4 addresses or special case usage etc) to it. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-avtext-client-to-mixer-audio-level-05.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please resolve these comments along with any other comments you may receive. Document: draft-ietf-avtext-client-to-mixer-audio-level-05.txt Reviewer: Alexey Melnikov Review Date: 2011-09-25 IETF LC End Date: 2011-10-04 IESG Telechat date: Summary: The document is ready for publication as a standards track RFC. Major issues: none Minor issues: Question: are the two encoding of the audio level indication option specified in the document really necessary? Nits/editorial comments: 6. Security Considerations A malicious endpoint could choose to set the values in this header extension falsely, so as to falsely claim that audio or voice is or is not present. It is not clear what could be gained by falsely claiming that audio is not present, but an endpoint falsely claiming that audio is present could perform a denial-of-service attack on an audio conference, so as to send silence to suppress other conference members' audio. Thus, if a device relys on audio level data from s/relys/relies ??? untrusted endpoints, it SHOULD periodically audit the level ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On 24 Sep 2011, at 02:20, Keith Moore wrote: To me it seems clear that the risks associated with this proposal are less than the other risks. Software that assumes that IPv4 space other than RFC 1918 space is unambiguous will break in either case. But at least with this proposal, there's a well-defined and easily-understood path to fix such software to minimize the breakage. +1, but I'm a little bit concerned about transition mechanisms which depend on exclusively upstream NAT functions rather than in addition to the CPE, i.e. DS-Lite. As it stands, the two cases can be distinguished, and it seems to me to be against this proposal, for that situation, since private addresses will probably provoke Find my public address semantics in existing software rather better than Public-seeming addresses on directly-attached hosts behind a DS-Lite gateway. Otherwise, yep, it's inevitable. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RIP, Einar Stefferud, 1930-2011
For those who haven't heard, Einar Stefferud passed away this week. Many of you will remember Stef as an early pioneer of email. My own remembrance of him can be found here: http://blogs.msexchange.org/migration/2011/09/25/an-underappreciated-email-pioneer-einar-stefferud-1930-2011/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Need help tracking down problem accessing IETF Subversion repository on Mac OS X
I'm using the IETF Subversion repository, described here: http://trac.tools.ietf.org/misc/venue/wiki/ IetfSpecificFeatures#SourceControlRepositorySVN It used to work for me, but for the last few months, on both OS X SnowLeopard and on Lion, it hasn't worked: % svn info https://svn.tools.ietf.org/svn/wg/hybi svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/hybi': SSL negotiation failed: SSL error code -1/1/336032856 (https:// svn.tools.ietf.org) It's supposed to do this: % svn info https://svn.tools.ietf.org/svn/wg/hybi Path: hybi URL: https://svn.tools.ietf.org/svn/wg/hybi Repository Root: https://svn.tools.ietf.org/svn/wg/hybi Repository UUID: 5e38896a-673a-488c-9143-21546a17fde4 Revision: 137 Node Kind: directory Last Changed Author: ife...@google.com Last Changed Rev: 137 Last Changed Date: 2011-08-31 11:18:27 -0700 (Wed, 31 Aug 2011) If you're on a Mac, can you please try this command for me and let me know if it works for you or gives the 336032856 error? If it's just my machine that's having the problem then I'll continue troubleshooting, but if it turns out that this doesn't work AT ALL for ANY Mac user, then I'll file a bug report. We should probably also update the IETF Wiki page to document this, and if we find a workaround that should go on the page too. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIP, Einar Stefferud, 1930-2011
Nathaniel, Thanks for passing this along. I had the pleasure of working for Stef almost 50 years ago. I was a freshman at UCLA in 1961. Stef was on the staff of the Western Data Processing Center (WDPC), one of two major data centers IBM had set up with universities to foster the use of computing within business schools. WDPC had the IBM 700/7000 series scientific computer -- a 709, followed by a 7090, a 7094 and then a large 360 series machine. As it happened, I started to work for Stef exactly on my 17th birthday in mid-October, so I remember the date easily. Stef had previously spent time at CMU where, among many other things, he had learned IPL-V, a pioneering list processing language that was shortly superseded by LISP. Stef and his boss had a project to write an IPL-V compiler, and although the project didn't reach fruition, it opened my eyes to a rich set of possibilities. Stef was indeed a kind man. He was a pleasure to work for and I felt very fortunate to have encountered him early in my career. We crossed paths in the IETF and in the payments business -- I was involved in a start up competitive with First Virtual -- and always enjoyed a lively exchange. I will miss him. Steve On Sep 26, 2011, at 12:51 AM, Nathaniel Borenstein wrote: For those who haven't heard, Einar Stefferud passed away this week. Many of you will remember Stef as an early pioneer of email. My own remembrance of him can be found here: http://blogs.msexchange.org/migration/2011/09/25/an-underappreciated-email-pioneer-einar-stefferud-1930-2011/ ___ 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: Need help tracking down problem accessing IETF Subversion repository on Mac OS X
On Sep 25, 2011, at 7:20 PM, Stuart Cheshire wrote: % svn info https://svn.tools.ietf.org/svn/wg/hybi svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/hybi': SSL negotiation failed: SSL error code -1/1/336032856 (https://svn.tools.ietf.org) If you're on a Mac, can you please try this command for me and let me know if it works for you or gives the 336032856 error? Happens to everyone with a Mac. Someone else will chime in before we Californians wake up tomorrow saying what the problem is. Speculation on a different list was that this is a mismatch between SSL library versions with some interaction with the new TLS renegotiation fix, but I haven't seen substantiation. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Grey Beards (was [81all] Quick Meeting Survey)
Ah, but how do you also take into account the people who go apache instead of salt and pepper? On Wed, Sep 21, 2011 at 5:46 AM, Elwyn Davies elw...@googlemail.com wrote: Time for the facial hair standard and ensuring that there is a proper three stage progression from provisional salt and pepper to full blown white out. /Elwyn Eric Burger wrote: You all are just bragging you still have hair :-( On Sep 21, 2011, at 12:55 AM, Melinda Shore wrote: On 9/20/11 6:26 PM, Ronald Bonica wrote: This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Beardless, but back when I started participating in the IETF my hair was nearly black. Now I've gone completely grey. Not trying to imply causality, of course. Count me in. Melinda ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
