Subject: Re: "IETF consensus" in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ]

From: Robert Elz <[email-masked]>
Date: Tue, 11 Feb 2003 19:45:04 +0700

Date:        Thu, 30 Jan 2003 15:45:13 -0500
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

I had been avoiding reading this set of messages, because I couldn't
really see discussions of what was required to get IANA to assign a
number in some (irrelevant to me) code space could possibly be interesting.

But ...

  | In practice, "IETF Consensus" (as defined in 2434) means that
  | procedurally the IESG has to sign off on a document before IANA
  | assigns code points for it.

This is certainly true.   Unfortunately, it seems that the IESG sometimes
believes that this is all that is required (for IETF Consensus as a general
term).

That's nonsense.   Nor is "publication as a standards track RFC" or
anything similar the definition of what is "IETF Consensus" - that would
be absurd, as IETF Consensus is required for that to happen - that is,
publication as a standards track RFC is general evidence of IETF
consensus, but is not a necessary product of IETF consensus.

There can be IETF Consensus not to publish a document, just as there can
be to publish it.

IETF Consensus is the IETF's way of agreeing to some action.   The IETF
makes that decision, the IESG (currently anyway) is tasked with determining
whether or not the IETF has actually made a decision.   IETF Consensus
clearly requires a last call be made.   It does not (of itself) require
publication of anything at all - publication may be made to record the
consensus, it does not cause it, and is not required to obtain it.

kre

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 18 Feb 2003 14:30:51 +0100

--On tirsdag, februar 11, 2003 19:45:04 +0700 Robert Elz 
<[email-masked]> wrote:

> makes that decision, the IESG (currently anyway) is tasked with
> determining whether or not the IETF has actually made a decision.   IETF
> Consensus clearly requires a last call be made.   It does not (of itself)
> require publication of anything at all - publication may be made to
> record the consensus, it does not cause it, and is not required to obtain
> it.

Given that a large portion of the IETF does not in fact subscribe to the 
ietf-announce list, and that in some cases the IETF consensus is pretty 
obvious (for instance when the decision is just paperwork following up on 
another IETF consensus decision), I wouldn't even say that a Last Call is 
always required.

But it's certainly one tool, and a fairly powerful one, for getting 
objections out in public.

(now, does the recent DJB discussion of axfr-clarify by itself invalidate 
WG or IETF consensus? I think not.... but it's certainly input that has to 
be considered when determining the IETF consensus.)

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 17:03:39 +0700

Date:        Tue, 18 Feb 2003 14:30:51 +0100
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | Given that a large portion of the IETF does not in fact subscribe to the 
  | ietf-announce list,

That's irrelevant, anyone who cares can subscribe (or can request someone
else to forward any relevant messages).

Anyone who fails to subscribe to the list where last calls are made, is
effectively saying that they have no objection to anything the rest of the
IETF decides on some issue (just as not replying to a last call request
does - which is what most of us do to most last calls that are made).

  | and that in some cases the IETF consensus is pretty obvious

This gets dangerous.   What is obvious to one person, or one group of
people, is not always obvious to others.   It is certainly OK to send
one last call which asks several questions (may be harder to decide what
the consensus actually is if there's any contention, but that's an
operational issue).   In some cases it may even be possible to infer what
the consensus mush have been without explicitly mentioning an issue
(eg: last calls rarely mention that an RFC number will be issued by the
RFC editor - but I think it is pretty safe to assume that everyone knows
that if a document is published it will need an RFC number allocated to
it...   Similarly, documents that call for IANA assignments will, if
agreed to, require the IANA to actually make the necessary assignments).

But caution is needed here.   Jumping from "There is clear consensus for
X" to "There must be consensus for Y then" because "to do X we must do Y"
can be very dangerous, because the "to do X we must do Y" is very often
just an opinion - sometimes a very strongly held opinion, and in some
cases people think of it as "so obvious to not need discussion", but that
doesn't mean that there won't be other options - but they'll only appear
if requested.  So except in cases where it can really be shown that the
requirement for Y is fundamental for X (X cannot conceivably be done in
any other way, and no-one could reasonably suggest an alternative), err
on the side of caution, and send a last call to obtain opinions.

  | (for instance when the decision is just paperwork following up on 
  | another IETF consensus decision), I wouldn't even say that a Last Call is 
  | always required.

I would.   That's the definition (IMO) of IETF consensus.  However, I'm not
saying that there needs to be a separate last call for every individual
decision that is to be made (of those which require IETF consensus).

  | But it's certainly one tool, and a fairly powerful one, for getting 
  | objections out in public.

Do we have any other?

  | (now, does the recent DJB discussion of axfr-clarify by itself invalidate 
  | WG or IETF consensus? I think not.... but it's certainly input that has to 
  | be considered when determining the IETF consensus.)

I'm not sure on the relevance of this.   This looks to be more pertinent to
what it takes to determine whether IETF consensus actually exists.   No-one
would have considered making any decision on axfr-clarify without a last call
(or at least, not a decision to publish it on the standards track).

Once the last call has been issued, and people have had a chance to reply,
then someone (the IESG currently) has to determine whether there actually
is some kind of "rough consensus" or not from reading all of the responses.
I'm not claiming that's easy... but I don't think it is at all relevant
to the issue of whether or not a last call should be issued before the
decision on whether IETF consensus exists or not is taken.

kre