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

[Yuval Lifshitz <[e-mail]>]

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]
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