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