Re: dane-openpgp 2nd LC resolution
John C Klensin <john-ietf@jck.com> Sat, 19 March 2016 14:26 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A012D5C9; Sat, 19 Mar 2016 07:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 XTr1T4daoQUx; Sat, 19 Mar 2016 07:26:31 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 E710512D7D6; Sat, 19 Mar 2016 07:26:30 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ahHpl-0000u7-BM; Sat, 19 Mar 2016 10:26:29 -0400
Date: Sat, 19 Mar 2016 10:26:24 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: dane-openpgp 2nd LC resolution
Message-ID: <7B35165CF1E545B14FE01F7F@JcK-HP8200.jck.com>
In-Reply-To: <56ED45A8.7060304@cs.tcd.ie>
References: <56DC484F.7010607@cs.tcd.ie> <3470AB158222ED0ECAF2CAEA@JcK-HP8200.jck.com> <56ED45A8.7060304@cs.tcd.ie>
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: <http://mailarchive.ietf.org/arch/msg/ietf/mK5j8msPIHqSuklVkJjHZNTwQqU>
Cc: IETF-Discussion <ietf@ietf.org>, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Mar 2016 14:26:33 -0000
--On Saturday, March 19, 2016 12:27 +0000 Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hi John, > > Slow response, but as I said offlist, I wanted to let it sit > for a few more days to see if anything new developed. (And > then I got busy and let it sit even more days;-) But I don't > think anything new has developed to change where we're at. > > The TL;DR here is that I continue to conclude we should > go ahead with this experiment and have put this into IESG > review and on the IESG telechat agenda for April 21st. > > That leaves plenty of time for folks to comment and/or > appeal if there's more to be said that hasn't already been > said, and we have IETF95 in the meantime as well so interested > folks who're there will also have that chance to discuss. > > On the topic of possible appeals which you mention way down > at the end, I think appealing my decision here or whatever > decision the IESG may reach is just fine - having the > possibility to appeal is an important part of our process - > and I'll be happy to try to help anyone who wants to appeal to > craft text if that's useful. Responses to your specific points > are below. Stephen, In the interest of being constructive and focused, let me suggest the following (more to those who have been participating in this discussion than to you in particular). First, at least between now and 21 April, let's try to keep discussions (at least on the IETF list) of dane-openpgp issues narrowly focused on what the document, in its current version, actually says or, if other discussions are necessary, very clearly changing subject lines. From my point of view, that excludes discussion of using this for opportunistic encryption with no check on key signatures or other validation (the document appears to say "don't do that" and, if that isn't clear enough to people, the question of clarity should be within scope) or for heuristics or canonicalization to try to guess at equivalencies among email addresses (the document has no provision for doing that). In both cases, the WG apparently decided, however rough the consensus, that it didn't want the spec to do such things at this point, so, if someone believes the spec should be approved and published by the IETF, then introducing those possibilities, or writing a message that assumes they are in the spec or intended by it, is a distraction and source of confusion at best. On the other hand, if someone believes the spec is so seriously defective without those characteristics that it should be returned to the WG, they should say that clearly (I haven't heard it yet). I'm sure you have a different list of topics that should be set aside for a while unless they take the form of "the document should be stopped unless these changes are made" rather than speculation on fanciful alternate documents. From my point of view, you (or, better, the WG Co-Chairs) posting such a summary list would be helpful. If we discover that we can't agree on what the topics are, that should be a helpful discussion. Second, I hope that those who feel strongly about this set of issues will raise it forcefully in Buenos Aires, both in the DANE WG (and I hope the co-Chairs will make allowances for such a discussion, especially to raise points people feel have been dealt with dismissively, if only because failure to do so would be excellent grounds for an appeal) and, as needed, at the plenary that, conveniently, immediately follows. And then we will see what the IESG decides later in April, presumably informed by the above. best, john
- dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution E Taylor
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Treat model (was: Re: dane-openpgp 2nd LC resolut… John C Klensin
- Case distinctions as theoretical exercise (was: R… John C Klensin
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution John Levine
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise Doug Barton
- Re: Threat model Doug Barton
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise John C Klensin
- Re: dane-openpgp 2nd LC resolution John R Levine
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Mark Andrews
- Re: dane-openpgp 2nd LC resolution Warren Kumari
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: Case distinctions as theoretical exercise John Levine
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Hashing local-parts of addresses (was: dane-openp… ned+ietf