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

My vote on this topic is to keep it as-is in Framework PIB
(using Integer32 (-1 | 1..4094) ).
The reasoning is as follows:
1. The -1 value does not gets into the data packet being forwarded by the
     network device, it is used in the management plane only.
     Using the -1 value will just be as good as using 4095 from that 
prospective.
2. The -1 value allow it to be more distinct from the normal legal on the wire
     IEEE value of 1 to 4094, hence it is cleaner to use -1.
3. The DSCP and IPv6 FlowLabel is already using the -1 or "OrAny" concepts,
     hence keeping it as -1 will be more beneficial.

Thanks!
-- Kwok Ho Chan --


At 06:03 PM 2/28/03 +0100, Wijnen, Bert (Bert) wrote:
>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