Subject: RE: [ipcdn] Textual Convention VlanIdOrAny

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 14 Aug 2003 23:34:32 +0200

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: donderdag 14 augustus 2003 17:05
> To: Murwin William-LWM008
> Cc: Richard Woundy (E-mail); [email-masked]'; Michael W. Patrick
> (E-mail); IPCDN (E-mail) (E-mail)
> Subject: Re: [ipcdn] Textual Convention VlanIdOrAny
> 
> 
> 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 will accept such a definition, since that is similar to what the
Framework PIB has defined.

My eprsonal believe however is that if we now were to define a TC
for this, that it would probably be (0..4095) where 4095 would
be defined as the wildcard value. I base this on the discussion
we have had sofar on this topic. But it is only my current expectation,
one is never sure untill we do see consensus on the topic.

So if you were to ever want to import and use that TC and we indeed
ended up with (0..4095), then you could not replace your definition
with the TC. Probably that is OK. Just want you to be aware of this.

I will try to stirr up discussion in bridge MIB WG and see if 
we can get to consensus, so you can use it as input when you
decide.

W.r.t. the below... Mike is correct.

Bert
> > 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
> 

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