Subject: Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IP

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 12:26:31 +0200

Scott,

--On 29. juni 2005 19:22 -0400 Scott Bradner <[email-masked]> wrote:

>
>> It's not a hard concept. It just isn't mentioned or implied in RFC 2780.
>
> neither is not drinking gasoline but I trust that will not change
> your desire to not do so

while Brian and the IESG have certainly chosen to eat fire......

"check with the community" has its own "codepoint" in RFC 2434. It's called 
"IETF Consensus". (I've abandoned the theory that the IESG could sometimes 
tell that there was IETF consensus without asking. Too many opportunities 
for firestorms like this one, even when it sometimes IS obvious).

The people who wrote 2780 chose to write:

5.5 IPv6 Hop-by-Hop and Destination Option Fields

   Values for the IPv6 Hop-by-Hop Options and Destination Options fields
   are allocated using an IESG Approval, IETF Consensus or Standards
   Action processes.

So we've got two possible interpretations:

- The authors and the community that let this be published thought that 
there were some cases where the IESG could make a decision without 
consulting the community. Presumably this included "no" decisions.

- The authors and the community did not understand that there was a 
difference between "IESG Approval" and "IETF Consensus".

I trust the competence of these authors, so I think the first decision is a 
reasonable one.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 19:20:37 +0700

Date:        Fri, 01 Jul 2005 12:26:31 +0200
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <B0E3C978F498DC96D6CED4DA@B50854F0A9192E8EC6CDA126>

  | So we've got two possible interpretations:
  | 
  | - The authors and the community that let this be published thought that 
  | there were some cases where the IESG could make a decision without 
  | consulting the community. Presumably this included "no" decisions.
  | 
  | - The authors and the community did not understand that there was a 
  | difference between "IESG Approval" and "IETF Consensus".
  | 
  | I trust the competence of these authors, so I think the first decision is a 
  | reasonable one.

I agree with every word of that.

The question is, upon what basis should the IESG make the yes/no decision.

Some apparently believe (and I suspect that most or many of the IESG,
and recent past IESGs are included) that it means "for whatever reason
the IESG concludes is appropriate".

I do not agree.   To me, everything in 2434 is talking about what level
of documentation should be required to register a parameter (code point,
whatever you want to call it) via the IANA.   The "IESG approval"
section contains nothing to suggest it should be different.  To the
contrary, it expressly says that no RFC (ie: one documentation possiblilty)
is required, but that the IESG can request more documentation if it feels it 
necessary.  Everything is about documentation.

Documentation is  the subject to be judged, and should be the sole
basis for the yes/no decision.

If you agree with that, then we are in total agreement, and I'd suggest
that you should have yourself moved from the "satisfied" to the
"dissatisfied" column in Ken Carlberg's list.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 16:14:54 +0200

--On fredag, juli 01, 2005 19:20:37 +0700 Robert Elz <[email-masked]> 
wrote:

>   | - The authors and the community that let this be published thought
> that    | there were some cases where the IESG could make a decision
> without    | consulting the community. Presumably this included "no"
> decisions.   |
>   | I trust the competence of these authors, so I think the first
> decision is a    | reasonable one.
>
> contrary, it expressly says that no RFC (ie: one documentation
> possiblilty) is required, but that the IESG can request more
> documentation if it feels it  necessary.  Everything is about
> documentation.
>

I don't agree, which is no surprise.

RFC 2434 also says (section 2):

   One way to insure community review of prospective assignments is to
   have the requester submit a document for publication as an RFC. Such
   an action insures that the IESG and relevant WGs review the
   assignment. This is the preferred way of insuring review, and is
   particularly important if any potential interoperability issues can
   arise. For example, many assignments are not just assignments, but
   also involve an element of protocol specification. A new option may
   define fields that need to be parsed and acted on, which (if
   specified poorly) may not fit cleanly with the architecture of other
   options or the base protocols on which they are built.

That's technical review, not just documentation review.

Like you, I don't think the issue itself is important enough to waste this 
many cycles on. Whether the IESG did a competent technical review or not is 
beside the question - they make mistakes, like any other body.

The important part is that when they are asked to review something, we 
SHOULD expect them to make technical judgments. And that's how I think it 
should stay.

                 Harald

PS: Going on holiday in 14 hours. So this may be the last I say on the 
subject.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 1 Jul 2005 11:24:42 -0400

> necessary.  Everything is about documentation.

So if someone documented a code point in a registry with a scares
number of available code points which was actively harmful to the
entire infrastructure, as long as the documentation was appropriate,
the IESG should approve it?

Why then would we bother to delegate that kind of decision to the
IESG?  If it's all about documentation, the IANA can do that level of
work.  We go to a lot of trouble via the nomcom process to find people
who are technically competent and have the widsom to apply that
technical comptence for the Powers of Good.  Why then should we charge
them to act like programmable robots?

I can imagine registries where all that should be used is to require
that the paperwork be shuffled correctly, but that shouldn't require
the scarce resources of the IESG; that can be done by the IANA.  (And
we do have an option for that in RFC 2434 already.)  So if the
protocol specification required IESG approval, then IMHO the IESG _is_
empowered to make those decisions.  If you don't like the decisions
you make, there is a process to have IESG members replaced; it's
called the nomcom process.

						- Ted

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jul 2005 00:49:55 +0700

Date:        Fri, 01 Jul 2005 16:14:54 +0200
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't agree, which is no surprise.

Not really!

  | RFC 2434 also says (section 2):
  | 
  |    One way to insure community review of prospective assignments

Yes, and all that is fine, and I am by no means proposing to do anything
to prevent people getting that kind of review if they desire it.  Not
even to prevent working groups from requiring that kind of review for a
paramater if they can convince themselves, and the IETF at last call, that
a parameter really is so fundamental that new values cannot simply be
allocated (as I said before, I haven't read John's draft yet, so I'm
not sure if this is in accordance with that draft or not).

However, not every parameter needs such a review - if that was essential
the working group would demand a standards action RFC before a new
parameter could be defined (and I believe that has been done).  If
slightly less than that is required, review can also be obtained by
demanding at least IETF consensus.

For most parameters neither is necessary.   IPv6 options are one such.
That's simply true because of the way they're defined, and recognised as
such by rfc2780 when it allows ietf consensus or standards action processes
to allocate options, but also allows IETF consensus, which does not
require that kind of review, which I believe is where we do agree.

  | Like you, I don't think the issue itself is important enough to waste this 
  | many cycles on.

There I do disagree with you.   Not with respect to the particular
option that was requested, I don't doubt but that if they need it,
they will have their option (registered by IANA or not).   That's
not crucial.

However the IESG process that led to all of this is.

  | Whether the IESG did a competent technical review or not is 
  | beside the question - they make mistakes, like any other body.

I dont' care whether their review was competent or not, what I care
about is that they did it at all, when they should not have, and then
the way they handled things afte that.

  | The important part is that when they are asked to review something, we 
  | SHOULD expect them to make technical judgments. And that's how I think it 
  | should stay.

There I absolutely disagree.   Technical judgements should be the
provence of the IETF and its working groups.   If a technical judgement
was required, then as in the section you quoted above, there are
mechanisms to demand that.   Both because the IESG has quite enough
work to do without being lumbered by being required to do this, and
because they're (almost necessarily) a small insular group who tell the
world almost nothing about why they do what they do, expecting the IESG
to make that kind o judgement is simply the wrong choice to make.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Jul 2005 00:58:18 +0700

Date:        Fri, 1 Jul 2005 11:24:42 -0400
    From:        "Theodore Ts'o" <[email-masked]>
    Message-ID:  <[email-masked]>

  | So if someone documented a code point in a registry with a scares
  | number of available code points which was actively harmful to the
  | entire infrastructure, as long as the documentation was appropriate,
  | the IESG should approve it?

Yes.   If the code point space is really that scarce that you'd consider
that a relevant issue, then something needs to be done to increase the
space, as even if an occasional "weird" request were rejected, the
legitimate ones are clearly going to fill it quickly anyway.   For IPv6
options, the option space is not a problem, not now, and at the rate
options are being allocated, not anytime this century.

  | Why then would we bother to delegate that kind of decision to the
  | IESG?  If it's all about documentation, the IANA can do that level of
  | work.

That point was raised in private mail as well.   And no, the IANA no
longer can.   Once, yes, but now IANA isn't given the discretion to make
any value judgements.   I don't think I like that much, but that wasn't
my decision.   If the question were just whether documentation exists,
then IANA could do that, that's a simple yes/no.  That's also approximately
what FCFS allocations require.   But where the question is whether the
documentation is adequate, someone who can make that kind of judgement
is required.

As I said in an earlier message, you'd only ask the IESG to do that
normally if you didn't expect there to be very many requests.  Where
many are expected, having a designated expert is the better choice.

  | We go to a lot of trouble via the nomcom process to find people
  | who are technically competent and have the widsom to apply that
  | technical comptence for the Powers of Good.  Why then should we charge
  | them to act like programmable robots?

Not like that, and the competence that should most be required of
IESG members is the ability to manage the process.   That is not
necessarily technical brilliance.   Some of the best IESG members that
we have had I would characterise as technically mediocore.   The ones
who have been technically excellent have also sometimes been the ones
who have obstructed things the most (IMO).

kre