--On Wednesday, June 13, 2007 08:27 -0700 Paul Hoffman
<paul.hoffman@xxxxxxxx> wrote:
At 12:08 PM +0300 6/13/07, <Pasi.Eronen@xxxxxxxxx> wrote:
The hurdle of getting IETF consensus and publishing an RFC
does weed out many crazy proposals that, in all fairness,
would not have made the Internet work better, and would not
have promoted interoperability.
It does not need to promote interoperability; being
interop-neutral is sufficient. How does giving a codepoint to
someone with a crazy (and let's say even dangerous to the
Internet) idea hurt interoperability? It seems to be
interop-neutral.
As Brian has suggested, this is a discussion that should really
be had around the specifics of draft-narten-iana... I believe
that discussion needs to be a community one leading to a BCP,
because some fundamental policy issues are involved that
interact with the IAB's role with regard to IANA and general
community interests, not just the policy role that falls to the
IESG as the result of its management/steering responsibilities.
Fortunately or unfortunately, I don't believe it is worth
spending more time on that document until there are firm
commitments to moving it forward. Until then, the WGs and IESG
will do what they like, with or without adequate consideration
of implications, and the community will need to express its
opinions and manage by Last Call comments and appeal, if at all.
Following Paul's earlier comment, I do believe that there is
something the IESG could do on its own initiative and without
much fuss that might help with situations like this going
forward. The vast majority of the community, at best, skims
Last Call announcements and decides to ignore most of the
documents because nothing controversial or important to their
work leaps out at them. But there are cases in which the IESG,
or WG Chairs, or others know that there are issues --either
technical or procedural ones, but especially the latter-- that
might be controversial. I'd like to see those explicitly
identified in Last Call announcements, just as
draft-klensin-norm-ref (RFC4897 RSN) requires that downward
references be identified.
Given this thread, I believe that any registration requirement
stronger than "good, publicly-available, documentation required"
(deliberately not using Thomas's terminology to avoid getting
tied up with the specifics of those categories) should be called
out in that way in Last Call announcements.
That said, I think strawmen are very dangerous here and that we
should be looking at exactly what is being proposed. To my
knowledge, no one has seriously suggested that we should give
numbers or parameter values to everyone who asks or every
half-baked idea that comes along.
I think real specifications of what the requested parameter will
mean and be used for are important. I think there is a
difference between registering a parameter for a non-standard
specification that is already deployed and in successful use and
registering one for a wild idea by one person. I think we ought
to be thinking seriously about how to handle some registrations/
number allocations that were made on the basis of I-Ds which the
IESG and RFC Editor then declined to publish as RFCs. And the
solution is probably not to withdraw the registrations, at least
IMO.
But, again, unless the IESG believes that this topic is
important enough to give priority and invest energy in looking
at policies and moving documents forward, I fear that this
discussion is largely a waste of time.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf