Traditionally, it was sufficient for the IETF to publish an RFC
specifying requirements or behavior; the purchasing process, through
RFIs and RFPs, then cited the long list of RFCs, essentially creating
the protocol police force that the IETF doesn't have.
That list-of-RFC-numbers approach is clearly not workable for consumer
gear. The consumer wireless providers recognized that a while ago. Thus,
802.11b became "WiFi" and an easily recognizable logo, with
interoperability testing. Same for BlueTooth.
Trying to devise ever more elaborate NAT traversal mechanisms that
include sending keep-alives every few seconds and various "let's try
this and then that" algorithms clearly don't scale if we want to get to
consumer-grade reliability, not just interesting toys that try to stay
one step ahead of the next stupid NAT trick.
Thus, I think we need a separate organization (or work with a separate
organization) that does branding and certification. It's hard to buy a
non-WiFi device in stores today; the equivalent consumer assurance needs
to be true for core consumer and small-business network devices, and
possibly services.
Henning
Spencer Dawkins wrote:
Dear All,
My apologies for not being clearer - my intention was not to criticize
WG or IAB actions in the past, but to point out that we are now in an
escalating game of whack-a-mole with our applications as the moles that
NATs and FWs are finding new ways to frustrate.
The security guys have taught us that holding the mallet and waiting for
the next mole to pop up is not fun; I think the NAT/FW guys are teaching
us that being the mole is just as bad ("gee, this used to work, until
someone decided that yet another normal operation was a security threat
and configured their FW to block it, or someone just installed a NAT
that is broken in some new and exciting way").
Thanks,
Spencer
p.s. I apologize for the use of culture-specific analogies. For an
explanation of "Whack-a-mole", see
http://en.wikipedia.org/wiki/Whack_a_mole or http://whacamole.com/ ("the
official website" - now, that's scary).
From Wikipedia:
"Colloquial usage: The term Whac-a-Mole, or Whack-a-mole, has been used
in the computer and networking industry to describe the phenomenon of
fending off recurring spammers, vandals or miscreants. The connotation
is that of a repetitious and futile task: each time the attacker is
"whacked" or kicked off of a service, he only pops up again from another
direction. Also used in the military to refer to opposing troops who
keep re-appearing: Whack the mole here and it dies, but another pops up
in a different spot."
From: "Melinda Shore" <mshore@xxxxxxxxx>
On 3/25/06 7:47 PM, "Spencer Dawkins" <spencer@xxxxxxxxxxxxx> wrote:
So my point was, I'd really like to take a chance on some IAB statements
about things that need to be stated about our architecture. They
might be
ignored. Would the result be any worse?
This is a somewhat bothersome case, because the IAB *did* issue
an RFC explaining what many of the problems were with "Unilateral
Network Self-Address Fixing" (i.e. STUN). They included a list
of conditions they felt that an UNSAF protocol had to meet in order to
be published, including a description of a transition mechanism away
from itself and towards something more robust. I don't know what
more the IAB could have done in order to kill what I think is
a clearly pathological approach to NAT traversal (and I chaired the
working group that standardized it, so I accept a great deal of
responsibility for this mess), but if putting out a document that
says "These are the reasons that this isn't a good protocol" isn't
enough, well, I'm not sure. But it seems to me that trying to
fix it this late in the process (my other .sig is "software longa,
hardware brevis") has less to do with architecture and more to do
with oncology.
At any rate, I do think that in this case the IAB did do their job
and it was the rest of us louts who messed up. And I'll tell you
where I think it happened: when we accepted the idea that something
might be transitional and would eventually go away.
Melinda
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf