Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
Misha Zaytsev <misha.zaytsev.rus@gmail.com> Mon, 20 February 2017 08:00 UTC
Return-Path: <misha.zaytsev.rus@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD3612945F for <dime@ietfa.amsl.com>; Mon, 20 Feb 2017 00:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUVMdeBmBAgk for <dime@ietfa.amsl.com>; Sun, 19 Feb 2017 23:59:55 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF9A12940B for <dime@ietf.org>; Sun, 19 Feb 2017 23:59:54 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id l12so8351632lfe.0 for <dime@ietf.org>; Sun, 19 Feb 2017 23:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q0phVH7JJFiSwiojwIIAUrGcpiLVlXySI6uJzbcEL0I=; b=gLb8pbuAtuKz+bgpWC5r3QXPeufLPIhfxwNHd0HBe6NjO7gE60t5vtx9DD4GOzLmFR Ek7YiptRFeHGMAdiRiNWMYtSGyp4TEvFwmb62yVNzQ46xA4UzwE8kL4EgWdsZHbNZW5J qVB1TkZFmIXSnUUa49qLBVWRlzSAJkZQJEZKdgqY3lYQT1Fbqb42XnBgy6Vbr/v2g+js SGCqmyp+ZinZdZXm6M1Rff/TXgfR8wmQAARaZR80LOQnC/7iWaUcQzcOlEF8EEnFPwGp KcrIPTh5e2xNtyGNcTHmmyDZhJGzrmZTb8RvO6w9WLM0nNUaahew+turxajs/IaDnEow pc1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q0phVH7JJFiSwiojwIIAUrGcpiLVlXySI6uJzbcEL0I=; b=JLzhBhWIpwHD5Xpc4qp5OvS6EH2qeMQ3rQGaSUJOVCSv59EIewcAzxIGc4KDral62h 2y1BKaMZuezY7b0XEnXMoBmoVvkWUs6/4gKxn0H6YaaDoJIooYUkPhpjxOgOvKUMweun vmm/ywd/8NJywcyd/ULcybqKsLgwAwpoS0IU2RxqtoCbHjw9nJUwGxFeDDCvtFz69m0i UGzi2MdpGDicM5OcyWT7MPUOLQtFOmayRhcEITj+12LEHmbY+k230yg52XUb7uO9bOU8 9yKLTR1H319oJV9Fv+GOotdWpmqDn6gWcaTHwCeV/gJwe+Cn1T+bXZlEMHYfKTwrR2LX RI3g==
X-Gm-Message-State: AMke39nYIqV8DrqqZslyRgohn8eZH++11oXNLf0smwpB/z4XkVo1kDSNiEcYGWdrPtQVHdRNaaondPhEBvqVhA==
X-Received: by 10.25.15.41 with SMTP id e41mr909961lfi.117.1487577592240; Sun, 19 Feb 2017 23:59:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.92.1 with HTTP; Sun, 19 Feb 2017 23:59:51 -0800 (PST)
In-Reply-To: <CABPQr260AzHA8KEgFZb2MQ5d65Q_azDwtS0KSsFh28BwCkG4Lw@mail.gmail.com>
References: <C43C255C7106314F8D13D03FA20CFE497000AF59@wtl-exchp-1.sandvine.com> <HE1PR0701MB28573F830861577D13DBC916FC750@HE1PR0701MB2857.eurprd07.prod.outlook.com> <C43C255C7106314F8D13D03FA20CFE497002AC18@wtl-exchp-1.sandvine.com> <CABPQr243oqJxrC52+FAJUaLv9K2aQEuO0sD8ouD49rr5kXR4xQ@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE497002D184@wtl-exchp-1.sandvine.com> <CABPQr24Y79vFg=ZW=xAPDi5NgBah2Mk2=ai0GzRg-zA5Z75-Gw@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE497002DB6B@wtl-exchp-1.sandvine.com> <CABPQr25sj_G-PN6aowSrbGfeYs_Wa-tNtmzsndXA+=Ca4U4qxw@mail.gmail.com> <CABPQr27D=Bga1by0c2+B=x5ZaE_a20GhL=R9h=QYagQE_+Nqqg@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE49700334DE@wtl-exchp-1.sandvine.com> <HE1PR0701MB2857C1123305ABCF88BD295BFC420@HE1PR0701MB2857.eurprd07.prod.outlook.com> <C43C255C7106314F8D13D03FA20CFE4970038B30@wtl-exchp-1.sandvine.com> <HE1PR0701MB28578B05AAA4390541E22F54FC590@HE1PR0701MB2857.eurprd07.prod.outlook.com> <C43C255C7106314F8D13D03FA20CFE497003A6FE@wtl-exchp-1.sandvine.com> <C43C255C7106314F8D13D03FA20CFE497003F238@wtl-exchp-1.sandvine.com> <HE1PR0701MB285704FE40A25057A8921300FC5A0@HE1PR0701MB2857.eurprd07.prod.outlook.com> <CABPQr250Kj02_DvMvwjou0LqtQX5RyO6ceUVs-c_kksmQZDgDA@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE497003FA03@wtl-exchp-1.sandvine.com> <CABPQr26eMg=zgaU+J4xgc==JX+CNW=8XOUO1uLN+FBHknV7pow@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE4970041192@wtl-exchp-1.sandvine.com> <CABPQr27QoMeCZP1ZDKPzXvBx5+a1XkBMNBchb+4dsF17i+fk5g@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE497004130B@wtl-exchp-1.sandvine.com> <CABPQr260AzHA8KEgFZb2MQ5d65Q_azDwtS0KSsFh28BwCkG4Lw@mail.gmail.com>
From: Misha Zaytsev <misha.zaytsev.rus@gmail.com>
Date: Mon, 20 Feb 2017 10:59:51 +0300
Message-ID: <CABPQr25UjoCehDCN7uhZKEDMYcQnDodm40US6c=dRtkRkUMBUw@mail.gmail.com>
To: Yuval Lifshitz <ylifshitz@sandvine.com>
Content-Type: multipart/alternative; boundary="001a113fb526f61ede0548f1a5c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/5wyekBmxUVpMvC0J2TQwXAyAEF4>
Cc: "dime@ietf.org" <dime@ietf.org>, "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com>
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2017 08:00:00 -0000
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 <misha.zaytsev.rus@gmail.com>: > 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 <ylifshitz@sandvine.com>: > >> 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:misha.zaytsev.rus@gmail.com] >> *Sent:* Sunday, February 19, 2017 11:38 AM >> >> *To:* Yuval Lifshitz >> *Cc:* Gardella, Maryse (Nokia - FR); dime@ietf.org >> *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 <ylifshitz@sandvine.com>: >> >> 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:misha.zaytsev.rus@gmail.com] >> *Sent:* Saturday, February 18, 2017 10:47 AM >> >> >> *To:* Yuval Lifshitz >> *Cc:* Gardella, Maryse (Nokia - FR); dime@ietf.org >> *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 <ylifshitz@sandvine.com>: >> >> *inline* >> >> >> >> *From:* Misha Zaytsev [mailto:misha.zaytsev.rus@gmail.com] >> *Sent:* Friday, February 17, 2017 11:13 AM >> *To:* Gardella, Maryse (Nokia - FR) >> *Cc:* Yuval Lifshitz; dime@ietf.org >> *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) < >> maryse.gardella@nokia.com>: >> >> 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:ylifshitz@sandvine.com] >> *Sent:* jeudi 16 février 2017 17:41 >> >> *To:* Gardella, Maryse (Nokia - FR) <maryse.gardella@nokia.com>; Misha >> Zaytsev <misha.zaytsev.rus@gmail.com> >> *Cc:* dime@ietf.org; Yuval Lifshitz <ylifshitz@sandvine.com> >> *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:* dime@ietf.org; 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:maryse.gardella@nokia.com >> <maryse.gardella@nokia.com>] >> *Sent:* Monday, February 13, 2017 7:19 PM >> *To:* Yuval Lifshitz; Misha Zaytsev >> *Cc:* dime@ietf.org >> *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:ylifshitz@sandvine.com >> <ylifshitz@sandvine.com>] >> *Sent:* dimanche 12 février 2017 08:19 >> *To:* Gardella, Maryse (Nokia - FR) <maryse.gardella@nokia.com>; Misha >> Zaytsev <misha.zaytsev.rus@gmail.com> >> *Cc:* dime@ietf.org; Yuval Lifshitz <ylifshitz@sandvine.com> >> *Subject:* RE: [Dime] RFC4006bis - Subscription-Id-Extension AVP >> >> >> >> *inline* >> >> >> >> *From:* Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com >> <maryse.gardella@nokia.com>] >> *Sent:* Wednesday, February 08, 2017 12:47 PM >> *To:* Yuval Lifshitz; Misha Zaytsev >> *Cc:* dime@ietf.org >> *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:ylifshitz@sandvine.com >> <ylifshitz@sandvine.com>] >> *Sent:* lundi 6 février 2017 21:31 >> *To:* Misha Zaytsev <misha.zaytsev.rus@gmail.com> >> *Cc:* Gardella, Maryse (Nokia - FR) <maryse.gardella@nokia.com>; >> dime@ietf.org; Yuval Lifshitz <ylifshitz@sandvine.com> >> *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:misha.zaytsev.rus@gmail.com >> <misha.zaytsev.rus@gmail.com>] >> *Sent:* Monday, February 06, 2017 9:36 PM >> *To:* Yuval Lifshitz >> *Cc:* Gardella, Maryse (Nokia - FR); dime@ietf.org >> *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 <misha.zaytsev.rus@gmail.com>: >> >> 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 <ylifshitz@sandvine.com>: >> >> 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:misha.zaytsev.rus@gmail.com] >> *Sent:* Sunday, January 29, 2017 8:21 PM >> >> >> *To:* Yuval Lifshitz >> *Cc:* Gardella, Maryse (Nokia - FR); dime@ietf.org >> *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 <ylifshitz@sandvine.com>: >> >> 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:misha.zaytsev.rus@gmail.com] >> Sent: Saturday, January 28, 2017 11:07 PM >> To: Yuval Lifshitz >> Cc: Gardella, Maryse (Nokia - FR); dime@ietf.org >> 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 <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] 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 >> >> >> >> >> >> >> >> >> >> >> >> >> > >
- [Dime] RFC4006bis - Subscription-Id-Extension AVP Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Misha Zaytsev
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Gardella, Maryse (Nokia - FR)
- Re: [Dime] RFC4006bis - Subscription-Id-Extension… Yuval Lifshitz