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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, May 6, 2013 at 9:29 AM, Alessandro Vesely <[e-mail]> wrote:

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

The RFC Editor always changes that to Network Working Group.  It's probably
only there because I copied the XML from some other draft that had it.
Safe to ignore.


>
> 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.
>

Although you're right about the intent of the document, the point of this
section is to indicate that it covers entire messages only, not
encapsulated messages.  It doesn't have anything to do with the consumer.


>
> 2.2. *Formal Definition*
>
> There is a mismatch "authres-version" != "authserv-version".
>

Right; fixed.


> 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.
>

You're aware of how this works; what would you suggest?  The ABNF is
"value" because it is usually an FQDN, but we also say that it doesn't have
to be.


> 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.
>

Are those not synonymous?  From the perspective of a module consuming this
field, it has to be the case that such a module can safely assume that a
field bearing the authserv-id it expects (or one of a set, perhaps) can be
trusted.


>
> 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.
>

Good idea.  Done.


>
> 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").
>

I don't agree with including that specific example, as it encourages a
particular local policy debate that I don't think this document should
approach.


>
> 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.
>

Good point, but rather than doing this, I've added a note to the editor to
make sure the section numbers line up right before publication, in case
they change again.  We can deal with that during the IANA Actions phase of
publication.


>
>
> 8.1. *Normative References*
>
> [AR-ORIG] will be obsolete by the time this I-D is published.  How can
> it be a normative reference?
>
>
>
That's a good procedural question.  I think it has to be because it
involves IANA actions that are being amended, but I think this is something
that can be sorted out during IESG Evaluation.

Thanks!

-MSK