Ran, On Wed, Nov 14, 2007 at 08:19:56AM -0500, RJ Atkinson wrote: > > 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.
This paragraph is misleading in many ways: your reference [1] actually points to a reference that indicates that a company that you are very familiar with does not have a NAT-PT product, let alone that any customers of that company might be able to deploy it. I would not call such a reference supportive of the point that the RFC is actually deployed as you claim. Furthermore, you seem to know that the IESG ignored inputs when this draft was up for Last Call. I was the shepherding AD at the time and reality was very different: I was very reluctant to take this draft on as I didn't look forward for yet another inconclusive round of discussions on the merits of NAT. In addition, personally I am not convinced that the Historic status really has any value, especially if one considers the amount of work to actually get it done as opposed to using the same energy for other important work. However, it was very clear that there was consensus within the working group to request this status change as an alternative to moving it to experimental as the process didn't seem to allow us to do that. I talked to the chairs at multiple occasions and made it clear that in my judegement, I expected that this status change might not be easily accepted by the wider IETF community. However, to my own surprise, after I issued the Last Call, it became very clear from the comments received that there was no significant opposition to making NAT-PT historic. Your statement that the IESG just "ignored inputs from some number of people" seems thus not to reflect what actually happened. I do understand why quite a few operators have a somewhat cynical view due to a believe that the IETF is not listening enough to them. While there is definitely some truth there, there is very often also a serious amount of misunderstanding due to incomplete information and often misleading information spread by self-appointed spokes(wo)men for the IETF. For example in this particular case, the working group really wanted to move NAT-PT to experimental with the intention to show that it is was not the preferred IETF solution but at the same time not completely rule it's use out either (in fact even Historic doesn't really say that one should not use it under any circumstance), but as mentioned earlier we didn't find a way to actually do that with our process rules. At the same time, there were already quite a few voices within the IETF pushing for a new and improved NAT-PT. I honestly cannot call that a situation where the IETF simply ignores the needs of operators. David Kessens PS as my personal opinion on NAT-PT, as long as we define it as middlebox as opposed to a protocol that has strong interoperation needs, I am not convinced that it actually even needs to be standardized by IETF as it is perfectly possible to implement NAT-PT without a stable IETF specification and to make it work across the Internet. --- > 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 mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
