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

[Harald Tveit Alvestrand <harald at alvestrand.no>]

--On fredag, juli 01, 2005 19:20:37 +0700 Robert Elz <kre at munnari.OZ.AU> 
wrote:

>     Date:        Fri, 01 Jul 2005 12:26:31 +0200
>     From:        Harald Tveit Alvestrand <harald at alvestrand.no>
>     Message-ID:  <B0E3C978F498DC96D6CED4DA at 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.

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.


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf