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

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