IETF Logo Mail Archive

Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 25 January 2020 19:59 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4312007C for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 11:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Buu9ms5VUQNp for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 11:59:42 -0800 (PST)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838F112001E for <last-call@ietf.org>; Sat, 25 Jan 2020 11:59:42 -0800 (PST)
Received: by mail-pl1-x62c.google.com with SMTP id p12so1791878plr.7 for <last-call@ietf.org>; Sat, 25 Jan 2020 11:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MnLK4BZn2psnFAfZpQap0jhIYtWIj0s56OQUDViozPU=; b=Nme7XsrW6hvzv8OMkCnz5We1X/hE7mYk1lH4jsZlYllqfVHq+0mU9IyCpeP6u/IL80 RsJb6TMhwvnXr/JzChDpR6I+CnYc5qTziV4UE/EW6aT69gZZ+kC2JN+Q8niYnLjBG/w1 eLPPGpYW8xtksXH1hpWPJZdvxAtXf15WUiU6ChRxyLjsmfD1Rr7UOcq9d0RYs7zndQrQ DqarxxYvpRJVjOHHPNk8JowugFBdvTFJ8/RjdhpIJWDRMG7YYFWf1l7Ck7gczj1FP67U 21ZlkY0WVwNaDqicTWwOq+JNRpSP8oYxLmrxxoRA7m/RWkc89EQkIgAs0ZeYrtW5j9FA c+pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MnLK4BZn2psnFAfZpQap0jhIYtWIj0s56OQUDViozPU=; b=GopX58MdoF0mOz6FO7bV1QQZBKaViUhdOE/EcmzVQHLVCkLUMibXU0PXrN6S2yH0bp O3Y6Dryj2idnvv+z3/EuOk2gY7w8u4r8moVlsLyR9vcy5HInhrmSzNZ9AKa/4qFRpP3z NM1IEvqx17ox0YHPJpd8CdS5Mo+Uh1FFiD3XywDj7vM0UnqmkX4ACouLq/k/jQEbZVwU E1AJPTcX72LFJgX1rp8K5X9uoyf86nEYscD7VoSk/0To2zJbigT42uKjGsITI9oez8Nl BXYzpw0A+svrO8wEjTnixweSIhTm+59wlQej0/5yfLcFn7BwrmOD1FnCnaJ8I3I9lwZ6 Z2+g==
X-Gm-Message-State: APjAAAXuQiFRvAbxdLoac9jeaF9MU5YrkXTo1bG5LEd7KVE6zlwyTl6I 1gcUNzlonvo0x+S8VR7bDNI=
X-Google-Smtp-Source: APXvYqyBIVnjxHB2FWX1liS6xToro/Q12Ytt5+DQ0Wx2iupiF3LnDRoN3jD1F1Fa2oxOiC0vCPwrvg==
X-Received: by 2002:a17:90a:dc86:: with SMTP id j6mr3423188pjv.33.1579982381929; Sat, 25 Jan 2020 11:59:41 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id b185sm10864262pfa.102.2020.01.25.11.59.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jan 2020 11:59:41 -0800 (PST)
To: Russ Housley <housley@vigilsec.com>, Joel Halpern <jmh@joelhalpern.com>
Cc: last-call@ietf.org, Eric Rescorla <ekr@rtfm.com>
References: <CAChr6Sy5-ejdjw5zgZgiF1hSyuiAErmas-dbWFmx1b+1vftT1Q@mail.gmail.com> <CABcZeBOMVYpEYaEUzYsa0ApDfGtA6oD5P67A40=HQVBN+yTuKQ@mail.gmail.com> <CAChr6Sz7vihWaoeG8H11JzQ5YqrbYLPLneuY3PD4syMYEaKQ4w@mail.gmail.com> <99d34ee9-8ea6-a77f-39fc-f1889a050358@joelhalpern.com> <CAChr6SwHd2=Qf2SSbQeKs1CS_c1UuBqPEtO_x4MmF71iv0zE9Q@mail.gmail.com> <CABcZeBMdonehuZ3re4UnGY2_B6A2sOBqkoE+m4SfBa8N3vYEhg@mail.gmail.com> <CAChr6Sw1LSXj=L2WAu=R1QfBi4UFDXC5Z6EODqwJ6-z9o5Z5vw@mail.gmail.com> <CABcZeBPBhGZDxnh2p=trL8yHveBiMsy38+-G_7oQu_eR+45d5w@mail.gmail.com> <CAChr6SyNTsz9uZNiN16OHLj6e=Xhcn1A8pr105Of+y_Jw8HSFw@mail.gmail.com> <994c4462-ef24-6d46-3bec-8aa5e14b9f78@joelhalpern.com> <74CB9B39-6D18-45CA-AAF7-96D4748C6646@vigilsec.com> <7f253bfc-1e18-1a3d-4d43-d464b50ad8b8@joelhalpern.com> <D0512C70-CBD5-4C76-B98C-3A7FCA8F888C@vigilsec.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ef1ec6bc-1970-5a2e-97c3-5264bd04387e@gmail.com>
Date: Sun, 26 Jan 2020 08:59:38 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <D0512C70-CBD5-4C76-B98C-3A7FCA8F888C@vigilsec.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/fbfqcXzrfZDebp41v3iONE0ilBc>
Subject: Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2020 19:59:44 -0000

Russ,

On 26-Jan-20 06:26, Russ Housley wrote:
> Joel:
> 
> It seems to me that you would need to pot other things that are in this IESG statement into the BCP that updates RFC 2026.  You are really building on top of the procedure that are required by the existing IESG statement.  For example, RFC 2026 does not require an IETF Last Call for an informational or experimental document at all.

More pedantically, BCP 9 does not require an IETF Last Call for an informational or experimental document at all. When this draft is approved, BCP 9 will do so, because that's how we determine IETF rough consensus. That is rock solid, whereas an IESG statement can always be reversed.

I agree that we will still depend on the IESG's assessment of IETF rough consensus, but there is no way round that.

(BCP 9 is irrelevant for non-IETF documents, since it defines IETF process.)

     Brian

v2.23.0 | Report a Bug | By Email