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

From: Misha Zaytsev <[email-masked]>
Date: Mon, 6 Feb 2017 22:36:21 +0300

Hi Yuval,

Just wondering what will be the outcome of this discussion?
Have you concluded how it would be better to handle new future proof AVPs?
If yes, are you going to update the draft with this info included?

Thanks in advance!

/Misha

2017-01-31 23:07 GMT+03:00 Misha Zaytsev <[email-masked]>:

> 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/rf
>> c4006bis/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,
>>
>>
>>
>> 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]>:
>>
>> 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/dim
>> e/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:
>>
>>   Subscription-Id-Extension ::= < AVP Header: XXX >
>>                              [ Subscription-Id-E164 ]
>>                              [ Subscription-Id-IMSI ]
>>                              [ Subscription-Id-SIP-URI ]
>>                              [ Subscription-Id-NAI ]
>>                              [ Subscription-Id-Private ]
>>                            *[ AVP ]
>>
>> 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?
>>
>>
>> 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]>:
>> 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,
>>
>> 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,
>> 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
>>
>>
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>>
>>
>
>

---

From: Yuval Lifshitz <[email-masked]>
Date: Mon, 6 Feb 2017 20:30:39 +0000

Hi Misha,
RFC6733 gives the “{}” notation just as an example for a required AVP, it does not say it is the only trigger for the missing AVP error. There are AVPs that are marked as optional in ABNF, but are actually required in some cases (e.g. Termination-Cause AVP). Also, note that RFC4006 says:
The Subscription-Id AVP SHOULD be included to identify the
   end user in the credit-control server.

Regardless of that, since it is not strictly defined in the spec I can rephrase my answer as:

“

In a case of a new type of subscription, not covered in RFC4006, the credit-control 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, or, in the case that this AVP is required for its operation, reply with an error message (e.g. DIAMETER_MISSING_AVP)
”

So far, I didn’t think the above clarification needs to be added to the spec, but I can add that if you and Maryse feel that it would make it easier to understand when to set the M-bit for these AVPs.

Yuval

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Monday, February 06, 2017 9:36 PM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

Thanks in advance!

/Misha

2017-01-31 23:07 GMT+03:00 Misha Zaytsev <[email-masked]<mailto:[email-masked]>>:
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:

      {AVP}.  The receiver issues an answer with the Result-Code set to

/Misha

2017-01-30 11:29 GMT+03:00 Yuval Lifshitz <[email-masked]<mailto:[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]<mailto:[email-masked]>]
Sent: Sunday, January 29, 2017 8:21 PM

To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]<mailto:[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!

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

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

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]<mailto:[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

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,

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

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

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

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Wed, 8 Feb 2017 10:46:44 +0000

Hi Yuval,

With the new Subscription-Id-Extension AVP to be marked with the M-bit as a “may”, the way I understand it :
 -  For old types the CC Client would send both Subscription-Id and Subscription-Id-Extension AVPs: Subscription-Id with M-bit set and Subscription-Id-Extension with M-bit cleared, however the behavior for the RFC4006bis CC server when Subscription-Id-Extension is supported is unclear to me)
-  For new types the CC Client would send Subscription-Id-Extension AVP with M-bit set, so that RFC4006 and RFC4006bis server can reject by DIAMETER_AVP_UNSUPPORTED (5001) if not supported, would be the best approach.

Maryse

From: Yuval Lifshitz [mailto:[email-masked]]
Sent: lundi 6 février 2017 21:31
To: Misha Zaytsev <[email-masked]>
Cc: Gardella, Maryse (Nokia - FR) <[email-masked]>; [email-masked]; Yuval Lifshitz <[email-masked]>
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Yuval Lifshitz <[email-masked]>
Date: Sun, 12 Feb 2017 07:19:18 +0000

inline

From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]]
Sent: Wednesday, February 08, 2017 12:47 PM
To: Yuval Lifshitz; Misha Zaytsev
Cc: [email-masked]
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

With the new Subscription-Id-Extension AVP to be marked with the M-bit as a “may”, the way I understand it :
 -  For old types the CC Client would send both Subscription-Id and Subscription-Id-Extension AVPs: Subscription-Id with M-bit set and Subscription-Id-Extension with M-bit cleared, however the behavior for the RFC4006bis CC server when Subscription-Id-Extension is supported is unclear to me)
[yuval] will add following clarification: “RFC4006bis CC server receiving both Subscription-Id AVP and Subscription-Id-Extension AVP SHOULD ignore the Subscription-Id AVP.” IMO, this would be along the lines if the “robustness principal”

-  For new types the CC Client would send Subscription-Id-Extension AVP with M-bit set, so that RFC4006 and RFC4006bis server can reject by DIAMETER_AVP_UNSUPPORTED (5001) if not supported, would be the best approach.
[yuval] agree, will add clarification to the text

Maryse

From: Yuval Lifshitz [mailto:[email-masked]]
Sent: lundi 6 février 2017 21:31
To: Misha Zaytsev <[email-masked]<mailto:[email-masked]>>
Cc: Gardella, Maryse (Nokia - FR) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Mon, 13 Feb 2017 17:19:09 +0000

Hi Yuval,

I now realize the problem I have with the behavior for the RFC4006bis CC server, is more due to missing statements on the RFC4006bis CC client side (e.g. to allow this “robustness principle”).
May be adding a clarification that when only old type(s) are needed to be sent, the CC client should send both: multiple Subscription-Id AVPs and corresponding multiple entries of Subscription-Id-Extension AVP, so that the RFC4006bis CC sever can decide to consider Subscription-Id-Extension AVP only when both are received. Do you think this could be added although it looks a bit heavy?

BR
Maryse

From: Yuval Lifshitz [mailto:[email-masked]]
Sent: dimanche 12 février 2017 08:19
To: Gardella, Maryse (Nokia - FR) <[email-masked]>; Misha Zaytsev <[email-masked]>
Cc: [email-masked]; Yuval Lifshitz <[email-masked]>
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

inline

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

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Yuval Lifshitz <[email-masked]>
Date: Mon, 13 Feb 2017 19:03:17 +0000

The clarification makes sense. Hopefully the text didn’t became too cumbersome - please let me know if you think I should remove any of the text.
Following modified text includes clarifications on the topic of the M-bit as well as sending multiple AVPs.

8.58.  Subscription-Id-Extension AVP

   The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify
   the end user's subscription and is of type Grouped.  The
   Subscription-Id-Extension AVP contains an included AVP holding the
   subscription identifier itself.  The type of this included AVP
   indicates the type of the subscription identifier.  If the type of
   the identifier is one of the types listed in the Subscription-Id-Type
   AVP, then the credit-control client SHOULD send the information in
   the Subscription-Id AVP, in addition to or instead of the
   Subscription-Id-Extension AVP.  If the Subscription-Id-Extension is sent alongside
   the Subscription-Id AVP, its M-bit SHOULD NOT be set. This is in order
   to preserve backward compatibility with credit-control servers that support only RFC4006.
   When a credit control server that supports both Subscription-Id-Extension AVP
   and Subscription-Id AVP receives both AVPs, it SHOULD ignore the Subscription-Id AVP.
   If the type of the identifier is not one of the types listed in the Subscription-Id-Type
   AVP, the credit-control client MAY send the Subscription-Id-Extension AVP

   with the M-bit set, causing a credit control server that supports

   RFC4006 only, to reply with DIAMETER_AVP_UNSUPPORTED. The credit

   control client MAY send the Subscription-Id-Extension AVP without the M-bit set,

   in this case, an RFC4006 only credit control server, SHOULD ignore the

   Subscription-Id-Extension AVP.
   Exactly one AVP MUST be included inside the Subscription-Id-Extension
   AVP.

   It is defined as follows (per the grouped-avp-def of [RFC6733]):

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

From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]]
Sent: Monday, February 13, 2017 7:19 PM
To: Yuval Lifshitz; Misha Zaytsev
Cc: [email-masked]
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

BR
Maryse

From: Yuval Lifshitz [mailto:[email-masked]]
Sent: dimanche 12 février 2017 08:19
To: Gardella, Maryse (Nokia - FR) <[email-masked]<mailto:[email-masked]>>; Misha Zaytsev <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Yuval Lifshitz <[email-masked]>
Date: Thu, 16 Feb 2017 16:40:45 +0000

Any comment on the text below?
If none, I’ll just move ahead with the changes.

From: Yuval Lifshitz
Sent: Monday, February 13, 2017 9:03 PM
To: Gardella, Maryse (Nokia - FR); Misha Zaytsev
Cc: [email-masked]; Yuval Lifshitz
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Thu, 16 Feb 2017 16:57:33 +0000

Hi Yuval,
Sorry for the delay, I will have comments, I am still working on them.

Thanks
Maryse

Sent: jeudi 16 février 2017 17:41

From: Yuval Lifshitz
Sent: Monday, February 13, 2017 9:03 PM
To: Gardella, Maryse (Nokia - FR); Misha Zaytsev
Cc: [email-masked]<mailto:[email-masked]>; Yuval Lifshitz
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Thu, 16 Feb 2017 18:24:25 +0000

Hi Yuval,

I think it is not needed to add text for the server side:  the text blue highlighted, this should be governed by M-bit Rule

1)      For
If the Subscription-Id-Extension is sent alongside

   the Subscription-Id AVP, its M-bit SHOULD NOT be set.
      Is it clear that only the Subscription-Id-Extension should not have the M-bit set?

2) For new Types my proposal was to always have the M-bit set (I am not sure we can have scenario with new subscription types which can be handled by RFC4006 servers)

  To have:

If the type of the identifier is not one of the types listed in the Subscription-Id-Type
   AVP, the credit-control client SHOULD send the Subscription-Id-Extension AVP

   with the M-bit set.

3) I also have an issue with:

Exactly one AVP MUST be included inside the Subscription-Id-Extension
   AVP.
  And this is a more general comment to the text: there may be multiple  *[ Subscription-Id ], therefore more than one AVP can be present in Subscription-Id-Extension

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Fri, 17 Feb 2017 12:13:14 +0300

Hi Yuval,

To be honest, I find the Subscription-ID-Extension AVP description is a bit
messy and hard to understand.

Let me formulate the principles I would follow when describing it:

- For old types the legacy Subscription-Id AVP (with M-bit set) SHOULD be
used when communicating with both RFC4006 and/or RFC4006bis server. That
will ensure a backward compatibility.
- For new types the newly defined Subscription-Id-Extension AVP (with M-bit
set) SHOULD be used as a future proof one.
Thus, only RFC4006bis server will handle this AVP, while the legacy one
will reply with AVP_UNSUPPORTED answer.

All in all, future proof AVP - for future use, the legacy AVP - to keep BC.
This interpretation will avoid any "playing" with M-bit and exclude
potential new and legacy AVPs combinations from consideration.

/Misha

2017-02-16 21:24 GMT+03:00 Gardella, Maryse (Nokia - FR) <
[email-masked]>:

> Hi Yuval,
>
>
>
> I think it is not needed to add text for the server side:  the text blue
> highlighted, this should be governed by M-bit Rule
>
>
>
> 1)      For
>
> 2) For new Types my proposal was to always have the M-bit set (I am not
> sure we can have scenario with new subscription types which can be handled
> by RFC4006 servers)
>
>
>
>   And this is a more general comment to the text: there may be multiple
>  *[ Subscription-Id ], therefore more than one AVP can be present in
> Subscription-Id-Extension
>
>
>
>
>
> Thanks
>
> Maryse
>
>
>
> *From:* Yuval Lifshitz [mailto:[email-masked]]
> *Sent:* jeudi 16 février 2017 17:41
> *To:* Gardella, Maryse (Nokia - FR) <[email-masked]>; Misha
> Zaytsev <[email-masked]>
> *Cc:* [email-masked]; Yuval Lifshitz <[email-masked]>
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> *From:* Yuval Lifshitz
> *Sent:* Monday, February 13, 2017 9:03 PM
> *To:* Gardella, Maryse (Nokia - FR); Misha Zaytsev
> *Cc:* [email-masked]; Yuval Lifshitz
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> The clarification makes sense. Hopefully the text didn’t became too
> cumbersome - please let me know if you think I should remove any of the
> text.
>
> *From:* Gardella, Maryse (Nokia - FR) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, February 13, 2017 7:19 PM
> *To:* Yuval Lifshitz; Misha Zaytsev
> *Cc:* [email-masked]
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
>
>
> I now realize the problem I have with the behavior for the RFC4006bis CC
> server, is more due to missing statements on the RFC4006bis CC client side
> (e.g. to allow this “robustness principle”).
>
> May be adding a clarification that when only old type(s) are needed to be
> sent, the CC client should send both: multiple Subscription-Id AVPs and
> corresponding multiple entries of Subscription-Id-Extension AVP, so that
> the RFC4006bis CC sever can decide to consider Subscription-Id-Extension
> AVP only when both are received. Do you think this could be added although
> it looks a bit heavy?
>
>
>
> BR
>
> Maryse
>
>
>
>
>
> *From:* Yuval Lifshitz [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* dimanche 12 février 2017 08:19
> *To:* Gardella, Maryse (Nokia - FR) <[email-masked]>; Misha
> Zaytsev <[email-masked]>
> *Cc:* [email-masked]; Yuval Lifshitz <[email-masked]>
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> *inline*
>
>
>
> *From:* Gardella, Maryse (Nokia - FR) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, February 08, 2017 12:47 PM
> *To:* Yuval Lifshitz; Misha Zaytsev
> *Cc:* [email-masked]
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
>
>
>  -  For old types the CC Client would send both Subscription-Id and
> Subscription-Id-Extension AVPs: Subscription-Id with M-bit set and
> Subscription-Id-Extension with M-bit cleared, however the behavior for the
> RFC4006bis CC server when Subscription-Id-Extension is supported is unclear
> to me)
>
> *[yuval] will add following clarification: “RFC4006bis CC server receiving
> both Subscription-Id AVP and Subscription-Id-Extension AVP SHOULD ignore
> the Subscription-Id AVP.” IMO, this would be along the lines if the
> “robustness principal”*
>
>
>
> -  For new types the CC Client would send Subscription-Id-Extension AVP
> with M-bit set, so that RFC4006 and RFC4006bis server can reject by DIAMETER_AVP_UNSUPPORTED
> (5001) if not supported, would be the best approach.
>
> *[yuval] agree, will add clarification to the text*
>
>
>
> Maryse
>
>
>
>
>
> *From:* Yuval Lifshitz [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* lundi 6 février 2017 21:31
> *To:* Misha Zaytsev <[email-masked]>
> *Cc:* Gardella, Maryse (Nokia - FR) <[email-masked]>;
> [email-masked]; Yuval Lifshitz <[email-masked]>
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Misha,
>
> RFC6733 gives the “{}” notation just as an example for a required AVP, it
> does not say it is the only trigger for the missing AVP error. There are
> AVPs that are marked as optional in ABNF, but are actually required in some
> cases (e.g. Termination-Cause AVP). Also, note that RFC4006 says:
>
> So far, I didn’t think the above clarification needs to be added to the
> spec, but I can add that if you and Maryse feel that it would make it
> easier to understand when to set the M-bit for these AVPs.
>
>
>
> Yuval
>
>
>
> *From:* Misha Zaytsev [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, February 06, 2017 9:36 PM
> *To:* Yuval Lifshitz
> 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.
>
> the text to state that explicitly (added: https://github.com/lbertz02/
> rfc4006bis/issues/18)
>
>
>
> Yuval
>
>
>
> Following the recommendations in https://tools.ietf.org/
> html/rfc7423#section-5.6 that you pointed out, I think bitmask based AVPs
> captured in the following ticket: https://trac.ietf.org/trac/
> dime/ticket/95
> 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
> 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.
> 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.

---

From: Yuval Lifshitz <[email-masked]>
Date: Fri, 17 Feb 2017 13:16:16 +0000

(1)    So lets rephrase as:
If the Subscription-Id-Extension AVP is sent alongside the Subscription-Id AVP, its M-bit
In the Subscription-Id-Extension AVP SHOULD NOT be set.

(2)    Agree. will add your text:
If the type of the identifier is not one of the types listed in the Subscription-Id-Type
   AVP, the credit-control client SHOULD send the Subscription-Id-Extension AVP with the M-bit set.

(3)    ABNF does not allow for “one and only one notation”. So, how about?
In each instance of the Subscription-Id-Extension AVP, exactly one AVP MUST be included.

From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 8:24 PM
To: Yuval Lifshitz; Misha Zaytsev
Cc: [email-masked]
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Yuval Lifshitz <[email-masked]>
Date: Fri, 17 Feb 2017 13:20:31 +0000

inline

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Friday, February 17, 2017 11:13 AM
To: Gardella, Maryse (Nokia - FR)
Cc: Yuval Lifshitz; [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

To be honest, I find the Subscription-ID-Extension AVP description is a bit messy and hard to understand.

- For old types the legacy Subscription-Id AVP (with M-bit set) SHOULD be used when communicating with both RFC4006 and/or RFC4006bis server. That will ensure a backward compatibility.
[yuval] this simplifies the spec, but make it harder to implement. We should allow implementation of client server that uses the new AVP for the old types

- For new types the newly defined Subscription-Id-Extension AVP (with M-bit set) SHOULD be used as a future proof one.
Thus, only RFC4006bis server will handle this AVP, while the legacy one will reply with AVP_UNSUPPORTED answer.
[yuval] agree

All in all, future proof AVP - for future use, the legacy AVP - to keep BC.
This interpretation will avoid any "playing" with M-bit and exclude potential new and legacy AVPs combinations from consideration.
[yuval] same comment as above – this makes it easier to implement

/Misha

2017-02-16 21:24 GMT+03:00 Gardella, Maryse (Nokia - FR) <[email-masked]<mailto:[email-masked]>>:
Hi Yuval,

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz [mailto:[email-masked]<mailto:[email-masked]>]

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Sat, 18 Feb 2017 11:46:47 +0300

Hi Yuval,

Thanks for your comments! But could you clarify this point?

*[yuval] this simplifies the spec, but make it harder to implement. We
should allow implementation of client server that uses the new AVP for the
old types*

What is the reason behind this? Why does it make harder to implement.
Why should we allow to use new AVP for old types if this new AVP is future
proof (for future use)?

Thanks in advance!

/Misha

2017-02-17 16:20 GMT+03:00 Yuval Lifshitz <[email-masked]>:

> *Sent:* Friday, February 17, 2017 11:13 AM
> *To:* Gardella, Maryse (Nokia - FR)
> *Cc:* Yuval Lifshitz; [email-masked]
> *[yuval] this simplifies the spec, but make it harder to implement. We
> should allow implementation of client server that uses the new AVP for the
> old types*
>
>
>
> - For new types the newly defined Subscription-Id-Extension AVP (with
> M-bit set) SHOULD be used as a future proof one.
>
> *[yuval] agree*
> *[yuval] same comment as above – this makes it easier to implement*
>
>
>
> /Misha
>
>
>
>
>

---

From: Yuval Lifshitz <[email-masked]>
Date: Sun, 19 Feb 2017 09:02:20 +0000

Hi Misha,
If the spec says that the CC client has to send the Subscription-Id AVP for the existing types and Subscription-Id-Extension AVP for the new types, then the CC server will have to support both AVPs even if backward compatibility is not needed.
Once the new spec is widely adopted, a CC server implementation could have a configuration parameter indicating that RFC4006-only CC clients are not supported anymore. In this case the Subscription-Id AVP will not be needed anymore, since the old types could be sent using the new AVP.

Hope this clarify,

Yuval

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Saturday, February 18, 2017 10:47 AM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

What is the reason behind this? Why does it make harder to implement.
Why should we allow to use new AVP for old types if this new AVP is future proof (for future use)?

Thanks in advance!

/Misha

2017-02-17 16:20 GMT+03:00 Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>:
inline

Cc: Yuval Lifshitz; [email-masked]<mailto:[email-masked]>

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Sun, 19 Feb 2017 12:38:24 +0300

Hi Yuval,

Thanks for the clarifications!

In my head backward compatibility of CC server is a MUST - that's why I
would follow the specified way.
At least I would keep BC where possible with minimal efforts. In this
particular case keeping BC seems natural for me.

But if new spec has another intention, then you will have to consider where
both legacy and future proof AVPs (carrying old and new types) may be
included in the message.

If you want, I could present my version of new AVP description, but I think
you have all already to do it yourself :)
Sometimes, I just noticed that it is useful to propose your view, since the
formulations is of a matter or preference.
In this case I think that only idea may be a matter of discussion (while it
looks we have just come to agreement).

Best regards,

/Misha

2017-02-19 12:02 GMT+03:00 Yuval Lifshitz <[email-masked]>:

> Hi Misha,
>
> If the spec says that the CC client has to send the Subscription-Id AVP
> for the existing types and Subscription-Id-Extension AVP for the new types,
> then the CC server will have to support both AVPs even if backward
> compatibility is not needed.
>
> Once the new spec is widely adopted, a CC server implementation could have
> a configuration parameter indicating that RFC4006-only CC clients are not
> supported anymore. In this case the Subscription-Id AVP will not be needed
> anymore, since the old types could be sent using the new AVP.
>
>
>
> Hope this clarify,
>
>
>
> Yuval
>
>
>
> *Sent:* Saturday, February 18, 2017 10:47 AM
>
> *To:* Yuval Lifshitz

---

From: Yuval Lifshitz <[email-masked]>
Date: Sun, 19 Feb 2017 11:03:58 +0000

Hi Misha,
The spec has to be written in backward compatible manner, but giving the implementer the freedom on whether to do that or not, would make adoption of it easier. Note that, in case of DCCA, most actual implementations are not based directly on it. They are based on 3GPP TS 32.299, which sometimes modifies the IETF spec, and may decide to treat compatibility differently (3GPP release a major revision to their spec almost every year).
Anyway, would appreciate if you send over your description of the AVP.

Best Regards,

Yuval

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Sunday, February 19, 2017 11:38 AM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

In my head backward compatibility of CC server is a MUST - that's why I would follow the specified way.
At least I would keep BC where possible with minimal efforts. In this particular case keeping BC seems natural for me.

But if new spec has another intention, then you will have to consider where both legacy and future proof AVPs (carrying old and new types) may be included in the message.

If you want, I could present my version of new AVP description, but I think you have all already to do it yourself :)
Sometimes, I just noticed that it is useful to propose your view, since the formulations is of a matter or preference.
In this case I think that only idea may be a matter of discussion (while it looks we have just come to agreement).

Best regards,

/Misha

2017-02-19 12:02 GMT+03:00 Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>:
Hi Misha,
If the spec says that the CC client has to send the Subscription-Id AVP for the existing types and Subscription-Id-Extension AVP for the new types, then the CC server will have to support both AVPs even if backward compatibility is not needed.
Once the new spec is widely adopted, a CC server implementation could have a configuration parameter indicating that RFC4006-only CC clients are not supported anymore. In this case the Subscription-Id AVP will not be needed anymore, since the old types could be sent using the new AVP.

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Misha Zaytsev <[email-masked]>
Date: Mon, 20 Feb 2017 10:58:10 +0300

Hi Yuval,

Here is my version of the Subscription-Id-Extension:

   indicates the type of the subscription identifier. The existing
identifier types are listed in the Subscription-Id-Type

   AVP.

then the credit-control client SHOULD send the information in

   Subscription-Id-Extension AVP.  If the Subscription-Id-Extension is sent
alongside

   to preserve backward compatibility with credit-control servers that
support only RFC4006.

   When a credit control server that supports both
Subscription-Id-Extension AVP

   and Subscription-Id AVP receives both AVPs, it SHOULD ignore the
Subscription-Id AVP.

   If the type of the identifier is not one of the types listed in the
Subscription-Id-Type

   AVP, the credit-control client MAY send the Subscription-Id-Extension
AVP

   control client MAY send the Subscription-Id-Extension AVP without
the M-bit set,

   AVP.

                             [ Subscription-Id-E164 ]

                             [ Subscription-Id-IMSI ]

                             [ Subscription-Id-NAI ]

                            *[ AVP ]

2017-02-19 14:03 GMT+03:00 Yuval Lifshitz <[email-masked]>:

> Hi Misha,
>
> The spec has to be written in backward compatible manner, but giving the
> implementer the freedom on whether to do that or not, would make adoption
> of it easier. Note that, in case of DCCA, most actual implementations are
> not based directly on it. They are based on 3GPP TS 32.299, which sometimes
> modifies the IETF spec, and may decide to treat compatibility differently
> (3GPP release a major revision to their spec almost every year).
>
> *Sent:* Sunday, February 19, 2017 11:38 AM
>
> *To:* Yuval Lifshitz
> But if new spec has another intention, then you will have to consider
> where both legacy and future proof AVPs (carrying old and new types) may be
> included in the message.
>
>
>
> If you want, I could present my version of new AVP description, but I
> think you have all already to do it yourself :)
>
> Sometimes, I just noticed that it is useful to propose your view, since
> the formulations is of a matter or preference.
>
> In this case I think that only idea may be a matter of discussion (while
> it looks we have just come to agreement).
>
>
>
> Best regards,
>
>
>
> /Misha
>
>
>

