[Dime] WGLC Review of draft-ietf-dime-app-design-guide-15

Ben Campbell <ben@nostrum.com> Tue, 28 August 2012 21:54 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9A21F8535 for <dime@ietfa.amsl.com>; Tue, 28 Aug 2012 14:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, 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 1Sgq065dxUv0 for <dime@ietfa.amsl.com>; Tue, 28 Aug 2012 14:54:58 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9832321F8532 for <dime@ietf.org>; Tue, 28 Aug 2012 14:54:58 -0700 (PDT)
Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7SLstMB043115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 16:54:57 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <FDA0E339-0BFC-4EC3-94F9-8ABE95CD4476@nostrum.com>
Date: Tue, 28 Aug 2012 16:54:53 -0500
To: "dime@ietf.org" <dime@ietf.org>, draft-ietf-dime-app-design-guide@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)
Subject: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2012 21:54:59 -0000

Hi,

The draft gives good guidance overall. I do have a few comments, though:

Substantive Comments:

-- section 4:

The section seems to talk mainly about syntax, rather than semantics. Is there any guidance to give about things (applications, commands, avps) that might be syntactically similar but mean very different things?

-- 4.3.2, last paragraph:

Does it become an error if a peer uses the "no-longer-used-but-not-deleted" avp?

-- 5.9

Does the advice in this section open up an unmanaged extension vector? In the extreme case, would this encourage an external group to register a single application id for a highly extensible application, then bypass IETF extension processes by just adding more functions to the original application?

-- 8:

The security considerations say that this draft does not define nor address security related protocols or schemes. But there was an entire section dedicated to the use of IPSec, which certainly seems to address a security related protocol and scheme. 


Editorial Comments:

-- section 1:

I'm confused by list item 2. It seems to talk both about adding new function to an existing application and creating a new application. I suspect this is about the case of using two applications together to effectively add function--if so, that could be more clear.

-- section 3, Major Extension case: "... in such a way that this implies backward compatible change to the existing application ..."

Do you mean a _non_ backwards compatible change?

-- section 4.1, third bullet: " Care should be taken to avoid a liberal method of importing existing command’s CCF syntax specification."

I'm not sure I understand what you mean by a "liberal method of importing"?

"This would result in a monolithic and hard to manage applications..." 

singular/plural disagreement

-- 4.2, 2nd paragraph

s/" indicates of a flawed design"/"indicates a flawed design"


-- 4.3, 2nd paragraph:

s/"It is worth to note that"/"It is worth noting that"   [Or even better, skip the whole clause]

s/"in the [RFC3588]"/"in [RFC3588]"

-- 4.3.1, title:

s/ommand/command

-- 4.3.1, 2nd bullet list, 3rd bullet:

The second half of this bullet item seems redundant with the previous bullet.

-- 5.8

The section may have some meaning obscured by passive voice. In particular, who foresaw that translation would be easy, who acknowledged that it wasn't, and who might foresee the need for RADIUS interworking? (I think those are the work group, the work group, and application designers, respectively)

-- 5.9, third bullet: "Applications that do not understand these AVP can discard it ..."

singular/plural disagreement

-- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms such as IPsec can also be deployed to secure connections between Diameter peers."

Do you mean "IPSec can also be deployed...", or "Additional security mechanisms such as IPSec can also be deployed..."?


Thanks!

Ben.