VLAn ID

Randy, you wrote:
>To:   [email protected]
>cc:   [email protected] (Les Bell/GB/3Com)
>Subject:  Re: [Bridge-mib] VLAN-ID
>
>Hi -
>
>I think it would be better if the "any" value in the *OrAny TC were
>a non-negative value so that the type could be used to define an
>index.  There may not be a need today, but thinking ahead to
>representing policy-like things wouldn't hurt.
>

As far as I can tell, you seem to be the only one sofar who 
has spoken up on the idea of not having a negative value
for the "any" for the VlanIdOrAny TC that I proposed.

You do not claim an immediate need, but a possible future
(yet-undefined) need.

So if there are any other people who feel that this makes sense,
please speak up soon.

We already have (rfc3289)
DscpOrAny ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS   current
    DESCRIPTION
       "The IP header Differentiated Services Code-Point that may be
       used for discriminating among traffic streams. The value -1 is
       used to indicate a wild card i.e. any value."
    REFERENCE
        "RFC 2474, RFC 2780"
    SYNTAX   Integer32 (-1 | 0..63)

Based on that, we also got to (draft-ietf-ops-ipv6-flowlabel-00.txt)
   IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION
       DISPLAY-HINT  "d"
       STATUS         current
       DESCRIPTION   "The flow identifier or Flow Label in an IPv6
                      packet header that may be used to discriminate
                      traffic flows.  The value of -1 is used to
                      indicate a wildcard, i.e. any value.
                     "
       SYNTAX         Integer32 (-1 | 0..1048575)

And so now we were going down the same path
    VlanIdOrAny       ::= TEXTUAL CONVENTION
        DISPLAY-HINT "d"
        STATUS        current
        DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
                      The value of -1 is used to indicate a wildcard,
                      i.e. any value.
                     "
        SYNTAX        Integer32 (-1 | 1..4094)

So that seems consistent, no?
If we do so, we can bypass that discussion about if it is valid
to use value 4095 to mean "any"... I suspect that discussion may
take a while and we may need to check with IEEE 802 people/docs.

Or are you telling us we better change all of the above to
use a positive number for "any".

>Randy
>

Thanks,
Bert