Subject: [Bridge-mib] VLAn ID

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 27 Feb 2003 17:35:53 +0100

Randy, you wrote:
>To:   [email-masked]
>cc:   [email-masked] (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 
_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 27 Feb 2003 09:53:56 -0800

Bert,

The whole point of defining these TCs in a separate document is to serve
"possible future (yet-undefined) needs" - why else would we bother to
break them out in a separate document or module? 

The need to use VlanIdOrAny as an index in the future seems likely to
me. It is especially likely if you believe that we're trying to set a
precedent here for how to represent "some sort of packet field or
don't-care". Personally, I think it's a bit clunky to overload the value
like this - a separate flag object is more elegant, but, if we're
comfortable with the overloading, I'd go with Randy and say (as I did
before - maybe you missed my message?) that the syntax here should be
unsigned, not signed (I understand the practical reasons for the
non-negative-index restriction in SNMP but it is a limitation on the
SMIv2 language). I don't think there's a need to consult with IEEE 802
on this - I think most of the people with relevant opinions on this are
already on this thread - but that's the bridge-mib WG chair's call if he
wants to ask himself for help.

My opinions (I know you're looking for others though ...).

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wijnen, Bert (Bert)
Sent: Thursday, February 27, 2003 8:36 AM
To: Randy Presuhn (E-mail)
Cc: Bridge-Mib (E-mail); [email-masked]
Subject: VLAn ID

S