Standards Process wrt IANA (was Re: [mpowr] Mailing List Management)

[Allison Mankin <[e-mail]>]

	
	* At the time 2026 (and 2418) were written, most IANA
	allocations of port and protocol numbers were done at
	IANA's own discretion and initiative, with IANA asking
	questions when needed (and selecting whom to ask).  Now,
	a large fraction of those require either IESG approval,
	or approval of experts appointed by the IESG.  In both
	cases the reviews are apparently done on a "when we get
	around to it" basis, with no timeouts or quality
	control: if some AD doesn't push for something to get
	done, it may take a _very_ long time.  Now, given the
	changed circumstances at IANA, some additional (and more
	formal) review and technical input is certainly
	justified in many of these circumstances.  But I can
	find nothing in 2026 or 2418 that assigns authority to
	IESG to decide how these things should be handled, put
	itself in the loop, etc., without going back to the
	community for authorization.  Do you think the IESG
	actions and assertions of authority in this case are
	appropriate?  Do you think they are healthy for the
	community given that some of the tasks, once created and
	assumed, don't get done in a timely fashion?


In this case, there's a question about what degree of process people
consider enough.  It's true that RFC 2026 doesn't discuss the
relationship with the IANA.  But routinely, assignment processes and
interactions with IANA are written by document editors into BCPs or
standards track RFCs, which get IETF Last Call, after WG review, and
therefore have community authorization to the same extent that any
WG-advanced standard does.  IANA also consents to the IANA contents of
the documents - that this is not formalized is another part of the big
picture functions discussion we are all trying to have, and part of the
procedure point you and Harald exchanged earlier today.  IANA negative
reviews and remedies can be seen in the tracker for specific documents,
but the procedures in use today are not clearly documented.

The use of Expert Review appointments by IESG (when requested by WG
documents) was approved by the community in RFC 2434, BCP 26.  So
again this process was authorized by the IETF.  

Are there a bunch of overload problems in the IANA processing system,
on all sides (IANA too).  Resounding yes.  Many arise in the steps
having to do with the IANA processing for the approved documents,
which is not the issue in your comment, but should resonate for many
document editors.  ADs play hastener on these, rather than roadblock.

The big picture is to take on a structured review of such functions
and their overloads, but saying that the IESG seized IANA-related
functions without community process doesn't present the history, 
because the community has supported the BCPs.

There are questions related to the symptoms of a number of the
functional problems in these points John raised.  There's a structured
discussion here -- a working group discussion?  Perhaps we should get
back to the charter discussion, and perhaps the charter to be
discussed is shaping up differently than first proposed.

My non-vacation Dec 24 is over, happy holiday everyone!

Allison

_______________________________________________
mpowr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpowr