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 <ylifshitz@sandvine.com>:

> 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:maryse.gardella@nokia.com]
> *Sent:* Tuesday, January 24, 2017 5:25 PM
> *To:* Yuval Lifshitz; dime@ietf.org
> *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:dime-bounces@ietf.org <dime-bounces@ietf.org>] *On
> Behalf Of *Yuval Lifshitz
> *Sent:* vendredi 13 janvier 2017 15:24
> *To:* dime@ietf.org
> *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
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>