Re: FlowId and FlowIdOrAny

>>>>> Wijnen, Bert (Bert) writes:

Bert> Now... if we do this, then this could still be used by the
Bert> framework pib.  However, for the diffserv-mib it would mean they
Bert> must deprecate a current object and create a new one (switching
Bert> from Unsigned to Integer32 causes a change on the wire!).

Oops, I missed that part of the picture. So if there is concensus to
change the range as a bug fix in the DIFFSERV0MIB without introducing
a new object (which formally the SMIv2 would require to do), then
using Unsigned32 makes some sense. Note that this will also most
likely include the definition of a DEFVAL which is in fact the new
value.  However, if we decided that it is safer to use deprecate the
filter obejct and introduce a new one, I prefer to use Integer32.

BTW, this is what I found in the INTEGRATED-SERVICES-MIB:

    intSrvFlowFlowId OBJECT-TYPE
        SYNTAX      INTEGER (0..16777215)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
           "The flow ID that  this  sender  is  using,  if
           this  is  an IPv6 session."
       ::= { intSrvFlowEntry 11 }

Note that this range is [0..2^24-1] while the other definitions under
discussion use a range of [0..2^20-1]. Note that RFC 2460 says:

:    Flow Label           20-bit flow label.  See section 6.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>