I must admit to some confusion about what Harald is asking for.
The context here is discussion of RFC 2434 "Guidelines for Writing
an IANA Considerations Section" (BCP 26). We're discussing "example"
policies for IANA assignments. Specifically there is:
" IETF Consensus - New values are assigned through the IETF consensus
" process. Specifically, new assignments are made via RFCs approved by
" the IESG. Typically, the IESG will seek input on prospective assignments
" from appropriate persons (e.g., a relevant Working Group if one exists).
which requires publication of an RFC, and
" IESG Approval - New assignments must be approved by the IESG, but
" there is no requirement that the request be documented in an RFC
" (though the IESG has discretion to request documents or other
" supporting materials on a case-by-case basis).
I think Harald is asking for comments on this.
Harald Tveit Alvestrand <harald(_at_)Alvestrand(_dot_)no> wrote:
Question:
What review process must the IESG take before taking the action to block or
allow publication of such an internet-draft (ie "what does IETF Consensus
mean")?
This is not written in RFC 2434.
I read this section of RFC 2434 as an escape hatch, not as a regular
process.
Before I can intelligently discuss the "process" for "IESG Approval",
I need some justification of why this option is used at all. It strikes
me as decidedly unwise to make a permanent IANA assignment based upon
an Internet Draft (which by definition expires in six months).
Some tactics that have been used in the past to gather information for the
IESG's decision include:
- "It's obviously OK". Approved WG document, or competently written
documentation from subject matter experts, reviewed by people with
competence on the specific registry. The IESG looks at it and thinks that
it's obvioiusly right. Example: application/ogg, documented in
draft-walleij-ogg-mediatype.
Well, immediately we are struck with the question, _which_
draft-walleij-ogg-mediatype. I believe draft-walleij-ogg-mediatype.08
is current.
Granted, I have no reason to believe the IANA assignment has
changed or will change; and the actual registration is minimal:
" To: ietf-types(_at_)iana(_dot_)org
" Subject: Registration of MIME media type application/ogg
" MIME media type name: application
" MIME subtype name: ogg
" Required parameters: none
" Optional parameters: none
" Encoding Considerations: ...
" Security Considerations: ...
" Interoperability considerations: ..
" Published specification: See [1]
where [1] is:
" [1] Pfeiffer, S., "The Ogg encapsulation format version 0",
" Internet-Draft XXXX, November 2002.
There's the problem: We've got an unquestionably useful format
depending on a document which will expire in May. IMHO, this richly
deserves an RFC (which doesn't expire).
- Subject matter expert group review. For instance, posting to the DHC WG
asking for opinions on a DHCP extension. WG chairs' feedback will carry a
lot of weight.
This is a limited case, where the appropriate WG is still active.
Clearly the WG Chair is the appropriate judge of WG consensus. But the
documentation is always in danger of being too sparse...
- IETF Last Call for Informational/Experimental, with the IESG evaluating
the feedback.
Isn't that an RFC?
In all cases, the IESG has to evaluate; there's no other established body
to do it. "The buck stops here".
Among the cases to consider:
- Everyone approves. Go for it.
- Nobody cares. No comments; the IESG will usually decide that nobody saw
any looming danger to the Internet, and allow the registration.
So long as there's no imminent danger of exhaustion of the name space,
and the documentation is adequate, I agree.
- Serious objections. The comments clearly indicate that the registration
would be harmful to the Internet (and how), and the IESG agrees with that
evaluation. The IESG will refuse.
- Incompetent or incomplete document. The IESG will usually object to this
on its own - without documentation clear enough to determine whether this
is OK or harmful, it would be remiss of the IESG to let the document go
forward even to an IETF Last Call.
We can't claim IETF consensus on something we can't understand.
Technically, we're not talking about "IETF consensus" ...
However, "IESG Approval" certainly _should_ imply that the IESG
_understands_ the registration request.
- Dissension within the IETF. Like in the case of a WG, the IESG has to
evaluate the arguments on their merits; obviously the proposers think
that the registration should be allowed, and opposition without a
rational basis should no more be allowed to block this registration
than it should be allowed to block WG progress. But as the saying goes
- "this is why you get the big bucks".
Did I miss the part where your salary was increased?
Among the things to consider here is that the determination must be made
in a timely fashion - sometimes there are reasons why letting debate
rage for another 6 months doesn't seem like an attractive option.
So often, when "time is of the essence", it means that the person(s)
preparing the request _chose_ not to allow sufficient time. This sort
of behavior should NOT be rewarded.
That said, "letting debate rage for another 6 months" isn't the
right solution either. Clearly defining the issue to be resolved is
the best policy, followed by careful reading (and possible feedback)
of the documentation which ensues.
Questions for the audience:
- should this description, or something like it, go into
draft-iesg-procedures?
I'm not convinced. I still think we're talking about an escape hatch,
not the "normal" process.
- are there guidelines that the IESG should use when trying to determine
the right outcome in the "dissension" case?
Minimize your work!
Demand clear documentation.
- does this debate belong on the POISED list, together with the discussion
of the IESG charter and the IESG procedures?
Seems reasonable to me...
--
John Leslie <john(_at_)jlc(_dot_)net>