[apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1

Eliot Lear <lear@cisco.com> Tue, 07 December 2010 07:05 UTC

Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177FD3A691C; Mon, 6 Dec 2010 23:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.232
X-Spam-Level:
X-Spam-Status: No, score=-110.232 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2a4m+ClJI76; Mon, 6 Dec 2010 23:05:54 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6A8333A672E; Mon, 6 Dec 2010 23:05:53 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIEAOxr/UyQ/khNgWdsb2JhbACDT5sIhF8VAQEWIiKkNopBkQiEVnMEim4
X-IronPort-AV: E=Sophos; i="4.59,310,1288569600"; d="scan'208,217"; a="14777265"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2010 07:07:17 +0000
Received: from dhcp-10-55-81-114.cisco.com (dhcp-10-55-81-114.cisco.com [10.55.81.114]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oB777HAi018326; Tue, 7 Dec 2010 07:07:17 GMT
Message-ID: <4CFDDD2F.2020201@cisco.com>
Date: Tue, 07 Dec 2010 08:07:27 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, eai-chairs@tools.ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, 'IESG' <iesg@ietf.org>, Ted Hardie <hardie@qualcomm.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/alternative; boundary="------------010001010405060808040104"
Subject: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 07 Dec 2010 07:05:56 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-eai-rfc5337bis-01
Title: Internationalized Delivery Status and Disposition Notifications
Reviewer: Eliot Lear
Review Date: 7 Dec 2010

Summary:

This draft is almost ready for publication but has a few *minor* issues
that should be considered prior to publication.  Great job!

Major Issues:  none.  Cool!

Minor Issues:

The document does not state clearly what the differences between this
specification and RFC5337.  Doing so could speed adoption of this
specification.  As some of the changes seem subtle, such an addition
would be particularly welcome.

ABNF:  Courtesy of Bill Fenner's ABNF checker, there are several changes
that could be made for clarity:

Upper-casify hex (e.g., 2a->2A) [throughout]
Combine "Diagnostic-Code" ":" -> ""Diagnostic-Code:"
Combine "Localized-Diagnostic" ":" -> ""Localized-Diagnostic:"
Combine "Failure" ":" -> "Failure:"
Combine "Warning" ":" -> "Warning:"

More importantly, the specification makes use of the =/ operator  from
RFC 5234, but for constructs that it does not control.  I don't know if
this was the original intent or not, but I am a little concerned that
use of =/ in a construct that is not wholly controlled by a single
specification is asking for confusion later.  This is an optional
specification, right?

Finally, in the beginning of the document you discuss whether or not to
create a new registration, and indicate that the working group chose not
to create a new registration. I can easily imagine good reasoning for
this, but perhaps you might elaborate in descriptive language the nature
of the choice and why you chose one way rather than the other,
especially in light of what may seem like a contrary decision in 5336bis.

Regards,

Eliot