---

From: Misha Zaytsev <[email-masked]>
Date: Mon, 20 Feb 2017 10:59:51 +0300

Hi All,

Please ignore this mail, it was sent by mistake! Sorry for spamming!

/Misha

2017-02-20 10:58 GMT+03:00 Misha Zaytsev <[email-masked]>:

>> Once the new spec is widely adopted, a CC server implementation could
>> have a configuration parameter indicating that RFC4006-only CC clients are
>> not supported anymore. In this case the Subscription-Id AVP will not be
>> needed anymore, since the old types could be sent using the new AVP.
>>
>>
>>
>> Hope this clarify,
>>
>>
>>
>> Yuval
>>
>>
>>
>> *[yuval] will add following clarification: “RFC4006bis CC server
>> receiving both Subscription-Id AVP and Subscription-Id-Extension AVP SHOULD
>> ignore the Subscription-Id AVP.” IMO, this would be along the lines if the
>> “robustness principal”*
>>
>>
>>

---

From: Misha Zaytsev <[email-masked]>
Date: Mon, 20 Feb 2017 12:23:42 +0300

Hi Yuval,

The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify the
end user's subscription and is of type Grouped.  The
Subscription-Id-Extension AVP contains an included AVP holding the
subscription identifier itself.  The type of this included AVP indicates
the type of the subscription identifier. The existing identifier types are
listed in the Subscription-Id-Type AVP. For each existing identifier type
there is a separate sub-AVP corresponding to it. If a new identifier type
is required a corresponding new sub-AVP SHOULD be defined.

If a full backward compatibility with [RFC4006] is required, then
Subscription-Id
AVP MUST be used to carry out the identifier type. While
Subscription-Id-Extension
AVP MUST be used only for newly defined identifier types.

If a full backward compatibility with [RFC4006] is not required, then
Subscription-Id-Extension
AVP MAY be used to carry out the existing identifier types. In this case,
Subscription-Id-Extension AVP MAY be sent together with Subscription-Id
AVP. If Subscription-Id-Extension AVP M-bit is set, an RFC4006 credit
control server MUST reply with DIAMETER_AVP_UNSUPPORTED. RFC4006bis credit
control server SHOULD prioritize the handling of Subscription-Id-Extension
AVP over Subscription-Id AVP and ignore Subscription-Id AVP if present.

Exactly one sub-AVP MUST be included inside the Subscription-Id-Extension
AVP.

                             [ Subscription-Id-E164 ]

                             [ Subscription-Id-IMSI ]

                             [ Subscription-Id-NAI ]

                            *[ AVP ]

Best regards

/Misha

2017-02-20 10:59 GMT+03:00 Misha Zaytsev <[email-masked]>:

>>> - For old types the legacy Subscription-Id AVP (with M-bit set) SHOULD
>>> be used when communicating with both RFC4006 and/or RFC4006bis server. That
>>> I think it is not needed to add text for the server side:  the text
>>> blue highlighted, this should be governed by M-bit Rule
>>>
>>>
>>>
>>> 1)      For
>>>
>>> May be adding a clarification that when only old type(s) are needed to
>>> be sent, the CC client should send both: multiple Subscription-Id AVPs and
>>> RFC6733 gives the “{}” notation just as an example for a required AVP,
>>> it does not say it is the only trigger for the missing AVP error. There are
>>> 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/dim
>>> e/ticket/95
>>> •         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

