Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 7 Jun 2011, at 07:33, Gert Doering wrote: Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Keith, I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree. I strongly object to the proposed reclassification of these documents as Historic. 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) (It could be argued that reclassification of RFC 3068 (by itself) to Historic is appropriate, but that would require a separate document and last call.) In addition, this document is misleading and perhaps even vituperative. For instance: There would appear to be no evidence of any substantial deployment of the variant of 6to4 described in [RFC3056]. This statement is blatantly false. 6to4 is supported by every major desktop and server platfrom that is shipping today, and has been supported for several years. incorrect. there is no evidence that the _managed_ model of 6to4 described in rfc3056 has any deployment. that's the model where relay operators advertise what parts of the 6to4 space they are routing. with BGP neighborships between managed and participating relays. _deployment_ not _support_. The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party. The fact that some firewalls block protocol 41 traffic causes problems for many tunneling solutions, not just 6to4; yet this document appears to recommend some tunneling solutions while trashing 6to4. it is the unmanaged aspect of 6to4 deployment that exhibits the most problems. a manually configured managed point to point tunnel may also be blocked in a firewall, but then the operator will have to sort that out. 6to4 has no operator. Teredo is similar in many aspects to 6to4, but there is little evidence that it causes the same problems. largely because it is the choice of last resort in implementations and it hasn't/can't be enabled by default in CPEs. The recommendations to treat 6to4 as a service of last resort will do harm to users and applications using it. A better recommendation is for hosts to disable 6to4 by default. This document appears to make the mistake of assuming that the purpose of applications using IPv6 is to interoperate with the existing Internet. I have maintained for many years that it is new applications, or existing applications that can't tolerate widespread deployment of IPv4 NAT, that will drive use of IPv6. I therefore believe that it is inappropriate to judge 6to4 merely by how well it works in scenarios where it is being used to talk to applications that work well over IPv4 NAT such as HTTP. The Internet is much more diverse than that, and will become even more diverse as IPv6 enjoys wider deployment. 6to4 does not work through IPv4 NATs. It is also premature to remove references to 6to4 from RFC 5156bis, for IANA to mark the prefix and DNS zones as deprecated. This will only cause confusion and difficulty for legitimate continued uses of 6to4. the purpose of the text in the document is to ensure that the deprecated prefixes are not reused before 6to4 has been phased out. cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR Review for draft-ohba-pana-relay-03
Hello Ohba-san, Thank you so much for your quick response. I agree with your comments and won't have further comments as long as the doc is updated based on your response. Regards, -- Yoshifumi Nishida nish...@sfc.wide.ad.jp 2011年6月6日5:59 Yoshihiro Ohba yoshihiro.o...@toshiba.co.jp: Nishida-san, Thank you very much for reviewing the draft. Please see my comments below. (2011/06/06 17:39), Yoshifumi Nishida wrote: Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Summary: This draft specifies protocol for PANA Relay Element that can relay messages between a PaC and a PAA where they cannot reach each other. The proposed function is simple and straightforward and useful. I couldn't find any transport related issues in the draft. Minor comments: Please consider clarifying the following points. 1) I think clarifying communication model of this proposal will be helpful for readers. It seems to me that a PRE should communicate only one PAA. But, can a PAA communicate multiple PREs? PANA allows multiple PAAs in an access network. For example, RFC 5192 defines a DHCP option to carry a list of PAA addresses and a PaC will choose one PAA to communicate with. Similarly, there can be multiple PAAs in an access network with PREs. In this case, a PRE will choose one PAA to communicate with for a given PaC. Next, a PAA can communicate with multiple PREs. We can clarify these in the draft. 2) The draft seems to presume PRE to be a multi-homed node. But, is this mandatory requirement? Is it possible to use single-homed node as a PRE? You are right, PRE can be either single-homed or multi-homed. In fact, in ZigBee IP, each mesh router is a PRE having a single 802.15.4 radio interface. We can clarify this in the draft as well. 3) Is it possible to place a PRE behind NAT? Is there any concern for this? There are two cases, (i) a NAT between a PaC and a PRE, and (ii) a NAT between a PRE and a PAA. I don't see a NAT issue specific to PANA relay for both cases. 4) How p2 (PRE-assigned UDP port number) is determined? Is it possible to use ephemeral port? If so, the protocol will need to be robust against PRE rebooting. Similarly, can we use dhcp-ed address for IP2b? Yes, p2 can be ephemeral. Since a PAA just uses the UDP and IP headers received from the relay to generate UDP and IP headers of its response PRY to the relay, I think the protocol is robust against PRE rebooting. For the same reason, use of DHCP-ed address for IP2b works. Even when IPsec is used between a PRE and a PAA, I think DHCP-ed address for IP2b works as long as IKEv2 identity for the PRE is not based on IP address. Kind Regards, Yoshihiro Ohba Regards, -- Yoshifumi Nishida nish...@sfc.wide.ad.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-faltstrom-5892bis-04
Hi Paul, The IANA registry is in http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml#idnabis-ta bles-properties I saw that in the beginning it has as reference RFC 5892 for the whole table. Will it stay this way after the change proposed in this draft and just the three individual values will change based on 1.1, 1.2 and 1.3? or are there no changes in the IANA registry at all. This is unclear to me according to the section 3 of your draft. Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. Thanks Roni -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Tuesday, June 07, 2011 1:13 AM To: Roni Even Cc: draft-faltstrom-5892bis@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04 On May 29, 2011, at 4:13 AM, Roni Even wrote: Major issues: 1. I am not sure how the IANA consideration section is in-line with the IANA consideration section of RFC5892. Maybe some clarification text would be helpful. We think that the IANA considerations here are, in fact, what RFC 5892 was designed for. That is, RFC 5892 says that the registry will be updated (IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2), and this is such an update. Please let me know if that doesn't match your understanding. 2. The IANA registry for derived property value has RFC 5892, does this draft want to change the reference, how will it be done. Section 2 of the draft is pretty clear here: No change to RFC 5892 is needed based on the changes made in Unicode 6.0. I think that it relates also to the issue of whether this draft updates RFC 5892. And here too. --Paul Hoffman __ Information from ESET NOD32 Antivirus, version of virus signature database 6185 (20110606) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6186 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Less than 1% of the IPv6 traffic reaching us is 6to4. Unless you provide IPv6 only sites, you should see very little ... that is part of the point :). snip It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. Just my $.02, /TJ ... ready for world IPv6 Day? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 08:56, George, Wesley wesley.geo...@twcable.comwrote: From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of TJ Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Wes George I agree with the end goal here, but for a mechanism that relies on the good will of others (relays) changing it to historic could have a more-abrupt impact on those who use the mechanism than in other cases of similar demotions. That is my concern. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New Non-WG Mailing List: fun -- FUture home Networking (FUN)
--On Tuesday, June 07, 2011 04:56 + Barry Leiba barryle...@computer.org wrote: ... We've seen quite a few non-WG mailing lists announced, where the title of the list was all we got, and we'd have no idea whatsoever if we wanted to subscribe to it. Please, when we send out announcements, let's include enough of a description -- even two or three paragraphs, if that's what it takes -- so that we can understand what's meant to be discussed, and so that we can know whether we want to subscribe. Agreed. I certainly wasn't trying to suggest that zero-information announcements were a good thing, only that we shouldn't try to prohibit them if an AD believed that was the right thing to do. The announcements for the obscurity-interest and paws lists are examples of particularly good ones. This one and the one for weirds are particularly lacking. Especially since it is now apparent that the relevant information was readily available in both cases: See Jari's note for this one; in the case of weirds, three documents are now in the I-D directory and there is apparently a plan to ask for a BOF in Quebec. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 10:39 AM, George, Wesley wrote: At the risk of rehashing discussion from WGLC... Ole has addressed some of your points, I'll address a few others below inline. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, June 06, 2011 1:22 PM To: ietf@ietf.org Cc: v6...@ietf.org; IETF-Announce Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? The best current use cases for 6to4 that I'm aware of are: - Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks. This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT. Widespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it. The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4. Operators rarely have a good understanding of what individual application users or developers need. They tend to focus mostly on the applications that generate the most traffic, or cause them particular amounts of trouble, or the ones that their biggest customers need. Problem is, those aren't the only applications that are important. Every application is important to its users, no matter how much or little traffic (or revenue) it generates. 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay router. And there are valid reasons to use 6to4 even where IPv4 connectivity already exists. Even in cases where 6to4 traffic must cross a relay router, sometimes it's the best solution available. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Mon, Jun 06, 2011 at 07:41:49PM -0400, TJ wrote: On Mon, Jun 6, 2011 at 13:22, Keith Moore mo...@network-heretics.comwrote: I strongly object to the proposed reclassification of these documents as Historic. *snipped lots of great thoughts/comments, solely for brevity* Agreed that this is too harsh, too soon. Fixing the broken implementations is a better idea than trying to break the working ones. And I am not just saying this because I successfully use 6to4 on a fairly common basis ... Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of TJ Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011 12:16 AM, Tim Chown t...@ecs.soton.ac.uk wrote: On 7 Jun 2011, at 07:33, Gert Doering wrote: Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. +1. Let's move on and not repeat this tired discussion. Cb Tim ___ 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: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
At the risk of rehashing discussion from WGLC... Ole has addressed some of your points, I'll address a few others below inline. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, June 06, 2011 1:22 PM To: ietf@ietf.org Cc: v6...@ietf.org; IETF-Announce Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party. WEG Again, please substantiate this with examples of implementations that are actively using non-relay 6to4. Also, the number of applications of 6to4 that can be guaranteed to avoid any unknown 3rd party relays is extremely limited due to the nature of anycast and 6to4's asymmetric routing. The protocol action requested in this draft in no way prevents one or more consenting networks from using 6to4 and continuing to run relays for their local traffic indefinitely - in fact, it even provides a reference to a document to show them how to make it work as well as possible. It is simply saying that it's not a good idea. The recommendations to treat 6to4 as a service of last resort will do harm to users and applications using it. A better recommendation is for hosts to disable 6to4 by default. WEG this seems to be to be splitting hairs. Please explain the distinction you're making here. Disable by default means never use. Use as last resort means use when no better IP connectivity is available. I would think if you insist that 6to4 must stick around you'd prefer it to be enabled. I understand that there are different values of better but if 6to4 works, this means that the host is not behind a NAT, and therefore by most definitions, its IPv4 connectivity would be better than 6to4. If it's behind an IPv4 NAT, and therefore IPv6 connectivity would be better (especially if there are one or more applications that work via IPv6 but not via IPv4 + NAT) then 6to4 won't work in lieu of IPv6 connectivity anyway. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4 to Historic status) to Informational RFC
After a fair amount of thought, I have decided that I support this document without reservation. I support the recommendation that RFC 3056/3068 support should be off by default in CPEs; the reasons for this are clear enough in my companion draft. Specifically, I support the choice of SHOULD NOT enable (rather than MUST NOT) because it leaves open the option for a CPE or host vendor to enable RFC 3056/3068 by default if there is a sound reason to do so for a specific product. I support the recommendation to reclassify RFC 3056 as Historic, because its time is past. The reason for inventing 6to4 in the first place was for the benefit of customers whose ISPs could not deploy IPv6. There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers, so it is entirely reasonable to consider the technique as Historic. This has no impact on current successful use of 6to4 - the recommendation is to retain existing relays until traffic diminishes and to follow appropriate operational recommendations meanwhile. As my companion draft indicates, relays advertising the 2002::/16 prefix are needed as long as there is residual 6to4 traffic in the network. Regards Brian Carpenter (co-author of RFC 3056) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
On Jun 7, 2011, at 3:56 AM, rontlv wrote: The IANA registry is in http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml#idnabis-ta bles-properties I saw that in the beginning it has as reference RFC 5892 for the whole table. Will it stay this way after the change proposed in this draft and just the three individual values will change based on 1.1, 1.2 and 1.3? or are there no changes in the IANA registry at all. This is unclear to me according to the section 3 of your draft. The table will likely change, based on the input of the expert reviewer. I assume that a reference to this RFC-to-be would be added to the top of the table, next to [RFC5892]. That is, this would be an additional reference, not a replacement. But that's up to IANA. Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. The draft says: This imply the derived property value differs depending on whether the property definitions used are from Unicode 5.2 or 6.0. We intended that as non-backwards-compatible; we can change the wording to make that explicit. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 4:48 AM, Ole Troan wrote: I'm loathe to go through this discussion again. let me just respond to some of the points you make, and then agree that we disagree. I'm also loathe to go through the discussion again. It shouldn't be necessary. 6to4 has long been useful, and continues to be useful, for some cases. It's appropriate to document problems with 6to4, perhaps revise its applicability based on experience, and also to publish recommendations for how to manage 6to4 relays, and to urge removal of broken relays and/or filtering of their routing advertisements. But deprecating it is entirely premature. (When I recently asked local ISPs when they'll be offering IPv6 support, their answer was what?. ) (It could be argued that reclassification of RFC 3068 (by itself) to Historic is appropriate, but that would require a separate document and last call.) In addition, this document is misleading and perhaps even vituperative. For instance: There would appear to be no evidence of any substantial deployment of the variant of 6to4 described in [RFC3056]. This statement is blatantly false. 6to4 is supported by every major desktop and server platfrom that is shipping today, and has been supported for several years. incorrect. there is no evidence that the _managed_ model of 6to4 described in rfc3056 has any deployment. that's the model where relay operators advertise what parts of the 6to4 space they are routing. with BGP neighborships between managed and participating relays. _deployment_ not _support_. The recommendations of the proposal are overkill anyway. But assuming there's some merit in writing an applicability statement for 6to4 (and I think there might be), this text should be clearer and more balanced. And I'm not sure where you get the idea that RFC 3056 recommends that relay operators advertise what parts of the 6to4 space they are routing. 3056 doesn't say anything about BGP advertisements for IPv4, as 3056 assumes there will be a manually configured relay router. As for advertisement of IPv6 prefixes, the idea has always been that we didn't want to incorporate the v4 routing table into v6, so 3056 specifically says that the only prefix advertised in BGP should be 2002::/16. (Obviously no such prefix should be advertised if the router isn't willing and able to route to the entire 2002::/16 space, i.e. arbitrary addresses on the public IPv4 network.) The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party. The fact that some firewalls block protocol 41 traffic causes problems for many tunneling solutions, not just 6to4; yet this document appears to recommend some tunneling solutions while trashing 6to4. it is the unmanaged aspect of 6to4 deployment that exhibits the most problems. a manually configured managed point to point tunnel may also be blocked in a firewall, but then the operator will have to sort that out. 6to4 has no operator. Indeed, that is one of its main virtues. 6to4 decouples application deployment of v6 from network deployment of v6, and helps reduce the chicken or egg problem. (At least, that's the intent. Reality is that 6to4 does have some impact on the network, at least where relay routers that publicly advertise prefixes through BGP are concerned. But 6to4 is useful - admittedly in corner cases - even without relay routers.) Teredo is similar in many aspects to 6to4, but there is little evidence that it causes the same problems. largely because it is the choice of last resort in implementations and it hasn't/can't be enabled by default in CPEs. Bogus argument. Teredo has a different set of problems than 6to4 - higher overhead, not as scalable, dependent on a single provider for relays, not as widely deployed in hosts, etc. If you're seeing fewer problems with Teredo, it's because it's not used as much as 6to4 is (in part because it has more problems) - not because
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
George, Wesley wrote: It's time to remove the stabilisers on the IPv6 bicycle. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. In my personal perception, the historic status used to be a technical characterization to indicate that (1) a protocol or technology has been fully replaced by some newer protocol and there is no reason to continue using the original technology anymore because the successor can be used in each of the original usage scenarios today (2) the protocol/technology has been largely put out of use, and its active use has dropped to marginal levels (like less than 1% of the original active use) Personally, I have never conciously used anything related to IPv6 so far, so for me it is difficult to comment, but what has been said looks to me that neither (1) nor (2) apply to 6to4. The user base seems to have always been small, and most of the users of 6to4 simply did _not_ have an alternative -- and its current users still do _not_ have an alternative today. Classification of 6to4 as historic is appropriate use of the IETF process, because it would be a political, but not an accurate technical statement. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-faltstrom-5892bis-04
Hi Paul, My understanding that the new value does not replace the current one since 5892bis is not updating rfc5892. So should the IANA registry reflect that you are not replacing the current value or is my understanding wrong Roni Even -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Tuesday, June 07, 2011 7:39 PM To: rontlv Cc: draft-faltstrom-5892bis@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04 On Jun 7, 2011, at 3:56 AM, rontlv wrote: The IANA registry is in http://www.iana.org/assignments/idnabis-tables/idnabis- tables.xml#idnabis-ta bles-properties I saw that in the beginning it has as reference RFC 5892 for the whole table. Will it stay this way after the change proposed in this draft and just the three individual values will change based on 1.1, 1.2 and 1.3? or are there no changes in the IANA registry at all. This is unclear to me according to the section 3 of your draft. The table will likely change, based on the input of the expert reviewer. I assume that a reference to this RFC-to-be would be added to the top of the table, next to [RFC5892]. That is, this would be an additional reference, not a replacement. But that's up to IANA. Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. The draft says: This imply the derived property value differs depending on whether the property definitions used are from Unicode 5.2 or 6.0. We intended that as non-backwards-compatible; we can change the wording to make that explicit. --Paul Hoffman __ Information from ESET NOD32 Antivirus, version of virus signature database 6186 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6188 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Liaison and request for review of ITU-T document
The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a Draft Recommendation. That liaison is available as https://datatracker.ietf.org/liaison/1054/. The official liaison is available at https://datatracker.ietf.org/documents/LIAISON/file1232.pdf. The liaison asks for IETF review of Draft Recommendation Signalling protocols and procedures relating to Flow State Aware QoS control in a bounded sub-network of a NGN, which is available at https://datatracker.ietf.org/documents/LIAISON/file1231.pdf. This note opens an IETF comment period on the document, ending midnight, anywhere on earth, 2011/7/5. After the comment period, a summary will be prepared and returned in a liaison to ITU-T Q5/SG-11. Of specific interest to the IETF are any ways in which the signalling protocols and procedures defined in the Draft Recommendation might interact with existing IETF Internet protocols. We are especially interested in potential adverse interactions or interference with IETF Internet protocols. The technical merits of the signalling protocols and procedures defined in the Draft Recommendation are of interest inasmuch as the IETF community might provide technical advice and recommendations to improve the Draft Recommendation itself. Please respond with any comments on the Draft Recommendation to ietf@ietf.org. Thanks in advance for your review of the Draft Recommendation. - Ralph Droms, Internet Area Director for the IESG ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
On Jun 7, 2011, at 3:56 AM, rontlv wrote: The IANA registry is in http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml#idnabis-ta bles-properties I saw that in the beginning it has as reference RFC 5892 for the whole table. Will it stay this way after the change proposed in this draft and just the three individual values will change based on 1.1, 1.2 and 1.3? or are there no changes in the IANA registry at all. This is unclear to me according to the section 3 of your draft. Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. Ah, very good catch! My earlier comment about us listing this new RFC in the registry is, in fact, wrong. When we wrote RFC 5892, we said: IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2. That's one registry that has the properties for most current version of Unicode at any given time. Thus, the registry would be updated *even if* we didn't publish 5892bis. We are not updating either 5892, nor the registry, by publishing 5892bis. We are simply giving IETF consensus advice about what we think the expert reviewer who updates the registry should consider. Our IANA considerations in 5892bis are: IANA is to update the derived property value registry according to RFC 5892 and property values as defined in The Unicode Standard version 6.0. That might sound like they are initiating the registry update, but they really aren't: the update was already specified in 5892. We can change the IANA considerations to reflect that: IANA will update the derived property value registry according to RFC 5892 and property values as defined in The Unicode Standard version 6.0, regardless of the content of this RFC. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 5:27 PM, George, Wesley wrote: From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? KMThe best current use cases for 6to4 that I'm aware of are: KM- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. WEG Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against. Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. That doesn't require IPv6 connectivity to the outside world. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that works and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution. I've been using 6to4 on a regular, often daily, basis since the late 1990s. 6to4 has allowed me to develop IPv6 applications and test them on real networks, and deploy them in limited circumstances. 6to4 has also allowed me to remotely access computers on my SOHO networks, using any application protocol that I chose to do so, with out-of-the-box hardware and software, without any application-specific proxies, and generally without any application-specific configuration. None of these scenarios required a relay router. All of them were, and continue to be, useful. Yes, I've experienced on many occasions that using 6to4 to access dual-stack web servers doesn't always work so well. Sometimes it picks a suboptimal path because the relay router isn't convenient. Sometimes the v6 path doesn't work at all and the application has to time out and retry using v4. But this never really bothered me much, because my purpose in using 6to4 wasn't to try to access services that I could get to via IPv4 anyway. And neither, I suggest, is that a reasonable metric for evaluating 6to4 or any other IPv6 transition mechanism. The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that are IPv6 only. And sure, 6to4 is a sort of last resort for those services, except maybe for the other transition mechanisms that are worse: Teredo is often worse, configured tunnels are often worse, for all of the obvious reasons. If your ISP offers you native IPv6 access you should probably use that instead, even if internally they use 6rd or some other tunneling scheme. There's definitely benefit to having professional management and support (such as it is) for your IPv6 connectivity. Yet, time and time again the argument gets made that 6to4 gets in the way of trying to access such services. 6to4 by itself is not the problem. The problem is address selection rules that favor v6 over v4. If the service is supported under v4, if it works fine through any NATs in the signal path, the application should probably use v4 to talk to that service. And if the service is v6-only, and 6to4 is the best way of getting there that's available, you might as well try to use it. Further, I don't buy the separate tunnel to every host... thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
--On Tuesday, June 07, 2011 14:43 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: Section 5.1 of RFC5892 says If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. . My question was if the change is backward compatible. The 5892bis draft does not say it. Ah, very good catch! My earlier comment about us listing this new RFC in the registry is, in fact, wrong. When we wrote RFC 5892, we said: IANA has created a registry with the derived properties for theversions of Unicode released after (and including) version 5.2. That's one registry that has the properties for most current version of Unicode at any given time. Thus, the registry would be updated *even if* we didn't publish 5892bis. We are not updating either 5892, nor the registry, by publishing 5892bis. We are simply giving IETF consensus advice about what we think the expert reviewer who updates the registry should consider. Our IANA considerations in 5892bis are: IANA is to update the derived property value registry according toRFC 5892 and property values as defined in The Unicode Standardversion 6.0. That might sound like they are initiating the registry update, but they really aren't: the update was already specified in 5892. We can change the IANA considerations to reflect that: IANA will update the derived property value registry according toRFC 5892 and property values as defined in The Unicode Standardversion 6.0, regardless of the content of this RFC. Paul, I think this is an improvement but there is one issue about which we have slightly different impressions. I hope the difference can be resolved without needing yet more tedious arguments about documentation. Indeed, if such arguments are required, I'd prefer that we just forget about it. Anyway, your comments above about most current version imply to me that IANA should keep derived property tables for the most current version only. My expectation when 5982 was completed was that IANA was expected to keep derived property tables, clearly identified by version, for each and every Unicode version from 5.2 forward. In other words, the tables for the [most] current version would be added to, not replace, whatever previous version tables were around. The reasons for this, in terms of systems and implementations in various stages of development, implementation, and deployment, seem obvious... but maybe it was too obvious to some of us at the time to get the wording exactly right. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
On Jun 7, 2011, at 6:24 PM, John C Klensin wrote: I think this is an improvement but there is one issue about which we have slightly different impressions. I hope the difference can be resolved without needing yet more tedious arguments about documentation. Indeed, if such arguments are required, I'd prefer that we just forget about it. Anyway, your comments above about most current version imply to me that IANA should keep derived property tables for the most current version only. My expectation when 5982 was completed was that IANA was expected to keep derived property tables, clearly identified by version, for each and every Unicode version from 5.2 forward. In other words, the tables for the [most] current version would be added to, not replace, whatever previous version tables were around. The reasons for this, in terms of systems and implementations in various stages of development, implementation, and deployment, seem obvious... but maybe it was too obvious to some of us at the time to get the wording exactly right. While your interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. RFC 5892 says: 5.1. IDNA-Derived Property Value Registry IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the specifications in Sections 2 and 3 and not by copying the non-normative table found in Appendix B. If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. Changes to the rules (as specified in Sections 2 and 3), including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty) require IETF Review, as described in RFC 5226 [RFC5226]. Note that every reference to the registry is singular. Also, the registry at http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml doesn't mention 5.2 at all. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, a registry means a single registry. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Pete, thanks for your helpful summary. Comments inline, now that I've had a chance to review all of the Last Call feedback. On 5/30/11 5:20 PM, Pete Resnick wrote: On 5/5/11 11:13 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-06.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 ietf@ietf.org mailing lists by 2011-06-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. Man without hat: Speaking as an individual contributor, not an AD. Ditto. Summary: I am in favor of most of the changes in this document. The primary change I am opposed to is the one identified in the title and therefore object the adoption of this document as a BCP. However, I believe there is a single (though significant) change that would make the document acceptable to me. My summary: I am in favor of many of the changes in this document, although what you and I like and dislike does not overlap much. :| Details: The document says in section 1 that the motivation for the changes is: In the current environment, many documents are published as Proposed Standard and never advance to a higher maturity level. I think that's fine and usually appropriate. In addition, IETF working groups and IESG members provide much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. Although this is adduced as a motivation, by my reading it doesn't actually motivate the proposals in this document. I certainly agree with addressing the above concerns. I'm not yet convinced that these are real problems. Section 2 lists one additional motivation for the changes: The benefit associated with a third maturity level has proven insufficient to justify the effort associated with document progression. I'll address this below. I think the third maturity level is unnecessary, but I'm not yet convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. Here is a summary of the process changes that occur in the document, by section: Section 2 (a) Generally, go to two maturity levels, Proposed Standard and Internet Standard (b) Only review the changes, not the entire document, when recycled at Proposed Section 2.1 (a) Go back to 2026 level of (i.e., less) scrutiny for Proposed Standard Section 2.2 (a) Specifically, merge Draft Standard into Internet Standard (b) Combine criteria from Draft Standard and Standard (i) Significant number of implementations with successful operational experience (ii) No unresolved errata causing interoperational problems (iii) No unused features, except allow unused features that do not greatly increase implementation complexity (iv) Independent patent/licensing for implementations (c) Remove overt requirement for documentation of interoperability testing Section 3 (a) No more annual review of Proposed Standards for movement to Historic Section 4 (a) Allow normative references from Internet Standards to Proposed Standards (Editorial note: Please move 2(b) into 2.1. That change is a change to the handling of Proposed Standards and therefore belongs in 2.1. That makes the rest of Section 2 just introductory text and not making a specific procedural change.) My analysis by section: 2(a) - I am opposed to this change and will discuss it below in section 2.2(a). I am in favor of this change. 2(b) - I like this change and support it. I'm mostly agnostic about this, although I note that sometimes things change (e.g., new security threats) and it makes sense to revisit parts of a document even if they haven't been changed (or, in some instances, especially if they haven't been changed). 2.1(a) - I wholeheartedly agree with this change (or, more to the point, reversion to the documented way of doing things). I disagree with this change. It sounds attractive (let's return to the golden age) but I agree with those who posted during the Last Call that it is a significant change from current practice. You could argue that current practice is not the best practice, but I don't see how a reversion to RFC 2026 principles here is truly best current practice. In addition, IMHO we have not thought enough about the consequences of a lower bar for Proposed Standard (e.g., our customers think that an RFC is an RFC, and if we suddenly start publishing PS specs of lesser quality then we might be diluting our brand). However: - This document gives no mechanism to facilitate this change. I would like to hear how this
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 6/7/11 11:00 PM, Peter Saint-Andre wrote: Pete, thanks for your helpful summary. Comments inline, now that I've had a chance to review all of the Last Call feedback. A conversation I'm happy to have. Comments inline. We are still men without hats. On 5/30/11 5:20 PM, Pete Resnick wrote: Details: The document says in section 1 that the motivation for the changes is: In the current environment, many documents are published as Proposed Standard and never advance to a higher maturity level. I think that's fine and usually appropriate. So you think that this is *not* a motivation for the changes and is *not* something we need to change? Interesting. In addition, IETF working groups and IESG members provide much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. Although this is adduced as a motivation, by my reading it doesn't actually motivate the proposals in this document. We agree on that point. I certainly agree with addressing the above concerns. I'm not yet convinced that these are real problems. This we're likely to agree to disagree on. Section 2 lists one additional motivation for the changes: The benefit associated with a third maturity level has proven insufficient to justify the effort associated with document progression. I'll address this below. I think the third maturity level is unnecessary, but I'm not yet convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. Strongly agreed on the latter point: I'm not at all convinced that we understand what results we're trying to achieve and what behaviors we're trying to encourage by modifying the standards track. And given that, whatever change we end up making, I have to say that this document can't be it, because it does not explain what we're trying to achieve. Skipping down to going back to 2026 requirements for proposed: I disagree with this change. It sounds attractive (let's return to the golden age) but I agree with those who posted during the Last Call that it is a significant change from current practice. You could argue that current practice is not the best practice, but I don't see how a reversion to RFC 2026 principles here is truly best current practice. In addition, IMHO we have not thought enough about the consequences of a lower bar for Proposed Standard (e.g., our customers think that an RFC is an RFC, and if we suddenly start publishing PS specs of lesser quality then we might be diluting our brand). However: - This document gives no mechanism to facilitate this change. I would like to hear how this will be accomplished. I have my doubts that this is even achievable now, at least absent serious changes to IETF culture and individual expectations among spec authors, WG chairs, Area Directors, review teams, and everyone else. - This change, along with 2(b) has the potential to greatly increase the number of RFCs published. The document does not discuss the impact of that. And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thing to do, and I haven't seen that consensus in the Last Call discussion. All of the above may be true. I personally think that the best thing that could happen in some sense is to decrease the quality of Proposed Standard RFCs, but that's certainly a controversial view. And I think it's worthy of an independent discussion. So, at the very least, we either need to agree on this as a topic for this document or remove it. As to the change to 2 levels: 2.2(a) - I see no motivation for this change other than the one sentence in section 2. This change does not address the difficulty of going from Proposed to Draft, and it doesn't address the heightened scrutiny for going to Proposed. Therefore, if the only reason for changing from three levels to two is that getting through the three levels is too hard, and most of the procedural changes in this document are to make it easier to get through the first two levels, I see no justification for removing the third (and in 2026, easiest to get through) level. It does not solve any identified problem. I'm in favor of this change. I don't think the document describes the motivation very well, but this one makes sense to me. As Thoreau said, simplify, simplify, simplify (although why did he need to say it three times?). Simplify (even three times) is not a good motivation for this change. If simplify, simplify, simplify means cut off your right arm, cut off your left arm, and cut off your left leg, I will certainly be a simpler being for the act, but none the better; I would argue a bit worse for my purposes. Simplify is not, in and of itself, a good justification.
Re: Last Call: draft-housley-two-maturity-levels-06.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On Tue, Jun 07, 2011 at 11:57:15PM -0500, Pete Resnick wrote: So you think that this is *not* a motivation for the changes and is *not* something we need to change? Interesting. For what it's worth, quite apart from thinking that the draft in question will do nothing to change the state of affairs with respect to advancement, I also wonder why anyone cares whether documents advance. If someone cares enough, documents will advance. Someone will do the work. For instance, apparently Scott Hollenbeck cared about the advancement of EPP. The Extensible Provisioning Protocol is a full Standard. Meanwhile, the protocol some EPP-using registries employ to update the contents of their DNS zone files (DNS Update, RFC 2136) is a Proposed Standard and has been since 1997. I assert that someone fooling with DNS dynamic update such that the protocol changed incompatably would have far more wide-ranging and deleterious consequences for the Internet than someone altering EPP in a backward-incompatible way. We have a hope of contacting all the EPP users on Earth, to begin with. (None of this is to denigrate EPP or the work that those who moved it along the standards track undertook. I think it is an excellent example of what to do and how to do it. It's just also a handy example of a well-defined protocol with a reasonably tightly packed user community, compared to some other protocols.) If the people who use and rely on a protocol don't care about this maturity-level advancement to do something about it, why should the rest of us care? A -- Andrew Sullivan a...@anvilwalrusden.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF Nominations Committee Chair - 2011 - 2012
To the IETF community, One of the roles you entrusted to the Internet Society (ISOC) President CEO is to appoint the IETF Nominations Committee chair. This is done through consultation with the IETF community. It gives me great pleasure to announce that Suresh Krishnan has agreed to serve as the 2011 - 2012 IETF Nominations Committee chair. A Call for Nominations for this committee will be sent shortly to the IETF Announcement list; and a list of the IESG, IAB and IAOC/IETF Trust seats to be filled will also be published shortly. Please give serious consideration to volunteering for the Nominations Committee as well as to possible candidates for the open positions. The NomCom process is central to the IETF's success, and it is important that it have the support of the IETF community. In the interim, feel free to make your suggestions known to Suresh, who will share them with the committee once it is seated. Suresh can be reached at: suresh.krish...@ericsson.com . Thank you in advance for your support and a sincere thank you to Suresh for agreeing to take on this very significant responsibility. Regards, Lynn St. Amour President CEO Internet Society (ISOC) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt (IPv6 Multihoming without Network Address Translation) to Informational RFC
The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 Multihoming without Network Address Translation' draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.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-06-21. 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 Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent host-to- host connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ 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
