"John" == John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
John> --On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman
John> <hartmans-ietf(_at_)mit(_dot_)edu> 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.
John> Sam, I would think that the purpose of a Last Call as part
John> of IESG review would primarily be not to evaluate success or
John> failure, but to be sure that the IESG has an opportunity to
John> hear, from the community, about issues of which the IESG
John> members might not be aware. I hope I can say this without
John> sound insulting, because insult is certainly not my intent--
John> but having the IESG make a decision after soliciting
John> comments from the community is a safer situation and process
John> than having the IESG members talk only with each other or
John> people whom they pick, and then decide. As I'm sure you
John> will agree, no one around here is omniscient; the way we get
John> quality decisions is to get input from as broad a population
John> as possible.
I think you have convinced me that a last call for IESg review is
valuable provided that we understand it is one way to seek input.
>> 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.
John> Right. And that is another key point, IMO: the main point
John> of IESG review is to have a fairly quick, low-impact process
John> for registrations that can be approved. If the IESG
John> concludes that, for any reason, it cannot approve a
John> particular request, then that request should --at the option
John> of the requester-- be taken up with the community, through
John> an IETF process
Agreed.
John> and without any prejudice from the IESG
John> review.
If you mean that the IESG should treat the process fairly, I agree.
If you mean that the IESG should not express an opinion I disagree.
John> Put differently, if the IESG is asked to look at
John> these things, you should, IMO, ask the community for comment
John> and then decide either "yes, register" or "decline to make a
John> decision on the community's behalf". "No, go away",
Agreed.
John> and
John> even "no, and we recommend that you go away and not pursue
John> this" should not be options unless there really is evidence
John> of community consensus.
Strongly disagreed.
>> 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.
John> I hope that issue is reasonably well covered in
John> draft-klensin-iana-reg-policy-01.txt. If it is not, I guess
John> I've got another rev in my future. I do not believe that
John> document is incompatible with the rfc2434bis document, just
John> that each raises some issues that should inform the other.
John> The iana-reg-policy doc is also intended to contain some key
John> details, such as a discussion of evaluation criteria, that
John> the other document omits.
I agree that your draft addresses most of these issues. It happens to
do so in a manner I believe I disagree with and hope to convince the
community is at least significantly wrong. However I do agree that if
the community approves of your draft, it would establish the criteria
I'm asking for.
Next week before getting on the plane I have catching up on newtrk and
reading your document scheduled. I will make detailed comments.
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf