From: Dave Crocker
Sent: Monday, October 04, 2004 11:58 AM
We need a tight and concise protocol with no MAY's and all
MUSTS and no crap that can be implemented in the fewest lines
of code possible and afford the most portability possible to
see that adoption, integration etc.. is as painless as
possible.
That would all be nice. And lots of optional behavior in a
protocol is, in fact, usually viewed as a negative.
Unfortunately, a standards activity is a social process that
entails developing group (rough) consensus. It is always easier
for a one person to develop compromise with themselves. Gaining
enough broad-based consensus to facilitate global adoption is a
very different matter.
Strongly agree with Dave's assessment. I'm sure WG chairs of the efforts
that led to previous standards wished there were fewer optional components,
but consensus entails compromise when the participants are reasonable.
Since none of us is smart enough to run the Internet, this is really the
best that can be done. I'm sure every one of us has many examples where we
would like to see an RFC say MUST instead of SHOULD or MAY, but invariably
we would all be thinking of different cases.
At any rate, if you have concerns about DNS, per se, there are
other venues for discussing it. The point, here, is the
distinction between using an established, global, infrastructure
service, versus creating a new one.
Point very well taken and for many people, the choice will be based on
precisely that consideration. It would be a mistake to tie any given
protocol to the requirement for a new service. As I mentioned in another
thread, I think debating the issue of creating a new UDP service vs. using
DNS is not the main question, Since the proposed protocol can happily run
over DNS. The real issue, IMO, is how does a callback scheme compare to a
PK scheme in terms of total transaction cost and how the cost is allocated.
This is a basic architectural decision that is worth thinking about. They
are two different models, each with advantages and disadvantages. To avoid
the issue of creating new infrastructure and to create an equitable
comparison, I suggest that we assume that both run over existing DNS,
perhaps with the option of using Tony's "stunt" DNS server, since this still
uses existing infrastructure. Once we have made that architectural choice,
there are all manner of optimizations possible for either style of protocol.
Dave: would it be appropriate to shift the discussion to that question?
--
Seth Goodman