Subject: [Dime] Review of Diameter App Guidelines

From: <[email-masked]>
Date: Tue, 18 Dec 2007 12:19:56 +0100

During last IETF I volunteered to review the
draft-ietf-dime-app-design-guife-05 draft. IMHO
the draft is in pretty good shape, at least it
appears so to me.

Few editorial & substantial nits:

 o Application ID is written in several ways depending
   on the section it appears at. Use consistent style.

 o section 1. intro

  "various attempts to extend Diameter applications where designers have
   no clear answer on whether to even define a new application or not."

   s/even/

 o section 3. brief overview..

  "As it is currently interpreted and practiced, the Diameter Base
   protocol is a two-layer protocol.  The lower layer is mainly"

   s/interpreted/specified

 o section 3. brief overview..

  "applications reside.  This model is in line with a Diameter node
   having an application layer and a peer-to-peer delivery layer.  The"

   s/peer-to-peer delivery/peer-to-peer message delivery

 o section 4. rules extending..

  "Extending Diameter can mean the reuse of commands, AVPs and AVP
   values in any combination for the purpose of inheriting the features
   of an existing Diameter applications.  This section discusses the
   rules on how such reuse can be done."

   In section 1 item 3 we also listed creating a new application. This
   should be added to above text.

 o section 4. rules extending..

  "1.  Minimal - which typically means adding optional AVPs to existing
       commands."

   I would add here "Does not necessarily require a new application."
   just for the clarity.

   2.  Invasive - where addition or deletion of commands and/or AVPs,
       and/or AVP values (in the case where the AVP is of type
       Enumerated).

   I would add here "Always requires a new application."
   just for the clarity.

 o section 4.1.1 adding a new..

  "In general, it is difficult to come to a hard and fast guideline, and
   so a case by case study of each application requirement should be"
  
   s/to a hard and fast/up with a general purpose, yet short and solid" 

 o section 4.1.1 adding a new..

     "initial proposal for Diameter MIPv6 split scenario (see [2]) where
      authorization and authentication is separated."

   Actually the current split is not entirely clear on auth & authz 
   separation. It is advocated in the intro but in the body of the
   text auth/authz is combined for RFC4877 & RFC5026 bootstrapping.
   From Diameter perspective that is..

 o section 4.2 reusing existing..

  "This section deals with a little more granularity than Section 4.1."

   Deals with what? Rephrase.

 o section 4.2.1 adding AVPs..

  "o  Do the AVPs change the state machine of the application ?

   o  Would the presence of the AVPs cause additional message round-
      trips; effectively changing the state machine of the application
?"

  The above two bullets could be combined to a one.

 o section 4.2.1 adding AVPs..

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

  This is what the dime-mip6-integrated actually does. You should
  give a reference to it as a bad design example ;) It could be
  emphasized here that if the "dual purpose" can be made entirely
  backwards compatible, it is ok.. like in mip6-integrated case

 o section 5.5 end-to-end..

  "applications itself.  Examples of this can be found in [2] and [3]."

  Add a reference to dime-mip6-integrated here.

 o section 6.4 system arch..

  "o  For general AAA applications, Diameter requires more message
      exchanges for the same set of services compared to RADIUS."

  Is it really so after the CER/CEA exchange?

 o section 6.4 system arch..

  "o  Application design should be agnostic to any Diameter topology.
      Application designers should not always assume a particular
      Diameter topology; i.e., assume that there will always be
      application proxies in the path or assume that only intra-domain
      routing is applicable."

   I would like to see some more text in general about impacts of AVPs
   that affect request routing. Especially in situations when those are
   attempted to be used with existing application. A good example is
   NAI decoration. Basically a new application is required when other
   AVPs than those listed in DBP for request routing affect routing
   decisions..

Cheers,
	Jouni

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Dec 2007 09:01:29 -0500

Hi Jouni,

> the draft is in pretty good shape, at least it

Ok. thanks.

>    s/peer-to-peer delivery/peer-to-peer message delivery

Above editorials are ok.

>    should be added to above text.

Ok

>    I would add here "Always requires a new application."

Sure.

>    From Diameter perspective that is..

I see. Ok I'll fix the text.

>    Deals with what? Rephrase.

Ok.

>   The above two bullets could be combined to a one.

Ok.

>   backwards compatible, it is ok.. like in mip6-integrated case

:) we can use mip6-integrated as a corner case where it is possible to 
do "dual purpose". In general, its probably not a good practice.

>   Is it really so after the CER/CEA exchange?

Mainly because of session maintenance (STR/STAs, ASR/ASAs ..) and peer 
maintenance (DWR/DWAs) etc ...

>    AVPs than those listed in DBP for request routing affect routing

I see. I guess we can add text on routing impacts to highlight possible 
issues.

thanks,
victor