Subject: [Bridge-mib] RE: Please review and comment: draft-ietf-ops-vlanid-tc-mib-00.tx t

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 21 Dec 2003 23:43:45 +0100

> On Thu, Oct 02, 2003 at 09:03:50AM -0700, C. M. Heard wrote:
> > > 
> > > The real interesting question is how RFC 2674 should pick up this
> > > definition. Is the idea that they import form the new TC MIB and
> > > just remove their definition? That might break other imports. If
> > > they import and keep the original definition in RFC 2674, you will
> > > have to distinguish the two TCs with the same name, which is likely
> > > to test the quality of MIB parsers.
> > > 
> > > So perhaps the new TCs should in fact go into an update of RFC 2674
> > > rather than introducing a new module? This would at least side-step
> > > this interesting problem...
> > 

Another way to side step it is to rename the TCs in my document
I can name them
  VlanIdentifier
  VlanIdentifierOrAny
  VlanIdentifierOrNone

A quick check seems to indicate they have not yet been used in
IETF MIB modules.

comments?
 
> > This approach would solve the "legal" problems but it does
> > have some significant drawbacks:
> > 
> > - It's necessary to re-spin RFC 2674.  Bert has suggested an
> > incremental update as one way to get around this.
> > 
> > - It causes any module that imports VlanID and kin to depend
> > normatively on the P-BRIDGE-MIB.  The upshot would be that absent a
> > variance of some kind, no module importing VlanID and kin could
> > advance on the standards track faster than P-BRIDGE-MIB.  That's not
> > desirable, because changes to things that are unrelated to  VlanID
> > and kin could hold back advancement.
> 
> So what is your suggestion how RFC 2674 should pick up the new TCs? Or
> is your suggestion to leave RFC 2674 alone?
> 
And with my suggested approach above we can leave 2674 alone till
it needs to be opened for other reasons.

Bert
> /js

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 21 Dec 2003 23:43:44 +0100

Sorry for late reaction... but I am now again looking at 
this document and the discussion that we had back in October.

inline
> -----Original Message-----
> From: Mark Ellison [mailto:[email-masked]]
> Sent: donderdag 2 oktober 2003 20:12
> To: Wijnen, Bert (Bert)
> Cc: Mark Ellison; [email-masked]
> Subject: Re: Please review and comment:
> draft-ietf-ops-vlanid-tc-mib-00.txt
> 
> 
> Hi Bert,
> 
> I'm wondering if there could be any mib or pib definition requiring a 
> range of ( 0 | 1..4094 | 4095 )  for possible values?
> 
Mark, I have not seen anyone react to this as a option that they
wanted, so for now I am not going to include it.
It can of course always be added later if a need arises.

By the way, what woyuld you call/name that TC?

Bert
> Regards,
> Mark

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 31 Dec 2003 17:51:59 +0100

Any comments?

Thanks,
Bert 

-----Original Message-----
From: Mark Ellison [mailto:[email-masked]]
Sent: woensdag 31 december 2003 20:04
To: Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: Re: Please review and comment:
draft-ietf-ops-vlanid-tc-mib-00.tx t

Hi Bert,

Thanks for your reply. 

I think I'd call a TC with a value range of Integer32 { 0 | 1..4094 | 
4095 }  a VlanIdReference or VlanIdAssociation.

This TC would be useful when defining an object that refers to a vlan.  
For example, a table where each entry can be associated with none, one, 
or any vlan.  One alternative, with the existing TCs, would be to use 
VlanIdOrAny, but have the agent return noSuchInstance when there is no 
association with a vlan. Another alternative, with the existing TCs, 
would be to use VlanIdOrNone, and not have use of the special any/4095 
value.

Regards,

Mark