Re: [Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19
Jouni Korhonen <jounikor@gmail.com> Sat, 14 September 2013 16:41 UTC
Return-Path: <jounikor@gmail.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 D9BDC21E80AD for <gen-art@ietfa.amsl.com>; Sat, 14 Sep 2013 09:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 IfCAxTdOUDdC for <gen-art@ietfa.amsl.com>; Sat, 14 Sep 2013 09:41:11 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0821E8109 for <gen-art@ietf.org>; Sat, 14 Sep 2013 09:41:09 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id lv10so1923949lab.23 for <gen-art@ietf.org>; Sat, 14 Sep 2013 09:41:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0LX4p2ql+Ukp6LxctypuFrQ8C4K1QVpVDWKDhZ8FX60=; b=WHLK1+EQXgyzsR1WOy7XhW2fXJDWoxgBtqD22RELFFaVtn2cE/14BrdkVqFxjr7uul muXqBN48lxGeuTcMqOoZDV/JC/k21GXRbMdEHZDAzarXjmfMSzGgofcodICrk8kj94S/ fWr4BnaYGyXLLsi4l0lPoh9ZooUxhUbUNrPEuP7XdQAYByW8A4nTokpFgCwni3O32YfN OFDR6JyJNcYUtLDAmYQc+22IYlvsHJrhfrTkIwiXD+neAuSeNbcXEPrUlYQjeYDH/AoX MIg/GV5msW6krHSOHAlGvA/2v+mmX1LIjdV19U4iw0kVB8e9jza4LDcfL2rhf/l1XWFn qhnA==
X-Received: by 10.152.18.228 with SMTP id z4mr2371071lad.26.1379176868554; Sat, 14 Sep 2013 09:41:08 -0700 (PDT)
Received: from [192.168.1.106] (80-186-41-232.elisa-mobile.fi. [80.186.41.232]) by mx.google.com with ESMTPSA id rd5sm8801760lbb.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 09:41:07 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Jouni Korhonen <jounikor@gmail.com>
In-Reply-To: <CABkgnnW_JWMC3CVoCpt6gVWzdJWv6ii_rUMtk=bt-=HEBMYGqg@mail.gmail.com>
Date: Sat, 14 Sep 2013 19:41:07 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <1231BCB9-DA24-4321-BDEF-F651D8145B8F@gmail.com>
References: <CABkgnnW_JWMC3CVoCpt6gVWzdJWv6ii_rUMtk=bt-=HEBMYGqg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: draft-ietf-dime-app-design-guide.all@tools.ietf.org, "gen-art@ietf.org" <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19
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: Sat, 14 Sep 2013 16:41:12 -0000
Martin, Thanks for the detailed review. I'll let the authors respond to these if they have further questions or clarifications to ask. - Jouni On Sep 14, 2013, at 3:13 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > 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-dime-app-design-guide-19 > Reviewer: Martin Thomson > Review Date: 2013-09-13 > IETF LC End Date: unknown, early review > IESG Telechat date: (if known) > > Summary: This document is ready, with some minor issues and nits. > > Minor issues: > I would find it a lot easier to read this document if it did as the > goals state (the first objective from the introduction) and clarify > what the extensibility rules in Diameter say with respect to each of > the described extensions. It's not easy to glean this information > from RFC 6733, which makes reviewing this a little tricky. > > For instance, Section 4.1 doesn't really say what the expectations are > with respect to implementations that receive unknown or unsupported > commands. I think that I could guess, but I'd rather not. (I just > read the relevant parts of 6733, and it turns out that my guess was > wrong.) > > The same applies to Section 4.2, presumably through applying the same > principles. The question here is: what would be the expected behavior > if a node was operating on the new application definition and that > node received a deleted command? (The old implementation presumably > has no problem with the absence of the command if it's being removed.) > > The same applies to Section 5. > > Sections 4.4.2 and particularly 5.6 lead me to infer that the > extensibility for enumerated types is fundamentally broken, so maybe > those properties need to be expanded upon a little here too. > > The placement of the guidance in Section 5.6 seems fairly important > for Section 4, lest that important information be lost to someone just > looking to tweak a command. > > Section 4.3.1, perhaps add to the M-bit criteria: Would the presence > or value of the AVP alter the interpretation of the command (or any > other AVP) in any way? (nit: s/AVPs/AVP on second bullet here.) > > I didn't find the list in Section 6 particularly compelling. It > seemed a little like motherhood statements. The description of what > it was this was talking about: good; the description of how these > "often" (always?) manifest is also useful. I wonder though whether > it's safe to generalize when you only see generic protocols extensions > as optional AVPs. Perhaps you need to refocus on exactly that, and > leave the other forms of extension to speculation. > > Nits/editorial comments: > The last paragraph of Section 3 is confusing to me. Firstly, the > subject of the reminder is missing from the first sentence. I think > that the intent of that sentence is to say that extending by adding > applications or commands is to be avoided, but then subsequent > sentences make it clear that doing so is easy. The last sentence > seems to be talking about something else entirely, which is the value > that IANA registries provide. I am going to have to suggest that this > be reworded entirely. > > In Section 4.1, I'd like to see the note turned into real text. The > size and complexity of an application seems to be a fairly significant > factor in determining whether a new application imports commands, or > whether separate applications are defined. > > I read the first bullet in Section 4.3.2 as a sentence, several times, > before realizing that it's a title. Please reconsider the formatting > of this list. At a very minimum, remove the period. > > --Martin > > p.s., I'm on vacation starting approximately ...now, since I'm out of > time for this review... so apologies for any slow responses to the > review.
- [Gen-art] Gen-ART review of draft-ietf-dime-app-d… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… Jouni Korhonen
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… Jouni Korhonen
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… lionel.morand
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… Jari Arkko
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… lionel.morand
- Re: [Gen-art] Gen-ART review of draft-ietf-dime-a… Jari Arkko