Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11

John C Klensin <> Wed, 16 October 2019 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7F44120819; Tue, 15 Oct 2019 19:22:59 -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 1DvfrpmQbnmo; Tue, 15 Oct 2019 19:22:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 741BF120826; Tue, 15 Oct 2019 19:22:57 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1iKYxg-000GTM-7x; Tue, 15 Oct 2019 22:22:52 -0400
Date: Tue, 15 Oct 2019 22:22:47 -0400
From: John C Klensin <>
To: Barry Leiba <>
cc: Joel Halpern Direct <>, Jiankang Yao <>, General Area Review Team <>, "draft-ietf-regext-bundling-registration.all" <>, IETF discussion list <>, regext <>
Message-ID: <C0EC60B9B3E7DE2D113201F4@PSB>
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: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2019 02:23:00 -0000

--On Tuesday, October 15, 2019 14:19 -0400 Barry Leiba
<> wrote:

>> If we do not have agreement on what the meaning is for the
>> relevant terms, then either
>> 1) The document should not be an IETF consensus document
>> (which even Informational publication is)
> Just a point on this: it's not true.
> We have a "consensus" flag in the datatracker, which triggers a
> boilerplate change.  It's always set to "yes" for Standards
> Track or BCP, but for Informational and Experimental it can be
> set either way. If it's set to "no", the boilerplate says that
> the document does not have IETF consensus.  It's possible that
> when we're done with this document it could settle into that.
> It's also possible that we might convince the regext working
> group to stop processing this document and suggest to the
> authors to go to the ISE.  I don't think we're there yet, and
> at the moment the working group has consensus to publish it as
> a working group product


I have to agree with Joel about this and one of his comments in
particular.  Every discussion we've had over the years about
identifying documents differently depending on whether there is
IETF consensus that they are sound technically and every
discussion we've had about better differentiation of IETF Stream
documents from others (including RFC++ nearly a year and a half
ago), has stressed that changes in the wording of boilerplate is
not enough.  It is, IIR, one of the reasons the RFC headers were
changed to reflect the Stream.  

In rare cases, I think it might make sense to publish a document
as "Informational, No IETF consensus" when a WG produced a spec
for which there was general consensus that the spec was sound
technically but the IETF was unsure that it was appropriate for
standards track or saw better options.  But here we have a
document that several people have suggested is not, in its
present form, sound technically.   In that situation, it seems
to me that the document should be sent back to the WG with
instructions to fix the problems and/or decide what else to do
and it should stay there until either the substantive technical
problems are resolved or the WG decides to dispose of the
document in some other way.