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
rja@xxxxxxxxxxxxxxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf