On 15 Nov 2007, at 02:27, David Kessens wrote:
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.
It is unfortunate that you mistook the financial-interest disclaimer [1] as something else. I've heard from end users in North America, Asia/Pacific, and also Europe who say they are using this operationally today. My relationship with our customers (who are most usually also customers of other suppliers) imposes NDA constraints upon me -- as it does on most other folks in my situation at other firms. I'm not inclined to provide free advertising for my employer's competitors by naming the products these folks say they are using. One imagines a web search likely will find them. So while I can, and have, asked those operational folks to participate directly, I can't provide a list without their consent. The broad reaction to my suggestion that they participate directly was usually of the form "waste of time; IETF won't listen; please ignore them and implement this anyway".
Furthermore, you seem to know that the IESG ignored inputs when this draft was up for Last Call.
"some number" is an indefinite number. I know there were some objections. You haven't denied that.
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.
That statement is in fact part of the problem here. The WG is not the entire universe of affected Internet stakeholders -- and the operational community is particularly impacted and also largely absent from the IETF and its WGs. Folks appear not to have done much outreach to operational folks (who generally aren't in the IETF for myriad reasons, including the perception that it is a waste of their time) to find out whether or not the technology was in use or not -- and what issues (if any) those operational folks might have been solving (or issues that they might have had with the RFC). Your statement merely tends to confirm the perceptions of those who refer to the IETF as the IVTF, which is sad to me. I really was hoping for better. I would prefer that a way be found to bridge this gap in perception, as that would be best for the future of the Internet.
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.
See comments above, which equally apply here.
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.
Another process option for the IESG would have been to form a WG or even a BOF on updating/enhancing/replacing the RFC -- instead of moving it to historic. Undertaking that process option would seem more consistent with your acknowledgement above that there were "quite a few voices ... puhsing for a new and improved NAT-PT". Moving it to Historic was not the only process option available to the IESG, as you seemed to be claiming earlier.
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.
I share the idea that in the abstract the IETF does not need to standardise such a thing -- mainly because I am in part an economist. Useful technology tends to deploy itself regardless of standards. In this case, what some operational folks say they need, which I believe I said in my earlier note, is an open specification so that it will be interoperable. Interoperation with the rest of the deployed Internet is clearly needed. As I've noted all along, those folks have advocated implementing the existing RFC regardless of its IETF status. If folks want to come up with an improved open specification, I think that would be great -- and I suspect that at least some operational folks would find that useful. I-Ds of the past few days seem to indicate that some effort on this topic is likely to happen, either with or without the IETF. Yours, Ran [EMAIL PROTECTED] _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
