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

John C Klensin <> Thu, 22 August 2019 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66862120C1C; Thu, 22 Aug 2019 13:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nS3HhXUi5XjT; Thu, 22 Aug 2019 13:18:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 613EF12011B; Thu, 22 Aug 2019 13:18:29 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1i0tXO-0001nQ-6I; Thu, 22 Aug 2019 16:18:26 -0400
Date: Thu, 22 Aug 2019 16:18:20 -0400
From: John C Klensin <>
To:, 'Barry Leiba' <>, 'The IESG' <>
Message-ID: <E33D9078696D60B2AD9F0590@PSB>
In-Reply-To: <003c01d558c8$518e4740$f4aad5c0$>
References: <> <003c01d558c8$518e4740$f4aad5c0$>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Iasa20] Barry Leiba's Yes on draft-ietf-iasa2-rfc7776bis-02: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Aug 2019 20:18:32 -0000

--On Thursday, August 22, 2019 10:02 +0100 Adrian Farrel
<> 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.