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

[Misha Zaytsev <[e-mail]>]

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:

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

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

> Hi Yuval,
>
> See my replies [mga]
>
>
>
> Thanks
>
> Maryse
>
>
>
> *From:* Yuval Lifshitz [mailto:[e-mail]]
> *Sent:* lundi 20 février 2017 15: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
>
>
>
> *Inline*
>
>
>
> *From:* Gardella, Maryse (Nokia - FR) [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, February 20, 2017 4:27 PM
> *To:* Yuval Lifshitz; Misha Zaytsev
> *Cc:* [e-mail]
> *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...*
>
> [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
>
>
>
> *From:* Yuval Lifshitz [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* lundi 20 février 2017 14:43
> *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,
>
> 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 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.*
>
> 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:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, February 20, 2017 11:24 AM
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); [e-mail]
> *Subject:* Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
> Here is my version of the Subscription-Id-Extension:
>
> 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 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.
>
>
>
> 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 ]
>
>
>
> Best regards
>
> /Misha
>
>
>
> 2017-02-20 10:59 GMT+03:00 Misha Zaytsev <[e-mail]>:
>
> 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 <[e-mail]>:
>
> Hi Yuval,
>
> Here is my version of the Subscription-Id-Extension:
>
> 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.
>
>
>
>
>
> 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 ]
>
>
>
>
>
> 2017-02-19 14:03 GMT+03:00 Yuval Lifshitz <[e-mail]>:
>
> 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:[e-mail]]
> *Sent:* Sunday, February 19, 2017 11:38 AM
>
>
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); [e-mail]
> *Subject:* Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> 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 <[e-mail]>:
>
> 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:[e-mail]]
> *Sent:* Saturday, February 18, 2017 10:47 AM
>
>
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); [e-mail]
> *Subject:* Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> 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 <[e-mail]>:
>
> *inline*
>
>
>
> *From:* Misha Zaytsev [mailto:[e-mail]]
> *Sent:* Friday, February 17, 2017 11:13 AM
> *To:* Gardella, Maryse (Nokia - FR)
> *Cc:* Yuval Lifshitz; [e-mail]
> *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.
>
>
>
> 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.
>
> *[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) <
> [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]>
> ...
>
> [Письмо показано не полностью]