Re: NomCom eligibility & IETF 107

John C Klensin <> Tue, 07 April 2020 22:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C1AD3A095D for <>; Tue, 7 Apr 2020 15:10:22 -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 A2LTPlQ5xUrc for <>; Tue, 7 Apr 2020 15:10:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA5DA3A0955 for <>; Tue, 7 Apr 2020 15:10:17 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jLwQA-0004Yn-F2; Tue, 07 Apr 2020 18:10:14 -0400
Date: Tue, 07 Apr 2020 18:10:08 -0400
From: John C Klensin <>
To: Barry Leiba <>, Bob Hinden <>
cc: IETF <>
Subject: Re: NomCom eligibility & IETF 107
Message-ID: <9CC3084E16DEBB3233FAC1E1@PSB>
In-Reply-To: <>
References: <> < om> <> <> <> <> <20200331184236.GT18021@localhost> <> < om> <> <> <>
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: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Apr 2020 22:10:22 -0000

--On Thursday, April 2, 2020 13:15 -0400 Barry Leiba
<> wrote:

>> I read the draft and I support it.
> Thanks, Bob.
>> One nit:  Should it say that it updates BCP10?
> I think it should not, but should be its own BCP.
> We need a broader effort to update BCP 10, but this is a
> one-time exception.  Publishing it as a BCP is a process
> formality, but sets no precedent and won't apply after this
> year's NomCom is seated.  I think it would be wrong for it to
> formally update BCP 10.


lLet me try an alternate theory out on you.  First, however
temporarily, this is a clarifying update to RFC 8713.
Regardless of what decisions are made about BCP numbers, that
update should be noted in the draft to make the thread clear and
so, at least during the several months (or perhaps close to a
year if there is a recall effort) in which this procedure is
active and relevant, any effort to look up the topics covered by
8713 provides a clear path to this specification.  I think,
given that, treating it as part of BCP 10 follows, but I don't
think it makes a lot of difference as long as the "updates"
thread is clear.

I don't think the "updates" relationship can be avoided.  When
the first sentence in Section 3 of the I-D says:

	The following text modifies, for the 2020-2021 NomCom
	selection only, the first two paragraphs (quoted above)
	of Section 4.14 of BCP 10 [RFC8713]:

That is about as clear a candidate for "updating" (in this case
8713) as I've seen in some time.

I do recognize what I think is your concern about BCP 10, but it
seems to me that is easily handled: when the more permanent fix
(the "[an]other update to BCP 10 [that] will be necessary..."
comes along, it formally obsoletes this temporary document,
making clear that the emergency interpretation no longer applies
and specifying what does.  Move it to Historic too, if that
seems sensible.   And, if having a dead document as part of BCP
10 bothers people. remove it at that time.

Just a thought...