--On Wednesday, 11 April, 2007 08:25 -0700
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
...
While I agree with you in principle, I think we need to be a
bit careful here. If the goal is to prevent the same code
from being used for different purposes, I think it is an
unpleasant necessity to recognize and register codes acquired
by squatting based on non-conforming code that has become
deployed widely enough to be significant.
If so, that is NOT an argument for the "RFC Required" model -
I see essentially no chance that a code-squatter is going to
write an RFC of any sort, let alone write one but then send it
to the RFC Editor instead of putting it through the IETF
process.
Agreed. See below.
Have a look at the registration-specification language in
draft-klensin-smtp-code-registry-00 (a parallel development to
Tony's draft that I hope will be quickly consolidated with it)
and let us know what you think.
You have gone with the "specification required" approach. This
is in one sense more lenient than the "RFC Required" since it
allows for non-RFC specificaitons and would avoid the problem
that code-squatters rarely if ever seem to be willing to write
RFCs to document their usage.
That was, more or less, the intent.
However, in another sense it is less lenient since it requires
approval by a designated expert. I think this is sufficient
(barely) to address my concerns about overlapping or poorly
defined codes getting into the registry.
One could, in principle, combine the two, allowing registration
by RFC if a document could make it through either the IESG or
the RFC Editor, but a specification for other cases. I don't
know if that would be helpful or not.
However, one of the requirements for expert review is that the
review criteria be clearly spelled out in the registration
document. I don't think what you have is sufficient in this
regard. I think it needs to have a list of requirements, such
as:
(1) The meaning of the code must be clearly defined.
(2) The code most not duplicate the functionality of a
previously defined code.
(3) Whenever possible the use-cases new codes should not
overlap the use-cases for existing codes, except when a
new code is intended to allow identification of a more
specific subcase of an existing code.
This is definitely an improvement. I'm going to leave the
merging and word-smithing to Tony unless he asked for help, but
would consider adding this worthwhile.
Finally, the document should say that exceptions to the rules
can be made when an unregistered code has achieved significant
deployment since the main purpose of the registry is to
document all code use in order to avoid confusion and prevent
multiple different definitions for the same code.
My bottom line is that, as long as some provision such as the
above is included -- I tried to treat it not as an exception
but as a nearly-sufficient justification for approval -- I can
live with almost any plausible "normal case" language. I am
concerned about getting into situations in which a code that is
in wide use cannot make it into the registry because a
capricious RFC Editor or IESG decide they don't like the idea
behind the code or the tone of the description and would prefer
to make it clear that would be an undesirable outcome.
john