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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





--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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]