---

From: Misha Zaytsev <[email-masked]>
Date: Mon, 20 Feb 2017 23:00:10 +0300

Hi Maryse and Yuval,

I agree with your counter proposals of my version.
Just a minor comment: I'm still thinking that the last statement is
sufficient in the following form:

There is no need to explicitly specify that this statement is valid for
each Subscription-Id-Extension AVP instance since this is the description
of such an instance. If there are multiple instances, the same statement is
valid for each one. Isn't it?

/Misha

2017-02-20 19:40 GMT+03:00 Gardella, Maryse (Nokia - FR) <
[email-masked]>:

> See my replies [mga]
> *Sent:* lundi 20 février 2017 15:41
> *Inline*
> *Sent:* Monday, February 20, 2017 4:27 PM
> Hi Misha, Yuval,
> -       I am ok in general as soon as it is clearly specified that second
> option is not backward compatible.
>
> *[yuval] I think that the text proposed by Misha is quite clear: **If
> full backward compatibility with [RFC4006] is not required...*
>
> [mga] Agree
>
>
>
> -       I also think there is no need to have explicitly statement for CC
> server, even the one on M-bit:  I am expecting the M-bit rule to apply as
> usual, since the Subscription-Id-Extension AVP will always have the M-bit
> set. I understand this will be reflected
>
> in the table chapter 8. , similarly as:
>
> *[yuval] I’m ok with removing the text regarding the server, agree it does
> not add too much. *
>
> *Note that, the M-bit for the Subscription-Id-Extension AVP is checked
> under the “may” column and not the “must” columns. If the CC-client want to
> be compatible with RFC4006 CC-server, but still sent the
> Subscription-Id-Extension AVP (e.g. if it does not know if the server is
> RFC4006 only or not) it should send it without the M-bit.*
>
>
>
> [mga] OK, I understand now this is to cover the second option, for the
> CC-client being able to send existing types in both Subscription-Id AVP
> and Subscription-Id-Extension AVP, and this would be the only case.
>
>
>
> -       May be I missed something, but I fail to understand the logic of
> having multiple Subscription-Id-Extension AVPs, each with a single sub-AVP,
> instead of one Subscription-Id-extension AVP with multiple sub-AVPs.
>
> *[yuval] don’t have strong preference for one way or the other. Proposed
> to have multiple instances of Subscription-Id-Extension AVP because this is
> how Subscription-Id AVP works – just to minimize changes.*
>
> [mga] OK to keep it as proposed.
>
>
>
> Thanks
>
> Maryse
>
>
>
> *Sent:* lundi 20 février 2017 14:43
> Looks good.
> * Added the clarification regarding the fact that multiple instances of
> the AVP may exist
>
> * Don’t think the recommendation for the RFC4006bis server is needed, I
> think it their decision how to prioritize in this case
>
> If a full backward compatibility with [RFC4006] is required, then Subscription-Id
> AVP MUST be used to carry out the identifier type*s listed in the **Subscription-Id-Type
> AVP*. While Subscription-Id-Extension AVP MUST be used only for newly
> defined identifier types. *In such a case the M-bit MUST be set for the
> Subscription-Id-Extension AVP.*
>
> Subscription-Id-Extension AVP MAY be used to carry out the existing
> identifier types. In this case, Subscription-Id-Extension AVP MAY be sent
> together with Subscription-Id AVP.
>
> If Subscription-Id-Extension AVP M-bit is set, an RFC4006 credit control
> server MUST reply with DIAMETER_AVP_UNSUPPORTED. RFC4006bis credit
> Exactly one sub-AVP MUST be included inside *each instance of* the
> *Sent:* Monday, February 20, 2017 11:24 AM
> *To:* Yuval Lifshitz
> If a full backward compatibility with [RFC4006] is required, then Subscription-Id
> Subscription-Id-Extension AVP MUST be used only for newly defined
> identifier types.
>
>
>
> Subscription-Id-Extension AVP MAY be used to carry out the existing
> identifier types. In this case, Subscription-Id-Extension AVP MAY be sent
> together with Subscription-Id AVP. If Subscription-Id-Extension AVP M-bit
> is set, an RFC4006 credit control server MUST reply with
> DIAMETER_AVP_UNSUPPORTED. RFC4006bis credit control server SHOULD
> prioritize the handling of Subscription-Id-Extension AVP over
> Subscription-Id AVP and ignore Subscription-Id AVP if present.
>
> *Cc:* Gardella, Maryse (Nokia - FR); <[email-masked]>
> ...
>
> [Письмо показано не полностью]

---

From: Yuval Lifshitz <[email-masked]>
Date: Mon, 20 Feb 2017 13:42:52 +0000

Hi Misha,
Looks good.
* Added the clarification regarding the fact that multiple instances of the AVP may exist
* Don’t think the recommendation for the RFC4006bis server is needed, I think it their decision how to prioritize in this case
8.58.  Subscription-Id-Extension AVP
The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify the end user's subscription and is of type Grouped.  The Subscription-Id-Extension AVP contains an included AVP holding the subscription identifier itself.  The type of this included AVP indicates the type of the subscription identifier. The existing identifier types are listed in the Subscription-Id-Type AVP. For each existing identifier type there is a separate sub-AVP corresponding to it. If a new identifier type is required a corresponding new sub-AVP SHOULD be defined.
If a full backward compatibility with [RFC4006] is required, then Subscription-Id AVP MUST be used to carry out the identifier types listed in the Subscription-Id-Type AVP. While Subscription-Id-Extension AVP MUST be used only for newly defined identifier types. In such a case the M-bit MUST be set for the Subscription-Id-Extension AVP.
If a full backward compatibility with [RFC4006] is not required, then Subscription-Id-Extension AVP MAY be used to carry out the existing identifier types. In this case, Subscription-Id-Extension AVP MAY be sent together with Subscription-Id AVP.
If Subscription-Id-Extension AVP M-bit is set, an RFC4006 credit control server MUST reply with DIAMETER_AVP_UNSUPPORTED. RFC4006bis credit control server SHOULD prioritize the handling of Subscription-Id-Extension AVP over Subscription-Id AVP and ignore Subscription-Id AVP if present.
Exactly one sub-AVP MUST be included inside each instance of the Subscription-Id-Extension AVP.
It is defined as follows (per the grouped-avp-def of [RFC6733]):
         Subscription-Id-Extension ::= < AVP Header: TBD7 >
                             [ Subscription-Id-E164 ]
                             [ Subscription-Id-IMSI ]
                             [ Subscription-Id-SIP-URI ]
                             [ Subscription-Id-NAI ]
                             [ Subscription-Id-Private ]
                            *[ AVP ]

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Monday, February 20, 2017 11:24 AM
To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

The Subscription-Id-Extension AVP (AVP Code TBD7) is used to identify the end user's subscription and is of type Grouped.  The Subscription-Id-Extension AVP contains an included AVP holding the subscription identifier itself.  The type of this included AVP indicates the type of the subscription identifier. The existing identifier types are listed in the Subscription-Id-Type AVP. For each existing identifier type there is a separate sub-AVP corresponding to it. If a new identifier type is required a corresponding new sub-AVP SHOULD be defined.

If a full backward compatibility with [RFC4006] is required, then Subscription-Id AVP MUST be used to carry out the identifier type. While Subscription-Id-Extension AVP MUST be used only for newly defined identifier types.

If a full backward compatibility with [RFC4006] is not required, then Subscription-Id-Extension AVP MAY be used to carry out the existing identifier types. In this case, Subscription-Id-Extension AVP MAY be sent together with Subscription-Id AVP. If Subscription-Id-Extension AVP M-bit is set, an RFC4006 credit control server MUST reply with DIAMETER_AVP_UNSUPPORTED. RFC4006bis credit control server SHOULD prioritize the handling of Subscription-Id-Extension AVP over Subscription-Id AVP and ignore Subscription-Id AVP if present.
Exactly one sub-AVP MUST be included inside the Subscription-Id-Extension AVP.

Best regards

/Misha

2017-02-20 10:59 GMT+03:00 Misha Zaytsev <[email-masked]<mailto:[email-masked]>>:
Hi All,

2017-02-20 10:58 GMT+03:00 Misha Zaytsev <[email-masked]<mailto:[email-masked]>>:
Hi Yuval,
Here is my version of the Subscription-Id-Extension:
8.58.  Subscription-Id-Extension AVP

   indicates the type of the subscription identifier. The existing identifier types are listed in the Subscription-Id-Type
   AVP.

2017-02-19 14:03 GMT+03:00 Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>:
Hi Misha,
The spec has to be written in backward compatible manner, but giving the implementer the freedom on whether to do that or not, would make adoption of it easier. Note that, in case of DCCA, most actual implementations are not based directly on it. They are based on 3GPP TS 32.299, which sometimes modifies the IETF spec, and may decide to treat compatibility differently (3GPP release a major revision to their spec almost every year).
Anyway, would appreciate if you send over your description of the AVP.

Best Regards,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Best regards,

/Misha

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Mon, 20 Feb 2017 14:27:09 +0000

Hi Misha, Yuval,

-       I am ok in general as soon as it is clearly specified that second option is not backward compatible.

-       I also think there is no need to have explicitly statement for CC server, even the one on M-bit:  I am expecting the M-bit rule to apply as usual, since the Subscription-Id-Extension AVP will always have the M-bit set. I understand this will be reflected
in the table chapter 8. , similarly as:

-       May be I missed something, but I fail to understand the logic of having multiple Subscription-Id-Extension AVPs, each with a single sub-AVP, instead of one Subscription-Id-extension AVP with multiple sub-AVPs.

