--On Saturday, November 28, 2009 9:29 PM +0000 Alexey Melnikov
<alexey.melnikov@xxxxxxxxx> wrote:
...
I'm hearing "it's within the scope of the expert's judgement
to require an IETF Consensus doc" and "In cases when an IMAP
Keyword being registered is already deployed, Expert
Reviewers should favour registering it over requiring
perfect documentation." If I were an implementer who got
told "you need a consensus doc", I'd be more than a little
tempted to go ahead and deploy, then reapply for the
registration.
Well, if one works for Microsoft, Google, Mozilla, etc. (not
trying to pick on anybody), then one does it every time.
Hopefully Expert Review is low enough bar to tempt people (if
tempt is the right word here at all) to register.
Sam,
For whatever it is worth, the above exchange goes to the very
root of the question of what we think our registration
procedures and registries are for, at least when there isn't a
scarcity of possible identifiers. One theory is that they
should be designed to prevent garbage, or warn people against
garbage by the fact that something isn't registered. I think
we've seen ample evidence that theory doesn't work, with your
comments and Alexey's above both constituting examples. The
other is that the main purpose of registration is to provide
sufficient information and documentation to promote
interoperability by virtue of encouraging people to avoid using
the same identifier for different purposes.
I'm more optimistic about the second than the first, but it
calls for a fairly low bar on registrations.
Neither model has much to do with security: registration, no
matter how high or low the threshold, won't prevent an attack if
someone is inclined to misuse or reuse an identifier in a
malicious way. Nor will non-registration help avoid someone
finding out what an identifier looks like an attacking whatever
it represents if one were inclined to do that... only the most
dedicated believer in security through obscurity could believe
that non-registration is helpful in that regard and it would be
a stretch even then.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf