Subject: [ipcdn] Textual Convention VlanIdOrAny

From: Murwin William-LWM008 <[email-masked]>
Date: Wed, 13 Aug 2003 16:37:36 -0400

Rich & Bert,

Some time ago a comment was made to change docsQosPktClassVlanId from Integer32 (0..4094) to
the textual convention "VlanIdOrAny". However at the time (5/7/2003), the Bridging Group was having a email "ballot" if 
4095 could be used as Wildcard. The status of that "ballot" is still unknown, do you have any updates?
I did not see this textual convetion in the Latest (version 5 July 2003), of the draft-ietf-bridge-bridgemib-smiv2-05.txt.

Does the DOCS-IETF-QOS-MIB really have to use this textual convention? Can we just Integer32(-1 | 0..4094), and state that -1 means that either a Wildcard or not present, and that the docsQosPktClassBitMap should be use to see if the VlanId was present in the Modem TLV file? 

I do not want to have the QoS MIB dependent on a textual convetion that may or may not be. And the QoS MIB is not the correct mib in which to define this Textual Convetion.

I really pefer not have the DOCS-IETF-QOS-MIB dependent on another MIB, just for a textual convetion to compile this MIB, especially if the textual convetion is being put into a draft the obsoletes RFC 1493, a RFC that DOCSIS requires Bridging CMTS/CM to implement and thus would be present in the SNMP managers, which could lead to more operator confusion.
______________________________
William Murwin
Broadband Communications Sector
Motorola Inc.
Email: [email-masked]
Tel: (508) 851-8385

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 14 Aug 2003 08:04:43 -0700 (PDT)

On Wed, 13 Aug 2003, Murwin William-LWM008 wrote:
> Some time ago a comment was made to change docsQosPktClassVlanId
> from Integer32 (0..4094) to the textual convention
> "VlanIdOrAny". However at the time (5/7/2003), the Bridging
> Group was having a email "ballot" if 4095 could be used as
> Wildcard. The status of that "ballot" is still unknown, do you
> have any updates? I did not see this textual convetion in the
> Latest (version 5 July 2003), of the
> draft-ietf-bridge-bridgemib-smiv2-05.txt.

I believe that the IEEE did agree that 4095 could be used as a
wildcard.  However, no work has been done on a set of VLAN
TEXTUAL-CONVENTIONS ... draft-ietf-bridge-bridgemib-smiv2-05.txt
doesn't use it.  draft-ietf-bridge-ext-v2-01.txt has expired, and
the Framework Policy Information Base was published as RFC 3318
in March 2003 with this definition:

  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 }

> Does the DOCS-IETF-QOS-MIB really have to use this textual
> convention? Can we just Integer32(-1 | 0..4094), and state that
> -1 means that either a Wildcard or not present, and that the
> docsQosPktClassBitMap should be use to see if the VlanId was
> present in the Modem TLV file?

I can't speak for the AD or WG chairs but under the circumstances
(specifically the lack of forward progress on getting a common TC) 
this sounds reasonable to me.

> I do not want to have the QoS MIB dependent on a textual
> convetion that may or may not be. And the QoS MIB is not the
> correct mib in which to define this Textual Convetion.

I agree.

> I really pefer not have the DOCS-IETF-QOS-MIB dependent on
> another MIB, just for a textual convetion to compile this MIB,
> especially if the textual convetion is being put into a draft
> the obsoletes RFC 1493, a RFC that DOCSIS requires Bridging
> CMTS/CM to implement and thus would be present in the SNMP
> managers, which could lead to more operator confusion.

I have some sympathy for your dislike of dependencies since it can
extend the publication schedule for reasons beyond your control.  
That said, there is something in the above paragraph that I feel
needs to be corrected.  The SMIv2 rules on MIB module revisions are
designed specifically to guarantee that a new version of a MIB
module can be used by managers to support agents that implement an
older version:  definitions of all kinds (objects, TCs, groups,
compliance statements) may not be removed or renamed (only
deprecated or obsoleted), semantically incompatible changes are not
allowed, and OIDs may not be assigned or re-used.  In the IETF we
strive to follow these rules, and with the review system we now have
in place I think we generally succeed.  So I don't think you should
be sticking to obsolete versions on MIB modules for fear of
backward-incompatible changes.  (And if there is a module you care
about that's being revised, you can and should comment either to the
WG or at IETF last call time if you see backward-incompatible
changes being made.)

Mike