John C Klensin wrote:
--On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
No, I was not intending to imply IESG review would gain a last
call. I was only speaking to IETF review.
I don't think IESG review gaining a last call is all that
benefical. It's not clear how you would interpret the results
or what the success/failure criteria is. I think interpreting
IESG review last calls would be significantly more difficult
than IETF review last calls. We have a lot of experience
publishing documents and even dealing with last calls on
documents that end up generating a lot of messages. But IESG
review would be different enough that it would be highly
problematic.
Sam, I would think that the purpose of a Last Call as part of
IESG review would primarily be not to evaluate success or
failure, but to be sure that the IESG has an opportunity to
hear, from the community, about issues of which the IESG members
might not be aware.
Then I don't think it's a Last Call in the normal sense.
It's what we might whimsically call a Request For Comments.
Seriously, we could call it a Call for Comments.
The IESG has been asked to assign a new Foobar codepoint
to support the Barfoo protocol specified by the Splat Consortium.
See http://splat.org/barfoo for details. The IESG
solicits comments on this request by February 29, 2007.
That seems reasonable to me.
Brian
I hope I can say this without sound
insulting, because insult is certainly not my intent-- but
having the IESG make a decision after soliciting comments from
the community is a safer situation and process than having the
IESG members talk only with each other or people whom they pick,
and then decide. As I'm sure you will agree, no one around here
is omniscient; the way we get quality decisions is to get input
from as broad a population as possible.
Instead, I recommend viewing IESG review as a short circuit
process that can be used when a request successfully convinces
the IESG that it should be approved. I think it is important
that IETF review always exist as an alternative when IESG
review is available. If your IESG review is not sufficiently
convincing, then you can either pursue IETF review or drop the
proposal depending on whether you found the IESG's arguments
convincing.
Right. And that is another key point, IMO: the main point of
IESG review is to have a fairly quick, low-impact process for
registrations that can be approved. If the IESG concludes that,
for any reason, it cannot approve a particular request, then
that request should --at the option of the requester-- be taken
up with the community, through an IETF process and without any
prejudice from the IESG review. Put differently, if the IESG is
asked to look at these things, you should, IMO, ask the
community for comment and then decide either "yes, register" or
"decline to make a decision on the community's behalf". "No,
go away", and even "no, and we recommend that you go away and
not pursue this" should not be options unless there really is
evidence of community consensus.
If you do choose to have a last call for IESG review, you need
to have some text explaining what the IESG is evaluating and
how the IESG should balance its own opinion against comments
made in the last call.
I hope that issue is reasonably well covered in
draft-klensin-iana-reg-policy-01.txt. If it is not, I guess
I've got another rev in my future. I do not believe that
document is incompatible with the rfc2434bis document, just that
each raises some issues that should inform the other. The
iana-reg-policy doc is also intended to contain some key
details, such as a discussion of evaluation criteria, that the
other document omits.
regards,
john
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf