Subject: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 10 Aug 2007 16:29:07 -0400

Hi Victor,

Please find below my comments for draft-dime-app-design-guide-02.txt. I
think this draft is in very good shape and almost all of my comments are
editorial.

   Thanks,
   Tolga

1)
4.1.2 Deleting a command
In general, it is unusual to delete an existing command from an existing
application for
^^^^^^^^^^^
 ADD

This design decision would normally be an indication of a flawed
designed. 
==> This normally would be an indication of a flawed design.

2)
4.2 Reusing existing commands
In some cases, there are a lot of ambiguity.
==> In some cases there is a lot of ambiguity.

So design considerations have been outlined to ease process.
                                          ^
                                          ADD

3)
4.2.1 Adding AVPs to a command
A mandatory AVP cannot be added
            ^^^
            ADD

4)
4.2.2 Deleting AVPs from a command
Instead of deleting AVPs from a command, a better alternative
                    ^^^^^^^^^^^^^^^^^^^
                         ADD

5)
6.3 Updating an existing application
"Optional AVPs can also be used to indicate version differences."
I think, using an *optional* AVP for this purpose could be problematic.
I can think of two different cases here:
a) An application has a mandatory AVP from very beginning on to indicate
version. In such a case, a new version can be safely signaled to
entities running an older version of the application. Because semantics
associated with the Version-AVP are defined by the initial release of
the application, all nodes would be able to interpret it successfully.
An older version implementation can reject a request containing a
Version-AVP with a newer value.
b) The new release of the application uses a new and mandatory AVP. This
would mean that a new command needs to be defined as well. New command
would not be recognized by the old implementation and would be rejected.
This is really an ugly solution but would make sure that sender is aware
of any possibly incompatibility due to version differences.

I guess, due to lack of elegance in b), we should add a recommendation
that new applications should use an AVP to indicate the version used by
a node. Actually, I even think that there should be a generic AVP
defined for this purpose.

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

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 13 Aug 2007 08:17:35 -0400

Hi Tolga,

Thanks for the comments. I'll incorporate editorial comments 1 through 4 
below.

> In general, it is unusual to delete an existing command from an existing

Sure. We may also consider the case where the initial version does not 
have a "version-avp" but the new version introduces it. In which case, 
the *optional* avp method maybe applicable to the "vesion-avp" to make 
the application inter operate with the old version.

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 13 Aug 2007 09:27:22 -0400

Hi Tolga, Victor,

Regarding the application version, I think there is more than optional/
mandatory AVPs involved.

By adding application versions, we are effectively saying that the peer
capability wrt a specific application is now defined by the Application
ID AND Application Version. This implies that the Application Version
needs to be exchanged in CER/CEA messages. 

Since Application ID is a secondary key field for routing table lookups,
the version also needs to be considered in routing decisions. Command
routing performance will be impacted if peers must scan messages for
Application Version AVPs. Ideally, the Application Version needs to be
in the Diameter header but I don't see any way to add it while
maintaining backwards compatibility.

Given these challenges, maybe it is simpler to state that designers MUST
request a new Application ID when they revise their application. Apart
from using up additional IDs, do you see any downsides with this
approach?

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 13 Aug 2007 09:51:46 -0400

Hi Mark,

> needs to be exchanged in CER/CEA messages. 

Mmm... not sure if this is necessary. The context of the versioning 
scheme in discussion is a corner case scenario that is confined within 
the application and hence the application id is not necessarily required 
to change.

> maintaining backwards compatibility.

Again, the knowledge of versioning is confined within an application; 
there should be no routing states or changes involved. Just to give a 
background, this section on versioning is present in the app guide to 
shed light on how one can do versioning within a specific application if 
the change is not significant enough to warrant defining a new 
application. Other SDOs have defined very ad-hoc ways of going from one 
version of the same application to the next without formally defining a 
scheme and this is intended to show the bad consequence of those decisions.

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 13 Aug 2007 10:21:31 -0400

> the application and hence the application id is not 

Thanks Victor. I re-read section 5.5 and I understand this scenario
better. 

If I understand correctly, the application has changed but the
enhancements are 'optional to understand', i.e. the new application
version is backwards compatible. The version/capability AVP is used to
communicate support of these enhancements between end-points and so
intermediate relays are not impacted. Is that correct?

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 13 Aug 2007 10:45:35 -0400

Hi Mark,

> intermediate relays are not impacted. Is that correct?

Yup.

regards,
victor

---

From: "Ulf Bodin" <[email-masked]>
Date: Mon, 13 Aug 2007 17:27:22 +0200

Hi,

As the comments made by Tolga my comments on
draft-dime-app-design-guide-02.txt are mostly editorial. I've got a few
comments on what's actually recommended as well though as well as
commenst on where I believe the text is somewhat unclear. Anyway, pls
find my comments below.

Best regards,
Ulf

Section 1

First bullet item: is the word "updated" really needed. Isn't the
obejective to clearify exensibility rules of 2588 in general and not
only those being updated in 2588bis?

Second bullet intem: Stike out "which are"

First paragraph after bullet list: The allusion with "These" is unclear
(doesn't ally to any text above this paragraph). I would rather say:
"The design gudelines given herein are necessary ...".

First paragraph after bullet list, second sentence:
A typical example would be deciding between item one(1) and two(2) above
when an application designer requires a new application functionality
which has many things in common with an existing application.
-- change to -->
A typical example would be deciding between item one(1) and two(2) above
when new application functionality is required that has many things in
common with functionality offered by an existing application.

First paragraph after bullet list, third sentence: replace "the existing
extensibility rules;" with "the original extensibility rules of
RFC3588;"

First paragraph after bullet list, last sentence: Does not make good
sence, should be rephrased. The allusion for "this example" is weak.
What does "it" refer to? The existing/original extensibility rules? What
did then the existing/original rules say they are now changed/updated.
Are the original rules based on collective experiences, or the statement
of that creating a new application is now seen as the cleanest approach?
A lot of questions - no suggestion unfortunately (since I'm not sure
what should be said).

Second paragraph after bullet list, second sentence: remove "times",
replace "foreseen as" with "considered"

Second paragraph after bullet list, last sentence: "(See ..)" -> "(see
..)"

Third paragraph after bullet list: The text mention examples and
implicitly talks about derived applications are no longer interoperable.
In case such examples exist (which I'm sure they do), it may be useful
to refernce them for clarity.

Section 3

Last sentence: I'm not sure what this sentence is actually saying (or
what informaiton it gives). A "Diameter node" is not mentioned before in
the paragraph, still it's said that "This document also treats ..." I.e.
the word "also" is somewhat ambiguous. Anyway, the meaning and purpose
of the sentence is unclear at least to me.

Section 4

First paragraph, second sentence: "applications" -> "application", or
remove "an" before existing.

Second paragraph, first sentence: "application's" -> "applications"

Second paragraph, second sentence: ".. much of the existing application
..." -> ".. much of an existing application ..."

Section 4.1.1

Fourth bullet item, first sentence: remove space before "?" and
introduce space in "maybe" -> "may be"

Section 4.2.1

First paragraph after second bullet list, first sentence: "consider" ->
"considered"

Section 4.2.2

First paragraph, first sentence: ".. is significant when trying to
extend an existing application" -> ".. constitutes a significant change
when extending and existent application."

Second paragraph, second sentence: "..mandatory would.." -> "..mantatory
AVPs would.."

Third paragraph, first sentence: "..command that would represent.." ->
"..command representing.."

Fourth paragraph, second sentence: delete "optional"

Fourth paragraph, fourth sentence: delete "to begin with"

Fifth paragraph: This may be a stupid question, but I wonder if any
gudence is needed for how to ignore an optional AVP because it's not
used by the application being in use (and instead only has a purpose for
the application from which the command in inhereted). That is, is
silently ignoring anything ok from an compatibility standpoint ok. Maybe
it, I'm just not enough of a Diameter expert to know for sure.

Section 4.3

First paragraph, first and second sentence: Delete "deals with even more
granularity than Section 4.1 and Section 4.2. Specifically, it"

Section 5 

Second paragraph, first sentence: Are we referring to new _mandatory_
AVPs and AVP values that _changes_ the behaviour of the applicatio, or
any new AVP and AVP value? If I understand the rules correctly it's the
former only and in case that's correct I suggest clearifying this. E.g.
by saying "..new commands, mandatory AVPS and/or AVP values that changes
the behaviour of the application for ..."

Second paragraph, last sentence: Could the givenm examples be clearified
beyond just giving the references? For example, by adding after the last
reference ", where ...."

Third paragraph, first sentence: "newly defined commands." -> "new
commands."

Section 5.3

First paragraph, last sentence: 
Change 
"However, this scheme is followed to avoid possible routing problems for
these messages." to 
"However, this scheme should be followed to avoid possible routing
problems."

Section 5.4

Third sentence: 
Change 
"The existing session statemachines defined by [1] is not intended for
general use beyond AAA services therefore any behavior not covered by
that category would not fit well." to 
"The existing session statemachines defined by [1] is not intended for
general use beyond AAA services therefore any behavior not covered by
that category may not fit well for the new application."

Section 6.1

Second last paragraph, first sentence: delete "obviously"

Last paragraph, first sentence: "Additionally," does not seem to apply
to anything said before e.g. in the previous paragraph. Henece another
start of that sentence may be good to have. 

-----Original Message-----
From: Asveren, Tolga [mailto:[email-masked]]
Sent: den 10 augusti 2007 22:29
To: [email-masked]
Subject: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt

Hi Victor,

   Thanks,
   Tolga

1)
4.1.2 Deleting a command
In general, it is unusual to delete an existing command from an existing
application for ^^^^^^^^^^^  ADD

2)

3)

4)

5)

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 13 Aug 2007 12:33:46 -0400

Hi Ulf,

Thanks for the review.

> extensibility rules;" with "the original extensibility rules of

Ok. I'll incorporate all of your suggestions above.

> A lot of questions - no suggestion unfortunately (since I'm not sure

Ok. Maybe we can re-phrase to:

"Certain design patterns did emerge from the experiences of application 
designers. For example,
in the case of using optional AVPs to indicate new functionality, it is 
now generally viewed that
the creation of a new application (item two(2)) is a better design 
approach. "

> Second paragraph after bullet list, last sentence: "(See ..)" -> "(see

Ok

> to refernce them for clarity.

Good point.

> of the sentence is unclear at least to me.

Ok. I think it is safe to remove that sentence since it does not seem to 
provide any value.

> Fourth paragraph, fourth sentence: delete "to begin with"

I'm ok with the editorials.

> it, I'm just not enough of a Diameter expert to know for sure.

In some sense, ignoring optional AVPs are an implied behavior in 
general. Though, for the application itself, not explicitly stating such 
behavior may have implications. For example, maybe apps should 
explicitly differentiate when ignoring an optional avp by choice or 
because it does not understand the avp. Anyway, maybe some additional 
text is needed.

> the behaviour of the application for ..."

Good point. we can clarify that.

> beyond just giving the references? For example, by adding after the last

Ok sure. we can further clarify the text.

> start of that sentence may be good to have. 

Ok.

regards,
victor

---

From: "Ulf Bodin" <[email-masked]>
Date: Tue, 14 Aug 2007 08:41:37 +0200

Hi Victor, 

Pls find by replies below. 

BR Ulf 

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: den 13 augusti 2007 18:34
To: Ulf Bodin
Cc: [email-masked]
Subject: Re: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt

Hi Ulf,

Thanks for the review.

> First paragraph after bullet list: The allusion with "These" is 
> unclear (doesn't ally to any text above this paragraph). I would
rather say:
> A typical example would be deciding between item one(1) and two(2) 
> above when an application designer requires a new application 
> functionality which has many things in common with an existing
application.
> -- change to -->
> A typical example would be deciding between item one(1) and two(2) 
> above when new application functionality is required that has many 
> things in common with functionality offered by an existing
application.
>
> First paragraph after bullet list, third sentence: replace "the 
> existing extensibility rules;" with "the original extensibility rules 
> of RFC3588;"
>   

> What does "it" refer to? The existing/original extensibility rules? 
> What did then the existing/original rules say they are now
changed/updated.
> Are the original rules based on collective experiences, or the 
> statement of that creating a new application is now seen as the
cleanest approach?

"Certain design patterns did emerge from the experiences of application
designers. For example, in the case of using optional AVPs to indicate
new functionality, it is now generally viewed that the creation of a new
application (item two(2)) is a better design approach. "

[Ulf1: Yes.]

Ok

Good point.

> what informaiton it gives). A "Diameter node" is not mentioned before 
> in the paragraph, still it's said that "This document also treats ..."
I.e.

> Second paragraph, second sentence: ".. much of the existing 
> application ..." -> ".. much of an existing application ..."
>
> Section 4.1.1
>
> First paragraph after second bullet list, first sentence: "consider" 
> -> "considered"
>
> Section 4.2.2
>
> extend an existing application" -> ".. constitutes a significant 
> change when extending and existent application."
>
> Second paragraph, second sentence: "..mandatory would.." -> 
> "..mantatory AVPs would.."
>

> used by the application being in use (and instead only has a purpose 
> for the application from which the command in inhereted). That is, is 
> silently ignoring anything ok from an compatibility standpoint ok. 
> Maybe it, I'm just not enough of a Diameter expert to know for sure.
>   

[Ulf1: Yes, I think such text would actually be useful. Especially if an
application is to differentiate between ignoring an optional AVP by
choice or because it does not understand the AVP (e.g. in reporting this
back to a requester).]

> Section 4.3
>
> First paragraph, first and second sentence: Delete "deals with even 
> more granularity than Section 4.1 and Section 4.2. Specifically, it"
>
> Section 5
>

> any new AVP and AVP value? If I understand the rules correctly it's 
> the former only and in case that's correct I suggest clearifying this.
E.g.
> by saying "..new commands, mandatory AVPS and/or AVP values that 
> changes the behaviour of the application for ..."
>   

> Second paragraph, last sentence: Could the givenm examples be 
> clearified beyond just giving the references? For example, by adding 
> after the last reference ", where ...."
>   

> "However, this scheme is followed to avoid possible routing problems 
> for these messages." to "However, this scheme should be followed to 
> avoid possible routing problems."
>
> Section 5.4
>
> Third sentence: 
> Change

> that category would not fit well." to "The existing session 
> statemachines defined by [1] is not intended for general use beyond 
> AAA services therefore any behavior not covered by that category may 
> not fit well for the new application."
>
> Section 6.1
>

Ok.

regards,
victor