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

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

 





--On fredag, juli 01, 2005 19:20:37 +0700 Robert Elz <kre@xxxxxxxxxxxxx> wrote:

    Date:        Fri, 01 Jul 2005 12:26:31 +0200
    From:        Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>
    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.

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

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