Re: To "lose the argument in the WG"

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

 



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




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