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.