Subject: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features

From: "dime issue tracker" <[email-masked]>
Date: Tue, 04 Feb 2014 08:46:15 -0000

#29: OC-Sequence-Number in OC-Supported-Features

 According to the current definition of the OC-Supported-Features AVP in
 the -01 draft, the OC-Supported-Features AVP contains an OC-Sequence-
 Number AVP.
 The author of this document believes that OC-Sequence-Number within OC-
 Supported-Feature is  not needed, is useless and could be misleading and
 therefore proposes to remove OC-Sequence-Number from OC-Supported-Feature.

 The -01 draft says in clause 4.1:
    The OC-Sequence-Number AVP is used to indicate whether the contents
    of the OC-Supported-Features AVP has changed since last time the node
    included the OC-Supported-Features AVP (see Section 4.4).  Although
    sending the OC-Sequence-Number AVP is mandatory in the OC-Supported-
    Features AVP, the receiving node MAY always choose to ignore the
    sequence number if it can determine the feature support changes
    otherwise.

 The text seems to imply that the reporting DOIC endpoint, when receiving
 an application request message that contains an OC-Supported-Features AVP,
 needs to determine whether a feature support change occured (either by
 checking the value of the received sequence-number (probably) against a
 stored value, or by other unspecified means). However,  this is not
 correct. The reporting DOIC endpoint may  ignore the sequence-number even
 if it cannot determine whether or not a feature support change occured:
 The reporting DOIC endpoint simply takes the value of the OC-Feature-
 Vector as received in the request  into account (if absent the default
 value applies) when processing the request.  There is no need for the
 reporting DOIC endpoint to know whether a previous request contained the
 same or a different value in OC-Feature-Vector, i.e. whether there was a
 recent change.
 It has been argued that the reporting DOIC endpoint may (optionally)
 benefit from the presence of a Sequence-Number within OC-Supported-
 Features: The reporting DOIC endpoint may have stored the Sequence-Number
 and Feature-Vector as received in a previous request, and when receiving a
 new request the reporting DOIC endpoint would compare the received
 Sequence-Number from the new request  with the stored Sequence-Number;  If
 they match (i.e. no change of supported features occured) the reporting
 DOIC endpoint would ignore the received Feature-Vector from the new
 request and use the stored Feature-Vector for further processing; if they
 don't match (i.e. a change of supported features occured), the reporting
 DOIC endpoint would update the stored Sequence-Number and Feature-Vector
 with the received values from the new request and use the updated Feature-
 Vector for further processing. While it is debatable whether the described
 usecase is reasonable, the following issues have not been addressed:
 In configurations where the client does not support DOIC, an agent (A1) on
 a path from client to reporting DOIC endpoint (e.g. server) may take the
 role of a reacting DOIC endpoint and insert an OC-Supported-Features AVP
 in the (first) request message indicating its supported features.  A
 subsequent request message sent from the same client to the same server
 may take another path on which another agent (A2) takes the role of the
 reacting DOIC endpoint. A2 then inserts an OC-Supported-Features AVP in
 the subsequent request message indicating its supported features (which
 may be different from A1's supported features but may have the same
 sequence number).  Since the reporting DOIC endpoint (e.g.server) - when
 receiving the subsequent request - cannot know whether the the reacting
 DOIC endpoint that inserted the OC-Supported-Features AVP in the
 subsequent request is identical to or different from the reacting DOIC
 endpoint that inserted the OC-Supported-Features AVP in the first request,
 it may frequently occure that the reporting DOIC endpoint receives request
 messages containing an OC-Supported-Features AVP with a Sequence-Number
 valuelower than the stored value (which may be interpreted as error), or
 equal to the stored value but with a different associated Feature Vector,
 or higher than the stored value but unmodified Feature Vector.

 In summary, the Sequence-Number within OC-Supported-Features is of no
 earthly use since the reporting DOIC endpoint cannot associate a received
 Sequence-Number (within OC-Supported-Features) with the identity of the
 reacting DOIC endpoint that sent the Sequence-Number.  Even when such
 association was possible by enhancing the OC-Supported-Features AVP with
 the Diameter Identity of the reacting DOIC endpoint that generated the
 Sequence-Number,  it would still simply not be needed as the reporting
 DOIC endpoint can base its processing on the received Feature-Vector
 (rather than on a stored Feature Vector).
 It is therefore proposed to remove the OC-Sequence-Number AVP from the OC-
 Supported Features AVP.

-- 
----------------------------------------------+--------------------------
 Reporter:  [email-masked]  |      Owner:  Ulrich Wiehe
     Type:  defect                            |     Status:  new
 Priority:  major                             |  Milestone:
Component:  draft-docdt-dime-ovli             |    Version:  2.0
 Severity:  Active WG Document                |   Keywords:
----------------------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/29>
dime <http://tools.ietf.org/wg/dime/>

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 09:10:25 +0000

This makes sense.
I agree to remove it.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de dime issue tracker
Envoyé : mardi 4 février 2014 09:46
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features

_______________________________________________
DiME mailing list
[email-masked]
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.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 10:01:20 +0200

Finally catching up with these.. see inline.

> same or a different value in OC-Feature-Vector, i.e. whether there was a

This is true for the current default algorithm. May not be true in the
future. Note, in IETF space versioning Diameter applications is not that
straight forward as in 3GPP, thus I would rather have forward looking
solution, even if that in places would mean "placeholder" AVPs.

> sequence number).  Since the reporting DOIC endpoint (e.g.server) - when

Since seq-no is NTP time, this would not happen, excluding cases
where clocks either in A1 or A2 are wrong. But that is a different
issue then..

> endpoint that inserted the OC-Supported-Features AVP in the first request,

Right.

> or higher than the stored value but unmodified Feature Vector.

See the above comment on the NPT.

> (rather than on a stored Feature Vector).

I buy the reasoning for the lack of binding between the reacting node
identity and the supported features AVP.

However, we should not assume that _all_ implementations will behave
as expected above i.e. not storing the feature vector.

> It is therefore proposed to remove the OC-Sequence-Number AVP from the OC-

I have no (more) strong view here. If folks are OK to remove
the seq-no, so be it.

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 11:24:22 -0600

If we agree that the lifetime of the OC-Supported-Features capability
advertisement is a single transaction then the utility of the sequence
number is reduced. 

My reason for pushing for having the sequence number originally was
based on the assumption that the capability advertised by a reacting
node was semi permanent.  While there might be no earthly use, the
heavenly use was to decrease the work for reporting nodes needing to
parse the AVP on every request received. 

It is still the case that the OC-Supported-Features AVP contents will
almost never change.  The contents of the AVP will also become more
complex as new extensions are defined.  The value of the sequence number
is to allow a reporting node to save the advertisement and not parse the
full content of the AVP unless the sequence number changes. 

I still think there is enough value in the reduced work on a reporting
node to keep the sequence number.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 11:32:26 +0000

Steve,

the use case you are describing requires more than just a sequence number within OC-Supported-Features. It also requires to add the Diameter identity of the reacting node (which inserted the OC-Supported-Features AVP)  to the OC-Supported-Features AVP.

Even with this mechanism in place, reporting nodes still would need to parse the OC-Supported-Features AVP to read Sequence-Number and Diameter Identity to check whether it is a replay. Also reporting nodes would need to maintain a database of reacting nodes.

Also, once a replay is detected, what is the benefit to process the stored Feature-Vector rather than the replayed Feature-Vector?

Overall the concept does not decrease work for reporting nodes and does not provide any benefit.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, February 10, 2014 6:24 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #29: OC-Sequence-Number in OC-Supported-Features

If we agree that the lifetime of the OC-Supported-Features capability advertisement is a single transaction then the utility of the sequence number is reduced.

My reason for pushing for having the sequence number originally was based on the assumption that the capability advertised by a reacting node was semi permanent.  While there might be no earthly use, the heavenly use was to decrease the work for reporting nodes needing to parse the AVP on every request received.

It is still the case that the OC-Supported-Features AVP contents will almost never change.  The contents of the AVP will also become more complex as new extensions are defined.  The value of the sequence number is to allow a reporting node to save the advertisement and not parse the full content of the AVP unless the sequence number changes.

I still think there is enough value in the reduced work on a reporting node to keep the sequence number.

Steve

On Feb 4, 2014, at 10:46 AM, dime issue tracker <[email-masked]><mailto:[email-masked]> wrote:

Number AVP.

   otherwise.

recent change.

issue then..

Right.

Supported Features AVP.

the seq-no, so be it.

- Jouni

--

Reporter:  [email-masked]<mailto:[email-masked]>  |      Owner:  Ulrich Wiehe

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/29><http://trac.tools.ietf.org/wg/dime/trac/ticket/29>

dime <http://tools.ietf.org/wg/dime/><http://tools.ietf.org/wg/dime/>

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>