Re: [Dime] RFC 4006 bis - Addition of Filter-Rule
Jouni Korhonen <jouni.nospam@gmail.com> Wed, 29 June 2016 19:29 UTC
Return-Path: <jouni.nospam@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 1D9B412D559; Wed, 29 Jun 2016 12:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 VVjVLdegL15H; Wed, 29 Jun 2016 12:29:04 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 A72A212D1D8; Wed, 29 Jun 2016 12:29:04 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id h14so20992579pfe.1; Wed, 29 Jun 2016 12:29:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5vyWQV4uRDlwtJ7qb3kPmjRr556PuwZEeS+REqb2TWA=; b=xfxS/s1jyq0MRNNUifS6CQc7aMRjsrvkOdCYJ6/p9Q1hAOg1P25ScT/0iJ64Nf/oWj Px7a+DrdcPH/TPT2jPoClnWY415BdxAiCa76RmGWqXxhmZyjzA9U1WwYkH9dt8E78XYH 1FSBOkTFCFM3niV0xQKcG2BlPdNe5Zl7+L9KWDC2pOo158v+g8ojBNfAgCvD7LHpGjJl Ek9nysw/vjGRIDHMEn4s9EJICv5uJ4CyYMbv5YE9SWRPmXTd08vlo0CJ5z0sqswU6uKH UGuKrYn9bwwciCpK/AUMzaQjm75AxgM4AGbGZIq3Dja99P7QwfUTf8h0MppwZ649dXwc AT/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5vyWQV4uRDlwtJ7qb3kPmjRr556PuwZEeS+REqb2TWA=; b=XD8xfh8keq5uQSrimrgTKUNdKNsHvJ8cUpnhgpGsASeLkX3SQBQ25fafW+u8XYO4jL Yrq8UkZEMVhuZOp6lFIlzKsnipwL36bx24jO8FDJ0epAfywgK4mmAvnVoRTxzV98mqRW cmQJbxfa+JSvuxog4dQmbGyBmXENNBRv410TmNRWiCUq1UsG8RbMJHWhF0E8o0IzeBWB Lc4W5epfK5ueu2fupcppuG8eXc9JEAsKyT1lAAsiitvCm97ZgM4HjxTT2GdUUclHMCbw 9wtu9oUOvdbRxEp0kr9so3U7FjK1eZYhubYcdPlhyTDCrUf0ZXztN2IbLrf5nGQcimpg B+zQ==
X-Gm-Message-State: ALyK8tI+27ByEzZEhMv4cxUxCrVuD35Um1GyBbO/EwQaQQMI5cq9TNjcKIZxlEvI46BBhA==
X-Received: by 10.98.82.68 with SMTP id g65mr14654417pfb.157.1467228544157; Wed, 29 Jun 2016 12:29:04 -0700 (PDT)
Received: from [10.16.75.6] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id o22sm7837795pfa.15.2016.06.29.12.29.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jun 2016 12:29:03 -0700 (PDT)
References: <126260c80f8b4afb87a67c39a66a4907@PLSWE13M07.ad.sprint.com>
To: "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>, "dime@ietf.org" <dime@ietf.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <49d1b984-2b96-8ef1-2a71-3abcd61e9208@gmail.com>
Date: Wed, 29 Jun 2016 12:28:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <126260c80f8b4afb87a67c39a66a4907@PLSWE13M07.ad.sprint.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/kb2PQ0d03VYgFFCUPg6YiWE3o-4>
Cc: "dime-chairs@ietf.org" <dime-chairs@ietf.org>
Subject: Re: [Dime] RFC 4006 bis - Addition of Filter-Rule
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.nospam@gmail.com
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: Wed, 29 Jun 2016 19:29:07 -0000
I have an issue with this. The Final-Unit-Indication grouped AVP was designed to be non-extensible. Adding a new AVP into this group would change the original ABNF and therefore then technically not be the same AVP anymore. - Jouni 6/29/2016, 7:37 AM, Bertz, Lyle T [CTO] kirjoitti: > All, > > > > As part of the updates to RFC 4006 I would propose that we add the > Filter-Rule specified in RFC 5777 where we use IPFilterRule. This > permits the specification of QoS filters (and other features not > supported by the IPFilterRule type) where they could only be referenced > by a Filter-Id (RFC 7155) which often uses an out-of-(diameter)band > mechanism. In the case of 4006, these values are used in > Redirect-Action (Section 5.6.2) and Restrict-Access Action (5.6.3). > > > > To do this I would propose we add the Filter-Rule AVP as an option in > the Final-Unit-Indication AVP. > > > > Summary of changes > > 1. Wherever Restriction-Filter-Rule and Filter-Id were used, > Filter-Rule was added (Sections 5.6.2, 5.6.3, 8.34 and 8.35). > > 2. Added Filter-Rule as AVP in Final-Unit-Indication AVP. > > > > Fundamental Change (Final-Unit-Action AVP) > > > > Original > > Final-Unit-Indication ::= < AVP Header: 430 > > > { Final-Unit-Action } > > *[ Restriction-Filter-Rule ] > > *[ Filter-Id ] > > [ Redirect-Server ] > > > > New > > Final-Unit-Indication ::= < AVP Header: 430 > > > { Final-Unit-Action } > > *[ Restriction-Filter-Rule ] > > *[ Filter-Id ] > > *[ Filter-Rule ] > > [ Redirect-Server ] > > > > Also, in 8.34 the use of the Filter-Rule is noted as: > > > >> The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can be > >> used when QoS filter rules must be specified. > > > > If there are no objections to this, we can incorporate it into the next > set of changes. > > > > Lyle > > > > xml Diff below > > > > 15a16 > >> <!ENTITY RFC5777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5777.xml"> > > 1727,1732c1728,1734 > > < include one or more Restriction-Filter-Rule AVPs or one or more > > < Filter-Id AVPs in the Credit-Control-Answer message to enable the > > < user to access other services (for example, zero-rated services). In > > < such a case, the access device MUST drop all the packets not matching > > < the IP filters specified in the Credit-Control-Answer message and, if > > < possible, redirect the user to the destination specified in the > > --- > >> include one or more Restriction-Filter-Rule AVPs, one or more Filter- > >> Rule AVPs <xref target="RFC5777"/>, or one or more Filter-Id AVPs in > >> the Credit-Control-Answer message to enable the user to access other > >> services (for example, zero-rated services). In such a case, the > >> access device MUST drop all the packets not matching the IP filters > >> specified in the Credit-Control-Answer message and, if possible, > >> redirect the user to the destination specified in the > > 1803,1806c1805,1809 > > < filters given in the Restriction-Filter-Rule AVP(s) or according to > > < the IP packet filters identified by the Filter-Id AVP(s). The > > < credit-control server SHOULD include either the Restriction-Filter- > > < Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message. > > --- > >> filters given in the Restriction-Filter-Rule AVP(s), Filter-Rule AVPs > >> <xref target="RFC5777"/> or according to the IP packet filters > >> identified by the Filter-Id AVP(s). The credit-control server > >> SHOULD include either the Restriction-Filter-Rule AVP, Filter-Rule AVP > >> or the Filter-Id AVP in the Credit-Control-Answer message. > > 1827c1830,1831 > > < Restriction-Filter-Rule AVP, the Filter-Id AVP, or none of the above. > > --- > >> Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, > >> or none of the above. > > 3610,3613c3614,3618 > > < Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP > > < or the Filter-Id AVP MAY be present in the Credit-Control-Answer > > < message if the user is also allowed to access other services that are > > < not accessible through the address given in the Redirect-Server AVP. > > --- > >> Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP(s), > >> Filter-Rule AVP(s) <xref target="RFC5777"/> or the Filter-Id(s) AVP MAY be > >> present in the Credit-Control-Answer message if the user is also allowed > >> to access other services that are not accessible through the address > >> given in the Redirect-Server AVP. > > 3615,3616c3620,3621 > > < If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the > > < Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present. > > --- > >> If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, Filter-Rule AVP(s), > >> Restriction-Filter-Rule AVP(s) or the Filter-Id AVP(s) SHOULD be present. > > 3622a3628,3630 > >> The Filter-Rule AVP is defined in <xref target="RFC5777"/>. The Filter-Rule AVP can be > >> used when QoS filter rules must be specified. > >> </t><t> > > 3631a3640 > >> *[ Filter-Rule ] > > 3662,3665c3671,3674 > > < IP packet filters defined in the Restriction-Filter-Rule AVP or > > < according to the IP packet filters identified by the Filter-Id > > < AVP. All the packets not matching the filters MUST be dropped > > < (see <xref target="sec-5.6.3"/>). > > --- > >> IP packet filters defined in the Restriction-Filter-Rule AVP(s), > >> Filter-Rule AVP(s) or according to the IP packet filters > >> identified by the Filter-Id AVP. All the packets not matching > >> the filters MUST be dropped (see <xref target="sec-5.6.3"/>). > > 4668a4678,4679 > >> &RFC5777; > >> > > > > > > > > > ------------------------------------------------------------------------ > *Learn more on how to switch to Sprint and save 50% on most Verizon, > AT&T or T-Mobile rates. See sprint.com/50off <http://sprint.com/50off> > for details. > * > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message.
- Re: [Dime] RFC 4006 bis - Addition of Filter-Rule Bertz, Lyle T [CTO]
- Re: [Dime] RFC 4006 bis - Addition of Filter-Rule Jouni Korhonen
- [Dime] RFC 4006 bis - Addition of Filter-Rule Bertz, Lyle T [CTO]