Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)

--On Wednesday, June 13, 2007 08:27 -0700 Paul Hoffman 
<paul.hoffman@vpnc.org> wrote:

> At 12:08 PM +0300 6/13/07, <Pasi.Eronen@nokia.com> 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf