Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

["Gardella, Maryse (Nokia - FR)" <[e-mail]>]

Hi Yuval,

Thanks for these explanations.


*         With "If the CC client want to work with RFC4006bis only CC server, and want to make sure that the subscription ID is understood by the server, it may set the M-bit. Any RFC4006 server will reply with DIAMETER_AVP_UNSUPPORTED (5001)
=> Does this mean it is acceptable here, for a CC client to use the same application ID, extended with a new AVP and M-bit set, based on "CC Application-level requirement" consideration? i.e. and not considering the rejection as a backward compatibility issue?

*         With "If the CC client is not sure whether the CC servers are RFC4006 or RFC4006bis... it may not set the M-bit

o   In this case it would send both AVPs for the old types, so that the new AVP will be ignored by the RFC4006 servers

=> what would be the RFC4006bis server behavior receiving 2 AVPs with old type?

o   In a case of a new type of subscription, not covered in RFC4006,
it may send the new AVP with the M-bit set, causing any old server to reply with DIAMETER_AVP_UNSUPPORTED (5001).

=> same Q as for first bullet

it may also send the new AVP without the M-bit set, here the server would just ignore the AVP, but would probably reply DIAMETER_MISSING_AVP (5005) as it will not have any subscription ID

=> is it really the case the RFC4006bis server could alternatively, instead of ignoring the AVP, send an Error? Based on application level decision?


I am just trying to understand the implication of the "may", and especially if it is really a mean to avoid creating a new Application Id while complying  with the rule, and also in case of M-bit not set, if possible for a server to reply with an error (instead of ignoring) if AVP not understood.

Maryse

From: Yuval Lifshitz [mailto:[e-mail]]
Sent: mercredi 25 janvier 2017 09:30
To: Gardella, Maryse (Nokia - FR) <[e-mail]>; [e-mail]
Cc: Yuval Lifshitz <[e-mail]>
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Maryse,
The idea is the following:

*         If the CC client want to work with RFC4006bis only CC server, and want to make sure that the subscription ID is understood by the server, it may set the M-bit. Any RFC4006 server will reply with DIAMETER_AVP_UNSUPPORTED (5001)

*         If the CC client is not sure whether the CC servers are RFC4006 or RFC4006bis, or have a mix of servers, and want to work with both, it may not set the M-bit

o   In this case it would send both AVPs for the old types, so that the new AVP will be ignored by the RFC4006 servers

o   In a case of a new type of subscription, not covered in RFC4006, it may send the new AVP with the M-bit set, causing any old server to reply with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP without the M-bit set, here the server would just ignore the AVP, but would probably reply DIAMETER_MISSING_AVP (5005) as it will not have any subscription ID

Yuval

From: Gardella, Maryse (Nokia - FR) [mailto:[e-mail]]
Sent: Tuesday, January 24, 2017 5:25 PM
To: Yuval Lifshitz; [e-mail]<mailto:[e-mail]>
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

Thanks for continuing on this.
I am not sure to understand the difference between "may" and "must", since with  "May" we can end having the M-bit set by the RFC4006bis CC client.
I guess from the protocol's perspective "may" and "must" makes no difference right?

BR
Maryse

From: DiME [mailto:[e-mail]] On Behalf Of Yuval Lifshitz
Sent: vendredi 13 janvier 2017 15:24
To: [e-mail]<mailto:[e-mail]>
Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi All,
As part of the RFC4006bis work there are several AVPs that we plan on making future proof (See also: https://trac.ietf.org/trac/dime/ticket/95). For example, Subscription-Id AVP cannot be extended to new types without changing the enumeration in Subscription-Id-Type AVP, which in turn requires a new application ID (something we really want to avoid).
To solve this issue we propose adding a new, extendable AVP. In this example:

Subscription-Id-Extension ::= < AVP Header: XXX >
                             [ Subscription-Id-E164 ]
                             [ Subscription-Id-IMSI ]
                             [ Subscription-Id-SIP-URI ]
                             [ Subscription-Id-NAI ]
                             [ Subscription-Id-Private ]
                            *[ AVP ]

When looking into Subscription-ID-Extension AVP  header flags I ran into a problem. The existing Subscription-ID AVP (and its sub-AVPs) are all marked with the M-bit as a "must", probably because they hold the subscriber's name which is critical information.
However, in order for a RFC4006bis CC client to be able to communicate with an RFC4006 CC-server, they will have to be marked as "may".

Would appreciate your point of view on that topic?

Best Regards,

Yuval