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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 14 May 2013 13:32 UTC

Return-Path: <alexey.melnikov@isode.com>
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 8216521F90C3 for <apps-discuss@ietfa.amsl.com>; Tue, 14 May 2013 06:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 pRPCesWrP7rO for <apps-discuss@ietfa.amsl.com>; Tue, 14 May 2013 06:32:44 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0E21F90B9 for <apps-discuss@ietf.org>; Tue, 14 May 2013 06:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368538362; d=isode.com; s=selector; i=@isode.com; bh=9UFVSBn+WPp/Z6rjGIErWna0U8dgjyjz7N/9G16B63c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=B9Qf49u0CjBwBzcBRsrBE7QlByLHzpGFXEf50Zgy4ROSrlfhM4Wfva8To+YuUA1goMQGGl RT0tabuQBN5awmU+CfG2OIQ3KE7OfzxDPnmpCJaViX/KhHbtuzpfEiUWE3JuUOsGZbQEiO BY2DmZAzPNPNkc3VflB+/kkdTMIxUlQ=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UZI8-gA6Fyb0@statler.isode.com>; Tue, 14 May 2013 14:32:42 +0100
Message-ID: <51923CFB.8090702@isode.com>
Date: Tue, 14 May 2013 14:32:43 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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: Tue, 14 May 2013 13:32:48 -0000

On 03/05/2013 22:26, S Moonesamy wrote:
> Hi APPSAWG,
>
> 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.
>
> Regards,
> S. Moonesamy (as document shepherd)
>
> 1. http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00
I just reviewed -01. I believe it is a well written document with good 
and detailed security considerations. Some nits are below:

In Section 2.2:

    Where an SMTP command is being reported as a "property", the MAIL
    FROM command MUST be represented by "mailfrom" and the RCPT TO
    command MUST be represented by "rcptto".  All other SMTP commands
    MUST be represented unchanged.

This seems to say that the SMTP reference is Normative, because one need 
to be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is 
listed as Informative.

In Section 2.5.4:

  LDAP needs an Informative Reference.


2.5.5.  Extension Result Codes

    Additional result codes (extension results) might be defined in the
    future by later revisions or extensions to this specification.
    Result codes MUST be registered with the Internet Assigned Numbers
    Authority (IANA) and preferably published in an RFC.  See Section 6
    for further details.

    Extension results MUST only be used within ADMDs that have explicitly
    consented to use them.  These results and the parameters associated
    with them are not formally documented.  Therefore, they are subject
    to change at any time and not suitable for production use.  Any MTA,
    MUA or downstream filter intended for production use SHOULD ignore or
    delete any Authentication-Results header field that includes an
    extension result.

I am mostly curious to see some examples of such extensions.