Subject: [Iasa20] Barry Leiba's Yes on draft-ietf-iasa2-rfc7776bis-02: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 21 Aug 2019 20:33:43 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-iasa2-rfc7776bis-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7776bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have to say that I find the changes to the metadata stuff to be odd and
confusing, and would have preferred that 7776bis completely replace 7776
instead of trying to update it.  No action nor response needed here... just
wishing it had been handled differently.

 Typo: “contained updated” should be “contained updates” in both the Abstract
 and Introduction.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Aug 2019 10:02:24 +0100

Thanks Barry,

> I have to say that I find the changes to the metadata stuff to be
> odd and confusing, and would have preferred that 7776bis
> completely replace 7776 instead of trying to update it.  No action
> nor response needed here... just wishing it had been handled
> differently.

Yeah. Fear of re-opening documents overwhelms our ability to do the right thing 😊

> Typo: “contained updated” should be “contained updates” in both
> the Abstract and Introduction.

Damn my fingers!

Best,
Adrian

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Aug 2019 16:18:20 -0400

--On Thursday, August 22, 2019 10:02 +0100 Adrian Farrel
<[email-masked]> wrote:

>> I have to say that I find the changes to the metadata stuff
>> to be odd and confusing, and would have preferred that 7776bis
>> completely replace 7776 instead of trying to update it.  No
>> action nor response needed here... just wishing it had been
>> handled differently.
> 
> Yeah. Fear of re-opening documents overwhelms our ability to
> do the right thing ?

As someone who often argues for replacement but who strongly
argued for updates in tie IASA2 case, I want to object to
sweeping generalizations like the one above.  IASA2 is a
particularly interesting example.   Independent of the various
reasons that motivated the transition to the IETF LLC, the
changes were presented to the community as not having any impact
of how the IETF did its day to day business.  Indeed, the WG was
specifically prohibited from making any changes to the standards
process.   So, given that IASA2 was charged with making only
those document changes necessary to reflect the administrative
and terminology changes associated with the IASA-> IASA2
transition, then I suggest that The Right Thing is to patch and
update, and not replace, documents.

If a document needs more than patching or if the patches are
very complicated and hard to understand, it almost certainly
indicates basic flaws in the base document.  However, that
implies we need a comprehensive replacement  Such a replacement
that is outside the scope of the WG, a scope that has been
reinforced by AD rulings that even minor corrections (including
application of errata) are out of the WG's scope.   A
replacement document that would apply the patches but exclude a
number of other known outstanding issues would be a potential
source of even more confusion, especially if it did not
enumerate those issues in, e.g., an appendix (probably even
reaching consensus about that those issues were would also be
out of scope for the IASA2 WG).

One thing makes 7776bis more complicated that it would otherwise
be -- the interconnection with the changes 7776 made to 7437.
If one took a narrow procedural view of IASA2's charter (I
contend not much narrower than have been taken in other cases),
7437bis should be published (and numbered) before 7776bis, it
should apply the needed changes (which it does), it should
update 7776 (which it does not do), and 7776bis should not need
to address this issue at all.  The approach this is taken here
should actually require that 7776bis formally update 7437bis
because the latter references (normatively) 7776 for important
information.  If this document were to replace 7776 rather than
updating it, that would be necessary.

There is another problem with replacement documents coming out
of a WG whose charter is very narrow, much narrower than those
documents and 7776bis is a good example.  We know, from the
discussions leading to RFC 7776, that a large portion of the
community is very interested in harassment and related issues
and how the IETF intends to deal with them.   Perhaps because
the IETF has been told that IASA2 was addressing administrative
and terminology changes and nothing more fundamental, the number
of people who commented on this (or any other IASA2) document in
that WG was far smaller than those who were involved in the
development of 7776.  In a more perfect world, I'd claim that,
if an earlier document is approved by consensus over a broad
range of people and perspectives, we should not be approving
revisions to that document if the consensus only involves a much
smaller and more narrowly-focused group of people than those who
approved and commented on the base document.   It would be
implausible for us to adopt such a rule and probably impossible
to design criteria to get it right.  But we should still use
caution and either scope WGs narrowly and hold them too it or be
sure that the community knows (especially when Last Calls are
announced) there is a risk of unintentional side effects without
sufficient review.   And, for those reasons and for a case like
7776bis, I think The Right Thing is very much an update document
rather than a replacement.

best,
   john