Given that the IESG ignored inputs from some number of people noting that the RFC in question was actually deployed [1], it seems doubtful that it would be worthwhile for any of the operators who have deployed NAT+PT to travel to an IETF for the purpose of commenting in person. More than one person in the operator community now refers to the "IVTF" rather than IETF, because of the perception that the large vendors and professional standards-goers dominate IETF processes and IESG decisions and that network operators [2] are mostly ignored. It seems a bit of hubris for one to insist that operators must come to IETF given the history of IETF and IESG ignoring many operator inputs for much of the past decade.[3] The main bit of operator input that has been undertaken by IETF has been NetConf (basically standardising an equivalent to the then already deployed, albeit then proprietary, JunOS Script). That was done because of the recommendation from the IAB Network Management Workshop held in Reston earlier this decade (which itself was a bit of IAB outreach, rather than IESG/IETF outreach). Rather than demanding that operators come to IETF as if supplicants, particularly given the history, some would prefer to see the IETF/IESG engage in more outreach to the operational community -- not as a one-time thing but as an ongoing obligation. IETF and IESG should go to the operational community, rather than expecting or demanding that they come to the IETF. [4] This burden of operator outreach ought not be levied only on the O&M Area, but across the whole IESG. IETF WG chairs should similarly be encouraged to actively reach out to collect operational feedback. Several operators have said that they have deployed this IPv6::IPv4 NAT+PT technology. So the data seems to indicate at least some operational folks view that RFC as "good enough", even if some IETF folks view it as "imperfect". (The separate conclusions of "good enough" and "imperfect" are not mutually exclusive, of course. Sometimes "perfect" is the enemy of "good enough".) Further, at the recent RIPE meeting in Amsterdam, there seemed to be very broad operator feedback in the hallways that this NAT+PT approach is the only viable transition strategy left available to operators at this late date. Projections at the RIPE 55 meeting were that the last ordinary IPv4 block will go from IANA to an RIR circa November 2010. There was similar broad agreement that dual-stack can't happen fast enough to be viable, given the short 3 year period left and the lack of current economic incentives for most folks to enable IPv6.[5,6] In any event, Alain Durand (Comcast) has just posted an I-D with some requirements in this area. He also made a public presentation asking for NAT+PT at the last NANOG. (I believe his NANOG presentation is available online in PDF; it was a "lightning talk". Folks who have read down this far probably want to read that.) There is an opportunity in all of this mess for some folks to initiate work to develop a replacement RFC for NAT+PT. As near as I can tell, operators aren't particularly worried whether that RFC is on the standards-track or not, but they do want to have an open specification for the function. Such an effort would likely benefit from holding focused BOFs on the topic at the various operational fora around the globe to present then-current thinking about how to specify that and to solicit operational feedback. Yours, Ran DISCLAIMER: I am never authorised to speak for my employer and am not doing so in this note. Further, I personally am not the decision-maker for what we do or don't implement or for when we might implement something. [1] Extreme has not shipped an implementation of this so far as I am aware. It is the most-requested-of-us not-yet-implemented IPv6 feature that I know of. Since the IESG deprecation, several users have told me that my employer should ignore the IESG action and implement NAT+PT anyway -- according to that existing (and recently deprecated) RFC. [2] Although some use the term "network operators" narrowly to mean Internet Service Providers. I *always* use a very broad definition to include all sorts of network operators, including but not limited to academic network operators, enterprise network operators, content providers, Internet Exchange Points, and Internet Service Providers. So please interpret this phrase very broadly. [3] Some individual O&M Area Directors have tried to help inject operational inputs to IETF/IESG activities. Different individuals in that role have had different levels of effectiveness with that over the past decade or so. [4] Credit where due. Russ Housley and a few other IESG folks have been attending some operationally oriented meetings on their own. For example, Russ was at RIPE 55 in Amsterdam recently. It would be nice to see the IESG regularly hold BOFs at APRICOT, NANOG, RIPE, SANOG, and so forth around the globe to solicit network operator inputs/feedback. [5] In most organisations, budgets really are a zero sum game. This means that spending money on X means reducing spending on Y and Z. Budgets are tight everywhere, which means the money needed to enable IPv6 right now within some enterprise/campus/network just might not exist, given that many users already have enough IPv4 address space and that IPv6 doesn't usually generate incremental revenue to cover the incremental costs and there are other business/academic needs unrelated to IPv6 or even networking. [6] Folks might also want to go read the actual memoranda (dated 09 Jun 2003 & 29 Sep 2003) from US ASD/NII on IPv6 policy for US DoD. The common summaries of those memoranda are usually misleading at best and wrong at worst. It is worth doing a web search and reading the actual memoranda in full as written. Perhaps the least widely reported sentence there is: "No implementation of IPv6 shall be permitted on networks carrying operations traffic within DoD at this time." I am told the US DREN has enabled IPv6, but that is a research network and does not carry "operations traffic". I am also told that, as of last week, DoD networks carrying "operations traffic" are still prohibited from deploying IPv6 -- for myriad reasons, including unresolved security concerns with IPv6. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf