Re: Consensus Call: draft-weil-shared-transition-space-request
Randy, On 11/30/11 6:09 AM, Randy Bush wrote: skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? cool. then, by that logic, let's use 240/4. the apps will patch within a week. ok, maybe two. As someone who tried to Go There, I agree with you that 240/4 is not usable. It would be fine in routers in short order, as it's fairly easy for ISPs to exert influence and get that code changed, but general purpose computing and all the OSS systems are a completely different kettle of fish. But that actually supports the notion that we need to use a different block of address space. So does the argument that 10/8 et al are well deployed within SPs. You wrote also that: and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. To keep this in the realm of the technical, perhaps you would say (a lot) more on how you think this would break IPv4? For the record, I'm of two minds- I hate the idea that the SPs haven't gotten farther along on transition, and I also wonder whether a rapider deployment of something like 6rd would be better than renumbering all edges into this space. On the other hand, that speaks nothing about all the content on v4 today, and that's where the pain point is. Thanks, Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gregorio-uritemplate-07.txt (URI Template)
On 30 November 2011 00:44, Mark Nottingham m...@mnot.net wrote: Not sure what you're saying here; the URI escape syntax is % HEXDIG HEXDIG. ACK, sorry for the confusion, I used the same ABNF hex. constructs as in the literals section for the square brackets. If the literal character [ occurs in a template, it'll also be copied into the result, since that's part of reserved (thanks to gen-delims). The intent here is definitely for a processor NOT to need to know what part of the URI it's in, since templates can make this ambiguous. Okay, that was answered my question, when the draft says anywhere it actually means anywhere, even if the output is no valid UEL. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gregorio-uritemplate-07.txt (URI Template)
2.3 Is undefined formally defined? This section suggests that 'undef' or 'null', inter alia, may be used to undefine a variable while 3.2 uses 'null'. I see no more formal definition of how to undefine a variable, as opposed to it having a value or having an empty value. 1.2 worth pointing out that 'reserved' and 'unreserved' are formally defined in 1.5, to stop people reaching for RFC3986. The examples are rather complicated. If I have a month to spare, I will work my way through them by which time, were I to find anything, doubtless it would be erratum time and no longer LC time. (How simple life was in the days of -00). Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 1 December 2011 05:09, Murray S. Kucherawy m...@cloudmark.com wrote: so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) Depends on the registry, some registrations need standards track, others want published RFC, some need IETF consensus, and so on, down to first come first served. The author of RFC 5451 wants published RFC with IETF review. that's below standards track, or in other words, IETF experimental with IETF Last Call is okay. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote: Randy, On 11/30/11 6:09 AM, Randy Bush wrote: skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? cool. then, by that logic, let's use 240/4. the apps will patch within a week. ok, maybe two. As someone who tried to Go There, I agree with you that 240/4 is not usable. It would be fine in routers in short order, as it's fairly easy for ISPs to exert influence and get that code changed, but general purpose computing and all the OSS systems are a completely different kettle of fish. Eliot - in the case of Shared CGN space, I think all that's needed is for the ISP routers between the CPEs and the CGN to forward 240.0.0.0/10 traffic. Those addresses will be hidden from the rest of the Internet by the CGN on one side and the subscriber GWs on the other side. If this address space weren't hidden, RFC 1918 space (e.g., 10.64.0.0/10) or a /10 reserved from public IPv4 space wouldn't work, either. Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, and there would likely have to be some small amount of parallel RFC 1918 space in the ISP core network for servers, hosts, etc. Of course, I'm not an operator, so I'd be happy to hear why I'm confused. - Ralph But that actually supports the notion that we need to use a different block of address space. So does the argument that 10/8 et al are well deployed within SPs. You wrote also that: and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. To keep this in the realm of the technical, perhaps you would say (a lot) more on how you think this would break IPv4? For the record, I'm of two minds- I hate the idea that the SPs haven't gotten farther along on transition, and I also wonder whether a rapider deployment of something like 6rd would be better than renumbering all edges into this space. On the other hand, that speaks nothing about all the content on v4 today, and that's where the pain point is. Thanks, Eliot ___ 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: Consensus Call: draft-weil-shared-transition-space-request
Ralph, Where we ran into trouble the last time on this was that the OSS systems themselves that manage the edge devices needed to be able to actually communicate with those devices using the reserved space (reachability testing, what-have-you). All that stuff runs on a variety of h/w, including Linux, Windows, and other. But if ops want to use 240/4, I say have at it! It's just sitting there, after all... Eliot On 12/1/11 2:06 PM, Ralph Droms wrote: On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote: Randy, On 11/30/11 6:09 AM, Randy Bush wrote: skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? cool. then, by that logic, let's use 240/4. the apps will patch within a week. ok, maybe two. As someone who tried to Go There, I agree with you that 240/4 is not usable. It would be fine in routers in short order, as it's fairly easy for ISPs to exert influence and get that code changed, but general purpose computing and all the OSS systems are a completely different kettle of fish. Eliot - in the case of Shared CGN space, I think all that's needed is for the ISP routers between the CPEs and the CGN to forward 240.0.0.0/10 traffic. Those addresses will be hidden from the rest of the Internet by the CGN on one side and the subscriber GWs on the other side. If this address space weren't hidden, RFC 1918 space (e.g., 10.64.0.0/10) or a /10 reserved from public IPv4 space wouldn't work, either. Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, and there would likely have to be some small amount of parallel RFC 1918 space in the ISP core network for servers, hosts, etc. Of course, I'm not an operator, so I'd be happy to hear why I'm confused. - Ralph But that actually supports the notion that we need to use a different block of address space. So does the argument that 10/8 et al are well deployed within SPs. You wrote also that: and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. To keep this in the realm of the technical, perhaps you would say (a lot) more on how you think this would break IPv4? For the record, I'm of two minds- I hate the idea that the SPs haven't gotten farther along on transition, and I also wonder whether a rapider deployment of something like 6rd would be better than renumbering all edges into this space. On the other hand, that speaks nothing about all the content on v4 today, and that's where the pain point is. Thanks, Eliot ___ 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: Consensus Call: draft-weil-shared-transition-space-request
On Dec 1, 2011, at 8:10 AM 12/1/11, Eliot Lear wrote: Ralph, Where we ran into trouble the last time on this was that the OSS systems themselves that manage the edge devices needed to be able to actually communicate with those devices using the reserved space (reachability testing, what-have-you). All that stuff runs on a variety of h/w, including Linux, Windows, and other. But if ops want to use 240/4, I say have at it! It's just sitting there, after all... Got it. I mistakenly inferred you were referring back to the discussion about adding 240.0.0.0/4 to the global address space pool... - Ralph Eliot On 12/1/11 2:06 PM, Ralph Droms wrote: On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote: Randy, On 11/30/11 6:09 AM, Randy Bush wrote: skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? cool. then, by that logic, let's use 240/4. the apps will patch within a week. ok, maybe two. As someone who tried to Go There, I agree with you that 240/4 is not usable. It would be fine in routers in short order, as it's fairly easy for ISPs to exert influence and get that code changed, but general purpose computing and all the OSS systems are a completely different kettle of fish. Eliot - in the case of Shared CGN space, I think all that's needed is for the ISP routers between the CPEs and the CGN to forward 240.0.0.0/10 traffic. Those addresses will be hidden from the rest of the Internet by the CGN on one side and the subscriber GWs on the other side. If this address space weren't hidden, RFC 1918 space (e.g., 10.64.0.0/10) or a /10 reserved from public IPv4 space wouldn't work, either. Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, and there would likely have to be some small amount of parallel RFC 1918 space in the ISP core network for servers, hosts, etc. Of course, I'm not an operator, so I'd be happy to hear why I'm confused. - Ralph But that actually supports the notion that we need to use a different block of address space. So does the argument that 10/8 et al are well deployed within SPs. You wrote also that: and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. To keep this in the realm of the technical, perhaps you would say (a lot) more on how you think this would break IPv4? For the record, I'm of two minds- I hate the idea that the SPs haven't gotten farther along on transition, and I also wonder whether a rapider deployment of something like 6rd would be better than renumbering all edges into this space. On the other hand, that speaks nothing about all the content on v4 today, and that's where the pain point is. Thanks, Eliot ___ 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: An Antitrust Policy for the IETF
On 11/28/11 12:58 , Jorge Contreras wrote: On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com mailto:g...@gtwassociates.com wrote: __ Ted, I like your approach of enquiring what problem we are striving to solve and I like Russ's concise answer that it is Recent suits against other SDOs that is the source of the concern Russ, what are some of the Recent suits against other SDOs It would be good to pin down the problem we are addressing There is FTC and N-data matter from 2008 http://www.gtwassociates.com/alerts/Ndata1.htm George -- one recent example is the pending antitrust suit by True Position against ETSI, 3GPP and several of their members (who also employ some IETF participants, I believe). Here is some relevant language from the Complaint: When or if that suit is concluded you may be able to divine whether the antitrust policy of either SDO was of any value. 100. By their failures to monitor and enforce the SSO Rules, and to respond to TruePosition's specific complaints concerning violations of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and complicit in, the abuse of authority and anticompetitive conduct by Ericsson, Qualcomm, and Alcatel-Lucent. These failures have resulted in the issuance of a Release 9 standard tainted by these unfair processes, and for the delay until Release 11, at the earliest, of a 3GPP standard for UTDOA positioning technology. By these failures, 3GPP and ETSI have authorized and ratified the anticompetitive conduct of Ericsson, Qualcomm, and Alcatel-Lucent and have joined in and become parties to their combination and conspiracy. ___ 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: An Antitrust Policy for the IETF
From: IETF Chair [ch...@ietf.org] The IETF legal counsel and insurance agent suggest that the IETF ought to have an antitrust policy. To address this need, a lawyer is needed. My first observation is that the IETF legal counsel is a lawyer, so we have that covered. Then I thought about it and realized that the IETF counsel may not be the right type of lawyer. Then I thought about it some more and realized that the choice of lawyer might be *very* important. Ideally, an antitrust policy is to prevent future legal problems, especially lawsuits. Unfortunately, lawyers on the whole tend to suggest solutions to problems that create additional legal work. And the situation of the IETF creating an optimal antitrust policy is hardly routine. So we're going to want a lawyer with very good judgment who understands the complications of antitrust law in an international context. I have no idea how to go about it, but selecting a good lawyer for this job is an important and nontrivial task. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: An Antitrust Policy for the IETF
Note that the suit does not complain about the 3GPP and ETSI rules. It alleges instead that the rules were not enforced, and that the leadership of these organization failed to prevent the alleged anti-competitive behavior of some companies. I believe that our current rules are fine. They were specifically designed to prevent the kind of collusion described in the complaint. Yes, these rules were defined many years ago, but the Sherman Antitrust Act is even older -- it dates from 1890. We have an open decision process, explicit rules for intellectual property, and a well-defined appeals process. If the plaintiffs in the 3GPP/IETF lawsuit had been dissatisfied with an IETF working group, they could have use the IETF appeal process to raise the issue to the IESG, and the dispute would probably have been resolved after an open discussion. Rather than trying to set up rules that cover all hypothetical developments, I would suggest a practical approach. In our process, disputes are materialized by an appeal. Specific legal advice on the handling of a specific appeal is much more practical than abstract rulemaking. -- Christian Huitema -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel jaeggli Sent: Thursday, December 01, 2011 8:56 AM To: Jorge Contreras Cc: Ted Hardie; IETF Chair; IETF; IESG Subject: Re: An Antitrust Policy for the IETF On 11/28/11 12:58 , Jorge Contreras wrote: On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com mailto:g...@gtwassociates.com wrote: __ Ted, I like your approach of enquiring what problem we are striving to solve and I like Russ's concise answer that it is Recent suits against other SDOs that is the source of the concern Russ, what are some of the Recent suits against other SDOs It would be good to pin down the problem we are addressing There is FTC and N-data matter from 2008 http://www.gtwassociates.com/alerts/Ndata1.htm George -- one recent example is the pending antitrust suit by True Position against ETSI, 3GPP and several of their members (who also employ some IETF participants, I believe). Here is some relevant language from the Complaint: When or if that suit is concluded you may be able to divine whether the antitrust policy of either SDO was of any value. 100. By their failures to monitor and enforce the SSO Rules, and to respond to TruePosition's specific complaints concerning violations of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and complicit in, the abuse of authority and anticompetitive conduct by Ericsson, Qualcomm, and Alcatel-Lucent. These failures have resulted in the issuance of a Release 9 standard tainted by these unfair processes, and for the delay until Release 11, at the earliest, of a 3GPP standard for UTDOA positioning technology. By these failures, 3GPP and ETSI have authorized and ratified the anticompetitive conduct of Ericsson, Qualcomm, and Alcatel-Lucent and have joined in and become parties to their combination and conspiracy. ___ 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
Re: IAOC Member Selection
The IESG has received a single nomination for the IAOC position. Given this situation, we are extending the deadline to nominations to 7 December 2011. In addition, we are opening the comment period on the single willing candidate that we have before us: Ole Jacobsen. Please send new nominations and comments on Ole to i...@ietf.org. On behalf of the IESG, Russ Housley IESG Chair On Nov 13, 2011, at 1:04 AM, IETF Chair wrote: Ole Jacobsen is the IAOC member that was appointed by the IESG, and his two-year term is up in March. The IESG is starting the process to fill this seat in March 2012, with the term ending in March 2014. The two-week nominations period opens today, and closes on 27 November 2011. Nominations and eligibility The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, and IESG members are eligible for nomination. Of course, IAB and IESG members who accept nomination will recuse themselves from selection and confirmation discussions. Please send nominations to i...@ietf.org. Please include the following with each nomination: - Name - Contact information - Candidate background and qualifications Desirable Qualifications and Selection Criteria Candidates for the IAOC position should have a demonstrable involvement in the IETF, knowledge of contracts and financial procedures, awareness of the administrative support needs of the IAB, the IESG, and the IETF standards process. The candidate is also expected to understand the respective roles and responsibilities of the IETF and ISOC in IASA, and be able to articulate these roles within the IETF community. The candidate must be able to exercise all the duties of an IAOC Board member, including fiduciary responsibilities, setting of policies, oversight of the administrative operations of the IETF, representing the interests of the IETF, and participating in IAOC meetings and activities. The candidate must be able to serve as a Trustee for the IETF Trust. Although the IESG selects this member of the IAOC, the selected member does not directly represent the IESG. The IESG-selected member is accountable directly to the IETF community. BCP 101 says: The IAOC shall consist of eight voting members who shall be selected as follows: o Two members appointed by the IETF Nominations Committee (NomCom); o One member appointed by the IESG; o One member appointed by the IAB; o One member appointed by the ISOC Board of Trustees; o The IETF Chair (ex officio); o The IAB Chair (ex officio); o The ISOC President/CEO (ex officio). Selection The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and make a selection. Confirmation The IAB will act as the confirming body for the selection. In the event that the IAB determines not to confirm the nominated candidate, the IAB will provide the IESG with the basis for this determination and the IESG will nominate another candidate. Care of Personal Information The following procedures will be used in managing candidates' personal information: - The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. - Excerpts of the information provided to the IESG by the nominated candidate will be passed to the IAB as part of the confirmation process. The IAB will be requested to maintain confidentiality of candidate information. - Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. Timeframe The two-week nominations period opens today, and closes on 27 November 2011. The list of willing candidates will be posted shortly after the nominations close, and the community will have two weeks to provide comments on the candidates to the IESG. The IESG will make a selection on an IESG telechat following the comment period and send the name of the selected candidate to the IAB for confirmation. On behalf of the IESG, Russ Housley IESG Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Ralph, I'm not sure what would take longer - getting new subscriber gws supporting 240/4 or IPv6 into the field, and I know which one I'd prefer vendor engineers to be working on ;-). Chris On 12/1/11 6:06 AM, Ralph Droms rdroms.i...@gmail.com wrote: Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, and there would likely have to be some small amount of parallel RFC 1918 space in the ISP core network for servers, hosts, etc. Of course, I'm not an operator, so I'd be happy to hear why I'm confused. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 29 Nov 2011, at 18:54, Ronald Bonica wrote: I think that our time would be used much more productively if we discussed whether to make the allocation or not. The proposed status of the document is a secondary issue. yes, it is, and yes, we should. I've slept on it, but it's no good. Ultimately, here is how it works: there are stupid people, organisations and ISPs who will resist all common sense and do the wrong thing no matter what. It is in our best interests if they do the wrong thing at the cost of the least inconvenience to everybody else involved when that is at all possible. IPv4 is now practically dead. Saving it is a waste of time. It has market value in its reduced form; let those of us who know how to exploit it to the last do so. It does not matter. It is seppuku to take no action on IPv6. Nobody here should be applying their principles to the contrary in standards. A lasting strategy to keep what's left of IPv4 is now purely transitional; no new entrants will want or need full IPv4 access, at the expense of every other legitimate user, even in reduced form, but especially not the grasshoppers who will no doubt foolishly try to create market differentiation. And when they do, they can make their case to the regional registries, using only the address space that is needed, and benefiting everybody. Wasting little drops of ARIN's resources with this allocation, by extension, is also no problem to the Hastening of IPv6 deployment; the space is used, whichever way, and to the same effect. Artificially created scarcity through non-prov ision of private space will still result in the creation of private spaces and lack of addresses. ISPs will be left communicating their incompetence in either case. Later, we can watch the live executions and tortures of management behind the IPv4 crisis. Just now, though, IPv4 is a market requirement for everybody. Simple as. We must provide. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
I will add one more concern with this allocation. IPv4 address allocation is a market (supply exceeds demand in this case), and thus a strategic game (like chess) to gather limited resources . We have known for a long time how IPv4 was not an acceptable long term solution. We have known for a long time that IPv6 is the only path forward for a growing internet (more people online, more devices connected, up and to the right...) This allocation is changing the rules of the game in the last few minutes (IANA and APNIC are already out...) and is dubiously blessing an Internet model based on CGN. Changing the rules of the game towards the end to manipulate the outcome is seldom acceptable, regardless of the context. AFAIK, there have been no extenuating circumstance that have dictated a need for a change. IPv4 did not magically run out. My favorite IPv4 risk artifact should be familiar to the draft authors or other people in the ARIN region: https://www.arin.net/knowledge/about_resources/ceo_letter.pdf I understand how this allocations benefits folks in the short run, and i promise to use this allocation to my benefit (better than squat space, right?!). But, at the macroscopic level at which the IETF, IESG, and IAB should be working, this is just changing the rules of the game at the last minute because some players don't like the outcome, even though this outcome (ipv4 is out, need to use v6) has had 10+ years of runway. I do not believe this is a positive sum game where this allocation is made and everyone wins. I do believe IPv6 loses (CGN vs v6 investment*, urgency, lines on strategy diagrams...) if this allocation is made, and i do not think it is acceptable to change the rules of the game in the final moments because the outcome is costly for some. Cameron *i already have the link to your press release that your lab is ipv6 enabled, thanks! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Document Writeup for draft-betts-itu-oam-ach-code-point-01.txt As required by RFC-to-be draft-iesg-sponsoring-guidelines, this is the current template for the Document Shepherd Write-Up for individual submissions via the IESG. Changes are expected over time. This version is dated February 5, 2007. -- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Huub van Helvoort (huub.van.helvo...@huawei.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG to be published. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was first posted on 16th October; no discussion has taken place on any email lists. However, this draft is addressing a well know issue that was first brought to the attention of the IETF in a request from the director of the ITU-T in June 2010 requesting the assignment of an ACh code point that would be used to run Ethernet based OAM on MPLS-TP networks. The draft requests IANA to assign a code point from the registry of Pseudowire Associated Channel Types. It does not make any proposals to modify the MPLS data plane forwarding behaviour or of the any IETF defined protocols. Therefore, review by the MPLS WG is not required. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The purpose of the document is clear and the scope is limited to the assignment of a code point for (restricted) use by the ITU-T. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The issue of supporting an alternative set of OAM mechanisms for MPLS-TP based on Ethernet OAM has been widely discussed without reaching any firm conclusion. Note that more than 350,000 nodes have now been deployed with Ethernet based OAM using a code point from the experimental range. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? This draft is requesting the assignment of an ACh code point that will be used to run Ethernet based OAM on MPLS-TP networks. This protocol has been defined in the ITU-T and should not be considered to be a MPLS protocol and therefore should not subject to the provisions of RFC 4929. This request is supported by a significant number of network operators. However, discussion on the IETF list during the last call of draft-sprecher-mpls-tp-oam-considerations indicates that other do not support the view that aa alternative Ethernet based OAM mechanism is required. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated, however see the discussion on the IETF list during the last call of draft-sprecher-mpls-tp-oam-considerations. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist http://www.ietf.org/id-info/checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? No ID_nits found; the draft does not define a MIB or any protocols. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as
Re: Consensus Call: draft-weil-shared-transition-space-request
From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com IPv4 is now practically dead. The logic here doesn't seem to follow. If it's basically dead, why do you care how the remaining address space is allocated? From: Cameron Byrne cb.li...@gmail.com I do not believe this is a positive sum game where this allocation is made and everyone wins. I do believe IPv6 loses ... if this allocation is made Insanity: doing the same thing over and over again and expecting different results. -- Albert Einstein, (attributed) This whole 'if we make life difficult for IPv4, it will hasten the spread of IPv6' strategy has been tried again, and again, and again, and again... and how much success has it had? Whether this allocation is made or not, I would guess that basically all the ISPs who are going with CGN are going to... go with CGN. My sense is that allocating, or not allocating, this space is not going to have much influence on that decision - only on how ugly the results are. Blocking this, hoping that doing so will speed deployment of IPv6, is just lame. Is IPv6 really that desperate? Perhaps you could be putting the time and energy you all are putting into fighting this into coming up with _positive_ ideas on how to spread IPv6, instead. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Notes below. On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick presn...@qualcomm.com wrote: ** Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr I wrote a response to Brian's original statement then deleted it because I assumed others would ignore it as clearly last minute and ill-researched. Apparently, that was wrong. There are enterprises that currently use 172.16/12. (There are enterprises which use every tiny piece of RFC 1918 space.) *Any* piece of the current RFC 1918 space you attempt to define as being used for this will conflict *somewhere*. Anyone who happened to chose this for an enterprise deployment and gets stuck behind a CGN would be forced to renumber, in other words, because of this statement. That is, if they actually followed the statement--they're much more likely to work with the CGN operator to use squat space on the CGN instead, since that's the existing way of avoiding this pain. Rubbing my crystal ball real hard, in other words, I predict that the consequences of assigning a piece of existing RFC 1918 space to this at this late date will have the same consequences as assigning no space at all, with the addition of a tiny increment of confusion among those souls who happen to read the RFC and briefly think it reflects reality. Either allocate new space or reject; the middle ground of assuming that some part of RFC 1918 can be safely allocated for this should not be considered as an option. My personal opinion, not that of my employer, spouse, child, or the man on the street. regards, Ted On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.comwrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnick http://www.qualcomm.com/~presnick/ http://www.qualcomm.com/%7Epresnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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-ietf-marf-redaction-03.txt (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC
This draft proposes a way to semi-redact personal information in spam reports by replacing the address or other string by a hash. It's a reasonable idea, but as far as I know, it has not been implemented. Speaking as one of the authors of RFC 5965, which this draft would update if it were on the standards track, I'd have no objection to folding this into an updated version of 5965 if there were some evidence that people actually did what it proposes. Hence I would suggest it be published as experimental rather than informational. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
As shown at https://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ballot/, a few (heh) members of the IESG want to have more discussion on the draft. Maybe we should wait for one of them (likely Ron) to give direction to that discussion. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/1/11 4:02 PM, Paul Hoffman wrote: As shown at https://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ballot/, a few (heh) members of the IESG want to have more discussion on the draft. Maybe we should wait for one of them (likely Ron) to give direction to that discussion. Yes, that will be forthcoming soon. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
This is not a new proposal. People have been asking for the same thing for a long time. Draft-bdgks does a good job spelling out the history (below). To say that we're trying to change the rules at the last minute is wrong. People have been asking for such an allocation considering this use case as long ago as 2004, and fairly consistently since 2008. We and the other draft authors have been following IETF process, documenting the need, documenting the tradeoffs, and documenting the challenges with CGN for quite some time. People wouldn't keep coming back to the IETF again and again for seven years or so if we had a better way to satisfy this need (although I am aware that some operators have opted for squat space rather than push for a shared pool of CGN space). Chris From bdgks: Proposals for additional Private space date back at least to [I-D.hain-1918bis http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.hain-1918bis] in April 2004. Some of these proposals and surrounding discussion may have considered similar use-cases as described herein. However, they were fundamentally intended to increase the size of the [RFC1918 http://tools.ietf.org/html/rfc1918] pool, whereas a defining characteristic of Shared Transition Space is that it is distinctly not part of the Private [RFC1918 http://tools.ietf.org/html/rfc1918] address pool. Rather, the Shared Transition Space is reserved for more narrow deployment scenarios, specifically for use by SPs to meet the needs of ongoing IPv4 connectivity during the period of IPv6 transition. This key feature emerged in more recent proposals such as [I-D.shirasaki-isp-shared-addr http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.shirasaki-isp-shared-addr] in June 2008 where a proposal to set aside ISP Shared Space was made. During discussion of these more recent proposals, many of the salient points where commented upon, including challenges with RFC1918 http://tools.ietf.org/html/rfc1918 in the ISP NAT Zone, Avoidance of IP Address Conflicts, and challenges with 240/4. This effort was followed up by [I-D.weil-opsawg-provider-address-space http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-opsawg-provider-address-space] in July 2010 which was re- worked in November 2010 as [I-D.weil-shared-transition-space-request http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-shared-transition-space-request]. These latter efforts continued to point out the operators' need for Shared Transition Space, with full acknowledgement that challenges may arise with NAT444 as per [I-D.donley-nat444-impacts http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.donley-nat444-impacts] and that such space does not reduce the need for IPv6 deployment. Most recently, following exhaustion of the IANA's /8 pool [NRO-IANA-exhaust http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -NRO-IANA-exhaust], this proposal has been discussed by various RIR policy development participants. As described herein, the body of ARIN policy development participants has reached consensus and recommended a Shared Address Space policy for adoption [ARIN-2011-5 http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -ARIN-2011-5]. This history shows that operators and other industry contributors have consistently identified the need for a Shared Transition Space assignment, based on pragmatic operational needs. The previous work has also described the awareness of the challenges of this space, but points to this option as the most manageable and workable solution for IPv6 transition space. Chris On 12/1/11 2:05 PM, Cameron Byrne cb.li...@gmail.com wrote: I will add one more concern with this allocation. IPv4 address allocation is a market (supply exceeds demand in this case), and thus a strategic game (like chess) to gather limited resources . We have known for a long time how IPv4 was not an acceptable long term solution. We have known for a long time that IPv6 is the only path forward for a growing internet (more people online, more devices connected, up and to the right...) This allocation is changing the rules of the game in the last few minutes (IANA and APNIC are already out...) and is dubiously blessing an Internet model based on CGN. Changing the rules of the game towards the end to manipulate the outcome is seldom acceptable, regardless of the context. AFAIK, there have been no extenuating circumstance that have dictated a need for a change. IPv4 did not magically run out. My favorite IPv4 risk artifact should be familiar to the draft authors or other people in the ARIN region: https://www.arin.net/knowledge/about_resources/ceo_letter.pdf I understand how this allocations benefits folks
Re: Consensus Call: draft-weil-shared-transition-space-request
Ted, There are enterprises that currently use 172.16/12. Yes, but I thought the topic of discussion when I wrote was the default prefix used by mass-market NAT CPE boxes. That's a very different problem than dealing with enterprise networks or even ISPs that have intentionally deployed 172.16/12. I'm not suggesting that reconfiguring those intentional deployments is easy, but then no solution to this problem is easy. Reconfiguring mass-market boxes is simply impossible. Regards Brian On 2011-12-02 11:27, Ted Hardie wrote: Notes below. On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick presn...@qualcomm.com wrote: ** Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr I wrote a response to Brian's original statement then deleted it because I assumed others would ignore it as clearly last minute and ill-researched. Apparently, that was wrong. There are enterprises that currently use 172.16/12. (There are enterprises which use every tiny piece of RFC 1918 space.) *Any* piece of the current RFC 1918 space you attempt to define as being used for this will conflict *somewhere*. Anyone who happened to chose this for an enterprise deployment and gets stuck behind a CGN would be forced to renumber, in other words, because of this statement. That is, if they actually followed the statement--they're much more likely to work with the CGN operator to use squat space on the CGN instead, since that's the existing way of avoiding this pain. Rubbing my crystal ball real hard, in other words, I predict that the consequences of assigning a piece of existing RFC 1918 space to this at this late date will have the same consequences as assigning no space at all, with the addition of a tiny increment of confusion among those souls who happen to read the RFC and briefly think it reflects reality. Either allocate new space or reject; the middle ground of assuming that some part of RFC 1918 can be safely allocated for this should not be considered as an option. My personal opinion, not that of my employer, spouse, child, or the man on the street. regards, Ted On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.comwrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnick http://www.qualcomm.com/~presnick/ http://www.qualcomm.com/%7Epresnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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
Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 1, 2011 4:02 PM, Chris Donley c.don...@cablelabs.com wrote: This is not a new proposal. People have been asking for the same thing for a long time. Draft-bdgks does a good job spelling out the history (below). To say that we're trying to change the rules at the last minute is wrong. People have been asking for such an allocation considering this use case as long ago as 2004, and fairly consistently since 2008. We and the other draft authors have been following IETF process, documenting the need, documenting the tradeoffs, and documenting the challenges with CGN for quite some time. People wouldn't keep coming back to the IETF again and again for seven years or so if we had a better way to satisfy this need (although I am aware that some operators have opted for squat space rather than push for a shared pool of CGN space). I know this is not a new case. And I know efforts to make 240/4 workable are also not new. And, historically the answer is always no to new special ipv4 space. Someone else can expound why. If I had 240/4 in 2008, I would not have ipv6 now, that is a straight strategic business planning fact. Saying yes now, would be changing the rules because 'the rule' was/is 'no' new space. Cb Chris From bdgks: Proposals for additional Private space date back at least to [I-D.hain-1918bis http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.hain-1918bis] in April 2004. Some of these proposals and surrounding discussion may have considered similar use-cases as described herein. However, they were fundamentally intended to increase the size of the [RFC1918 http://tools.ietf.org/html/rfc1918] pool, whereas a defining characteristic of Shared Transition Space is that it is distinctly not part of the Private [RFC1918 http://tools.ietf.org/html/rfc1918] address pool. Rather, the Shared Transition Space is reserved for more narrow deployment scenarios, specifically for use by SPs to meet the needs of ongoing IPv4 connectivity during the period of IPv6 transition. This key feature emerged in more recent proposals such as [I-D.shirasaki-isp-shared-addr http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.shirasaki-isp-shared-addr] in June 2008 where a proposal to set aside ISP Shared Space was made. During discussion of these more recent proposals, many of the salient points where commented upon, including challenges with RFC1918 http://tools.ietf.org/html/rfc1918 in the ISP NAT Zone, Avoidance of IP Address Conflicts, and challenges with 240/4. This effort was followed up by [I-D.weil-opsawg-provider-address-space http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-opsawg-provider-address-space] in July 2010 which was re- worked in November 2010 as [I-D.weil-shared-transition-space-request http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-shared-transition-space-request]. These latter efforts continued to point out the operators' need for Shared Transition Space, with full acknowledgement that challenges may arise with NAT444 as per [I-D.donley-nat444-impacts http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.donley-nat444-impacts] and that such space does not reduce the need for IPv6 deployment. Most recently, following exhaustion of the IANA's /8 pool [NRO-IANA-exhaust http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -NRO-IANA-exhaust], this proposal has been discussed by various RIR policy development participants. As described herein, the body of ARIN policy development participants has reached consensus and recommended a Shared Address Space policy for adoption [ARIN-2011-5 http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -ARIN-2011-5]. This history shows that operators and other industry contributors have consistently identified the need for a Shared Transition Space assignment, based on pragmatic operational needs. The previous work has also described the awareness of the challenges of this space, but points to this option as the most manageable and workable solution for IPv6 transition space. Chris On 12/1/11 2:05 PM, Cameron Byrne cb.li...@gmail.com wrote: I will add one more concern with this allocation. IPv4 address allocation is a market (supply exceeds demand in this case), and thus a strategic game (like chess) to gather limited resources . We have known for a long time how IPv4 was not an acceptable long term solution. We have known for a long time that IPv6 is the only path forward for a growing internet (more people online, more devices connected, up and to the right...) This allocation is changing the rules of the game in the last few minutes (IANA and APNIC are already out...) and is dubiously
Re: Consensus Call: draft-weil-shared-transition-space-request
On 1 Dec 2011, at 21:41, Noel Chiappa wrote: From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com IPv4 is now practically dead. The logic here doesn't seem to follow. If it's basically dead, why do you care how the remaining address space is allocated? I don't. The marketeers do. For everybody who says, Don't worry, the IETF is there for us, IPv4 will not go away because there is always going to be a need for it, I am happy to oblige the loss of another /8, or /10, for use in some horrible NAT4 arrangement. However, it's true that I'd much rather we had botched, but available, IPv4 than full, but scarce, IPv4, because that provides the greatest benefit to everybody concerned in the current conditions, i.e., mostly IPv4. So, to the extent that people have *any* working IPv4, I care, otherwise, we can just start with the slate the IETF proposed over a decade ago now. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
+1 On Dec 1, 2011, at 1:44 PM, Christian Huitema wrote: Note that the suit does not complain about the 3GPP and ETSI rules. It alleges instead that the rules were not enforced, and that the leadership of these organization failed to prevent the alleged anti-competitive behavior of some companies. I believe that our current rules are fine. They were specifically designed to prevent the kind of collusion described in the complaint. Yes, these rules were defined many years ago, but the Sherman Antitrust Act is even older -- it dates from 1890. We have an open decision process, explicit rules for intellectual property, and a well-defined appeals process. If the plaintiffs in the 3GPP/IETF lawsuit had been dissatisfied with an IETF working group, they could have use the IETF appeal process to raise the issue to the IESG, and the dispute would probably have been resolved after an open discussion. Rather than trying to set up rules that cover all hypothetical developments, I would suggest a practical approach. In our process, disputes are materialized by an appeal. Specific legal advice on the handling of a specific appeal is much more practical than abstract rulemaking. -- Christian Huitema -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel jaeggli Sent: Thursday, December 01, 2011 8:56 AM To: Jorge Contreras Cc: Ted Hardie; IETF Chair; IETF; IESG Subject: Re: An Antitrust Policy for the IETF On 11/28/11 12:58 , Jorge Contreras wrote: On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com mailto:g...@gtwassociates.com wrote: __ Ted, I like your approach of enquiring what problem we are striving to solve and I like Russ's concise answer that it is Recent suits against other SDOs that is the source of the concern Russ, what are some of the Recent suits against other SDOs It would be good to pin down the problem we are addressing There is FTC and N-data matter from 2008 http://www.gtwassociates.com/alerts/Ndata1.htm George -- one recent example is the pending antitrust suit by True Position against ETSI, 3GPP and several of their members (who also employ some IETF participants, I believe). Here is some relevant language from the Complaint: When or if that suit is concluded you may be able to divine whether the antitrust policy of either SDO was of any value. 100. By their failures to monitor and enforce the SSO Rules, and to respond to TruePosition's specific complaints concerning violations of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and complicit in, the abuse of authority and anticompetitive conduct by Ericsson, Qualcomm, and Alcatel-Lucent. These failures have resulted in the issuance of a Release 9 standard tainted by these unfair processes, and for the delay until Release 11, at the earliest, of a 3GPP standard for UTDOA positioning technology. By these failures, 3GPP and ETSI have authorized and ratified the anticompetitive conduct of Ericsson, Qualcomm, and Alcatel-Lucent and have joined in and become parties to their combination and conspiracy. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Rather than trying to set up rules that cover all hypothetical developments, I would suggest a practical approach. In our process, disputes are materialized by an appeal. Specific legal advice on the handling of a specific appeal is much more practical than abstract rulemaking. +1 This has the admirable advantage of waiting until there is an actual problem to address, rather than trying to guess what has not happened in the past 30 years but might happen in the future. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/1/11 4:27 PM, Ted Hardie wrote: On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick presn...@qualcomm.com mailto:presn...@qualcomm.com wrote: The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by [Robert], among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. I wrote a response to Brian's original statement then deleted it because I assumed others would ignore it as clearly last minute and ill-researched. Apparently, that was wrong. There are enterprises that currently use 172.16/12. (There are enterprises which use every tiny piece of RFC 1918 space.) Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. I am happy to accept an answer of, Yes, all 1918 address space is used by such equipment, but nobody, including you, has actually said that. *Any* piece of the current RFC 1918 space you attempt to define as being used for this will conflict *somewhere*. Anyone who happened to chose this for an enterprise deployment and gets stuck behind a CGN would be forced to renumber, in other words, because of this statement. That statement does not logically follow from all 1918 address space is used. You are missing a premise: There exists equipment that is used in all of that space that can't handle identical addresses on the interior and exterior interface. The current draft says that the reason 1918 space can't be used is that equipment that deals in 1918 address space is hosed if 1918 addresses are used on their external interface. Brian claimed that perhaps 172.16/12 space might not be used by that equipment. Robert claimed that perhaps only 192.168 and 10.0.0.x addresses are used by that equipment. So the question I posed was, Does any of *that* equipment use 172.16/12 (or 10.x/16) space? Nobody has said yes. And *I'm* still not claiming that the answer is No. I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is Yes. That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/01/2011 19:47, Pete Resnick wrote: The current draft says that the reason 1918 space can't be used is that equipment that deals in 1918 address space is hosed if 1918 addresses are used on their external interface. Let's assume that's true for a second (I haven't seen any evidence of that). We all know that if the /10 is allocated that people are going to use it for 1918 space. So, back to square 1. Brian claimed that perhaps 172.16/12 space might not be used by that equipment. Robert claimed that perhaps only 192.168 and 10.0.0.x addresses are used by that equipment. So the question I posed was, Does any of *that* equipment use 172.16/12 (or 10.x/16) space? Nobody has said yes. And *I'm* still not claiming that the answer is No. I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is Yes. That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on. The lack of research on this point has been pointed out in the past, and TMK has never been addressed. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. I am happy to accept an answer of, Yes, all 1918 address space is used by such equipment, but nobody, including you, has actually said that. I suspect that is because it is impossible to know for sure. Ron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Would you take a check for $50 million USD instead of the /10? Sounds like they are equivalent value. http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/1/11 10:12 PM, Doug Barton wrote: On 12/01/2011 19:47, Pete Resnick wrote: The current draft says that the reason 1918 space can't be used is that equipment that deals in 1918 address space is hosed if 1918 addresses are used on their external interface. Let's assume that's true for a second (I haven't seen any evidence of that). We all know that if the /10 is allocated that people are going to use it for 1918 space. So, back to square 1. No, that's not true. Once this document claims that a particular block of addresses will be used on both internal and external interfaces, whether they're from a part of 1918 space that isn't used by the broken equipment *or* from a new /10 (which obviously isn't used by the broken equipment), any *new* use of this address space by *newly* broken equipment is acceptable to the CGN people. The only thing the current document worries about is deployed equipment that the CGN people can't push back on. So either a new /10 or 1918 space not used by current broken equipment addresses this problem. Brian claimed that perhaps 172.16/12 space might not be used by that equipment. Robert claimed that perhaps only 192.168 and 10.0.0.x addresses are used by that equipment. So the question I posed was, Does any of *that* equipment use 172.16/12 (or 10.x/16) space? Nobody has said yes. And *I'm* still not claiming that the answer is No. I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is Yes. That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on. The lack of research on this point has been pointed out in the past, and TMK has never been addressed. Ron's point (that part of the problem is that people simply don't know) is well-taken, but if there is not even anecdotal information that 172.16/12 or 10.x/16 is used by broken equipment, I'd like there to be some research before we say that allocating a /10 is necessary. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/1/11 20:28 , Pete Resnick wrote: On 12/1/11 10:12 PM, Doug Barton wrote: On 12/01/2011 19:47, Pete Resnick wrote: The current draft says that the reason 1918 space can't be used is that equipment that deals in 1918 address space is hosed if 1918 addresses are used on their external interface. Let's assume that's true for a second (I haven't seen any evidence of that). We all know that if the /10 is allocated that people are going to use it for 1918 space. So, back to square 1. No, that's not true. Once this document claims that a particular block of addresses will be used on both internal and external interfaces, whether they're from a part of 1918 space that isn't used by the broken equipment *or* from a new /10 (which obviously isn't used by the broken equipment), any *new* use of this address space by *newly* broken equipment is acceptable to the CGN people. The only thing the current document worries about is deployed equipment that the CGN people can't push back on. So either a new /10 or 1918 space not used by current broken equipment addresses this problem. Brian claimed that perhaps 172.16/12 space might not be used by that equipment. Robert claimed that perhaps only 192.168 and 10.0.0.x addresses are used by that equipment. So the question I posed was, Does any of *that* equipment use 172.16/12 (or 10.x/16) space? Nobody has said yes. And *I'm* still not claiming that the answer is No. I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is Yes. That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on. The lack of research on this point has been pointed out in the past, and TMK has never been addressed. Ron's point (that part of the problem is that people simply don't know) is well-taken, but if there is not even anecdotal information that 172.16/12 or 10.x/16 is used by broken equipment, I'd like there to be some research before we say that allocating a /10 is necessary. it's simpler than that. assuming that there existing a pool of devices for which it can be stipulated: * does not support a collision between internal and external address ranges * has a collision between it's internal address ranges and assigned external prefix in 10/8 It seems unlikely in the extreme that home cpe statifying both conditions would also have a collision with an assignment out of 172.16/12. I have never found the arguement that, that particular problem intractable enough to benifit from and additional prefix to be particularly compelling. pr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 263 messages in the last 7 days. script run at: Fri Dec 2 00:53:02 EST 2011 Messages | Bytes| Who +--++--+ 4.18% | 11 | 3.52% |71750 | julian.resc...@gmx.de 3.80% | 10 | 2.86% |58256 | jo...@iecc.com 3.42% |9 | 2.61% |53148 | d...@dcrocker.net 2.66% |7 | 2.66% |54208 | brian.e.carpen...@gmail.com 2.28% |6 | 3.02% |61671 | cb.li...@gmail.com 2.66% |7 | 2.41% |49166 | do...@dougbarton.us 3.04% |8 | 2.02% |41282 | ra...@psg.com 2.28% |6 | 2.52% |51455 | victor.kuarsi...@gmail.com 1.90% |5 | 2.89% |58975 | presn...@qualcomm.com 2.28% |6 | 2.38% |48475 | petit...@acm.org 2.28% |6 | 2.35% |47872 | yaako...@rad.com 2.28% |6 | 2.34% |47632 | rbon...@juniper.net 1.52% |4 | 2.96% |60432 | hous...@vigilsec.com 2.28% |6 | 2.07% |42181 | john-i...@jck.com 2.28% |6 | 1.96% |39963 | ma...@isc.org 1.90% |5 | 2.28% |46477 | c.don...@cablelabs.com 2.28% |6 | 1.68% |34221 | a...@anvilwalrusden.com 1.90% |5 | 1.75% |35788 | daedu...@btconnect.com 1.90% |5 | 1.56% |31818 | m...@cloudmark.com 1.90% |5 | 1.50% |30591 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com 1.52% |4 | 1.88% |38295 | rich...@shockey.us 1.52% |4 | 1.71% |34847 | rdroms.i...@gmail.com 1.52% |4 | 1.52% |31042 | huit...@microsoft.com 1.52% |4 | 1.49% |30420 | hen...@levkowetz.com 1.52% |4 | 1.46% |29712 | ch...@ietf.org 1.52% |4 | 1.38% |28161 | s...@resistor.net 1.14% |3 | 1.73% |35347 | ted.i...@gmail.com 1.52% |4 | 1.33% |27200 | ietf2d...@davearonson.com 1.52% |4 | 1.29% |26330 | bishop.robin...@gmail.com 1.52% |4 | 1.27% |25840 | ty...@mit.edu 1.52% |4 | 1.22% |24971 | m...@sabahattin-gucukoglu.com 0.76% |2 | 1.65% |33636 | ebur...@standardstrack.com 1.14% |3 | 1.22% |24811 | margaret...@gmail.com 0.76% |2 | 1.58% |32245 | daryl.tan...@blueyonder.co.uk 1.14% |3 | 1.02% |20847 | m...@sap.com 0.76% |2 | 1.37% |27981 | m...@townsley.net 1.14% |3 | 0.98% |19977 | j...@jck.com 1.14% |3 | 0.88% |18022 | paul.hoff...@vpnc.org 1.14% |3 | 0.84% |17036 | m...@sandelman.ca 1.14% |3 | 0.83% |16907 | hartmans-i...@mit.edu 1.14% |3 | 0.77% |15644 | j...@mercury.lcs.mit.edu 0.76% |2 | 1.10% |22504 | suma...@cablelabs.com 0.76% |2 | 0.98% |19915 | wesley.geo...@twcable.com 0.76% |2 | 0.88% |18038 | terry.mander...@icann.org 0.76% |2 | 0.87% |17704 | cgrundem...@gmail.com 0.76% |2 | 0.82% |16790 | eburge...@standardstrack.com 0.76% |2 | 0.78% |15966 | l...@cisco.com 0.76% |2 | 0.77% |15686 | stbry...@cisco.com 0.76% |2 | 0.72% |14735 | marshall.euba...@gmail.com 0.38% |1 | 1.06% |21671 | jean-francois.tremblay...@videotron.com 0.76% |2 | 0.66% |13490 | ned+i...@mauve.mrochek.com 0.76% |2 | 0.65% |13185 | bob.hin...@gmail.com 0.76% |2 | 0.63% |12883 | mansa...@besserwisser.org 0.76% |2 | 0.58% |11777 | d...@cridland.net 0.76% |2 | 0.57% |11621 | stpe...@stpeter.im 0.76% |2 | 0.46% | 9410 | i...@ietf.org 0.38% |1 | 0.72% |14689 | huub.van.helvo...@huawei.com 0.38% |1 | 0.66% |13373 | g...@gtwassociates.com 0.38% |1 | 0.56% |11339 | k...@munnari.oz.au 0.38% |1 | 0.53% |10807 | berti...@bwijnen.net 0.38% |1 | 0.52% |10570 | ida_le...@yahoo.com 0.38% |1 | 0.49% |10052 | cntre...@gmail.com 0.38% |1 | 0.49% | 9950 | o...@delong.com 0.38% |1 | 0.48% | 9788 | f...@cisco.com 0.38% |1 | 0.47% | 9559 | hsan...@isdg.net 0.38% |1 | 0.42% | 8467 | s...@sobco.com 0.38% |1 | 0.41% | 8330 | l...@asgard.org 0.38% |1 | 0.41% | 8292 | sha...@juniper.net 0.38% |1 | 0.39% | 7877 | s...@harvard.edu 0.38% |1 | 0.38% | 7768 | d3e...@gmail.com 0.38% |1 | 0.37% | 7583 | har...@alvestrand.no 0.38% |1 | 0.37% | 7489 | hkap...@acmepacket.com 0.38% |1 | 0.36% | 7337 | o...@cisco.com 0.38% |1 | 0.36% | 7315 | joe...@bogus.com 0.38% |1 | 0.35% | 7181 | sagriff...@gci.com 0.38% |1 | 0.35% | 7141 | barryle...@computer.org 0.38% |1 | 0.35% | 7103 | randy_pres...@mindspring.com 0.38% |1 | 0.35% | 7064 | wbee...@cisco.com 0.38% |1 | 0.34% | 7019 | nar...@us.ibm.com 0.38% |1 | 0.34% | 6915 | j...@joelhalpern.com 0.38% |1 | 0.33% | 6756 | war...@kumari.net 0.38% |1 | 0.32% | 6549 | dwor...@avaya.com 0.38% |1 | 0.32% | 6540 | m...@mnot.net
Re: Consensus Call: draft-weil-shared-transition-space-request
On Thu, Dec 1, 2011 at 7:47 PM, Pete Resnick presn...@qualcomm.com wrote: ** I wrote a response to Brian's original statement then deleted it because I assumed others would ignore it as clearly last minute and ill-researched. Apparently, that was wrong. There are enterprises that currently use 172.16/12. (There are enterprises which use every tiny piece of RFC 1918 space.) Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172.16/12 (and, for that matter ever bit of 1918 space). That's irrelevant and still does not address my question. The question is whether these addresses are used BY EQUIPMENT THAT CAN'T NAT TO IDENTICAL ADDRESSES ON THE EXTERIOR INTERFACE. Darling Pete, TYPING YOUR QUESTION IN CAPS DOESN'T MAKE IT THE RIGHT QUESTION. An enterprise that has numbered into this space and gets put behind a CGN by a provider will have no direct control over this equipment, and it might happen in the *future* after the allocation we're discussing here has been made. Asking whether anyone has this pain right now presumes a steady state in the deployment of CGN, which, sadly, seems awfully unlikely. To put this another way, you can't solve the problem of equipment which cannot have internal and external interfaces being in the same pool by moving to this, in other words; you just move the pain from users of one RFC 1918 pool to users of another. That statement does not logically follow from all 1918 address space is used. You are missing a premise: There exists equipment that is used in all of that space that can't handle identical addresses on the interior and exterior interface. No, I think that premise is mis-stated. Premise 1: There exists equipment that can't handle identical addresses on the interior and exterior interface. Premise 2: it may be deployed now or in the future for customers using any part of the RFC 1918 allocation *because those using the RFC 1918 allocations had no prior warning that this might create a collision*. Conclusion: You cannot avoid identical addresses on the interior and exterior interface by using any part of the RFC 1918 allocation. So the question I posed was, Does any of *that* equipment use 172.16/12 (or 10.x/16) space? Nobody has said yes. Any exhaustive attempt to categorize that would be single-point in time and therefore useless. And *I'm* still not claiming that the answer is No. I simply don't know. But I'm inclined to hear from anybody to indicate that there is *any* evidence that the answer is Yes. That would make me much more comfortable in concluding that new specialized address space is the better horn of this bull to throw ourselves on. CGNs are, in my humble opinion, an abomination unto Nuggan. Whether or not we throw ourselves onto this horn to enable them is, at best, a decision that keeping the abomination in a pen is better than having it flow over the countryside in squat space. But the worst decision we could make is to try to pull a /12 out of RFC 1918 space for this purpose; it will be at best simply ignored and at worst ensure yet another group's ox gets gored. Your humble and obedient servant, Ted pr -- Pete Resnick http://www.qualcomm.com/~presnick/ http://www.qualcomm.com/%7Epresnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/01/2011 22:07, Ted Hardie wrote: No, I think that premise is mis-stated. Premise 1: There exists equipment that can't handle identical addresses on the interior and exterior interface. Premise 2: it may be deployed now or in the future for customers using any part of the RFC 1918 allocation *because those using the RFC 1918 allocations had no prior warning that this might create a collision*. Conclusion: You cannot avoid identical addresses on the interior and exterior interface by using any part of the RFC 1918 allocation. But doesn't that same line of reasoning apply to any new allocation that's made for this purpose? You can fix the problem for today, but you can't fix it for the future because you can't prohibit customers from using the new allocation on the inside of their network. Therefore, making the allocation is a pointless waste of resources that can be better utilized elsewhere. Step 1: Determine the most popular inside prefixes for CPEs Step 2: Use the least popular RFC 1918 prefix for the CGN network Step 3: If your customer has somehow chosen the same prefix, tell them they can't do that. And yes, I realize that Step 3 is going to be incredibly unpopular for the ISPs, but they created the problem, so they should have to live with the results. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Ted, I've been trying to stay out of this round of this debate too, but... --On Thursday, December 01, 2011 22:07 -0800 Ted Hardie ted.i...@gmail.com wrote: ... An enterprise that has numbered into this space and gets put behind a CGN by a provider will have no direct control over this equipment, and it might happen in the *future* after the allocation we're discussing here has been made. Asking whether anyone has this pain right now presumes a steady state in the deployment of CGN, which, sadly, seems awfully unlikely. Sure. But, IMO, that is the point at which should we make this allocation segues into what do you think of CGNs. Now, personally, I've got a bad attitude toward CGNs. I share the concerns others have expressed that CGNs (and this allocation proposal) are not part of IPv6 deployment or transition plans but are, instead, IPv4 preservation plans... or IPv6 delaying plans, which, for many ISPs and equipment vendors, might be the same thing. That bad attitude is driven less by love of IPv6 than it is by the belief that global addressing and [nearly] end-to-end access are essential to what makes the Internet technology valuable: that we can innovate easily precisely because we don't need or have address and protocol-translation mechanisms in the middle of the network that have to understand (and effectively give permission for) the applications that are going to traverse them. The data networking community tried that (arguably a couple of times) with protocols and addresses that worked up to a peering point or national boundary and then got translated into something else. I'm sure there are still folks around who think that was a good idea, but I'm not one of them. There are others who didn't have that experience or don't understand its implications; for them, old adages about repeating history may be applicable. But it is clear that some ISPs are going to deploy CGNs. Whether they see that as keeping IPv4 as long as possible, arranging a really long transition, or something else --and whether their rationales actually make sense-- is largely irrelevant. So I think that question for the IETF is whether it is better to make this allocation or just let them squat (on 1918 addresses, on addresses they already have, or on some other addresses they don't believe will interfere with anything that they are doing). It seems to me that there are two ways to address that question. One is the question I think Pete is trying to ask. Restated to address your steady state comment, I'd make it more like: Assume that no vendor in its collective right mind would deploy new address translation gear (or firmware) that couldn't cope with having addresses from the same pool on the inside and outside and that we are willing to let the marketplace punish those who are not in their right minds, the topic of whether a separate address range is needed to maintain inside/outside distinctions becomes strictly one of legacy gear -- dealing with deployed CPE gear that is hard or impossible to replace on a near-term schedule and, quite bluntly, crappy. In that context, questions like Pete's make perfect sense because they are questions about how to patch around said legacy gear while causing minimum damage to today's assumptions about, e.g., routable and non-routable addresses. Even if the answer is no, there are no devices that both have 172.16/12 wired in and that can't handle overlapping 'inside' and 'outside' address pools, it doesn't necessarily make allocating an address pool to this use desirable. But that is the other question: Where is the stopping point? If 172.16/12 works for carrier-grade NATs, will we need a new allocation (possibly the one requested in the present I-D) for peering-point-grade NATs? If that allocation is made, will we need another one for country-boundary-NATs or RIR-boundary-NATs? Conversely, if we make the requested allocation (rather than using 172.16/12 or something else already reserved), does that fix anything or just bring the next NAT layer, next allocation question a little closer? From that point of view, this proposal doesn't improve things at all and doesn't buy enough time to be worth the the trouble. But one could then claim that any CGN that is deployed would be able to deal with the same address pool inside and outside even if the CPE gear cannot. Fair enough except that then turns into an argument that providing a special, dedicated address pool for CGN-CPE interactions just encourages long-term support for that CPE gear and, worse, violation of the no ISP in its right mind principle expressed above. On balance, a bad idea. That is perhaps just a long way to say what Randy (I think) expressed as NAT4... To put this another way, you can't solve the problem of equipment which cannot have internal and external interfaces being in the same pool by moving to this, in other words; you just move the pain from users of one RFC 1918
Last Call: draft-ietf-ippm-metrictest-05.txt (IPPM standard advancement testing) to BCP
The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'IPPM standard advancement testing' draft-ietf-ippm-metrictest-05.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This document includes a normative reference to RFC 2330, which is an Informational RFC, however, RFC 2330 has been used as a normative reference in several other IPPM working group documents, though some predate the requirement to split normative and informative references. One example of an existing normative reference to RFC 2330 is found in RFC 6049. The IESG is particularly interested in determining whether the community considers RFC 2330 sufficiently mature to serve as a normative reference for standards track and BCP publications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-metrictest/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-metrictest/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for VRRPv3' to Proposed Standard (draft-ietf-vrrp-unified-mib-10.txt)
The IESG has approved the following document: - 'Definitions of Managed Objects for VRRPv3' (draft-ietf-vrrp-unified-mib-10.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-vrrp-unified-mib/ Technical Summary This specification defines a Management Information Base (MIB) for VRRP Version 3 (which simultaneously supports both IPv4 and IPv6) as defined in RFC 5798 Working Group Summary There was nothing of note. Document Quality Huawei has implemented this specification. There is no information from other vendors about implementations or plans. MIB doctor review by Joan Cucchiara was very helpful, as was an early review by Dave Thaler. Personnel Radia Perlman (radiaperl...@gmail.com) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note Section 9: OLD Prior = vrrpOpeartionsPriority NEW Prior = vrrpv3OperationsPriority END --- Section 10 vrrpv3OperationsPriority OLD A 'badValue(3)' should be returned when a user tries to set 0 or 255 for this object. NEW Setting the values of this object to 0 or 255 should be rejected by the agents implementing this MIB module. For example, an SNMP agent would return 'badValue(3)' when a user tries to set the values 0 or 255 for this object. END --- Section 10 vrrpv3StatisticsNewMasterReason OLD If the virtual router never transitioned to master state, this SHOULD be set to notmaster(0). NEW If the virtual router never transitioned to master state, the value of this object is notMaster(0). END --- Section 10 vrrpv3StatisticsRefreshRate s/milli-seconds/milliseconds/ --- Section 11 OLD Specific examples of this include, but are not limited to: o The vrrpv3OperationsRowStatus object which could be used to disable a virtual router. While there are other columns that, if changed, could disrupt operations, they cannot be changed without first changing the RowStatus object. NEW Examples of how these objects could adversely affect the operation of a virtual router include: o An unauthorized change to vrrpv3OperationsPriority can affect the priority used in master election resulting in this router either becoming master when it should not, or in some other router being elected by preference. While this will disrupt the operator's plans it will only replicate the unfortunate failure of multiple routers and any router that does become master will be capable of filling that role. o Modification of vrrpv3OperationsPrimaryIpAddr would cause the configured router to take on an incorrect IP addresses if it becomes master which would be potentially very disruptive to the network operation. o A malicious change to vrrpv3OperationsAdvInterval could either result in the configured router flooding the network with advertisements when it becomes master, or the new master not advertising frequently enough such that some routers do not learn about the new master. o vrrpv3OperationsPreemptMode controls whether this router will preempt another master router. Setting it inappropriately will at worse cause one router to be master against the operator's plans, but that router will still be qualified to operate as a master. o Setting the vrrpv3OperationsAcceptMode could prevent an IPv6 capable VRRP router from accepting packets addressed to the address owner's IPv6 address as its own even if it is not the IPv6 address owner. Although the default for this object is false(2), unauthorized setting of this object to false might restrict the function of some parts of the network. o The vrrpv3OperationsRowStatus object which could be used to disable a virtual router. While there are other columns that, if changed, could disrupt operations, they cannot be changed without first changing the RowStatus object. END --- Section 13 Please move the referenced RFC 2787 into Section 14 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-marf-redaction-03.txt (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC
The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' draft-ietf-marf-redaction-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sieve-include-13.txt (Sieve Email Filtering: Include Extension) to Proposed Standard
The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Email Filtering: Include Extension' draft-ietf-sieve-include-13.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Sieve Email Filtering include extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sieve-include/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sieve-include/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'TCP Candidates with Interactive Connectivity Establishment (ICE)' to Proposed Standard (draft-ietf-mmusic-ice-tcp-16.txt)
The IESG has approved the following document: - 'TCP Candidates with Interactive Connectivity Establishment (ICE)' (draft-ietf-mmusic-ice-tcp-16.txt) as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-tcp/ Technical Summary Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. Working Group Summary This document is a product of the MMUSIC WG. The document has been in progress for a while with significant Working Group interest, contribution and review. There are no controversial issues. Document Quality The document has received significant review and the quality is good. The chairs are aware of multiple implementations of the mechanism. Personnel Flemming Andreasen is the document's shepherd. Gonzalo Camarillo is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: IAOC Member Selection
The IESG has received a single nomination for the IAOC position. Given this situation, we are extending the deadline to nominations to 7 December 2011. In addition, we are opening the comment period on the single willing candidate that we have before us: Ole Jacobsen. Please send new nominations and comments on Ole to i...@ietf.org. On behalf of the IESG, Russ Housley IESG Chair On Nov 13, 2011, at 1:04 AM, IETF Chair wrote: Ole Jacobsen is the IAOC member that was appointed by the IESG, and his two-year term is up in March. The IESG is starting the process to fill this seat in March 2012, with the term ending in March 2014. The two-week nominations period opens today, and closes on 27 November 2011. Nominations and eligibility The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, and IESG members are eligible for nomination. Of course, IAB and IESG members who accept nomination will recuse themselves from selection and confirmation discussions. Please send nominations to i...@ietf.org. Please include the following with each nomination: - Name - Contact information - Candidate background and qualifications Desirable Qualifications and Selection Criteria Candidates for the IAOC position should have a demonstrable involvement in the IETF, knowledge of contracts and financial procedures, awareness of the administrative support needs of the IAB, the IESG, and the IETF standards process. The candidate is also expected to understand the respective roles and responsibilities of the IETF and ISOC in IASA, and be able to articulate these roles within the IETF community. The candidate must be able to exercise all the duties of an IAOC Board member, including fiduciary responsibilities, setting of policies, oversight of the administrative operations of the IETF, representing the interests of the IETF, and participating in IAOC meetings and activities. The candidate must be able to serve as a Trustee for the IETF Trust. Although the IESG selects this member of the IAOC, the selected member does not directly represent the IESG. The IESG-selected member is accountable directly to the IETF community. BCP 101 says: The IAOC shall consist of eight voting members who shall be selected as follows: o Two members appointed by the IETF Nominations Committee (NomCom); o One member appointed by the IESG; o One member appointed by the IAB; o One member appointed by the ISOC Board of Trustees; o The IETF Chair (ex officio); o The IAB Chair (ex officio); o The ISOC President/CEO (ex officio). Selection The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and make a selection. Confirmation The IAB will act as the confirming body for the selection. In the event that the IAB determines not to confirm the nominated candidate, the IAB will provide the IESG with the basis for this determination and the IESG will nominate another candidate. Care of Personal Information The following procedures will be used in managing candidates' personal information: - The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. - Excerpts of the information provided to the IESG by the nominated candidate will be passed to the IAB as part of the confirmation process. The IAB will be requested to maintain confidentiality of candidate information. - Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. Timeframe The two-week nominations period opens today, and closes on 27 November 2011. The list of willing candidates will be posted shortly after the nominations close, and the community will have two weeks to provide comments on the candidates to the IESG. The IESG will make a selection on an IESG telechat following the comment period and send the name of the selected candidate to the IAB for confirmation. On behalf of the IESG, Russ Housley IESG Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ohye-canonical-link-relation-04.txt (The Canonical Link Relation) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The Canonical Link Relation' draft-ohye-canonical-link-relation-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract [RFC5988] specified a way to define relationships between links on the web. This document describes a new type of such relationship, canonical, which designates the preferred URI from a set of identical or vastly similar ones. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see https://www.ietf.org/mailman/listinfo/apps-discuss). The file can be obtained via http://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Collection Synchronization for WebDAV' draft-daboo-webdav-sync-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at mailto:w3c-dist-a...@w3.org, which may be joined by sending a message with subject subscribe to mailto:w3c-dist-auth-requ...@w3.org. Discussions of the WEBDAV working group are archived at http://lists.w3.org/Archives/Public/w3c-dist-auth/. The file can be obtained via http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC Series Editor Appointment
The Internet Architecture Board is pleased to announce the appointment of Heather Flanagan as the RFC Series Editor (RSE). Ms. Flanagan will assume the responsibilities from the Acting RSE, Olaf Kolkman, and begin her tenure on January 1, 2012. The contract negotiated by the IAOC includes an initial term of two years and a presumptive renewal of two years. Ms. Flanagan was selected by the RFC Series Oversight Committee (RSOC) based upon her experience, education, skills and energy she will bring to the position. Ms. Flanagan is currently the Project Coordinator for the COmanage project, an effort funded by a grant from NSF and Internet2 to create a collaboration management platform, prior to that she was Director of Systems Administration, IT Services at Stanford University. Her technical background is complemented by a Masters of Science of Library Science from the University of North Carolina, Chapel Hill that will prove invaluable in the accessing and indexing of RFCs. Ms. Flanagan brings a high degree of energy and enthusiasm to the position. Her interpersonal skills as a facilitator and good listener will enable her to work well with the capable staff at the RFC Production Center and with the community in reaching consensus on a variety of issues facing the RFC Series. The RSOC selection followed a lengthy process that included announcing the position inside and outside the community, several rounds of interviews, reference checks, and face-to-face interviews in Taipei at IETF 82. More than thirty-five applications were received, two-thirds of which were from outside the community. We express our congratulations to Ms. Flanagan. We also want to extend our thanks to Ray Pelletier and the RSOC chaired by Fred Baker for their role in bringing the RSE selection process to a successful conclusion; to Olaf Kolkman for his service to the community as Acting RSE; to Joel Halpern for his ongoing work as editor of the RFC Editor Model v2 document; and to the RFC Production Center for its customary diligence in the editing and publishing of RFCs this year, likely the second most productive in RFC publication history. We look forward to working with the new RSE; we wish her well; and know that the community will work with Heather for the betterment of the RFC Series. For the IAB, Bernard Aboba IAB Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Independent Series Editor Review
Colleagues, Under the RFC Editor model (RFC5620) the IAB periodically reviews the performance of the Independent Series Editor (ISE), currently Nevil Brownlee. If you have any feedback on the performance of the ISE, please send email to the IAB chair iab-ch...@iab.org before December 10, 2011. Your feedback will be shared with the voting members of the IAB and treated confidentially. For the IAB, Bernard Aboba IAB Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Privacy Terminology adopted as an IAB document
http://tools.ietf.org/html/draft-hansen-privacy-terminology Privacy Terminology has been adopted as an IAB document. Comments can be sent to the IAB mailto:i...@iab.org?subject=Comments%20on%20Privacy%20Terminology or the ietf-privacy mailto:ietf-priv...@ietf.org mailing list, which can be joined here https://www.ietf.org/mailman/listinfo/ietf-privacy . ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
