Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Thanks Lionel,
The comment equally applies in order to clarify when the Validity-Duration should include a new value. 

Now:
   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
   and describes the number of seconds the "new and fresh" OC-OLR AVP
   and its content is valid since the reception of the new OC-OLR AVP.

 Proposal:
    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
    and describes the number of seconds the OC-OLR AVP and its content is
    valid in relation to the reception of the first OC-OLR AVP with a
    specific sequence number. For a given sequence number, the
    OC-Validity-Duration shall always carry the same value.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: jueves, 06 de febrero de 2014 19:07
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Hi Maria Cruz,

Hi Maria Cruz, Steve,

Be careful! The reference you are using seems to be odd.

The current text in the draft says:

4.5. OC-Validity-Duration AVP

   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
   and describes the number of seconds the "new and fresh" OC-OLR AVP
   and its content is valid since the reception of the new OC-OLR AVP.
   The default value for the OC-Validity-Duration AVP value is 5 (i.e.,
   5 seconds).  When the OC-Validity-Duration AVP is not present in the
   OC-OLR AVP, the default value applies.  Validity duration values 0
   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
   Invalid validity duration values are treated as if the OC-Validity-
   Duration AVP were not present.

   A timeout of the overload report has specific concerns that need to
   be taken into account by the endpoint acting on the earlier received
   overload report(s).  Section 4.7 discusses the impacts of timeout in
   the scope of the traffic abatement algorithms.

   As a general guidance for implementations it is RECOMMENDED never to
   let any overload report to timeout.  Following to this rule, an
   overload endpoint should explicitly signal the end of overload
   condition and not rely on the expiration of the validity time of the
   overload report in the reacting node.  This leaves no need for the
   reacting node to reason or guess the overload condition of the
   reporting node.

I think that the definition of the OC-Validity-Duration AVP should remain independent of the notion of Sequence-Number.
The sequence number does not change the value of the OC-Validity-Duration AVP. It indicates that the OLR has to be updated or not. And if it is, a new duration will be there (either implicit or explicit with the OC-Validity-Duration AVP).

So if something needs to be clarified (I haven't checked), it should be in the handling of the OLR.

Regards,

Lionel 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : jeudi 6 février 2014 16:35 À : dime@ietf.org Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP

This change looks pretty straight forward to me.  I'll add it to the -02 version of the draft unless I hear objections soon.

Steve
On 2/6/14 4:44 AM, dime issue tracker wrote:
#36: OC-Validity-Duration AVP

 In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when  the OC-Validity-Duration AVP needs to be updated is ambiguous.

 Now:
    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
    and describes the number of seconds the OC-OLR AVP and its content is
    valid since the reception of the new OC-OLR AVP (as indicated by the
    OC-Sequence-Number AVP).

 Proposal:
    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
    and describes the number of seconds the OC-OLR AVP and its content is
    valid in relation to the reception of the first OC-OLR AVP with a
    specific sequence number. For a given sequence number, the
    OC-Validity-Duration shall always carry the same value.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime