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

From: Yuval Lifshitz <[email-masked]>
Date: Fri, 13 Jan 2017 14:24:25 +0000

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

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Tue, 24 Jan 2017 15:25:21 +0000

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:[email-masked]] On Behalf Of Yuval Lifshitz
Sent: vendredi 13 janvier 2017 15:24
To: [email-masked]
Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi All,

Best Regards,

Yuval

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 25 Jan 2017 08:29:55 +0000

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:[email-masked]]
Sent: Tuesday, January 24, 2017 5:25 PM
To: Yuval Lifshitz; [email-masked]
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

BR
Maryse

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

Hi All,

Best Regards,

Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Sun, 29 Jan 2017 00:07:13 +0300

Hi Yuval,

May I ask you several questions to be able to understand the whole
situation:

1. Why are you proposing to add new extendable AVPs only for *some *of the
AVPs listed in section 12?
I think the same concern is applicable for all these AVPs, isn't?

2. Could you clarify what official procedure to assign new available values
is meant here?
It is not working w/o defining new Application-ID as you mentioned above?

12.16.  Subscription-Id-Type AVP

   As defined in Section 8.47, the Subscription-Id-Type AVP includes
   Enumerated type values 0 - 4.  IANA has created and is maintaining a
   namespace for this AVP.  All remaining values are available for
   assignment by a Designated Expert [RFC2434].

Excuse me in advance if what I'm asking about are well-known things.
But still please clarify them at least for me...

Thanks a lot in advance!

/Misha

2017-01-25 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]>:

> ·         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:[email-masked]]
> *Sent:* Tuesday, January 24, 2017 5:25 PM
> *To:* Yuval Lifshitz; [email-masked]
> *Subject:* RE: RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
>
>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Yuval Lifshitz
> *Sent:* vendredi 13 janvier 2017 15:24
> *To:* [email-masked]
> *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).
>
> 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”.
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>

---

From: Yuval Lifshitz <[email-masked]>
Date: Sun, 29 Jan 2017 08:29:33 +0000

Hi Misha,
There is nothing “well known” in these issues and I’ll be happy to clarify!

(1) During IETF96 a question came regarding the support of the IMEI user equipment type – currently not one of the enumerated types of the User-Equipment-Info-Type AVP (IMEISV is there but not IMEI). As a result of this discussion, and due to the enum extension limitations (see here: https://tools.ietf.org/html/rfc7423#section-5.6), we were asked to do an analysis on which enumerated AVPs requires extensibility. The results were captured in the following ticket: https://trac.ietf.org/trac/dime/ticket/95  
For better clarity I’m posting here the actual analysis of AVPs. Some of them didn’t need to be extensible (in our view), some of them were already extensible and the rest were added to the ticket:

                     AVP  Section           
   Attribute Name    Code Defined Data Type 
   -----------------------------------------
   CC-Money          413  8.22   Grouped    - not extensible, does not need to be
   Cost-Information  423  8.7    Grouped    - not extensible, does not need to be
   Final-Unit-       430  8.34   Grouped    - not extensible, will be replaced by QoS-Final-Unit-Indication that will be extensible
     Indication                             
   Granted-Service-  431  8.17   Grouped    - extensible
     Unit                                   
   G-S-U-Pool-       457  8.30   Grouped    - not extensible, does not need to be
     Reference                              
   Multiple-Services 456  8.16   Grouped    - extensible
    -Credit-Control                         
   Redirect-Server   434  8.37   Grouped    - not extensible, has a problem similar to equipment type as it contains an enumerated type/value AVPs
   Requested-Service 437  8.18   Grouped    - extensible
     -Unit                                  
   Service-Parameter 440  8.43   Grouped    - not extensible, does not need to be
     -Info                                  
   Subscription-Id   443  8.46   Grouped    - not extensible, has a problem similar to equipment type as it contains an enumerated type/value AVPs
   Unit-Value        445  8.8    Grouped    - not extensible, does not need to be
   Used-Service-Unit 446  8.19   Grouped    - extensible
   User-Equipment    458  8.49   Grouped    - not extensible, will be replaced by an AVP that will be extensible
     -Info                                  

Would appreciate your comments if you think differently about any of the AVPs above, or that we have missed other AVPs that needs to.

(2) E.g adding new subscription ID. 

Unlike Subscription-Id-Type AVP which cannot be extended to a new type without a new application ID, a new AVP being proposed in RFC4006bis is:

So, in order to add a new type (post RFC4006bis), you would need to submit draft with an AVP definition in it to could be added to the Subscription-Id-Extension as it is extensible.
This new draft would be compliant with RFC4006bis and will therefore not require a new application ID.

Best Regards,

Yuval

From: Misha Zaytsev [mailto:[email-masked]] 
Sent: Saturday, January 28, 2017 11:07 PM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

May I ask you several questions to be able to understand the whole situation:

1. Why are you proposing to add new extendable AVPs only for some of the AVPs listed in section 12?
I think the same concern is applicable for all these AVPs, isn't?

2. Could you clarify what official procedure to assign new available values is meant here?
It is not working w/o defining new Application-ID as you mentioned above?

Thanks a lot in advance!

/Misha

2017-01-25 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]>:
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

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

Hi All,

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”. 

Best Regards,
 
Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Sun, 29 Jan 2017 21:20:44 +0300

Hi Yuval,

Thanks a lot for your clarifications! Now it seems I see your concern.

As I can see the problem is that there is no possibility to extend the
defined AVPs of type Enumerated in a backward compatible way. For me it
means that all enumerate AVPs defined in RFC4006 (listed in section 12) is
a matter of your investigation. Not the grouped ones, but the ones that are
used as indicators in these grouped AVPs.

Following the recommendations in https://tools.ietf.org/html/
rfc7423#section-5.6 that you pointed out, I think bitmask based AVPs may be
a way out in the current situation. Such AVP will be marked as mandatory.
While only one bit of this bitmask MUST be set.

 Subscription-Id-Extension ::= < AVP Header: XXX >
                             [ Subscription-Id-Type-Indicator ]
                             [Subscrition-Id-Data]

Have you considered this option? Or probably I'm missing something..

However, if we follow the way you are proposing with several mutually
exclusive AVPs, then these AVPs should be marked as not mandatory. While in
the description of the appropriate grouped AVP it should be stated that
only one of these AVPs MUST be present.

/Misha

2017-01-29 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]>:

> (1) During IETF96 a question came regarding the support of the IMEI user
> equipment type – currently not one of the enumerated types of the
> User-Equipment-Info-Type AVP (IMEISV is there but not IMEI). As a result of
> this discussion, and due to the enum extension limitations (see here:
> https://tools.ietf.org/html/rfc7423#section-5.6), we were asked to do an
> analysis on which enumerated AVPs requires extensibility. The results were
> captured in the following ticket: https://trac.ietf.org/trac/
> dime/ticket/95
> For better clarity I’m posting here the actual analysis of AVPs. Some of
> them didn’t need to be extensible (in our view), some of them were already
> extensible and the rest were added to the ticket:
>
>                      AVP  Section
>    Final-Unit-       430  8.34   Grouped    - not extensible, will be
> replaced by QoS-Final-Unit-Indication that will be extensible
>      Indication
>    Redirect-Server   434  8.37   Grouped    - not extensible, has a
> problem similar to equipment type as it contains an enumerated type/value
> AVPs
>    Subscription-Id   443  8.46   Grouped    - not extensible, has a
> problem similar to equipment type as it contains an enumerated type/value
> AVPs
>    User-Equipment    458  8.49   Grouped    - not extensible, will be
> replaced by an AVP that will be extensible
>      -Info
>
> Would appreciate your comments if you think differently about any of the
> AVPs above, or that we have missed other AVPs that needs to.
>
> Unlike Subscription-Id-Type AVP which cannot be extended to a new type
> without a new application ID, a new AVP being proposed in RFC4006bis is:
>
> So, in order to add a new type (post RFC4006bis), you would need to submit
> draft with an AVP definition in it to could be added to the
> Subscription-Id-Extension as it is extensible.
> •         If the CC client want to work with RFC4006bis only CC server,
> •         If the CC client is not sure whether the CC servers are RFC4006

---

From: Yuval Lifshitz <[email-masked]>
Date: Mon, 30 Jan 2017 08:29:21 +0000

Hi Misha,
We didn’t consider the option of using a bitmap, but I’m open to this idea. IMO, it would be more difficult managing the addition of new values in the case of a bitmap than in the case of adding new AVPs.  OTOH, adding a bitmap will be less changes to the RFC.
In our proposal the AVPs are marked as optional, and the M-bit *may* be set. I sent an explanation to Maryse on the M-bit – please see below, and let me know if you have comments on that.
As ABNF cannot show the concept of “one and only one AVP” I will update the text to state that explicitly (added: https://github.com/lbertz02/rfc4006bis/issues/18)

Yuval

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Sunday, January 29, 2017 8:21 PM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

As I can see the problem is that there is no possibility to extend the defined AVPs of type Enumerated in a backward compatible way. For me it means that all enumerate AVPs defined in RFC4006 (listed in section 12) is a matter of your investigation. Not the grouped ones, but the ones that are used as indicators in these grouped AVPs.

Following the recommendations in https://tools.ietf.org/html/rfc7423#section-5.6 that you pointed out, I think bitmask based AVPs may be a way out in the current situation. Such AVP will be marked as mandatory. While only one bit of this bitmask MUST be set.

However, if we follow the way you are proposing with several mutually exclusive AVPs, then these AVPs should be marked as not mandatory. While in the description of the appropriate grouped AVP it should be stated that only one of these AVPs MUST be present.

/Misha

2017-01-29 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>:
Hi Misha,
There is nothing “well known” in these issues and I’ll be happy to clarify!

                     AVP  Section

Best Regards,

Yuval

From: Misha Zaytsev [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, January 28, 2017 11:07 PM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

Thanks a lot in advance!

/Misha

2017-01-25 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>:
Hi Maryse,

Yuval

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

Hi Yuval,

BR
Maryse

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

Hi All,

Best Regards,

Yuval

_______________________________________________
DiME mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dime

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Tue, 31 Jan 2017 16:49:20 +0000

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

=> 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:[email-masked]]
Sent: mercredi 25 janvier 2017 09:30
To: Gardella, Maryse (Nokia - FR) <[email-masked]>; [email-masked]
Cc: Yuval Lifshitz <[email-masked]>
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Maryse,

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Tue, 31 Jan 2017 23:07:11 +0300

Hi Yuval,

I almost agree with your explanations that you sent to Maryse, except one
bullet:

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

RFC4006 server should not reply with DIAMETER_MISSING_AVP (5005) result
code according to RFC6733, since Subscription-Id AVP is *not* marked as
required in CCR definition:

      A received command that is missing AVPs that are defined as
      required in the commands CCF; examples are AVPs indicated as
      *{AVP}*.  The receiver issues an answer with the Result-Code set to
      DIAMETER_MISSING_AVP and creates an AVP with the AVP Code and
      other fields set as expected in the missing AVP.  The created AVP
      is then added to the Failed-AVP AVP.

The remaining part is according to the RFC6733 from my point of view.

All in all, to set M-bit or not, depends on what reaction you want to
see from RFC4006 server.

/Misha

2017-01-30 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]>:

> Hi Misha,
>
> We didn’t consider the option of using a bitmap, but I’m open to this
> idea. IMO, it would be more difficult managing the addition of new values
> in the case of a bitmap than in the case of adding new AVPs.  OTOH, adding
> a bitmap will be less changes to the RFC.
>
> In our proposal the AVPs are marked as optional, and the M-bit **may** be
> set. I sent an explanation to Maryse on the M-bit – please see below, and
> let me know if you have comments on that.
>
> As ABNF cannot show the concept of “one and only one AVP” I will update
> the text to state that explicitly (added: https://github.com/lbertz02/
> rfc4006bis/issues/18)
>
>
>
> Yuval
>
>
>
> *From:* Misha Zaytsev [mailto:[email-masked]]
> *Sent:* Sunday, January 29, 2017 8:21 PM
>
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); [email-masked]
> *Subject:* Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
>
>
> Following the recommendations in https://tools.ietf.org/
> html/rfc7423#section-5.6 that you pointed out, I think bitmask based AVPs
> may be a way out in the current situation. Such AVP will be marked as
> mandatory. While only one bit of this bitmask MUST be set.
>
>
>