Re: wildcard flowid in framework PIB?

[Brian Williams <brian.williams@ericsson.com.au>]

Hi Kwok.
I find the terminology proposed in your update unclear:

In your explanation, you have:
The requested change is to have a way for the PDP to indicate to the PEP 
that
the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used 
for defining
any filter match.

This appears clear enough. But then the acutal text change proposed is:
        "The flow identifier in an IPv6 header. The value
         4294967295 for this attribute MUST be interpreted
         as indication of this attribute NOT-USED, meaning
         not any value of flow identifier in the IPv6 header will
         result in a filter match.  Notice this is different from
         a wildcard match, in which case all values of flow
         identifier in the IPv6 header will result in a filter match."

I think the text is unclear in two specific ways.

Firstly, (assuming my assumption is correct), it would be much clearer 
to use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would 
be applicable if the field was optional, and you are checking if the 
field was specifically not provided. However, since the field is a part 
of the v6 header, it is not clear how NOT-USED applies.

The second part that is really unclear is how you should interpret:
"not any value of flow identifier in the IPv6 header will result in a 
filter match."

If you use the term IGNORED, then it is easy to explain that the field 
shall not be considered in the filter match.

Having made these comments on the current proposed text, I agree with 
the comments by Juergen below regarding the similarity to DSCP, and that 
a consistent approach should be sought.
/brian

Juergen Schoenwaelder wrote:

> > > > > > Kwok Ho Chan writes:
> > > > > >            
> Kwok> Hi all: I think we should call this "Not Used" FlowId condition
> Kwok> in framework PIB.
>
> [...]
>
> Kwok> To fix the "Not Used" case not realizable by the current
> Kwok> Framework PIB, we propose to make the following changes to the
> Kwok> Framework PIB:
>
> WAIT
>
> My reading here is that this is analog to Dscp and DscpOrAny. If this
> is true, then we have the same problem in the filter definition of the
> DIFFSERV-MIB. And if this is the same problem, then we should have a
> similar way of addressing it. So perhaps we need to define FlowId and
> FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use
> the same solution everywhere.
>
> If we agree that this would be the correct way to do things, then we
> need to find out how to implement this with the current state of the
> set of documents involved. Note that I have added Bert and Fred to the
> To: list since I think they should be involved in handling this if my
> interpretation of this situation is correct.
>
> /js
>
>