Thanks
Maryse

Sent: lundi 20 février 2017 14:43

Hi Misha,
Looks good.

Hi Yuval,

Best regards

/Misha

Best Regards,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Best regards,

/Misha

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: Yuval Lifshitz <[email-masked]>
Date: Mon, 20 Feb 2017 14:41:16 +0000

Inline

From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]]
Sent: Monday, February 20, 2017 4:27 PM
To: Yuval Lifshitz; Misha Zaytsev
Cc: [email-masked]
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Misha, Yuval,

-       I am ok in general as soon as it is clearly specified that second option is not backward compatible.
[yuval] I think that the text proposed by Misha is quite clear: If full backward compatibility with [RFC4006] is not required...

-       I also think there is no need to have explicitly statement for CC server, even the one on M-bit:  I am expecting the M-bit rule to apply as usual, since the Subscription-Id-Extension AVP will always have the M-bit set. I understand this will be reflected
in the table chapter 8. , similarly as:
[yuval] I’m ok with removing the text regarding the server, agree it does not add too much.
Note that, the M-bit for the Subscription-Id-Extension AVP is checked under the “may” column and not the “must” columns. If the CC-client want to be compatible with RFC4006 CC-server, but still sent the Subscription-Id-Extension AVP (e.g. if it does not know if the server is RFC4006 only or not) it should send it without the M-bit.

-       May be I missed something, but I fail to understand the logic of having multiple Subscription-Id-Extension AVPs, each with a single sub-AVP, instead of one Subscription-Id-extension AVP with multiple sub-AVPs.
[yuval] don’t have strong preference for one way or the other. Proposed to have multiple instances of Subscription-Id-Extension AVP because this is how Subscription-Id AVP works – just to minimize changes.

Thanks
Maryse

Hi Misha,
Looks good.

Hi Yuval,

Best regards

/Misha

Best Regards,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Best regards,

/Misha

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Mon, 20 Feb 2017 16:40:54 +0000

Hi Yuval,
See my replies [mga]

Thanks
Maryse

Sent: lundi 20 février 2017 15:41

Inline

Hi Misha, Yuval,

[mga] OK, I understand now this is to cover the second option, for the CC-client being able to send existing types in both Subscription-Id AVP and Subscription-Id-Extension AVP, and this would be the only case.

Thanks
Maryse

Hi Misha,
Looks good.

Hi Yuval,

Best regards

/Misha

Best Regards,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Best regards,

/Misha

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz

Hi Yuval,

/Misha

                     AVP  Section

Best Regards,

Yuval

Hi Yuval,

Thanks a lot in advance!

/Misha

Yuval

Hi Yuval,

BR
Maryse

Hi All,

Best Regards,

Yuval

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Tue, 21 Feb 2017 08:35:56 +0000

Hi Misha,

I agree the explicit “each instance of” is not needed.

Maryse

From: Misha Zaytsev [mailto:[email-masked]]
Sent: lundi 20 février 2017 21:00
To: Gardella, Maryse (Nokia - FR) <[email-masked]>
Cc: Yuval Lifshitz <[email-masked]>; [email-masked]
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Maryse and Yuval,

I agree with your counter proposals of my version.
Just a minor comment: I'm still thinking that the last statement is sufficient in the following form:

There is no need to explicitly specify that this statement is valid for each Subscription-Id-Extension AVP instance since this is the description of such an instance. If there are multiple instances, the same statement is valid for each one. Isn't it?

/Misha

2017-02-20 19:40 GMT+03:00 Gardella, Maryse (Nokia - FR) <[email-masked]<mailto:[email-masked]>>:
Hi Yuval,
See my replies [mga]

Thanks
Maryse

Inline

Hi Misha, Yuval,

Thanks
Maryse

Hi Misha,
Looks good.

Hi Yuval,

Best regards

/Misha

Best Regards,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Best regards,

/Misha

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz
Cc: Gardella, Maryse (Nokia - FR);
...

---

From: Yuval Lifshitz <[email-masked]>
Date: Tue, 21 Feb 2017 14:54:17 +0000

Thank you for the help in driving that into conclusion!

Updated the doc. diff is here: https://github.com/lbertz02/rfc4006bis/commit/41f48dd7916a9f3a32a667fa7205433be3f5a4fb?diff=split

From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]]
Sent: Tuesday, February 21, 2017 10:36 AM
To: Misha Zaytsev
Cc: Yuval Lifshitz; [email-masked]
Subject: RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Misha,

Maryse

From: Misha Zaytsev [mailto:[email-masked]]
Sent: lundi 20 février 2017 21:00
To: Gardella, Maryse (Nokia - FR) <[email-masked]<mailto:[email-masked]>>
Cc: Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi Maryse and Yuval,

/Misha

Thanks
Maryse

Inline

Hi Misha, Yuval,

Thanks
Maryse

Hi Misha,
Looks good.

Hi Yuval,

Best regards

/Misha

Best Regards,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Best regards,

/Misha

Hope this clarify,

Yuval

To: Yuval Lifshitz

Hi Yuval,

Thanks in advance!

/Misha

Hi Yuval,

/Misha

1)      For

  To have:

   with the M-bit set.

Thanks
Maryse

From: Yuval Lifshitz

Hi Yuval,

BR
Maryse

inline

Hi Yuval,

Maryse

Hi Misha,

“

Yuval

Hi Yuval,

Thanks in advance!

/Misha

/Misha

Yuval

To: Yuval Lifshitz