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

Hi Maria Cruz,

I'm fine with the proposed clarification.
My point is that some parts belong to the handling of the OLR itself and some other to the definition of the Validity duration.

Here is a proposal for clarification. Let me know if it covers your concern.

Regards,

Lionel

*******************

4.3. OC-OLR AVP

[skip]

   The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.
   It is possible to replay the same OC-OLR AVP multiple times between
   the overload control endpoints, however, when the OC-OLR AVP content
   changes or sending endpoint otherwise wants the receiving endpoint to
   update its overload control information, then the OC-Sequence-Number
   AVP MUST contain a new greater value than the previously received.
   The receiver SHOULD discard an OC-OLR AVP with a sequence number that
   is less than previously received one.

[New]

   The OC-Validity-Duration AVP indicates the validity time of the overload
   report associated with a specific sequence number, measured after reception
   of the OC-OLR AVP. The validity time MUST NOT be updated after reception 
   of subsequent OC-OLR AVPs with the same sequence number. 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.

[Skip]

4.5. OC-Validity-Duration AVP

OLD:
   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.

NEW:
   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
   and indicates in seconds the validity time of the overload report.
   The number of seconds is measured after reception of the first 
   OC-OLR AVP with a given value of OC-Sequence-Number AVP. 
   The default value for the OC-Validity-Duration AVP is 5 (i.e.,
   5 seconds).  When the OC-Validity-Duration AVP is not present in the
   OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values 0
   (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used.
   When invalid values are used, the default value for the OC-Validity-Duration
   AVP applies.

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : vendredi 7 février 2014 08:38
À : dime@ietf.org
Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Hello Lionel, all,

I would like to clarify what  "new and fresh", or even only "new" OC-OLR AVP mean in the text.
It should be understood that it does not refer to the new (latest) received AVP, but just the one that contains (potentially) new values, what only happens for a new Sequence Number. In that line is the proposed text I provided.

Best regards
/MCruz

-----Original Message-----
From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
Sent: viernes, 07 de febrero de 2014 8:33
To: dime@ietf.org; Maria Cruz Bartolome
Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Hi,

My point is just to say that we should make the difference between the definition and the use of the AVP.

And about the clarification, I would say that it is rather about how to populate the OC-OLR AVP or when a new sequence number should be used.

Regards,

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> a écrit :

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
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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

_________________________________________________________________________________________________________________________

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.