Subject: RE: authors 48 hours: RFC 3318 <draft-ietf-rap-frameworkpib-09.tx t> NOW AVAILABLE

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 28 Feb 2003 18:03:48 +0100

W.r.t. The VLAN ID.

I had proposed (to the bridgmib WG and mibs mailing list) a 
set of TCs that would be inline with your use, as follows:

  VlanId            ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "d"    
      STATUS        current
      DESCRIPTION  "A 12-bit VLAN ID used in the VLAN Tag header."
      SYNTAX        Integer32 (1..4094)
      REFERENCE    "Draft Standard for Virtual Bridged Local Area
                    Networks, P802.1Q/D10, chapter 3.13
                   "

  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)

The latter one, would have been inline with your use in

  frwk802FilterVlanId OBJECT-TYPE
      SYNTAX         Integer32 (-1 | 1..4094)
      STATUS         current
      DESCRIPTION
          "The VLAN ID (VID) that uniquely identifies a VLAN
          within the device. This VLAN may be known or unknown
          (i.e., traffic associated with this VID has not yet
          been seen by the device) at the time this entry
          is instantiated.

          Setting the frwk802FilterVlanId object to -1 indicates that
          VLAN data should not be considered during traffic
          classification."
      ::= { frwk802FilterEntry 5 }

But afte someone objected to a negative value for 'any, and
based on Andrew's input I believe, people are now discussing

  VlanIdOrAny       ::= TEXTUAL CONVENTION
      DISPLAY-HINT "d"
      STATUS        current
      DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
                    The value of 4095 is not a vlaid VLAN ID and
                    is used to indicate a wildcard, i.e. any value.
                   "
      SYNTAX        INTEGER (1..4095)

That would be conflicting with your definition, and I might later
ask you to deprecate your object and define a new one that
aligns with the generic VLAN ID as defined by the bridgemib WG.
Unfortunately, they are not sure yet, Bridgemib WG chair is
taking it to IEEE and they will discuss it in week of March 9th,
So it will take a while before we know for sure.

So I am inclined to let you go with what you have, or to redefine
it as       SYNTAX        INTEGER (1..4095).
In the latter case, pls again do a quick pseudo WG Last Call
for the change.

Please let me know how you want to proceeed.
Bert

---

From: "Hahn, Scott" <[email-masked]>
Date: Fri, 28 Feb 2003 16:38:48 -0800

Bert, 
I would agree with you and go with what we have today.
	-Scott 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Friday, February 28, 2003 9:04 AM
To: Hahn, Scott; Kwok Ho Chan; Sahita, Ravi; [email-masked];
[email-masked]; John Seligson; [email-masked]; [email-masked];
[email-masked]
Cc: Rap-wg (E-mail); Randy Bush
Subject: RE: authors 48 hours: RFC 3318
<draft-ietf-rap-frameworkpib-09.tx t> NOW AVAILABLE

W.r.t. The VLAN ID.

But afte someone objected to a negative value for 'any, and based on
Andrew's input I believe, people are now discussing

That would be conflicting with your definition, and I might later ask
you to deprecate your object and define a new one that aligns with the
generic VLAN ID as defined by the bridgemib WG. Unfortunately, they are
not sure yet, Bridgemib WG chair is taking it to IEEE and they will
discuss it in week of March 9th, So it will take a while before we know
for sure.

So I am inclined to let you go with what you have, or to redefine
it as       SYNTAX        INTEGER (1..4095).
In the latter case, pls again do a quick pseudo WG Last Call for the
change.