A Property Types Registry for the Authentication-Results Header Field
draft-ietf-appsawg-authres-ptypes-registry-04

[Ballot comment]
I'm curious to see the response to Stephen's question, if that's possible, it may be a good way to handle security issues that may arise with new ptypes.

[Ballot comment]

I wondered if it'd be worthwhile asking that the
designated expert try ensure that the security and privacy
consequences of new entries also be documented?  That's
assuming there are cases where the header field is likely
to transit between ADMDs. I'm not sure if that's really
needed though, but 7001 does have a fairly significant set
of security considerations, so presumably new entries
might also deserve a similar level of documentation. OTOH,
I could buy that experience with 7001 means that this
isn't really needed or that demanding that level of
documentation might be counterproductive.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-authres-ptypes-registry-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has questions about the action requested in the IANA Considerations section of this document.

Upon approval of this document, IANA understands that there is a single action which needs to be completed.

A new registry is to be created called the Email Authentication Property Types registry.

IANA Question --> Should this be a new sub-registry of the existing Email Authentication
Parameters located at:

http://www.iana.org/assignments/email-auth?

The new registry will be named the Email Authentication Property Types registry and will be located at [ TBD-see-above ]. The registry is maintained through Expert Review as defined by RFC 5226.

IANA Question --> IANA understands that initial reqistrations are to be made based on information in Section 2 of [ RFC 7001 ]. The Augmented Backus-Naur Form of the header field specifies ptype with the following possible options: "smtp" "header" "body" and "policy"

Is the initial registry supposed, then, to look as follows?

ptype | Description  |  Reference
---------+--------------------------------------------+-------------------
smtp |      ???            | [ RFC 7001 ]
header  |      ???            | [ RFC 7001 ]
body  |      ???            | [ RFC 7001 ]
policy  |      ???            | [ RFC 7001 }

If so, what are the "descriptions" to be used for each of the ptypes. If not, what should the initial registry look like?

QUESTION: Those new requested "ptypes" are actually mixed  between multiple header fields
RFC7001 in section 2.2.  For clarity purposes, can the author please describe the new "ptype"
values in the IC section of this draft?

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Property Types Registry for the Authentication-Results Header Field) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'A Property Types Registry for the Authentication-Results Header Field'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates RFC7001 by creating a registry for property
  types in the Authentication-Results header field, used in email
  authentication work, rather than limiting participants to using the
  original, small set of fixed values.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-authres-ptypes-registry/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Scott Kitterman.  The Responsible Area Director is Barry Leiba.

RFC7001 defines the email Authentication-Results header field that presents the results
of an authentication effort in a machine-readable format.  The specification in that
document enumerated a small set of types of  properties that can be reported using this
mechanism.  That constrained set of types has proven to be too narrow.  Accordingly, this
document updates the specification to allow for additional property types ("ptypes")
beyond the original set, and creates a registry where new ones can be listed and their
defining documents referenced.

As an update to RFC 7001, this document is appropriately placed on the standards track.

2. Review and Consensus

This is a simple document and WGLC was quiet (no comments).  There was significant
discussion prior to WGLC with reviews and comments from three different reviewers.
The only significant technical issue that was discussed was the possibility that the version
number of the field might need to be increased.  The unanimous conclusion was that it
does not.

This draft is a precursor to draft-martin-authentication-results-tls.

Once this document relaxes the ptype constraint, other authentication types such as TLS
(mentioned above) are expected.  Multiple participants reported plans to implement these.

3. Intellectual Property

No IPR disclosures have been submitted and the author has indicated he is not aware of
any other IPR issues.

4. Other Points

The IANA considerations appear clear and complete.

This document creates an Email Authentication Property Types registry.  The standard for
update is expert review.