Subject: important: updates to LL2, LL3, LL8, other info

From: Erik Guttman <[email-masked]>
Date: Tue, 11 Feb 2003 15:02:00 +0100 (CET)

Folks,

- I revised www.spybeam.org/issues.html so that the current last call
  items are clearly marked (bold)

- Issue LL8 was suggested by Alex Zinin not Alex Conta

- Spurious LL3 text from Thomas Narten (about something else) removed

- Additional text for LL2 was added.  This topic filled discussion in
  Oct-Dec 2002.  I add some representative views to aid newcomers to
  the topic, without making any attempt to cover all sides.

- In the future, all issue actions will also be posted to the list.
  Even though this is more verbose, it is important to get it into
  the archive as this is required by IETF policy.

- I added procedures and conflict resolution text already discussed on
  the mailing list:

  Procedures

    We will attempt to resolve points in an order which makes sense. A
    broader issue may require attention before another issue, so that
    the result of a later decision does not require us to revisit
    decisions.

    A series of one week last calls will be raised to intensely visit
    issues we have been discussing in an ad hoc fashion for many months.
    The result of that discussion as it relates to previous working
    group consensus will be used to determine the fate of the issue.

       * When referring to an issue in the subject line of an email
         message, please include the issue number as 'LL#', like LL12.
         This will ease searching through the mail archive for relevant
         comments.

       * Please state clearly up front if you would like to
          o Accept the issue,
          o Reject it.
          o Agree with the problem statement but not with the text. In
            this case, please say:
            Accept with revised text <include revised text>.

    Please be aware that the document under discussion has gone through
    WG last call and IETF last call several times. The IESG has
    outstanding issues which it would like the WG to resolve. This is
    not an invitation to revisit areas which have received no comments
    in the past. If there is a serious technical flaw which has been
    overlooked in the past - please bring it up. We are not, however,
    accepting bright new ideas or anything which would broaden the scope
    of the protocol.

   Conflict Resolution

    If we have contention, we have five possible avenues - in descending
    order of preference.

    1. There is a clear technical answer. Dissenters are dismissed.

    2. There is no clear technical answer. One group overwhelms the
    other. We go with rough consensus. This is for yes/no questions.

    NOTE: We try to deal with each issue as a yes/no issue first since
    it is much easier to understand this and conclude discussion.

    3. The dissenter posts a competing issue. We choose the group with
    overwhelming support. This is for multiple choice questions.

    4. We have a split we cannot overcome and even make a rough
    consenus call. Can we drop the goal, accomodate or compromise?

    5. We have a split, with no rough consensus possible. We fail.
    Throw up our hands and let a thousand mutant flowers blossom.

As ever - please send comments if any of this is not appropriate.

Erik