Re: To "lose the argument in the WG"

[Dave Crocker <[e-mail]>]

On 2/14/2017 7:12 AM, Ted Lemon wrote:
> Er, no.  The most important point of last call is to make sure that people who did not have time to participate in the last call in the working group, but who have relevant knowledge, get a chance to weigh in.


Unfortunately:

    Last Call Guidance to the Community
    https://www.ietf.org/iesg/statement/last-call-guidance.html

does not provide useful guidance about the purpose and substance of 
doing an IETF Last Call.

The IETF's formal process document on standards:

    The Internet Standards Process -- Revision 3
    https://www.ietf.org/rfc/rfc2026.txt

says nothing about Last Call.

So the formal IETF specification for the role of Last Call is in:

      IETF Working Group Guidelines and Procedures
      https://tools.ietf.org/html/rfc2418

>    This Last Call will announce the intention of
>    the IESG to consider the document, and it will solicit final comments
>    from the IETF within a period of two weeks.  It is important to note
>    that a Last-Call is intended as a brief, final check with the
>    Internet community, to make sure that no important concerns have been
>    missed or misunderstood. The Last-Call should not serve as a more
>    general, in-depth review.

(I should note that that text dates back to the original version of the 
document that Erik Huizer and I wrote, in RFC 1871, in 1994.)


What folks are doing is spontaneously changing the role of this step, 
ignoring the considerable costs and detriments, while relying on a 
theory of benefit that is very, very, very rarely actually demonstrated.

To Ted's point, indulging folk who 'did not have time' to participate 
earlier is frankly abusive of all those who did.

RFC 2416 (and the original, RFC 1871) has explicit text about revisiting 
a topic:

>    It is occasionally appropriate to revisit a topic, to re-evaluate
>    alternatives or to improve the group's understanding of a relevant
>    decision.  However, unnecessary repeated discussions on issues can be
>    avoided if the Chair makes sure that the main arguments in the
>    discussion (and the outcome) are summarized and archived after a
>    discussion has come to conclusion. It is also good practice to note
>    important decisions/consensus reached by email in the minutes of the
>    next 'live' session, and to summarize briefly the decision-making
>    history in the final documents the WG produces.
>
>    To facilitate making forward progress, a Working Group Chair may wish
>    to decide to reject or defer the input from a member, based upon the
>    following criteria:
>
>    Old
>    The input pertains to a topic that already has been resolved and is
>    redundant with information previously available;
>
>    Minor
>    The input is new and pertains to a topic that has already been
>    resolved, but it is felt to be of minor import to the existing
>    decision;
>
>    Timing
>    The input pertains to a topic that the working group has not yet
>    opened for discussion; or
>
>    Scope
>    The input is outside of the scope of the working group charter.



d/

ps. RFC
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net