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