[Gen-art] Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

Ben Campbell <ben@nostrum.com> Wed, 19 September 2012 01:45 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C5411E80A5; Tue, 18 Sep 2012 18:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.595
X-Spam-Level:
X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq1t2hu0AusI; Tue, 18 Sep 2012 18:45:21 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB411E808D; Tue, 18 Sep 2012 18:45:21 -0700 (PDT)
Received: from [10.0.1.3] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8J1jJdJ018117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 20:45:20 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Sep 2012 20:45:19 -0500
Message-Id: <8CE78C42-20B9-45BC-A872-90E7FBE27D24@nostrum.com>
To: draft-ietf-eai-rfc5721bis.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
X-Mailer: Apple Mail (2.1486)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "ietf@ietf.org List" <ietf@ietf.org>
Subject: [Gen-art] Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 01:45:22 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-rfc5721bis-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20



Summary:   The draft is mostly ready for publication as a draft standard. I have a few editorial comments that should be considered prior to publication.

Major issues: None

Minor issues: 

Nits/editorial comments:

-- IDNits has some complaints; please check.

-- The abstract should mention that this obsoletes 5721

-- section 2.1, 2nd paragraph: "The character encoding format of maildrops may not be UTF-8 or ASCII."

I'm confused by this sentence, as it seems to say that the format can't be UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the draft.  Do you mean to say that it may be some format other than those?

-- same paragraph : "The UTF8 command MAY fail."

Under what circumstances? (this seems sort of tacked onto the paragraph--does it belong there?)

-- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if they were."

Not preferable enough for a SHOULD? (Note that the previous sentence used SHOULD for reporting actual message size counts)

-- section 7, 3rd paragraph: "It is possible for a man-in-the-middle attacker to insert a LANG command in the command stream, thus making protocol-level diagnostic responses unintelligible to the user."

This seems a bit unnecessary to call out, given that a MiTM could just change the diagnostic responses into Klingon even in the absence of the LANG command. It's at least worth mentioning that the LANG command really doesn't make this issue worse than it already was.