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

[Misha Zaytsev <[e-mail]>]

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) <
[e-mail]>:

> 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)
>
>
>
> 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.
>
>
>
>   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 [mailto:[e-mail]]
> *Sent:* jeudi 16 février 2017 17:41
> *To:* Gardella, Maryse (Nokia - FR) <[e-mail]>; Misha
> Zaytsev <[e-mail]>
> *Cc:* [e-mail]; Yuval Lifshitz <[e-mail]>
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> 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:* [e-mail]; 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.
>
> 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:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, February 13, 2017 7:19 PM
> *To:* Yuval Lifshitz; Misha Zaytsev
> *Cc:* [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* dimanche 12 février 2017 08:19
> *To:* Gardella, Maryse (Nokia - FR) <[e-mail]>; Misha
> Zaytsev <[e-mail]>
> *Cc:* [e-mail]; Yuval Lifshitz <[e-mail]>
> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> *inline*
>
>
>
> *From:* Gardella, Maryse (Nokia - FR) [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, February 08, 2017 12:47 PM
> *To:* Yuval Lifshitz; Misha Zaytsev
> *Cc:* [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* lundi 6 février 2017 21:31
> *To:* Misha Zaytsev <[e-mail]>
> *Cc:* Gardella, Maryse (Nokia - FR) <[e-mail]>;
> [e-mail]; Yuval Lifshitz <[e-mail]>
> *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:
>
> 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:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, February 06, 2017 9:36 PM
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); [e-mail]
> *Subject:* Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> 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 <[e-mail]>:
>
> 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 <[e-mail]>:
>
> 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:[e-mail]]
> *Sent:* Sunday, January 29, 2017 8:21 PM
>
>
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); [e-mail]
> *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 <[e-mail]>:
>
> 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:
>
>   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:[e-mail]]
> Sent: Saturday, January 28, 2017 11:07 PM
> To: Yuval Lifshitz
> Cc: Gardella, Maryse (Nokia - FR); [e-mail]
> 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 <[e-mail]>:
> Hi Maryse,
> The idea is the following:
> •         If the CC client want to work with RFC4006bis only CC server,
> and want to make sure that the subscription ID is understood by the server,
> it may set the M-bit. Any RFC4006 server will reply with
> DIAMETER_AVP_UNSUPPORTED (5001)
> •         If the CC client is not sure whether the CC servers are RFC4006
> or RFC4006bis, or have a mix of servers, and want to work with both, it may
> not set the M-bit
> o   In this case it would send both AVPs for the old types, so that the
> new AVP will be ignored by the RFC4006 servers
> o   In a case of a new type of subscription, not covered in RFC4006, it
> may send the new AVP with the M-bit set, causing any old server to reply
> with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP without
> the M-bit set, here the server would just ignore the AVP, but would
> probably reply DIAMETER_MISSING_AVP (5005) as it will not have any
> subscription ID
>
> Yuval
>
> From: Gardella, Maryse (Nokia - FR) [mailto:[e-mail]]
> Sent: Tuesday, January 24, 2017 5:25 PM
> To: Yuval Lifshitz; [e-mail]
> Subject: RE: RFC4006bis - Subscription-Id-Extension AVP
>
> Hi Yuval,
>
> Thanks for continuing on this.
> I am not sure to understand the difference between “may” and “must”, since
> with  “May” we can end having the M-bit set by the RFC4006bis CC client.
> I guess from the protocol’s perspective “may” and “must” makes no
> difference right?
>
> BR
> Maryse
>
> From: DiME [mailto:[e-mail]] On Behalf Of Yuval Lifshitz
> Sent: vendredi 13 janvier 2017 15:24
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
>
>
>
>