Re: [Dime] RFC 4006 bis - Addition of Filter-Rule

["Bertz, Lyle T [CTO]" <[e-mail]>]

You're right.

The other AVPs are direct sub-types of IPFilterRule or use the Filter-Id which RFC 7155 states should not be used where backward compatibility is not required.  It's also problematic that the Filter-Id is described as a list of strings.

So effectively the Final-Unit-Indication cannot convey QoS.

We have some options (technically speaking):
Option 1 - Final Units cannot specify QoS (do nothing)
Option 2 - Create a 'side-car' AVP that, if present is add to the Final-Unit-Indication Rules but is permitted to carry QoS based rule.
Option 3 - Create an alternative to Final-Unit-Indication AVP and recommend when QoS based rules are used

imo
Option 1 - It seems a bit odd that we can only restrict to non-QoS parameters which can hurt services that need some level of QoS even in some sort of restricted mode.
Option 2 - Ugly but technically feasible.  However, it creates multiple AVPs to look across which complicates logic.  I don't like it but mention it here for completeness
Option 3 - Seems like the best option and similar to what happened in RFC 7155 for QoS-Filter-Rule.  We can say if you want QoS you should use <New Final Unit Indication AVP name> in the Final-Unit-Indication AVP then create a new one

-Lyle



-----Original Message-----
From: Jouni Korhonen [mailto:[e-mail]]
Sent: Wednesday, June 29, 2016 2:29 PM
To: Bertz, Lyle T [CTO] <[e-mail]>; [e-mail]
Cc: [e-mail]; Yuval Lifshitz <[e-mail]>; Dave Dolson <[e-mail]>
Subject: Re: RFC 4006 bis - Addition of Filter-Rule


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.

________________________________

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.