Re: dane-openpgp 2nd LC resolution

[John C Klensin <[e-mail]>]

--On Saturday, March 19, 2016 12:27 +0000 Stephen Farrell
<[e-mail]> 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