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

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 25 January 2020 17:59 UTC

Return-Path: <adrian@olddog.co.uk>
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 A7B9F120052 for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 09:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 4ZZJKbKK-w1t for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 09:59:37 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D28120048 for <last-call@ietf.org>; Sat, 25 Jan 2020 09:59:36 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00PHxX0i028225; Sat, 25 Jan 2020 17:59:33 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2375622044; Sat, 25 Jan 2020 17:59:33 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 0E4FC22042; Sat, 25 Jan 2020 17:59:33 +0000 (GMT)
Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00PHxVCS022604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Jan 2020 17:59:32 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Russ Housley' <housley@vigilsec.com>, last-call@ietf.org
Cc: 'Eric Rescorla' <ekr@rtfm.com>, 'Joel Halpern' <jmh@joelhalpern.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>
In-Reply-To: <74CB9B39-6D18-45CA-AAF7-96D4748C6646@vigilsec.com>
Date: Sat, 25 Jan 2020 17:59:30 -0000
Organization: Old Dog Consulting
Message-ID: <001e01d5d3a9$31fdfb80$95f9f280$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01D5D3A9.31FDFB80"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHy83dhZyFIcRxMiEAvWEPLdbpOOAJq0onqAeJF+jgCmlZmlgIq+R5wAa0erKECM6rYzwH/aIw6AV62JNYBQoqVAgLHGqq8px6RlOA=
Content-Language: en-gb
X-Originating-IP: 89.144.205.18
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25190.001
X-TM-AS-Result: No--35.463-10.0-31-10
X-imss-scan-details: No--35.463-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25190.001
X-TMASE-Result: 10--35.463200-10.000000
X-TMASE-MatchedRID: hwsFDxVJcFkzx9GDMr0HvzYTypjB3iDVuikHZcC6ceAlfitSyR4HIarY HzlIO/hdrT7fVziRzffoDamt1wGtCWBt4CaODzdDmOexU8E0y9GPSNdj1JMyAbdq40ujPlTZWOC arNYIZzfkErk3iQsGhT43ftRAH8vTLlr9+fl8Sh1uyDGIvvwW0iFceJVsZ+5j+S5C/08hWc1uEW auQb36M4aJYV4HPSu4Cd8Pd4Ejpo8PosntR6W6QZzEQqkMw+XnZ3TNrjZMua0ZSz1vvG+0mkfny 52zS9mSGtatud/+JwXCZwuQH/lZCfr7uaNX5h+5AjoaSw0EjFViGhXZaW6RJcxWo/NgqhfZKHrw 2R3zuRhDHIIipCtUzf0lefF3goszEEb1RF7UxjFYe2qRI33Kw6kM1LFyTS7hJsBO7ID7TfauBGQ 0NzLWHClxu/7TK0Qp/Byc/04iPnhHW+94FA8JF8K1Ib9JAALxrogFtKd/P7cLBZEuqIL9SpO9mQ Gx4jC3Sa7i4WMGYwF/2SsgU8jyNW7vEKjEI8LygNylVbI/EAyoCf7IdvPAJzAx/HIgP92dNEZZm AO2JUg/+RSNQ9LGXlDQ43dkW3a5LDC3FGTHI3eL6bUMM+bbIvJKfaMQf91ll32P5ZifvYZXfrX3 lielrsu5Qm3cullRmf7xoRlVTANjBcCC3w+2ICTc3NdTt+Z6Jd2n2XoSRFkOFxRlsKOuiHlEDb1 OO87ou7C4hieFwVKAMuqetGVettLvsKjhs0lda9+JVKonO7ekMChxbYOI3hcwnHgDaR+HIAcCik R3vq+zgN+S4Au9waa/T2h0jNTTBSIlckj4LagEtMI19GkkhgXP9mup0kOd
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/TzMC9loUqocoDOxKwY9QcwzzMso>
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 17:59:40 -0000

Hi Russ,

 

I believe you are misreading what the IESG statement says.

 

The first paragraph of Section 4 refers to “AD Sponsored documents to Standards Track” and to “AD Sponsored documents to Experimental/Informational”. It does not mention documents coming out of a working group.

 

It was a fine IESG statement (if a bit lengthy 😊) but seems designed to cover AD sponsored documents only.

 

For almost as long as I can recall, the IESG has applied a policy of always holding an IETF last call on every document. That seems to be an IESG prerogative, but I don’t see it written down anywhere.

 

It is, of course, possible for the IESG to issue a further statement on this. I believe Joel’s point may be that what the IESG giveth, the IESG may take away: but if the community likes the idea of a last call on all documents then putting it into the process of record would be the right thing.

 

I think Joel makes one other point which may be splitting hairs, or might be paranoid, but does no harm to fix. Holding an IETF last call, is not the same as not publishing a document until there is rough consensus.

 

Cheers,

Adrian

 

From: last-call <last-call-bounces@ietf.org> On Behalf Of Russ Housley
Sent: 25 January 2020 15:28
To: last-call@ietf.org
Cc: Eric Rescorla <ekr@rtfm.com>; Joel Halpern <jmh@joelhalpern.com>
Subject: Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice

 

Joel and EKR:

 

 this document deliberately addresses a very narrow issue that while admittedly rare has come up a few times.

 

In 2007, the IESG published this statement: https://ietf.org/about/groups/iesg/statements/area-director-sponsoring-documents/

 

In this statement, the IESG says that it will not approve any document without an IETF Last Call.  See the first paragraph of Section 4.

 

I suggest a better way forward would be to post an updated IESG statement that requires consensus as well.

 

Russ

v2.23.0 | Report a Bug | By Email