Keith,
You appear to beleive that the only reason someone might disagree with you is ignorance.
The question you do not appear to ask yourself is whether the disagreement results from their ignorance of technology or your own ignorance and cluelessness.
Neither the internet nor the IETF are perfect. There are problems to be solved and some of those problems are such that they can only be solved by people who are willing to question the dogmas and intellectual baggage that you constantly preach.
PHB
Sent from my GoodLink Wireless Handheld (www.good.com)
-----Original Message-----
From: Keith Moore [mailto:moore@xxxxxxxxxx]
Sent: Thursday, August 17, 2006 10:16 PM Pacific Standard Time
To: Shane Amante
Cc: l2vpn@xxxxxxxx; pekkas@xxxxxxxxxx; ietf@xxxxxxxx
Subject: Re: L2VPNs must not be IP(v4)-only
[followup to a reply that wasn't cc'ed to the IETF list, but I think
it's relevant for the broader audience ]
> Two of the fundamental tenets of education is: a) a willingness to
> learn; and, more importantly, b) a willingness to teach/lead/show
> others. No one in the L2VPN WG has expressed an unwillingness to learn
> about IPv6; instead, no one within the WG (modulo Giles; thanks Giles!),
> or elsewhere, has expressed a willingness to lead the group in
> developing the requisite features required to support IPv6 wrt ARP-MED.
> Unfortunately, your impudent message has not demonstrated a willingness
> to help lead the group wrt IPv6 support, leaving us no further ahead
> than where we were before. It would be much more productive if you
> could help contribute to the solution, rather than cast broad criticism
> against the WG.
My message was not directed specifically to L2VPN. Really it was a
statement about IETF and the qualifications to do engineering in this
space.
Several years ago when I was an AD I was shocked to find that the
principal participants in one of my working groups really didn't know
what IP was and only had the vaguest understanding of TCP. They didn't
know about the limitations of remote procedure calls or the
idiosyncrasies of slow-start and congestion control; they didn't know
anything about security or scalability. Based on this lack of
knowledge, they had somehow decided that it was okay to run all of their
traffic over HTTP, using a remote procedure call paradigm, to use port
80 as a default port, to not have any authentication in their protocol
and to expect network administrators to filter traffic for their
protocol at firewalls (because in their minds nobody would ever want to
use their protocol across administrative domains, nothing wrong with
using IP addresses as authentication tokens, and no reason why a network
admin wouldn't want to enumerate every one of the devices running this
protocol and block each one's address individually). In other words,
they were completely (and aggressively) clueless about the field of
endeavor they had adopted - and furthermore they thought it was someone
else's job to teach them how to do the engineering that they had agreed
to do. Frankly, I found this unacceptable, and I still do.
I'm not accusing L2VPN of being that bad or anywhere nearly that bad. I
am not familiar with the work that you've done and don't expect to take
the time to review it. But the fact that you didn't consider IPv6 in
your initial design certainly raises a red flag (didn't this come up in
the problem definition phase?), as does the apparent expectation that
IPv6 experts should help you design that part of the protocol. If I
were still an AD I would be making a mental note that your documents
should receive extra scrutiny during review, as such statements cast
doubt on the group's competency. On the other hand if the group had
said to IESG, well before Last Call, "we understand that IPv6 is
important, and we have this draft spec for how to do L2VPN for IPv6,
based on our imperfect understanding of the IPv6 and RD/ND protocols,
and we have some questions about whether we did it right, and we want
someone to check it for sanity before we invest too much into it", I'd
be thinking that the group really had its act together.
IETF is not an educational organization, it is an engineering
organization. Among the fundamental aspects of the discipline of
engineering are ability to define requirements, perform analysis, read
component specifications, synthesize designs, and predict the behavior
of those designs. When I went to school to learn electrical engineering
I wasn't given a tremendous amount of help in how to use specific
components like transistors or transformers; rather I was taught how to
do circuit analysis, and given circuits that modeled the behavior of
those components. I was then expected to use circuit analysis skills to
model how a more complex circuit using those components would function,
and finally, to design circuits according to certain specifications and
using those components. Similar processes were used by my friends in
other engineering disciplines, and I don't see why network protocol
engineers should not at least attempt to analyze the effects of using
combinations of network protocols and to predict the behavior of new
combinations of network protocols.
In this case, there are specifications for IPv6 and router/neighbor
discovery that are freely available for anyone to read. Perhaps they're
not basic reading material for just anyone, but they are not overly
complex. I don't see why people who are qualified to be IETF
participants shouldn't be able to read and understand them and at least
tentatively base designs on them. There might be some aspects of the v6
protocols that are hard to understand, but surely it is easier to find
IPv6 experts to answer specific questions than to find IPv6 experts who
are willing to conduct tutorials. Again, there might be some aspects of
the design that make L2 tunneling difficult, leading to a difficult
design choice - but surely such choices can be identified, and surely it
is easier to get IPv6 experts to answer questions about specific design
decisions than to get IPv6 experts to design the IPv6 portion of your
protocol for you.
Maybe in industry the usual practice is to hire an expert in a topic
rather than to have someone already on board to apply basic engineering
skills to a new problem domain. That might be a faster way of getting
something done, to jump ahead of the learning curve. But it's also hard
to make good compromises between different considerations if the people
involved don't have at least a rudimentary understanding of most of
those considerations. So as applied to L2VPN - basically I think that
the principals behind the L2VPN design need to learn enough about IPv6
and RD/ND to have at least a rough idea of what needs to happen to make
it work, even if you find an IPv6 expert who has a more precise idea.
Because at some point you're probably going to find a case where a
compromise is needed and without some shared understanding you aren't
going to be able to see what kind of compromise is a good one.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf