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

["Asveren, Tolga" <tasveren at sonusnet.com>]

Hi Victor,

> -----Original Message-----
> From: Victor Fajardo [mailto:vfajardo at tari.toshiba.com]
> Sent: Wednesday, May 02, 2007 6:10 PM
> To: Asveren, Tolga
> Cc: dime at ietf.org
> Subject: Re: [Dime] Comments for draft-fajardo-dime-app-design-guide-
> 02.txt
> 
> Hi Tolga,
> 
> > 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.
> >
> 
> 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
>       ......
> "
> 
> 
> >
> > 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.
> >
> 
> 
> Ok. The changes above should cover this as well.
[TOLGA]That sounds good to me.
> 
> 
> > 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.
[TOLGA]Yes you are right. I should have read it more carefully. Current
text covers this well.
> >
> 
> 
> 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.
> 
> 
> > 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.
> >
> 
> 
> 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.
> "
[TOLGA]Example:  Possible use of Session-Id and CC-Request-Number AVPs
for duplicate detection purposes in certain cases by DCCA
> 
> 
> regards,
> victor
> 
> >     Thanks,
> >     Tolga
> >
> > _______________________________________________
> > DiME mailing list
> > DiME at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> >
> >


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime