Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00

[Alessandro Vesely <[e-mail]>]

On Fri 03/May/2013 23:26:14 +0200 S Moonesamy wrote:
> 
> This message initiates a two weeks WGLC on
> draft-ietf-appsawg-rfc5451bis-00 ("Message Header Field for Indicating
> Message Authentication Status") [1].  Please send your comments to the
> mailing list before the end of Friday May 17.  Comments saying that
> you reviewed the draft and you are happy for it to be sent for IETF
> Last Call are also valuable.

Some comments:

The -00 version still says "Individual submission".  Shouldn't that be
changed to Network Working Group or some such?


1.3. *Processing Scope*

The sentence "It is not meant to address the security of [...]" seems
to refer to the addition of the field only, not its use by a consumer.
 For clarity, I'd s/It/The addition of this field/ or similar wording.
 It may be worth to mention that the field can qualify reported or
attached messages if trusted, and that ARF uses it in its
machine-readable part.


2.2. *Formal Definition*

There is a mismatch "authres-version" != "authserv-version".


2.3. *Authentication Identifier Field*

I tend to associate syntax with production rules, so I'm unable to
make sense of the sentence:

   This is similar in syntax to a fully-qualified domain name.


In the next paragraph, there is a difficult sentence:

   The uniqueness of the identifier MUST be guaranteed by the ADMD
   that generates it and MUST pertain to exactly that one ADMD.

What is actually required is not the "uniqueness" of the identifier,
but the ability to univocally identify the responsible ADMD using the
identifier.  I'd suggest to rephrase the sentence accordingly.


2.5.2. *SPF and Sender-ID Results*

I propose to delete the list of results:  Since they are already
defined in the relevant RFCs, it is not clear if the I-D means to
update those definitions, redefine them from scratch, or just refer to
the existing definitions.  I'd propose the following instead:

   The values "none", "neutral", "pass", "fail", "softfail",
   "temperror", and "permerror" are the possible results of the
   check_host() function.  One of them can be reported as the
   corresponding method's result, along with the "ptype.property" of
   the argument actually used to obtain it.  In case multiple checks
   gave the same result, multiple propspec can be given for it.

The definition of "policy" has to given in any case.  For a nit, I
think it might be a better example to rewrite the last but one
paragraph as:

   The "policy" result would be returned if, for example, [SPF]
   returned as "pass" result, but the local policy check finds that
   the sender's policy is unacceptable (e.g. terminates with "+all").


6.3. *Email Authentication Result Name Registry*

OLD
   All existing registry entries that reference [AR-ORIG] are to be
   updated to reference this document.
NEW
   All existing registry entries that reference [AR-ORIG] are to be
   updated to reference this document.  Where the meaning refers to
   section 2.4.* it has to be changed to section 2.5.*, due to the
   insertion of a new Section 2.4 in this document.


8.1. *Normative References*

[AR-ORIG] will be obsolete by the time this I-D is published.  How can
it be a normative reference?

> 1. http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00