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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 4 Jan 2004 11:44:36 +0100

Inline

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]]
> Sent: vrijdag 2 januari 2004 12:32
> To: Wijnen, Bert (Bert); Bridge-Mib (E-mail)
> Subject: Re: [Bridge-mib] FW: Please review and comment:
> draft-ietf-ops-vlanid-tc-mib-00.tx t
> 
> No thoughts on whether the TC should exist or no.
> 
> But if it does, then keep the name simple, don't overload the 
> name, the identifier, with a description of the semantics
> 
MMm... if we look at for example DateAndTime TC, does that not give
similar semantics in the name? I am sure there are many others
that do so too. 

> ie VlanIdentifier VlanIds VlanId2 .. good
> VlanIdOrNone VlanIdOrNoneOrAny VlanIdAssociation   .. bad
> 
Bert
> Tom Petch

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

---

From: "Andrew Smith" <[email-masked]>
Date: Sun, 4 Jan 2004 13:26:23 -0800

>similar semantics in the name? I am sure there are many others

I'd agree with Bert here: what's the point of having a name if it does
not convey semantics. Might as well call it "fred" or
"1.3.6.1.2.3.4.5.6.7.8.999" if not.

Andrew Smith

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Jan 2004 11:27:11 +0100

>>>>> Wijnen, Bert (Bert) writes:

>> -----Original Message----- From: Tom Petch
>> 
>> But if it does, then keep the name simple, don't overload the name,
>> the identifier, with a description of the semantics
>> 

Bert> MMm... if we look at for example DateAndTime TC, does that not
Bert> give similar semantics in the name? I am sure there are many
Bert> others that do so too.

I do not think this is a good comparison, especially since the
DateAndTime definition does not speel out a NULL value and people
frequently use a string will all 0s which is not really consistent
with the TC definition which requires a value unequal to 0 for the
month and day fields.

I think Tom was more pointing into the direction of
InterfaceIndexOrZero where Zero basically indicates that there is a
special value but its semantics must be specified in the description
of the object using that TC. If you are very precise how the special
value (or values) are going to be used, then you will end up with
many TCs.

So, let me play devils advocate: Can someone summarize why we already
have VlanIdOrAny plus VlanIdOrNone and why VlanIdOrZero is not good
enough?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany