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

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 2 May 2007 17:30:50 -0400

I read through the last version of Application Design Guidelines draft.
Here are my comments:

1)It could be a good idea to give a description of "mandatory AVP". I
propose to use the following terminology:
mandatory AVP: An AVP with M-bit set. A mandatory AVP has to be
understood and processed by its receiver.

2) 4.1
"This means that the M-bit is set and the AVP(s) is required to exist in
command ABNF."
I think even if the AVP is not required to exist in the command ABNF,
i.e. it is optional, it still changes the semantics of an existing
application. If it is received (it can be received because it is
optional on command ABNF), it has to be understood and processed. IMHO,
"and the AVP(s) is required to exist in command ABNF" should be removed.

This interpretation already caused some confusion/damage in 3GPP Rf/Ro
interfaces. There are a bunch of AVPs with M-bit defined for these
interfaces. They are defined as optional in command ABNFs and Rf/Ro are
reusing Accounting/DCCA Application Ids. I don't think a vanilla DCCA
server can handle CCRs for Ro interface. IMHO, Ro and Rf should have
used new application Ids.

3) I propose that we add the following items to the 5.9 system
Architecture and Deployment:

o Applications are encouraged to define their own application layer
timers to guard against requests not being delivered to the final
destination due to the transport errors. Relying on base protocol timer
Tw for that purpose may be problematic because Tw is a hop-by-hop timer
and its provisioning through the whole path may not be under the control
of the administrative entity operating originator of the request.
Furthermore, applications may have different characteristics regarding
timeout values to determine a non-delivery of a request.

o Applications should specify any AVP, which could be used for duplicate
detection and how these could be used for that purpose. This could help
to ease duplicate detection process for certain cases. 

    Thanks,
    Tolga

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 02 May 2007 18:10:29 -0400

Hi Tolga,

> understood and processed by its receiver.

Ok. How about in Sec 4.1 we re-phrase the first few sentence of the 
paragraph:

"
      The rules are strict in the case where the AVP(s) to be added is
      mandatory to be understood and interpreted.  This means that the
      M-bit is set and the AVP(s) is required to exist in command ABNF.
      Note that this mandatory AVP rule applies to AVP(s) that either
      ......
"

to:

"
      The rules are strict in the case where the AVP(s) to be added is
      mandatory. As defined in [1], a mandatory AVP is an AVP that has its
      M-bit flag set which requires a receiver to understand, correctly
      interpret and process the AVP when it is present in a message.
      This rule is independent of whether the AVP is defined as required
      or optional to exist in a message. As long as the AVP is to be added
      to a messages' ABNF then this rule will apply.
     
      Note that this mandatory AVP rule applies to AVP(s) that either
      ......
"

> "and the AVP(s) is required to exist in command ABNF" should be removed.

Ok. The changes above should cover this as well.

> timeout values to determine a non-delivery of a request.

The last bullet point in Sec 5.9 might also covers this item. Do you 
wish to have a more specific recommendation for timers ? If so, we can 
re-focus the exiting item.

> to ease duplicate detection process for certain cases. 

Ok. Some editorial changes:

"
Applications should specify AVPs which could be used to further aid in 
duplication
detection. [Can you add the case here to provide an example ?] It is 
recommended
that these AVPs be used only for this purpose.
"

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 3 May 2007 12:44:35 -0400

Hi Victor,

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2007 6:10 PM
> To: Asveren, Tolga
> Cc: [email-masked]
> Subject: Re: [Dime] Comments for draft-fajardo-dime-app-design-guide-
> 02.txt
> 
> Hi Tolga,
> 
[TOLGA]That sounds good to me.
> > timeout values to determine a non-delivery of a request.
[TOLGA]Yes you are right. I should have read it more carefully. Current
text covers this well.
> that these AVPs be used only for this purpose.
[TOLGA]Example:  Possible use of Session-Id and CC-Request-Number AVPs
for duplicate detection purposes in certain cases by DCCA