Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "John" == John C Klensin <john-ietf@xxxxxxx> writes:

    John> --On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman
    John> <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.

    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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]