Subject: Re: [Dime] comments on Diameter Guidelines draft

From: Victor Fajardo <[email-masked]>
Date: Tue, 11 Nov 2008 14:52:40 -0500

Hi Lionel,

Here's a much overdue response to your comments (all editorials are ok 
except those with comments below). Although the draft did not make it to 
the submission cutoff, it is still best to update it based on the latest 
review.

>    Major Extension:  Such an extension requires the definition of a new
>       Diameter application.  The rules outlined in Section 1.2 of [1]
>       indicate when an extension is significant enough to require a new
>       Command Code to be registered and when new Diameter applications
>       have to be defined.  Typically, these extensions require a longer
>       standardization effort, a little bit depending on the depending on
>       the degree of re-use, since additional aspects have to be taken
>       into consideration.
>
> [LM] "significant enough" and "little bit" should be prohibited in a
> specification documentation. But I think that there is already a comment
> on this.
> [LM] I don't see how is used the wording "standardization effort". The
> same "effort" will be needed in case of vendor-specific extension (e.g.
> SDO specific extensions or vendor-specific extensions). Could it be
> replaced by "specification effort"? [end]
>   

I agree. The sentence is not well formed and looses its meaning. We 
should change to:

"Typically, these types of extensions require a longer and more careful
  effort depending on the degree of re-use. Therefore, the amount of 
time and effort
  to complete the specification should also be considered by the designer. "

>    The subsequent sections provide discussions about the specific
>    Diameter Base protocol rules.
>
>
> 4.  Adding a new command
>
>    The rules are strict in this case.  Adding a command to an
>    application requires a new Diameter application to be defined.l
>
> [LM] remove "l" after "defined." [end]
> [LM] could we add that: "This falls into the "Major Extensions"
> category."?
>   

We should really change the 1st sentence to:

"Adding a new command is considered a major extension and requires a new
 Diameter application to be defined."

>    However, if this is the intent, then the new application can be
>    created by defining a new command for an existing application or
>    importing an existing command from another application so as to
>    inherit some or all of the functionality of that application.  
>
> [LM] For this part of the text, I would propose to clarify the text as
> follow:
>
> "Adding a new command to an application means either defining a new
> command for an existing application or importing an existing command
> from another application, the new application inheriting then some or
> all of the functionality of the existing application" [end]
>   

A minor re-word:

"Adding a new command to an application
 means either defining a completely new command or importing an existing
 command from another application whereby the new application inherits some
 or all of the functionality of the application where the command came from"

>    In the
>    former case, the decision is straightforward since this is typically
>    a result of adding new functionality that does not yet exist.  The
>    latter case would result in a new application but it has a more
>    subtle issue such as deciding whether importing of commands and
>    functionality is really better than simply using the existing
>    application as it is in conjunction with any new application.
>
>    In general, it is difficult to come to a hard guideline, and so a
>    case by case study of each application requirement should be applied.
>
> [LM] proposed text, for seek of clarity:
>
> "In the former case, the decision to create an new application is
> straightforward since this is typically a result of adding a new
> functionality that does not exist yet. For the latter, the decision will
> depend on whether importing the command in a new application is more
> suitable than simply using the existing application as it is in
> conjunction with any other application (a new one or an existing one).
> Therefore, a case by case study of each application requirement should
> be applied. [end]
>   

looks good.

>    Before adding or importing a command, application designers should
>    consider the following:
>
>    o  Can the new functionality be fulfilled by creating a new
>       application independent from the existing applications?  In this
>       case, a deployment architecture could be designed such that both
>       old and new application can work independent of, but cooperating
>       with each other.
>
> [LM] remove reference to "deployment architecture" out of scope here.
> Just say: "In this case, both old and new applications..." with "s" at
> the end of applications [end]
>   

Ok

> 5.  Deleting a Command
>
>    Although this is not typical, deleting an command from an existing
>    application is fundamentally changing the application.  In general,
>    the implications of this approach are the same as Section 4
>    regardless of whether new commands will also be added to the
>    resulting application.
>
> [LM] What is the meaning of "In general" in the last sentence? Removing
> of any command must result in the creation of a new application, isn't
> it? I would just say: "Removing a command to an application requires a
> new Diameter application to be defined. [end]
>   

I agree.

>    o  Mandatory to understand AVPs.  As defined in [1], these are AVPs
>       with the M-bit flag set, which means that a Diameter node
>       receiving these AVPs has to understand not only their values but
>       their semantics.  This is regardless of whether these AVPs are
>       required or optional to appear in the command; as specified by the
>       commands ABNF.
>
> [LM] should we add that an AVP not understood will cause a failure in
> the message handling? It's for me the main difference between mandatory
> and optional AVP i.e. Optional AVP can be ignored without causing a
> failure. [end]
> [LM] use "," instead of ";" in the last sentance [end]
>   

how about:

"...these are AVPs with the M-bit flag set, which means that a Diameter 
node receiving
 are required to understand not only their values but their semantics. 
Failure to do
 so will cause an message handling error. This is regardless of whether 
these AVPs are
 required or optional as specified by the commands ABNF."

>    All of these practices generally result in interoperability problems
>    so they should be avoided as much as possible.
>
> [LM] The conclusion being that a mandatory AVP is required, isn't it?
> [end]
>   

That was'nt the intent of the paragraph ... its just a badly form 
paragraph :). Here's a revised version:

"
   When one of the above questions can be answered with 'yes' then the

Fajardo, et al.           Expires May 15, 2009                  [Page 6]

Internet-Draft   Diameter Applications Design Guidelines   November 2008

   M-bit has to be set.  If application designers are contemplating on
   the use of optional AVPs instead, then the following are some of the
   pitfalls that should be avoided:

   o  Use of optional AVPs with intersecting meaning.  One AVP has
      partially the same usage and meaning as another AVP.  The presence
      of both can lead to confusion.

   o  An optional AVPs with dual purpose, i.e. to carry applications
      data as well as to indicate support for one or more features.
      This has a tendency to introduce interpretation issues.

   o  Adding one or more optional AVPs and indicating (usually within
      descriptive text for the command) that at least one of them has to
      be present in the command.  This essentially circumventing the
      ABNF and is equivalent to adding a mandatory AVPs to the command.

   These practices generally result in interoperability issues and
   should be avoided as much as possible.
"

> 6.2.  Deleting AVPs from a Command
>
>    Although this scenario is not as common, the deletion of AVPs from a
>    command ABNF is significant when trying to extend an existing
>    application.
>
> [LM] strange to see in the same sentance "deletion" and "to extend an
> existing application". Instead of "extend", I would use "modify" [end]
>   

Lets remove that sentence as it makes little sense :)

> [LM] Am I wrong if i say that the following case is missing and should
> be inserted before the "{}" case?
>   "An AVP that is indicated as <> in the ABNF in the Command (with or
> without the
>    M-bit set)
>   

Not sure if this is ok. <> is just a positional restriction and not a 
presence restriction.

-- victor

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime