RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Not that I am aware of. -Original Message- From: SM [mailto:s...@resistor.net] Sent: Monday, October 14, 2013 11:20 AM To: Ronald Bonica Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Hi Ron, At 16:55 13-10-2013, Ronald Bonica wrote: Are you suggesting that we don't address the problem because the code is too complex to touch? It's a known problem since at least seven years. Given that the problem is labelled as a security issue there would have to be some changes to the specification at some point. There were design decisions to implement the specification and the code has been deployed. The proposed outbound change is one sentence. The code change to implement that one sentence requires reviewing some implementation decisions (re. encapsulation, etc.). Please note that I am not arguing for or against a change in the RFC 2119 key words. The write-up only mentions that the draft has been implemented on stateless firewalls. I am curious about whether there are any implementations for a host. Regards, -sm
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
SM, Are you suggesting that we don't address the problem because the code is too complex to touch? Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Sunday, October 13, 2013 1:00 AM To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard At 11:55 02-10-2013, The IESG wrote: The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Implications of Oversized IPv6 Header Chains' draft-ietf-6man-oversized-header-chain-08.txt as 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 This document intends to update the IPv6 specification. I looked into some code (host) which would be affected by the RFC 2119 requirement in Section 5. The code is complex as it is. I am not sure whether the requirement can be implemented without too much difficulty. I have not looked into the code which processes inbound packets. Regards, -sm
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
+1 Is there a way to decouple this discussion from draft-ietf-6man-oversized-header-chain? I would be glad to discuss it in the context of a separate draft. Ron So, it wasn't necessarily the case that 1280 was a product of thoughtful analysis so much as the fact that **they were rushing to get a spec out the door**. So now, 16 years later, we get to put it back on the 6man charter milestone list. We could have that discussion in 6man, sure, but I don't believe that it's relevant to the question of whether draft-ietf-6man-oversized- header-chain is ready. This draft mitigates a known problem in terms of the current IPv6 standards.
RE: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
I agree with Ole. Ron -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Ole Troan Sent: Tuesday, October 08, 2013 12:17 PM To: Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org; IETF-Announce Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, Hi, I would like to make a small amendment to what I said in my previous message as follows: 4) Section 5, change the final paragraph to: As a result of the above mentioned requirements, a packet's header chain length MUST fit within the Path MTU associated with its destination. Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. However, if a host does not discover the Path MTU, it MUST assume the IPv6 minumum MTU of 1280 bytes [RFC2460]. The host MUST then limit each packet's header chain length to the Path MTU minus 256 bytes in case additional encapsulation headers are inserted by tunnels on the path. I would claim that additional encapsulation headers are already considered in the 1280 minimum MTU. as in: 1500 - 1280. cheers, Ole
Last Call: draft-ietf-lisp-deployment-08.txt (LISP Network Element Deployment Considerations) to Informational RFC
Folks, In keeping with the WG Charter, draft-ietf-lisp-deployment should be labeled EXPERIMENTAL, not INFORMATIONAL. For supporting information, please see the following milestone in the LISP Charter: - Sep 2012 Submit a deployment model document to the IESG for publication as an Experimental RFC Also in keeping with the LISP charter, draft-ietf-lisp-deployment should include the following disclaimer, which is taken from RFC 6830: - This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 [of RFC 6830] for specific, known issues that are in need of further work during development, implementation, and experimentation. I say this because of the following text, taken from the LISP WG Charter: - The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. Ron From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Reply-to: iesg-secret...@ietf.org Subject: Last Call: draft-ietf-lisp-deployment-08.txt (LISP Network Element Deployment Considerations) to Informational RFC X-C5I-RSN: 1/0/934/11346/12106 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Network Element Deployment Considerations' draft-ietf-lisp-deployment-08.txt as 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 ietf@ietf.org mailing lists by 2013-07-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.
RE: Last Call: draft-bonica-special-purpose-03.txt (Special-Purpose Address Registries) to Best Current Practice
Sure. I'll catch that in the next rev. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Donald Eastlake Sent: Thursday, December 20, 2012 7:57 PM To: ietf@ietf.org Subject: Re: Last Call: draft-bonica-special-purpose-03.txt (Special- Purpose Address Registries) to Best Current Practice How about changing the title from Special-Purpose Address Registries to Special-Purpose IP Address Registries. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Nov 29, 2012 at 3:55 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Special-Purpose Address Registries' draft-bonica-special-purpose-03.txt as Best Current Practice 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 ietf@ietf.org mailing lists by 2013-01-02. 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 memo instructs IANA to restructure its IPv4 and IPv6 Special- Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. This memo updates RFC 5736 and RFC 4773, which define the current structure of the IPv4 and IPv6 Special-Purpose Address Registries. It also obsoletes RFC 5735 and RFC 5156 which document special- purpose address blocks that are not currently, but will in the future, be recorded in the IPv4 and IPv6 Special-Purpose Address Registries. The file can be obtained via http://datatracker.ietf.org/doc/draft-bonica-special-purpose/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-bonica-special-purpose/ballot/ No IPR declarations have been submitted directly on this I-D.
RE: draft-bonica-special-purpose-04.txt
Hi Randy, It seems that we need one or both or the following: - a better title for the new column - a better definition to be associated with that column Any suggestions? Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: Friday, December 21, 2012 9:45 AM To: IETF Disgust Subject: draft-bonica-special-purpose-04.txt i remain confused. i am not being pedantic just to be a pita. i really worry that this document will be used to justtify strange brokenness. from my 2012.11.29 message: are the following definitions o Routable - A boolean value indicating whether a IP datagram whose destination address is drawn from the allocated special-purpose address block is routable (i.e., may traverse more than a single IP interface) o Global - A boolean value indicating whether a IP datagram whose destination address is drawn from the allocated special-purpose address block is routable beyond a specified administrative domain. intended to be baked in hardware, or are they SHOULDs to operators? i look at RFC 1918 space and 127.0.0.0/8 and am not so sure how hard these boundaries are meant to be. i worry because i think we regret how we specified (threw away is more like it) E space. does the prefix describes a specific prefix length or a covering range? e.g. 192.0.0.0/24 is neither routable nor global, while a subnet, 192.0.0.0/29, is routable. i.e. might i route and forward 192.0.0.128/25? another annoying example. 0.0.0.0/8 is said to be not routable, yet we commonly announce it in bgp (or igp) and propagate it. a protocol implmentor reading this document would be justified in preventing the injection of 0.0.0.0/8 into a routing protocol. [ let's not get into that it is commonly in the fib. ] randy
RE: Last Call: draft-bonica-special-purpose-03.txt (Special-Purpose Address Registries) to Best Current Practice
Geoff, I have just posted a new version of the draft, adding a column that distinguishes between reservations and allocations. In this version, our goal is to preserve the distinction between reservations and allocations while providing a single compendium of special addresses. Please take a look and tell me if we have solved the problem. Ron -Original Message- From: Geoff Huston [mailto:g...@apnic.net] Sent: Monday, December 03, 2012 6:25 PM To: Ronald Bonica Cc: Randy Bush; IETF Discussion Subject: Re: Last Call: draft-bonica-special-purpose-03.txt (Special- Purpose Address Registries) to Best Current Practice On 04/12/2012, at 9:30 AM, Ronald Bonica rbon...@juniper.net wrote: Geoff, Randy, Having reflected on your comments, I think that the two of you may be approaching the same problem from two directions. I will try my best to articulate the problem. When we agree that we have a common understanding of the problem, we can decide whether to fix draft-bonica or abandon it. Geoff points out that each of the entries mentioned in draft-bonica can be characterized as one of the following: - a special purpose address assignment - a address reservation All compliant IP implementations must respect special purpose address assignments. As Randy puts it, special purpose address assignments should be baked into IP stacks. However, the same is not true of address reservations. While operators may afford special treatment to packets that are sourced from or destined to reserved addresses, these treatments should not be baked into IP implementations. They should be configurable. Currently, there is nothing in draft-bonica that distinguishes between special purpose address assignments and address reservations. If we were to continue with this draft, we would have to add a field that makes this distinction. Having added that field, we should also make clear that that field, and only that field, determines whether an address should be baked into IP stacks? Randy, Geoff, have I restated the problem accurately? I'd use the opposite terminology. e.g.: - I regard 0.0.0.0/8 as a reservation, and should be baked into IP stacks - I regard 192.88.99.0/24 as a special purpose assignment and is configurable by IP stacks. In IPv4 my understanding of the current set of reservations are: 0.0.0.0/8 127.0.0.0/8 169.254.0.0/16 224.0.0.0/4 240.0.0.0/4 All others I would see as being special purpose assignments, given that they do not require special baked-in treatment by IP stacks. My personal preference would be to: -- record all special purpose assignments in a special purpose assignment registry, such as http://www.iana.org/assignments/iana-ipv4- special-registry/iana-ipv4-special-registry.xml for Ipv4 -- record all reservations in the address protocol registry, such as http://www.iana.org/assignments/ipv4-address-space/ipv4-address- space.xml for Ipv4 regards, Geoff
Re: Last Call: draft-bonica-special-purpose-03.txt (Special-Purpose Address Registries) to Best Current Practice
Geoff, Randy, Having reflected on your comments, I think that the two of you may be approaching the same problem from two directions. I will try my best to articulate the problem. When we agree that we have a common understanding of the problem, we can decide whether to fix draft-bonica or abandon it. Geoff points out that each of the entries mentioned in draft-bonica can be characterized as one of the following: - a special purpose address assignment - a address reservation All compliant IP implementations must respect special purpose address assignments. As Randy puts it, special purpose address assignments should be baked into IP stacks. However, the same is not true of address reservations. While operators may afford special treatment to packets that are sourced from or destined to reserved addresses, these treatments should not be baked into IP implementations. They should be configurable. Currently, there is nothing in draft-bonica that distinguishes between special purpose address assignments and address reservations. If we were to continue with this draft, we would have to add a field that makes this distinction. Having added that field, we should also make clear that that field, and only that field, determines whether an address should be baked into IP stacks? Randy, Geoff, have I restated the problem accurately? -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf
RE: Last Call: draft-ietf-v6ops-ra-guard-implementation-04.txt (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
Ran, Yes, he does. In fact, I thought that it had already been posted when I issued the last call, but forgot about the draft cutoff. So, I have asked the secretariat to post the updated version. Ron -Original Message- From: RJ Atkinson [mailto:rja.li...@gmail.com] I might be confused, but I understand that Fernando has an updated RA-Guard I-D ready to post.
RE: Last Call: draft-ietf-v6ops-ra-guard-implementation-04.txt (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
Ran, I agree that the references to I-D.gont-6man-oversized-header-chain and gont-6man-nd-extension-headers should both be NORMATIVE, and not INFORMATIVE. Sorry for having missed this. If Fernando were to post an updated version that makes this change, would it address all of your issues? If Fernando did this, it should address 6man's concerns because even if draft-ietf-v6ops-ra-guard-implementation were approved, it couldn't be published until the other two drafts are also approved. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of RJ Atkinson Sent: Friday, October 26, 2012 1:16 PM To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-v6ops-ra-guard-implementation- 04.txt (Implementation Advice for IPv6 Router Advertisement Guard (RA- Guard)) to Best Current Practice On 26 Oct 2012, at 12:04 , The IESG wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Implementation Advice for IPv6 Router Advertisement Guard (RA- Guard)' draft-ietf-v6ops-ra-guard-implementation-04.txt as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Starting IETF Last Call seems premature for this document. (Perhaps there was some slip of the keyboard somewhere ??) 1) Conflicts with active work items of the IPv6 WG This I-D has the effect of over-riding parts of the standards-track IPv6 specifications (e.g. by making currently valid/legal (if unusual) IPv6 packets illegal and instructing RA-Guard implementations to drop such currently valid/legal IPv6 packets). My understanding is that the 2 proposals to update the IPv6 specifications (directly related to this document) are current work items of the IETF 6MAN WG, but (as near as I can tell) those documents have not even begun WG Last Call within the IPv6 WG. 2) Previously agreed document edits are not present in the document version referenced by the IESG announcement. Prior discussion with the document author, both on the v6ops mailing list (e.g. various notes in June 2012, e.g., http://www.ietf.org/mail-archive/web/v6ops/current/msg13258.html) and also off-list, indicated that he had agreed to move the relevant IPv6 protocol update documents from Informative references to Normative references, specifically the draft-ietf-6man-* versions of these 2 references of the IESG cited document: [I-D.gont-6man-oversized-header-chain] Gont, F. and V. Manral, Security and Interoperability Implications of Oversized IPv6 Header Chains, draft-gont-6man-oversized-header-chain-01 (work in progress), April 2012. [I-D.gont-6man-nd-extension-headers] Gont, F., Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery, draft-gont-6man-nd-extension-headers-02 (work in progress), January 2012. 3) Email from document author indicates this document will be updated soon. Separately, overnight private email from the author (received by me prior to my receipt of this IESG announcement) indicates that an update to draft-ietf-v6ops-ra-guard-implementation is imminent. The pending update apparently resolves issue (2) above. So it seems to me that this document is not yet ready for IETF Last Call. Instead, it seems to me that the pending I-D update needs to occur, a (hopefully quick) review of that revision within IETF v6ops WG then needs to occur, and (ideally in parallel) IETF 6MAN WG review (and ideally approval) of the proposed changes to the IPv6 specifications needs to occur. LAST) In the (one hopes unlikely) event that the 6MAN WG is NOT comfortable with the 2 directly-related proposed IPv6 specification updates, then this document ought not be published on the IETF standards-track, on grounds that it specifies packet dropping behaviour inconsistent with the extant IPv6 specifications. Yours, Ran Atkinson
RE: WG Action: Conclusion of Address Resolution for Massive numbers of hosts in the Data center (armd)
Hello Stephane, My apologies. The shutdown message should have included a pointer to the following email, which was posted on the ARMD mailing list by Benson Schliesser on June 22: - http://www.ietf.org/mail-archive/web/armd/current/msg00472.html Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stephane Bortzmeyer Sent: Wednesday, October 24, 2012 6:08 AM To: IESG Secretary Cc: ldun...@huawei.com; ietf@ietf.org; a...@ietf.org Subject: Re: WG Action: Conclusion of Address Resolution for Massive numbers of hosts in the Data center (armd) On Tue, Oct 23, 2012 at 11:32:52AM -0700, IESG Secretary iesg- secret...@ietf.org wrote a message of 7 lines which said: The Address Resolution for Massive numbers of hosts in the Data center (armd) working group in the Operations and Management Area has concluded. Its charter is far from completed and I do not find in the archives of the mailing list of the WG an explanation. Two lines of text to explain what happened?
Liaison Statement from the Broadband Forum
Folks, The Broadband Forum has sent a liaison statement to the IETF regarding a New Project - Broadband Access Service Attributes and Performance Measures. Click on the following link for details: https://datatracker.ietf.org/liaison/1179/. Please review and send comments to this list. -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf
RE: Proposed IETF 95 Date Change
+1 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Perala, Timo (NSN - FI/Espoo) Sent: Friday, August 03, 2012 4:05 PM To: IETF Discussion Subject: RE: Proposed IETF 95 Date Change +1 Timo -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Philip Matthews Sent: Thursday, August 02, 2012 8:10 PM I would personally prefer if the meeting was rescheduled for the week of April 3 - 8. - Philip On 2012-08-02, at 9:45 , IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012.
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
SM, At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs ask for a /10 for CGN, we burn one of those /8s. Is that really a good idea? Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Thursday, February 09, 2012 10:45 AM To: ietf@ietf.org Subject: Re: Last Call: draft-weil-shared-transition-space-request- 14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP At 03:03 PM 1/30/2012, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Reserved IPv4 Prefix for Shared CGN Space' draft-weil-shared-transition-space-request-14.txt as a BCP On its December 15, 2011 telechat, the IESG reviewed version 10 of this document and requested various changes. These changes are reflected in the draft version 14 and the IESG now solicits community input on the changed text only. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-16. Exceptionally, comments may be sent to Is that a two-weeks Last Call? Will the determination of consensus be made only on the basis of this Last Call? In Section 3: A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply. Unique IPv4 address space is not in short supply in some regions. If it is globally in short supply, I gather that several regions have already reached their IPv4 Exhaustion phase. I haven't seen any announcements about that. While the Regional Internet Registries (RIR) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider. The above is incorrect as RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. On reading this draft, I conclude that as IPv4 addresses are nearly exhausted, the only option left is to deploy Carrier Grade NAT instead of requesting IPv4 addresses from a RIR. For the determination of consensus, I do not support this proposal. Regards, -sm ___ 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
Consensus Call (Update): draft-weil-shared-transition-space-request
Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? - Can alternative /10s be used? By contrast, further discussion of the following topics would not help the IESG gauge consensus: - Does the assignment of the requested /10 enable or hinder the deployment of IPv6? - Is CGN a viable service model for IPv4? - Can the deployment of CGN be prevented by not assigning Shared CGN address space? - How many ISPs really want this assignment and how many don't care because they don't need it? Further discussion of these questions is not helpful to us because we are deliberating over an address allocation, not the deployment of CGN/NAT444. Operators have already announced their intention to deploy. At least for the purposes of the current deliberation, we must assume that CGN/NAT444 will be deployed and concentrate on whether to allocate a /10 to facilitate its deployment. Ron Speaking as AD, But not on behalf of the IESG -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf ___ 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
Folks, Can anyone present empirical evidence that skype will break? I have heard claims in both directions. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Tuesday, November 29, 2011 11:50 PM To: Randy Bush Cc: IETF Disgust Subject: Re: Consensus Call: draft-weil-shared-transition-space-request In message m2sjl644h3.wl%ra...@psg.com, Randy Bush writes: anyone who thinks this will not be used as 1918 space should share what they are smoking. the question is not if, but rather how many milliseconds before it is. that is the operational reality. And what harm to others does that cause? If a ISP is using this and the customer is using this rather than RFC 1918 space then they only have themselves to blame for operational problems it causes. and we should have a betting pool on how long before it is leaked into a measure such as route-views. And users would be advised to filter routes for it the same as they should be filtering routes for other space they are using. and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. 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? this has become a contest of wills, not a technical discussion. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Doug, I did not refer to your message. The only two responses to the October 10 Last Call regarding draft-weil-shared-transition-space-request-09 were: - https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=60292tid=1322579909 - https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=59923tid=1322579994 The message that you reference below, as well as many other messages, were in response to a an August 19 Last call regarding draft-weil-shared-transition-space-request-03. Many of the problems pointed out in that last call were addressed between versions 03 and 09 of the document. However, many were not. Therefore, I summarized what I believed to be the outstanding issues in the message that I posted last night. If I missed any outstanding issues, please add to the list. I hope that this helps. Ron -Original Message- From: Doug Barton [mailto:do...@dougbarton.us] Sent: Monday, November 28, 2011 10:18 PM To: Brian E Carpenter Cc: Ronald Bonica; IESG IESG; IETF Discussion Subject: Re: Consensus Call: draft-weil-shared-transition-space-request [snip] ... and a meta-issue for Ron. I saw a lot more opposition to the document in the last call than you did. Are you by any chance referring to my message at https://www.ietf.org/mail-archive/web/ietf/current/msg69583.html below? If so, I guess I needed to actually say the words, I oppose publication of this document? If I wasn't clear, sorry. Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
Folks, 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. Ron -Original Message- From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, November 29, 2011 11:47 AM To: IESG IESG Cc: IETF Discussion Subject: Re: Consensus Call: draft-weil-shared-transition-space-request On Nov 29, 2011, at 7:57 AM, Russ Housley wrote: +1 On Nov 29, 2011, at 10:51 AM, Bradner, Scott wrote: to be pedantic - a BCP stands for the best way we know how to do something it is not required that the process actually be in use before the BCP is adopted as Mike O'Dell once said, if BCPs had to reflect what was actually being done we could never have a BCP defining good manners on the IETF mailing list see RFC 2026 - it says The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. i.e, the IETF's best current thinking on the best way to do something - not 'describing the way something is done' You stopped the excerpt from 2026 too soon on both ends; the community's best current thinking on a statement of principle. Ron already said that the community didn't agree on a clear best current thinking, and the document very clearly says that this is meant to be a new allocation of addresses, not a statement of principle. If the IESG wants to weasel around the actual words in RFC 2026, that's fine: this wouldn't be the first time. However, there is also an opportunity to be more honest and call it a Proposed Standard. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
Agreed! -Original Message- From: Chris Donley [mailto:c.don...@cablelabs.com] Sent: Tuesday, November 29, 2011 3:14 PM To: Ronald Bonica; IESG IESG; IETF Discussion Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Ron, One point of clarification, in your *against* list, you include: On 11/28/11 2:25 PM, Ronald Bonica rbon...@juniper.net wrote: - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Since this address space is between the CPE router and CGN device, and is therefore not globally routable, the same application(s) (e.g. 6to4) will break if public or 'squat' space are used instead of shared CGN space. Such applications rely on the home router detecting that there is private, non-globally routable space (i.e. RFC1918) on the WAN and disabling such an application. While that same detection code will always fail for public address space and squat space since the exact range is not defined, there is the possibility of fixing the detection code in home routers if we do define shared CGN space for that purpose. Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Consensus Call: draft-weil-shared-transition-space-request
On October 10, 2011, the IESG issued a last call for comments regarding draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for Shared CGN Space). While the community did not display consensus supporting the draft, it also did not display consensus against the draft. Therefore, I will submit the draft to the full IESG for its consideration at its December 1 teleconference. The draft will be published as a BCP if a sufficient number of IESG members ballot Yes or No Objection, and if no IESG member ballots Discuss. Because the decision to submit this draft to the full IESG is controversial, I will explain the decision making process. The IETF has a precedent for interpreting silence as consent. Typically, if a last call elicits no response, the draft is brought to the full IESG for consideration. The October 10 last call regarding draft-weil-shared-transition-space-request-09 evoked only two responses. One response supported publication of the draft while the other was opposed to it. The respondent voicing support for the draft offered no rationale. The respondent objecting offered many editorial comments, but almost no rationale for blocking the draft once the editorial comments are addressed. Because the October 10 last call elicited so little response, and because many community members have privately expressed strong opinions regarding this draft, I will summarize outstanding issues below. The following are arguments *against* draft-weil-shared-transition-space-request: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Arguments *supporting* draft-weil-shared-transition-space-request-09 assume that operators will deploy CGNs and will number the interfaces between CGN and CPE. If the /10 proposed by draft-weil-shared-transition-space-request is not allocated, operators will number from one of the following: - public address space - RFC 1918 address space - squat space If operators number from public address space, they will deplete an already scarce resource. If operators number from RFC 1918 space and the same RFC 1918 space is used on the customer premise, some CPE will behave badly. The consequences of numbering from squat space are determined by the squat space that is chosen. In summary, allocation of the /10 will have certain adverse effects upon the community. However, failure to allocate the /10 will have different adverse effects on the community. The IESG is being asked to choose the lesser of two evils. -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Calls: [SOME RFCs] to HISTORIC RFCs
Randy, Reclassifying old documents to historic is like cleaning your attic. Cleaning the attic may seem like a terrible waste of time and effort while you are doing it, but it makes your life much easier the next time you have to find or store something up there. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: Friday, October 28, 2011 2:47 PM To: Frank Ellermann Cc: IETF Discussion Subject: Re: Last Calls: [SOME RFCs] to HISTORIC RFCs we don't have enough real work to do? Clean up is necessary work. Some hours ago I tried to understand a discussion about the ISE (independent stream), and gave up on it when the maze of updates obsoleting RFCs which updated other RFCs turned out to be as complex as the colossal cave adventure. QED ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
Folks, This allocation cannot be made without IETF consensus. Publication on the Independent Stream does not reflect IETF consensus. Therefore, publication on the Independent Stream wouldn't enable the allocation. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Friday, September 23, 2011 8:54 PM To: ietf@ietf.org Subject: Re: Last Call: draft-weil-shared-transition-space-request- 03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC At 13:40 23-09-2011, Brian E Carpenter wrote: What makes you think that the Independent stream would publish such an RFC, which on the face of it would be a complete end-run around the IETF process, and fly in the face of the IAB position? There is an Editorial Board which can decide whether the draft is acceptable in that stream. In my opinion there will be more end-runs until ARIN gets what it wants. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
Is the draft being approved for publication as an Informational RFC? If so, I would appreciate if it documents IETF Consensus. Regards, -sm Before the allocation is made, it will need to be last called again as a BCP. Ron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Grey Beards (was [81all] Quick Meeting Survey)
Clearly, this photo needs to include the wise women of the Internet! Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, September 21, 2011 12:56 AM To: ietf@ietf.org Subject: Re: Grey Beards (was [81all] Quick Meeting Survey) On 9/20/11 6:26 PM, Ronald Bonica wrote: This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Beardless, but back when I started participating in the IETF my hair was nearly black. Now I've gone completely grey. Not trying to imply causality, of course. Count me in. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Grey Beards (was [81all] Quick Meeting Survey)
Folks, This reminds me that it has been a while since we took the last IETF grey beard photo. A few more of us have gone grey since then. Maybe we should plan on another photo to be taken after the next Administrative Plenary. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew Sullivan Sent: Tuesday, September 20, 2011 8:14 PM To: ietf@ietf.org Subject: Re: Fwd: [81all] Quick Meeting Survey On Tue, Sep 20, 2011 at 04:03:21PM -0700, Wes Hardaker wrote: Do you have a Gray Beard? [Ob.SpelThrd] That's spelled Grey Beard! A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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: Pre-IETF RFCs to Historic (not really proposing)
Scott, On one hand, most of these RFCs do not harm the Internet. However, if we don't clean house periodically, we are left with the following questions: 1) In the future, does the IETF have the latitude to do things that might break these old protocols? 2) If not, must the IETF maintain a cadre of people who are familiar with these old protocols to ensure that they are not broken? 3) If we don't maintain a cadre of people familiar with these RFCs, how should the community react to errata against them? Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott O Bradner Sent: Thursday, September 15, 2011 2:37 PM To: Mykyta Yevstifeyev Cc: IETF Discussion Subject: Re: Pre-IETF RFCs to Historic (not really proposing) I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet to historic but fail to see the usefulness of doing so for RFCs that describe unused but non-harmful technologies - seems like busywork and useless at best. Scott On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote: Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ 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: Pre-IETF RFCs to Historic (not really proposing)
Folks, After reading responses from Scott, John and Keith, I think that I get it. No matter how low hanging I believe the fruit to be, this isn't going to be cheap or easy. So, I withdraw the proposal and apologize to Mykyta for having wasted his time. Ron -Original Message- From: t.petch [mailto:daedu...@btconnect.com] Sent: Friday, September 16, 2011 10:24 AM To: Cyrus Daboo Cc: IETF Discussion; Keith Moore; Ronald Bonica Subject: Re: Pre-IETF RFCs to Historic (not really proposing) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IESG voting procedures
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of [snip] When an AD is clearly in the rough against the consensus of the IESG they should not have the power to individually block the progress of work for which there is clear IETF consensus. +1 The current voting procedure is the only protection that the community has against an AD who has decided that his opinion trumps the expertise of the working group and the rest of the IESG. Ron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic (yet again)
Folks, After an active discussion, it is clear that there is no consensus. So, I will transition draft-ietf-v6ops-6to4-to-historic to the DEAD state. Ron -Original Message- From: Ronald Bonica Sent: Monday, July 25, 2011 10:31 AM To: ietf@ietf.org Subject: draft-ietf-v6ops-6to4-to-historic (yet again) Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic (yet again)
Brian, Does the following text work for you? Ron N. Meaning of HISTORIC For the purposes of this document, the term HISTORIC means: - 6-to-4 should not be configured by default on any implementation (host, cpe router, other) - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products. - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Monday, July 25, 2011 11:09 PM To: Ronald Bonica Cc: ietf@ietf.org Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) To be clear, I'd like to see exact proposed text before expressing support for the proposal. The trick is to get 6to4 disabled by default at the user end, without disabling it for users who are getting good service from it. Regards Brian On 2011-07-26 09:49, Brian E Carpenter wrote: Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. This is, of course, an undeniable statement of fact (as it is for any other feature of the Internet). However, it needs to be made clear that doing so *prematurely* would penalise existing successful users of those relays, and therefore it should only be done when there is no successful traffic through them. Which is when any operator would remove them anyway. Therefore, I don't see much value in this statement, and possible harm to users. The ways to avoid such harm as far as possible are already in the RFC Editor queue. Regards Brian Carpenter On 2011-07-26 02:30, Ronald Bonica wrote: Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ 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: draft-ietf-v6ops-6to4-to-historic (yet again)
Tom, Sorry. I meant to copy both lists. They are both copied now. Ron -Original Message- From: t.petch [mailto:daedu...@btconnect.com] Sent: Tuesday, July 26, 2011 2:36 PM To: Ronald Bonica; ietf@ietf.org Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) It seems strange that this e-mail is not copied to the v6ops list. I would have expected this first to have been hammered out on the v6ops list and, if and only if consensus was reached there, the new text be then brought to the IETF list. I realise that, as you spell out, you are seeking IETF consensus but what is that if the WG is dead set against it? Tom Petch - Original Message - From: Ronald Bonica rbon...@juniper.net To: ietf@ietf.org Sent: Monday, July 25, 2011 4:30 PM After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ 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
draft-ietf-v6ops-6to4-to-historic (yet again)
Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
Noel, Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Monday, July 18, 2011 11:34 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu; v6...@ietf.org Subject: RE: Another look at 6to4 (and other IPv6 transition issues) From: Ronald Bonica rbon...@juniper.net RFC 2026's very terse definition of HISTORIC. According to RFC 2026, A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. That's the entire definition. Anything more is read into it. ... A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: Anything more is read into it.? To me, Historic has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is Based on or concerned with events in history.) I think obsolete is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not historic - historic actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
Hi John, I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. That's the entire definition. Anything more is read into it. Granted, the phrase for any other reason considered to be obsolete is pretty subjective. In this thread, I have seen people interpret that phrase as follows: the IETF thinks that there are no longer any valid use cases for this technology the IETF recommends that you remove this technology from your network the IETF believes that nobody is using this technology I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network. A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel Jaeggli Sent: Friday, July 15, 2011 3:17 PM To: John C Klensin Cc: v6...@ietf.org; IETF Discussion Subject: Re: Another look at 6to4 (and other IPv6 transition issues) On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli joe...@bogus.com wrote: So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not. Joel (and others), I understand the rationale. At the risk of repeating myself, I simply do not think it works or is appropriate. And there are people that disagree with you on that. Recategorizing set of documents as Historic is an extremely blunt instrument. If we do it in a consistent and logical fashion, the advice document would have to go to Historic along with the base documents because giving advice about a piece of ancient history is meaningless. That is not what most people who like the advice document intended, at least as I understood the consensus on that Last Call. SNIP Finally, if we had a wonderful transition model that would work well in all situations, then it would make sense to recommend it and depreciate everything else. You missed the boat about a decade back I guess. Transition technologies (none of them) are a substitute for actual deployment. They should naturally decline in popularity and in fact in the portions of the internet where we can measure them they are. Right now if we try and fit a story to the evidence that is happening because of host changes, and not because of deployment. ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. We don't. What we have are a bunch of mechanisms, each with advantages and disadvantages, some much better adapted to particular situations than others. It would be easier if we had a good single solution, but we don't... that is life, or at least engineering. Given that, we serve the community much better with analyses and explanations of tradeoffs (and RFC 6180 is, IMO, a really good start) than we do by going through exercises of figuring out what to denounce. IMO, the _only_ thing we should be categorically denouncing are tactics and strategies that encourage people to put off getting serious about IPv6. Unfortunately, trying to slap a Historic label on one particular transition strategy, or to rank transition strategies that have proven useful to some actors on the basis of how much various of us loathe them, are about denunciation and, however unintentionally, with the risk of encouraging people to sit and wait, not about progress or network engineering. back to lurking... john ___ 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: draft-ietf-v6ops-6to4-to-historic
Noel, I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic through without running the process. I said that draft-ietf-v6ops-6to4-to-historic has made it all the way past IESG approval. There is an appeal on the table (at the WG level) questioning whether draft-ietf-v6ops-6to4-to-historic ever had WG consensus. We will run the appeal process. If the WG chairs cannot justify WG consensus, draft-ietf-v6ops-6to4-to-historic stops dead in its tracks. If they can justify WG consensus, the appellant can escalate the appeal to the IESG (and to the IAB after that). If the appeal succeeds at any level, draft-ietf-v6ops-6to4-to-historic is not published. Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Tuesday, July 05, 2011 10:44 AM To: ietf@ietf.org; v6...@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic
Folks, I think that I get it. There is no IETF consensus regarding the compromise proposed below. So, at very least, we will have to abandon the compromise. Right now, the only alternative that I see is to reintroduce draft-ietf-v6ops-6to4-to-historic and let the appeal process run its course. I hate to do this, because the appeals process can be an incredible time sync and distraction. If anybody sees another alternative, please propose it. Ron speaking as AD P.S. This thread has generated over 100 messages in the last 28 hours. Let's all take two days to cool off and spend some time with our families. -Original Message- From: Ronald Bonica Sent: Saturday, July 02, 2011 12:36 PM To: v6...@ietf.org; IETF Discussion Subject: draft-ietf-v6ops-6to4-to-historic Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic
Comments inline -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Sunday, July 03, 2011 5:29 PM To: ietf@ietf.org; v6...@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... Right now, the only alternative that I see is to reintroduce draft-ietf-v6ops-6to4-to-historic But there is no rough consensus to do that either. RB That is the claim of an appeal on the table. Let's run the appeal process RB and figure out whether that claim is valid. We certainly aren't having any RB success reaching a decision on the mailing list. RB RB Ron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-v6ops-6to4-to-historic
Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Lorenzo, You pose very reasonable questions. I will try to reiterate them: 1) What are the criteria for determining consensus? What makes you think that there was no consensus on 6-to-4-historic? 2) What makes you think that the new draft is just as good? 3) What makes you think that the new draft will do any better than 6-to-4-historic? Responses follow: 1) Because we do not vote in the IETF, the process for determining consensus is squishy. A simple majority does not win the day. A few strongly held objections backed by even a scintilla of technical rational can increase the size of the super-majority required to declare consensus. While it was not clear that the IETF has achieved consensus regarding 6-to-4-historic, it also was not clear that the IETF had not achieved consensus. In this case, we had a choice between spending cycles arguing about consensus, or finding a solution that everybody could live with. 2) IMHO, the new draft will not be as good as 6-to-4-historic. However, it solves the operational problem by disabling 6-to-4 by default. That's much better than nothing. 3) I have been working behind the scenes with a few of those who objected to 6-to-4-historic. They didn't object to the new draft. However, I invite those people to speak for themselves. Ron From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Saturday, July 02, 2011 2:55 PM To: Ronald Bonica Cc: v6...@ietf.org; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.netmailto:rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Randy, You have three points that deserve to be addressed. These are: 1) as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot 2) perhaps that minority was also vocal in the back room 3) yes, but that will be a year from now. in the ietf, delay is one form of death Responses follow: 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication. 2) While there was no back-room activity, an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. So, any way you look at it, there would be delays. 3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay. Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. Comments? Ron -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Randy Bush Sent: Saturday, July 02, 2011 5:35 PM To: Lorenzo Colitti Cc: IPv6 Ops WG; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic If anyone objects to this course of action, please speak up soon. i object. as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot. it is damaging to the users and to the users' view of ipv6. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. perhaps that minority was also vocal in the back room But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, yes, but that will be a year from now. in the ietf, delay is one form of death. and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) this is nutso. but this is normal. welcome to the ietf randy ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The Evils of Informational RFC's
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Burger Sent: Wednesday, September 08, 2010 4:05 PM To: Bob Hinden Cc: IETF Discussion Subject: Re: The Evils of Informational RFC's I would offer RFC 5211 is PRECISELY the kind of RFC the IETF should NOT be publishing! I can see the press release now: IETF publishes IPv6 transition plan. NO ONE OUTSIDE THE IETF has a clue the RFC Editor is NOT the IETF. RFC = IETF is the *reality*, no matter how much we say it is not. Eric, The following text appears on page 1 of RFC 5211: IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. The IESG note should be clear to anyone who actually reads the RFC. Ron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [oam] IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance
Folks, Several potential attendees have indicated that it would be inconvenient for them if the Joint Design Session were moved from October 12-14 to October 28-29. Therefore, the session will be held, as originally scheduled, on October 12-14. Please email me privately if you intend to submit a paper and/or attend. Also indicate if you would like to stay at the hotel on campus. This will allow me to reserve a block of rooms. Ron -Original Message- From: oam-boun...@ietf.org [mailto:oam-boun...@ietf.org] On Behalf Of Ronald Bonica Sent: Wednesday, August 25, 2010 6:54 PM To: o...@ietf.org Subject: [oam] IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance Folks, Several members of the MPLS-TP community have indicated that they will be in Washington, D.C. from October 25 to October 27. In order to reduce their travel expenses and time away from home, they have asked if we could move the IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance to October 28-29, piggybacking on that conference. The conference would still be held at George Mason University in Fairfax, Virginia. If everyone is happy with this move, I would be glad to accommodate it. If this move causes you any inconvenience, please email me, either on the list or privately by COB September 1. Ron Bonica - Original Message - From: IESG Secretary iesg-secret...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org Sent: Friday, August 20, 2010 7:36 PM Subject: IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance The IAB and IESG would like to announce a joint design session on Forwarding Plane Operations, Administration and Maintenance (OAM) to be held on October 12 through October 14 at George Mason University in Fairfax, Virginia, USA. IP and ICMP support very simple forwarding plane diagnostic tools (e.g., PING, TRACEROUTE). During the Internet's first decades, these tools fulfilled most operational requirements. However, during the last decade, network operators have deployed many technologies that rely upon tunneling. These technologies include Pseudo-wires, Layer 2 Virtual Private Networks, and Layer 3 Virtual Private Networks. While the internet community has enhanced its forwarding plane diagnostic tool kit with the deployment of Bidirectional Forwarding Detection (BFD), some suggest that the tool kit is still inadequate for tunneled applications. The purpose of this design session is to discover and document operational requirements and constraints for tunneled forwarding plane OAM. The design session will also entertain solution proposals. While most activity in this area has been associated with Multi-Protocol Label Switching (MPLS), session organizers also encourage generic proposals that include other tunneling mechanisms (e.g., IP-in-IP). The scope of this design session is limited to the forwarding plane. Proposals concerning control and management plane protocols will not be accepted. For example, a proposal that probes a tunnel for continuity would be acceptable, while a proposal for reporting tunnel continuity to a routing protocol or management station would be productive, but beyond the scope of this workshop. Those intending to make presentations must submit position papers to the IAB/IESG by September 24. Position papers should constitute one to five pages on the problem or solution space, with a particular emphasis on areas that the IETF should address or revisit. Evaluation of the position papers will be performed by a committee consisting of IESG and IAB members. A limited number of seats will be available for persons not presenting. Position papers will be made publicly available. On the basis of the position papers, a number of invited speakers will be asked to present at the workshop. A final agenda with timeslots will be published by October 1. Further information about position paper submission procedures are forthcoming. Interested parties are advised to subscribe to the oam at ietf.org mailing list for discussion and announcements related to the workshop. Additional information will be available at http://www3.tools.ietf.org/area/ops/trac/wiki/oamJDS. Ron Bonica, IESG Danny McPherson, IAB Hannes Tschofenig, IAB ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ oam mailing list o...@ietf.org https://www.ietf.org/mailman/listinfo/oam
RE: IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance
Folks, Several members of the MPLS-TP community have indicated that they will be in Washington, D.C. from October 25 to October 27. In order to reduce their travel expenses and time away from home, they have asked if we could move the IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance to October 28-29, piggybacking on that conference. The conference would still be held at George Mason University in Fairfax, Virginia. If everyone is happy with this move, I would be glad to accommodate it. If this move causes you any inconvenience, please email me, either on the list or privately by COB September 1. Ron Bonica - Original Message - From: IESG Secretary iesg-secret...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org Sent: Friday, August 20, 2010 7:36 PM Subject: IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance The IAB and IESG would like to announce a joint design session on Forwarding Plane Operations, Administration and Maintenance (OAM) to be held on October 12 through October 14 at George Mason University in Fairfax, Virginia, USA. IP and ICMP support very simple forwarding plane diagnostic tools (e.g., PING, TRACEROUTE). During the Internet's first decades, these tools fulfilled most operational requirements. However, during the last decade, network operators have deployed many technologies that rely upon tunneling. These technologies include Pseudo-wires, Layer 2 Virtual Private Networks, and Layer 3 Virtual Private Networks. While the internet community has enhanced its forwarding plane diagnostic tool kit with the deployment of Bidirectional Forwarding Detection (BFD), some suggest that the tool kit is still inadequate for tunneled applications. The purpose of this design session is to discover and document operational requirements and constraints for tunneled forwarding plane OAM. The design session will also entertain solution proposals. While most activity in this area has been associated with Multi-Protocol Label Switching (MPLS), session organizers also encourage generic proposals that include other tunneling mechanisms (e.g., IP-in-IP). The scope of this design session is limited to the forwarding plane. Proposals concerning control and management plane protocols will not be accepted. For example, a proposal that probes a tunnel for continuity would be acceptable, while a proposal for reporting tunnel continuity to a routing protocol or management station would be productive, but beyond the scope of this workshop. Those intending to make presentations must submit position papers to the IAB/IESG by September 24. Position papers should constitute one to five pages on the problem or solution space, with a particular emphasis on areas that the IETF should address or revisit. Evaluation of the position papers will be performed by a committee consisting of IESG and IAB members. A limited number of seats will be available for persons not presenting. Position papers will be made publicly available. On the basis of the position papers, a number of invited speakers will be asked to present at the workshop. A final agenda with timeslots will be published by October 1. Further information about position paper submission procedures are forthcoming. Interested parties are advised to subscribe to the oam at ietf.org mailing list for discussion and announcements related to the workshop. Additional information will be available at http://www3.tools.ietf.org/area/ops/trac/wiki/oamJDS. Ron Bonica, IESG Danny McPherson, IAB Hannes Tschofenig, IAB ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ mpls-tp mailing list mpls...@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance
Folks, Several members of the MPLS-TP community have indicated that they will be in Washington, D.C. from October 25 to October 27. In order to reduce their travel expenses and time away from home, they have asked if we could move the IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance to October 28-29, piggybacking on that conference. The conference would still be held at George Mason University in Fairfax, Virginia. If everyone is happy with this move, I would be glad to accommodate it. If this move causes you any inconvenience, please email me, either on the list or privately by COB September 1. Ron Bonica - Original Message - From: IESG Secretary iesg-secret...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org Sent: Friday, August 20, 2010 7:36 PM Subject: IAB/IESG Joint Design Session on Forwarding Plane Operations, Administration and Maintenance The IAB and IESG would like to announce a joint design session on Forwarding Plane Operations, Administration and Maintenance (OAM) to be held on October 12 through October 14 at George Mason University in Fairfax, Virginia, USA. IP and ICMP support very simple forwarding plane diagnostic tools (e.g., PING, TRACEROUTE). During the Internet's first decades, these tools fulfilled most operational requirements. However, during the last decade, network operators have deployed many technologies that rely upon tunneling. These technologies include Pseudo-wires, Layer 2 Virtual Private Networks, and Layer 3 Virtual Private Networks. While the internet community has enhanced its forwarding plane diagnostic tool kit with the deployment of Bidirectional Forwarding Detection (BFD), some suggest that the tool kit is still inadequate for tunneled applications. The purpose of this design session is to discover and document operational requirements and constraints for tunneled forwarding plane OAM. The design session will also entertain solution proposals. While most activity in this area has been associated with Multi-Protocol Label Switching (MPLS), session organizers also encourage generic proposals that include other tunneling mechanisms (e.g., IP-in-IP). The scope of this design session is limited to the forwarding plane. Proposals concerning control and management plane protocols will not be accepted. For example, a proposal that probes a tunnel for continuity would be acceptable, while a proposal for reporting tunnel continuity to a routing protocol or management station would be productive, but beyond the scope of this workshop. Those intending to make presentations must submit position papers to the IAB/IESG by September 24. Position papers should constitute one to five pages on the problem or solution space, with a particular emphasis on areas that the IETF should address or revisit. Evaluation of the position papers will be performed by a committee consisting of IESG and IAB members. A limited number of seats will be available for persons not presenting. Position papers will be made publicly available. On the basis of the position papers, a number of invited speakers will be asked to present at the workshop. A final agenda with timeslots will be published by October 1. Further information about position paper submission procedures are forthcoming. Interested parties are advised to subscribe to the oam at ietf.org mailing list for discussion and announcements related to the workshop. Additional information will be available at http://www3.tools.ietf.org/area/ops/trac/wiki/oamJDS. Ron Bonica, IESG Danny McPherson, IAB Hannes Tschofenig, IAB ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
