Subject: Re: [Dime] Diameter Design Guidelines Draft Reviewers

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Sep 2007 09:33:44 +0200

Hi Alan, Hi Ulf,

at the Chicago IETF meeting you have volunteered to review the Diameter 
Design Guidelines draft

I haven't seen your review of it yet.
Could you post it asap?

Ciao
Hannes

PS: Thanks to Wolfgang for doing the review.

Hannes Tschofenig wrote:
> I would like to thank
>
> * Wolfgang Steigerwald
> * Ulf Bodin
> * Alan DeKok
>
> for their willingness to review the Diameter Design Guidelines draft 
> within the next 2 weeks.
>
> Ciao
> Hannes
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Sep 2007 10:27:50 +0200

> I haven't seen your review of it yet.

  From the -02 draft:

  Section 4.1.1:

   o  Can the new functionality be fulfilled by creating a new
      application independent from the existing applications ?
...

  I would expect that the answer to that question is *always* "yes".
The issue appears to be one of redundancy in functionality.  i.e. two
applications can be independent, and have significant redundancy.

  The goal here appears to be maximizing reuse by minimizing redundancy.

   o  Care should be taken to avoid a liberal method of importing many
      commands that results in a monolithic and hard to manage
      application which supports many different functionality.
...

  That sentence is a little long and could be clarified by splitting it
into shorter pieces.

  Nit: at the top of page 7, the paragraphs are not separated by whitespace.

      ..., messages for different applications
      providing service to the same user may end up in different servers
      would then need to be co-related.
...

  Is that supposed to be "correlated"?

  Section 4.2:

   So design considerations have been outline to ease the decision
   making process.
...

  Using "So" to start a sentence is not recommended.  Also "outline" is
missing a "d", to match the tense of the previous verb.

  Nit: The bullet points in 4.2.1 aren't separated by whitespace.

   The rules are strict in the case where the AVPs to be added is
   mandatory.  A mandatory cannot be
...

  "A mandatory ..." what?  The sentence needs a subject.  I suggest
adding "AVP" after "mandatory".

   [1] states that doing so would require the
   definition of a new application.
...

  I suggest adding a point to a specific section of the reference.  e.g.
"Section X.Y of [1] states..."  This makes it easier to find the text in
the reference, and also makes the sentence easier to parse.  This
comment applies to multiple references to [1] in the text, which are not
further qualified to section or subsection.

   If one or more of the above conditions are true, the AVP is consider
   mandatory.
...

  Maybe "... the AVP MUST be made mandatory".  I don't know what it
means to have an AVP "considered" mandatory.  It's a nice consideration
to have, but what does it mean for the application designer?

   These questions are not comprehensive in any way but in
   all cases the semantics of the application must change to justify the
   use of mandatory AVPs.
...

  That text doesn't inspire confidence.  Non-comprehensive guidelines
leave a lot of room for interpretation by application designers.  I
suggest saying that there are more considerations which can apply, which
are application-specific, and not enumerated here.  That phrasing makes
it a little clearer that the application designer should take great care
in marking AVP's mandatory or not.

  However, care should also be taken when opting for optional AVPs
...

  Nit: Suggest "... when using optional AVPs".  It's awkard to use the
same work multiple times.  e.g. "We opted to opt-in to the optional
options."

   Some of the issues associated with
   using optional AVPs are:
...

  Given the text following the bullet points, I suggest re-phrasing the
bullet points as a checklist of things to look for.

  Section 4.3:

   This section deals with even more granularity than Section 4.1 and
   Section 4.2.
...

  Granularity of what?  Maybe "deals with AVP rules in even more
granularity..."

   Section 6.4:

   o  For general AAA applications, Diameter requires more message
      exchanges for the same set of services compared to RADIUS.
      Therefore, application designers should consider scalability
      issues during the design process.
...

  Are there specific guidelines that can be followed?

   o  Application design should be agnostic to any Diameter topology.
...

  I would say "should not be dependent on any Diameter topology".  That
phrasing seems a little more forceful.

  There should be more spacing between the following bullet points.

  I also have a number of non-substantive comments on phrasing and
consistency, but they are not included here.

  Alan DeKok.

---

From: "Ulf Bodin" <[email-masked]>
Date: Thu, 13 Sep 2007 08:02:22 +0200

Hi Hannes, 

I sended my review the 13:th of Auguest and got some comments from
Victor which I aswered the day after. 

BR Ulf 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: den 11 september 2007 09:34
To: Ulf Bodin; [email-masked]
Cc: [email-masked]
Subject: Re: [Dime] Diameter Design Guidelines Draft Reviewers

Hi Alan, Hi Ulf,

Ciao
Hannes