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

[<[e-mail]>]

Hi Martin,

I don't know why but I cannot find your initial review. So this may explain that your review has not be explicitly addressed.

Part of your comments has already addressed into the latest version. Some are still applicable. Please see below.
Let me know if it is OK for you and I will produce a revision of the draft.

Regards,

Lionel


-----Message d'origine-----
De : Martin Thomson [mailto:[e-mail]] 
Envoyé : mardi 17 juin 2014 01:54
À : Jouni Korhonen
Cc : [e-mail]; [e-mail]
Objet : Re: Gen-ART review of draft-ietf-dime-app-design-guide-19

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.)

[LM] True. An unknown command request will cause the protocol error DIAMETER_COMMAND_UNSUPPORTED (3001).
 
>>
>> 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.)

[LM] this is already covered in section 4.2: a node not modified and still sending the deleted command will continuously received "DIAMETER_COMMAND_UNSUPPORTED" without no way to solve it.

>>
>> 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.

[LM] Section 4.4.2 and 5.6 have been extended to clarify the issue with Enumerated AVP. I think that the new version covers your point.

>>
>> 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.)
[LM] the use of the M-bit is described in the beginning of the section: an unrecognized AVP with the M-bit set will cause a failure in the command request processing. We could add that the resulting error is DIAMETER_AVP_UNSUPPORTED.
>>
>> 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.

[LM] Difficult to list all the possible "generic extension" that could be defined. So we give explicit recommendations on what to do when using optional AVPs to support generic extensions. For the rest, the general guidelines regarding Backward/forward compatibility and Trade-off in Signaling apply for any "other" kind of extension.

>>
>> 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.

[LM] last paragraph has been removed in the last version of the draft (-24)

>>
>> 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.

[LM] OK.

>>
>> 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.

[LM] OK.

>>
>> --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.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.