Thanks. On initial read, these all seem like fair points [1], and I'll
incorporate the ones that bear on the specific proposal I'm making in
the next version of the document.
/a
____
[1] I may have reason to quibble with one or two of the conclusions, but
they don't bear on the contents of the document, so I don't think
engaging on them would be useful for either of us at the moment. Maybe
later.
On 5/9/19 10:48 AM, John C Klensin wrote:
Adam,
Rather than quoting specific other responses but having read
them, a few general comments...
Some of the issues addressed in the document and in assorted
comments, including the type of first-time updates/replacements
for a base document that your draft appears to focus on, the
question of how to update or replace a document that has already
been updated by other RFCs, the related question of how to
address such document collections (sometimes known as "what is
really the standard for...?) when documents are not at full
standard, the slightly-related questions of the status of a
replacement for a document that already is at full standard,
are all issues that seem worth addressing, some of which are,
IMO, demonstrably seriously overdue for some review and action
(see below).
I appreciate your trying to make this change with an I-D and BCP
target rather than an IETF Proclamation^H^H^H^H^H^H^H^H^H^H^H
Statement. On the other hand, as another aspect of the issue
SM, Stephen, and others have addressed, I question whether it is
appropriate to use this document to specify how the IESG should
vote or count votes. If that is legitimate procedurally, then
it is legitimate for the community to develop an I-D, bottom-up,
that specifies IESG voting behavior and expect the IESG to
process it. The IESG has, in the past, sent clear signals that
such a specification would not be welcome. Assuming the lack
of enthusiasm for the community micromanaging the rule and
procedures by which the IESG makes decisions has not changed,
either take that instruction out, turn it into a general
expression of hope that both IETF Last Call and IESG review will
focus on the changes rather than other issues, or be careful
what you wish for. Similar comments apply to a few of the
bullet items in Section 3.2.
There are also several issues associated with Section 3.1 (3)
("Except as detailed in verified errata...") that I don't
believe that others have addressed. First, where "verified" or
not, errata have not gone through IETF Last Call and don't
represent community consensus, only an assertion (for IETF
Stream documents) by the authors and and AD or the IESG that
they look right. There is also considerable history of
classifying an erratum as "hold for future update" when if it
clear that there was an error (as with "verified") but no one
wants to cope with sorting out the right text to fix it.
Because the latter are not part of the exception, the procedure
specified encourages having a replacement document go through
that includes text known to be erroneous. And because
"verified" doesn't mean "community consensus when the erratum
was submitted", much less "community consensus when the proposed
replacement document goes into Last Call, discouraging comments
that do not address the changes that were the purpose of the
document seems unwise, even if the careful evaluation at the end
of Section 3.1 is performed.
Section 3.3 interacts with the traditional role of Applicability
Statements. In order to avoid further confusion (or further
accidental deprecation of Applicability Statements), that
interaction should be called out and discussed.
More broadly, while it was long before your time on the IESG
(and, I believe, before the time on the IESG of any current AD),
some of the issues mentioned above and the associated underlying
problems were addressed several years ago by a WG, called
NEWTRK, whose recommendations and drafts (which were, in the
WG's opinion, ready for IETF Last Call) took a rather different
and more comprehensive approach to the problem your I-D
identifies and addressed the issues of errata, updated documents
as well as replaced ones, and a complex of documents making up
the specification for a standard or practice as well. While the
IESG at the time declined to initiate an IETF Last Call on those
documents, it seems to me that, if some of the same problems are
going to be addressed, the community should have the opportunity
for consider whether the approach in this I-D or the more
comprehensive NEWTRK approach will better meet its needs.
Applying what I understand to have been the IESG's reasoning
about draft-moonesamy-recall-rev, I look forward to a BOF
proposal, an in-depth discussion of scope that includes the
NEWTRK approach as well as this one, a mailing list separate
from the IETF discussion one (or I suppose we could use the
NEWTRK one), and a WG.
best,
john
