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

Alessandro Vesely <vesely@tana.it> Mon, 06 May 2013 16:29 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B6521F86F2 for <apps-discuss@ietfa.amsl.com>; Mon, 6 May 2013 09:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GOJDeongEOW for <apps-discuss@ietfa.amsl.com>; Mon, 6 May 2013 09:29:42 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5312D21F8717 for <apps-discuss@ietf.org>; Mon, 6 May 2013 09:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367857780; bh=N+2fDMDsFtm1Jm1R5zyrk6Rvvna7JwEvt4SJUUs9khs=; l=3321; h=Date:From:To:References:In-Reply-To; b=GXG7Jx7Fy0uPqTTYDg5qDzLc8Q9IiDIwRFph3GKi5e1ENPWi4HsbxJeKRlAg9hEiD qOps7m1Op3JS0jqjDx9MMtxOxRgri/cYMImUDjjPsOWN8S1fSZZ+wqs9tS4sWe2qFj /23BBJ3VM1VFpQ7YKIAVyE3Bn6b/tzRe+3flwTJ8=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 06 May 2013 18:29:40 +0200 id 00000000005DC02B.000000005187DA74.00006380
Message-ID: <5187DA74.9020204@tana.it>
Date: Mon, 06 May 2013 18:29:40 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com>
In-Reply-To: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2013 16:29:46 -0000

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