Re: [Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19

[Jouni Korhonen <[e-mail]>]

Martin,

We'll check this again. Thanks.

- Jouni





On Jun 17, 2014, at 2:54 AM, Martin Thomson wrote:

> I just read through the diff of -24.  I'm assuming that my feedback
> was lost somewhere.
> 
> On 14 September 2013 09:41, Jouni Korhonen <[e-mail]> wrote:
>> 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 <[e-mail]> 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.
>>