Telechat Review of draft-ietf-dane-openpgpkey-10
review-ietf-dane-openpgpkey-10-genart-telechat-miller-2016-04-21-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dane-openpgpkey-10
Reviewer: Matthew A. Miller
Review Date: 2016-04-20
IETF LC End Date: 2016-04-22
IESG Telechat date: 2016-04-21

Summary:

This draft is basically ready for publication as an Experimental
RFC, but has nits that should be addressed before publication.


While I do wonder if Section 4. "Email address variants and
internationalization considerations" are too simplistic, I also
think it's enough to start the experiment.  It very well could prove
to be necessary to allow for some amount of canonicalization by the
sending MUA/MTA, but I think it's worth doing that after gathering
experimental results.


Major issues:

NONE

Minor issues:

NONE (really)

Nits/editorial comments:

- the authors do not seem to subscribe to the use of Oxford commas,
while the RFC Editor does, if I recall correctly.

-  In Section 1. "Introduction", there is an instance of "MUAs" that
is inconsistent with "MUA's" as it is used elsewhere in this document.
I do wonder why MTAs and MUAs are so possessive.

-  In Section 1. "Introduction", a period missing at the end of:

    "The OPENPGPKEY data is secured using Secure DNS [RFC4035]"

-  In Section 2.1.1. "The OPENPGPKEY RDATA content", the second
paragraph text "a relevant subkey should be included" ought to be "at
least one relevant subkey should be included", to be consistent with
the outline immediately proceeding the text.

-  In Section 4. "Email address variants and internationalization
considerations", the second paragraph says:

    "MUA's and MTA's supporting OPENPGPKEY therefore MUST NOT perform
    any kind of mapping rules based on the email address."

To me, this somewhat conflicts with the preceding sentence; I assume MTA
here is the sending MTA, or is only in the context of finding an
appropriate key.  I think some clarification is worth adding.

- In Section 5.1. "Obtaining an OpenPGP key for a specific email address",
There is a period missing at the end of the last sentence.

- In Section 7.2. "MUA behaviour", the phrase "encrypting to public key"
ought to be "encrypting to a public key".

- In Section 7.4. "Email address information leak", in the phrase:

    "Publishing OPENPGPKEY records however, will create a list"

The word "however" (and proceeding comma) seems superfluous, and can be
omitted.

- Although all in the acknowledgements, it seems worthwhile to me to
add [RFC4255], [draft-ietf-dane-smime], and [draft-levine-dns-mailbox]
as Informative References.


--
- m&m

Matt Miller
Cisco Systems, Inc.



Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail