ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
BTW, RFC 3864 is an _excellent_ model for an "expert review" registry
The jury is still out on that, but things aren't looking good. RFC 3864
has been out for two and a half years, and in that time there has
apparently been exactly one non-RFC provisional registration: Martin's
Archived-at: proposal.
Meanwhile three, it took some time to kick IANA that they kick the IESG
to appoint an expert reviewer. For JabberID the registration was aborted
after Bruce found that the syntax had issues, IMO related to a bug in the
RFC 4622 URI scheme. Indirectly the JabberID review helped to identify
the 4622 bug.
Which is all well and good but has little to do with the intended goal of the
provisional registry.
I have a very hard time beleving the world has stood still in regards
to header field name use for all this time. A far more elaborate
registration procedure than most that's rarely is ever used is NOT an
"excellent" model for anything IMO.
If folks get used to register their new header fields specified in I-Ds
it can help to avoid collisions. And if they don't use it it won't help,
with effects as noted in the subject of this thread.
Exactly. And this means that the goal of any registry is first and foremost to
encourage its use, even if that involves constructing the registry in a way
that may admit race conditions. And the only meaningful measure of the success
of any registry is whether or not it gets used.
in the fullness of time all of this stuff may prove to be useful and
therefore justified. But little if any of it has so far.
It's one of the many things that can work if folks want it to work. I'm
no big fan of the "expert review" model, experts tend to be MIA or AWOL,
or the review lists stop to work, but when it's anyway used, then adding
"provisional registrations" as a feature where collisions are possible
makes sense.
Again, it may make theoretical sense, but practically speaking only actual
results matter, and we're not seeing those, at least not yet.
There are all sorts of ways to define a collision-avoiding registry
that don't involve a provisional registration step. An obvious one is
the "IANA assigns number during the publication process".
Does that work for ideas published only in drafts ?
Of course not. But that begs the question of whether or not you want people
implementing and deploying ideas that only appear in drafts. And the answer to
that is sometimes you don't care, but other times you actually want to actively
discourage such behavior, and one way to do that is to deny allocation until
RFC publication.
Without an "expert review", what about name squatters ?
What about them? It is axiomatic that registries only work when they are used.
Squatters by definition aren't following the process.
I don't think it is the right approach for extended status codes even
though they are numeric and hence amenable to being assigned this
way. But it is simply not the case that the elaboration of provisional
registration is necessary to solve this problem
I don't see how the draft under discussion solves the collision problem
that triggered its creation.
There are actually two collision problems here, one IMO major and the other IMO
fairly minor. The major one is that if Chris Newman hadn't done a careful
review we would have ended up with a conflict between two published RFCs. It's
unacceptable to depend on this sort of careful review to avoid such problems
and that's the problem we really need to solve.
The issue that draft-siemborski-rfc2554bis.txt sat around for a good long while
with a conflict is far less important. And while it can theoreticallly be
solved either through the use of a provisional registry or an
assign-at-publication-time approach, that only works if the construct is used,
and we're not seeing the running code elsewhere indicating the provisionaal
registry approach will be used if it is adopted.
I would also argue that the real problem here is that 2554bis sat around for
literally years without forward progress and despite apparent need for the
revision. I really don't think it is a good idea to effectively encourage
implementation of security services from drafts no matter what the registry
mechanism for error codes happens to be.
_in practice_ simply having a registry, even one whose procedues don't
prevent race conditions, eliminates most collisions. The enhanced status
code problem is the result of not having a registry period, as opposed
to not having the right sort.
It would be the same mess if the long forgotten I-D had a proper "IANA
considerations" section requesting a registration.
No it wouldn't. IANA would have caught the conflict before publication and we
would not have had to depend on a review happening across it.
If an expired I-D
is implemented, but the name or number isn't registered, unrelated I-Ds
could run into the same trap. For any enumeration the next (allegedly)
free number is an obvious choice.
And if the draft fails to use the provisional registry - as will likely be the
case - the same problem will exist. As usual we're letting the best be the
enemy of the good.
Ned