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

From: [email-masked] (Scott Bradner)
Date: Thu, 14 Jul 2005 12:52:38 -0400 (EDT)

imo this update is much needed - there has been considerable confusion 
about some of the processes in RFC 2434 and it would be good to
clear up the confusion

one specific area of confusion was what used to be called "IETF
Consensus" - renaming it to "IETF Review" may help but I'm not sure

I think there should be a IANA evaluation process that includes a
required IETF-wide Last-Call and evaluatiopn of the results of
that Last-Call by the IESG - the current text for "IETF Review" does
not make a Last-Call manditory  (this is seperate from IETF Standards
action because it should not require a standards-track RFC - an info or
exp RFC should be fine)

it would be my suggestion to use a very specific term such as "IETF
Last-Call & Consensus"  for a process that includes the following
	requires a public document (not limited to IDs & RFCs)
	requires an IETF-wide Last-Call
	includes IESG evaluation of results of Last-Call
		IESG permitted to do own evaluation but if
		results differ from results of Last-Call then
		IESG has to specifically justify difference in
		public message to IETF list

also concerning the "IESG Approval" process
	I'm fine with having such a process but considering the
	mess we have been going through I would like to add a 
	step to the "IESG Approval" process 
		if the IESG decides to turn down a request it
		must document the reason(s) for the reject in
		a message to the IETF list and run a Last-Call
		like request for opinions on the proposed IESG
		rejection - if the responses to the comment
		requested process clearly do not support the
		proposed IESG rejection the IESG must withdraw its
		proposed rejection.  The IESG can publish 
		a RFC listing its issues with the proposed use
		but can not block the assignment
		if the responses to the comment requested process
		do not clearly object to the proposed IESG rejection
		then the IESG recommendation for rejection can
		be forwarded to the IANA

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Jul 2005 18:12:40 -0400

would it be reasonable to just say that we are going to always last
call IETF review documents?  Personally I'd approve of this option
unless people think it is too restrictive.

---

From: [email-masked] (Scott Bradner)
Date: Thu, 14 Jul 2005 20:06:13 -0400 (EDT)

works for me (assuming that you include non-IETF documents when you
say "IETF review documents")

Scott

----

>From [email-masked]  Thu Jul 14 18:12:46 2005
To: [email-masked] (Scott Bradner)
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
From: Sam Hartman <[email-masked]>
Date: Thu, 14 Jul 2005 18:12:40 -0400

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Jul 2005 14:17:23 +0200

> say "IETF review documents")

In which case, what you last call is not the document itself but
what the IETF intends to say about it, and do about the related
IANA action.

That being so, I think we now have running code proof that this is
what the community wants.

     Brian

> X-Original-To: [email-masked]
> Delivered-To: [email-masked]
> References: <[email-masked]>
> In-Reply-To: <[email-masked]> (Scott
>  Bradner's message of "Thu, 14 Jul 2005 12:52:38 -0400 (EDT)")
> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
>

---

From: [email-masked] (Scott Bradner)
Date: Fri, 15 Jul 2005 08:18:49 -0400 (EDT)

> what the IETF intends to say about it, and do about the related

just so

Scott

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 15 Jul 2005 21:46:58 -0700 (PDT)

On Fri, 15 Jul 2005, Brian E Carpenter wrote:
> Scott Bradner wrote:
> > Sam Hartman wrote:
> > > would it be reasonable to just say that we are going to
> > > always last call IETF review documents?  Personally I'd
> > > approve of this option unless people think it is too
> > > restrictive.
> >
> > works for me (assuming that you include non-IETF documents
> > when you say "IETF review documents")
> 
> That being so, I think we now have running code proof that this
> is what the community wants.

To make sure I understand what is being said here, is the proposal
that a Last Call would be required for the policies labelled "IETF
Review" and "IESG Approval"?  That seems reasonable to me.  And if a
last call requirement is added, I don't think there is a reaon any
more to change the name to "IETF Review" from "IETF Consensus".

I would be less supportive of a proposal to require Last Call in
connection with the "Specification Required" and "RFC Required"
assignment policies.  That seems too heavyweight.  However, I do
think that it would be reasonable to require that the supporting
documents be reviewed by a designated expert to verify that it they
are sufficiently clear to make possible interoperability between
independent implementations.

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Jul 2005 11:24:11 +0200

> more to change the name to "IETF Review" from "IETF Consensus".

That's what I meant.

> independent implementations.

I agree, as long as there is enough of a public record that
anybody can find out the history.

     Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Jul 2005 07:03:52 -0400

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.

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.

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.

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jul 2005 10:22:11 -0400

--On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman
<[email-masked]> 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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Jul 2005 13:59:06 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> --On Wednesday, 20 July, 2005 07:03 -0400 Sam Hartman

    >> review would be different enough that it would be highly

    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.

    >> proposal depending on whether you found the IESG's arguments

    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.

    >> how the IESG should balance its own opinion against comments

    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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2005 00:27:25 +0200

John C Klensin wrote:
> 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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 22 Jul 2005 12:52:17 +0200

> Seriously, we could call it a Call for Comments.

The IAB has a tradition of issuing "impending publication" notices on their 
architectural guidance documents.

The resulting document is still labelled an IAB document, not an IETF 
consensus document, but I think the process improves the output (You'd have 
to ask the IAB what they think about the resulting feedback, however).

If something works - copy it :-)

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Jul 2005 07:35:30 -0400

BTW, this conversation and a side conversation with John has convinced
me that IESG review should involve a call for comments phase.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 22 Jul 2005 15:51:19 -0400

> me that IESG review should involve a call for comments phase.

A call for comments requires having something for the community to
comment on. 

Will an internet draft will be required from folks seeking IESG review
of a proposed assignment, or will we invent yet another mechanism for
circulating a description of the proposal to the community?

					- Bill

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jul 2005 14:03:38 -0700

>circulating a description of the proposal to the community?

It would make sense for the IESG to send to the community what was 
sent to them; that way, we can judge what they are judging. If it was 
a pointer to an Internet Draft, great; a pointer to some other 
document(s) works just as well.

--Paul Hoffman, Director
--VPN Consortium