Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)

John C Klensin <john-ietf@jck.com> Tue, 09 July 2019 00:39 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF80712004C; Mon, 8 Jul 2019 17:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INoCmVG9HZL6; Mon, 8 Jul 2019 17:39:05 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACC412001E; Mon, 8 Jul 2019 17:39:05 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hke9v-0008zq-5T; Mon, 08 Jul 2019 20:39:03 -0400
Date: Mon, 08 Jul 2019 20:38:57 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: IASA 2 WG <iasa20@ietf.org>, iasa2-chairs@ietf.org, IESG <iesg@ietf.org>, draft-ietf-iasa2-rfc7437bis@ietf.org
Message-ID: <B2AD2AADD838CCA85DCDF3FE@PSB>
In-Reply-To: <7257b4a9-1d7f-ced2-08fb-0a7bf33e1036@gmail.com>
References: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com> <1C131171-0ABE-4DB1-BEB7-03E765B1E6C6@cooperw.in> <CALaySJKHut1EL_eKQ5rhSXFeF6_+EizwcHdhxhieRy3D3dzQwg@mail.gmail.com> <F15F78D3-2257-4F1B-B832-D9C7CC47E512@gmail.com> <CALaySJK+=W6FwMcHJ-nuyZFmvukMN_GUh6qDAWvwHnizyZqy9A@mail.gmail.com> <4710C519-37CC-4586-83E7-02776889370F@gmail.com> <CALaySJ+1q4jrFk9+g=kwk86Lc=GMpFniFWXoNYsidOL6F_uZag@mail.gmail.com> <cc578052-6be1-6a5a-f05f-2bf38d3210dc@gmail.com> <CALaySJ+64zmmbtYy4P+ke9q78MdrKitDCNk=8ErtoD7HzeLY_Q@mail.gmail.com> <CALaySJ+N20pRmd58EZjtaBERGWo=F3S-2yQqRjsgvN9AJO+n9w@mail.gmail.c om> <09C83635-DC7B-47BD-999D-2E6D0BBCA68F@cooperw.in> <CALaySJJsgj0cVu3oWU-=1MVeWooKiRpZ7XRpjhpnQALrmam+Ag@mail.gmail.com> <7257b4a9-1d7f-ced2-08fb-0a7bf33e1036@gmail.com>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/oRtgHACgsalzjAQsOqSWH3o_AeY>
Subject: Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 00:39:08 -0000


--On Tuesday, July 9, 2019 08:56 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

>...
>> OK... then you're saying that in the case that the NomCom has
>> not yet announce the IAB slate, the exception says that they
>> can fill an extra IAB position without advertising that to
>> the community, because there's already a bunch of people who
>> put their names in for IAB positions and there's no reason to
>> think that knowing that there's one more open position will
>> matter.
>> 
>> I get that, and, understanding it, I do agree that that was
>> the intent of that text.
>> 
>> May I suggest, then, the following edit to make it clear?:
>> 
>> OLD
>>    However, the following exception is permitted in the case
>>    where the candidate for an open position is currently a
>>    sitting member of the IAB.
>> 
>> NEW
>>    However, an exception is permitted in the case where the
>>    candidate for an open position is currently a sitting
>>    member of the IAB.  Because there is already a pool of
>>    candidates for a set of IAB positions, the NomCom does not
>>    a need to inform the community explicitly that one more
>>    position is becoming available, so par of the process can
>>    overlap.
>> 
>> END
>> 
>> Tweak as necessary, but does that work?  Alissa, Bob, others,
>> what do you think?
> 
> FWIW I think I finally understood what was bothering Barry and
> I think this tweak does express what the drafters of RFC7437
> thought they were saying. So this would be a confirmed erratum
> on RFC7437, if that was where we were in the process. It's
> above my pay grade to decide whether we should handle it now
> or wait for RFC7437bisbis.
> 
> John Klensin's subsequent message would be a substantive
> change of intent, IMHO. I'm not sure how I feel about it.

Brian,

I'm actually not sure how I feel about it either.  I am,
however, fairly certain it was a scenario that was not actively
discussed when 7437 was being discussed and approved.  However,
the bottom line to me is that either 

* we have general consensus that the sentences in the document
mean what the above (and Barry's suggested revised text) say it
means.  In that case, the clarification is not urgent and can
wait until we get around to doing a comprehensive revision of
7437bis.

or

* we don't have that level of agreement on what the sentence
means, in which case there is no clarification in our
traditional sense but a substantive decision followed by, or
associated with, text to reflect that decision and make it
perfectly clear.  In that case, it is unambiguously out of scope
for IANA2 documents given both the decisions that have been made
by WG Chairs and the AD and rules applied to other documents on
that WG's menu.

If there is a lesson from this for the future, it is that there
are distinct downsides to telling a WG that it is expected to
produce documents that replace older ones but are not allowed to
fix known errors or other difficulties with those earlier ones.
I'm not suggesting we should never do it, but  For technical
specifications, at least as I read 2026, such a replacement with
a "we didn't look at anything else" disclaimer is actually not
permitted because of the "known omissions" language.  Such a
document would be ok if it enumerated the issues that were not
addressed and the IESG explicitly signed off on that list. 

That would presumably not be an issue for a BCP that was
actually a description of current, established, best practices.
For wishful thinking that we'd like to be the best practices and
for IETF procedures... well, in might be the 2026 is in need of
clarification and revision, not just 7437/7437bis.

   john