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: Mon, 16 Feb 2004 00:03:45 +0100

> 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 would yopu prefer that instead of:

   VlanIdentifierOrNone  ::= TEXTUAL-CONVENTION
       DISPLAY-HINT     "d"
       STATUS            current
       DESCRIPTION      "The VLAN ID that uniquely identifies a VLAN.

                         The special value of zero is used to indicate
                         that no VLAN ID is present or used.  
                        "
       SYNTAX            Integer32 (0 | 1..4094) 

I do a different descriptor and DESCRIPTION, something like:

   VlanIdentifierOrZero  ::= TEXTUAL-CONVENTION
       DISPLAY-HINT     "d"
       STATUS            current
       DESCRIPTION      "The VLAN ID that uniquely identifies a VLAN.

                         The special value of zero is object-specific
                         and must therefore be defined as part of the
                         description of any object which uses this syntax.
                         Examples of the usage of zero might include
                         situations where VLAN ID is unknown, where a
                         VLAN ID is not present, or where none or any
                         VLAN ID need to be specified."
                        "
       SYNTAX            Integer32 (0 | 1..4094) 

And then possibly do away with the VlanIdentifierOrAny?

Bert

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

---

From: "Andrew Smith" <[email-masked]>
Date: Sun, 15 Feb 2004 16:13:26 -0800

Bert,

As I've said before, I think that's a backwards step. There's no point
in having the TC either (a) if you have to still refine its
definition/semantics in the DESCRIPTION of any object that uses it, or
(b) if the name represents syntax, not semantics 

(I don't care how many other TCs people have already defined called
"...OrZero" - that does not make them good - if only the syntax is
common between various uses of such a TC, without there being common
semantics, again I think the TC does not deserve to exist).

Sorry for the repetitiocity - this argument does seem to be going around
in non-diminishing circles.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wijnen, Bert (Bert)
Sent: Sunday, February 15, 2004 3:04 PM
To: 'Juergen Schoenwaelder'; Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: RE: [Bridge-mib] FW: Please review and comment:
draft-ietf-ops-vl anid-tc-mib-00.tx t

                         description of any object which uses this
syntax.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Feb 2004 12:49:12 +0100

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

Bert> I do a different descriptor and DESCRIPTION, something like:

[... VlanIdentifierOrZero removed ...]

Bert> And then possibly do away with the VlanIdentifierOrAny?

Yes, this is what I had in mind.

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Feb 2004 12:56:09 +0100

>>>>> Andrew Smith writes:

Andrew> As I've said before, I think that's a backwards step. There's
Andrew> no point in having the TC either (a) if you have to still
Andrew> refine its definition/semantics in the DESCRIPTION of any
Andrew> object that uses it, or (b) if the name represents syntax, not
Andrew> semantics

The reason why the name represents syntax and not semantics is that
the TC just says there is a special value (typically zero) where the
interpretation of the special value is up to the usage of the TC.
This has the big benefit that you need to allocate only one special
value. Experience with the InterfaceIndex so far shows that this
seem to work reasonably well.

Andrew> (I don't care how many other TCs people have already defined
Andrew> called "...OrZero" - that does not make them good - if only
Andrew> the syntax is common between various uses of such a TC,
Andrew> without there being common semantics, again I think the TC
Andrew> does not deserve to exist).

While I would agree with this principle in a pure programming
environment, we have to accept that allocating special values
is not as easy in MIB space and putting new semantically rich
TCs on the standards track is a slow operation. This is why
the solution to have fewer but more generic TCs is attractive
in this space.

Andrew> Sorry for the repetitiocity - this argument does seem to be
Andrew> going around in non-diminishing circles.

I like to understand whether there is a real technical reason why the
various usages of the TC must use different numbers. Allocating 4096
or whatever was choosen might be a pain down the road (the IETF has
some experience with number spaces that at some point in time need
to get enlarged, even though this sounded unrealistic when the number
space was defined).

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 26 Feb 2004 12:04:45 -0800

Hi -

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "'Juergen Schoenwaelder'" <[email-masked]>; "Wijnen, Bert (Bert)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, February 15, 2004 3:03 PM
> Subject: RE: [Bridge-mib] FW: Please review and comment: draft-ietf-ops-vl anid-tc-mib-00.tx t
...
> And then possibly do away with the VlanIdentifierOrAny?
...

This works as long as one doesn't need to be able to represent
both "none" and "any" as well as the specific VLAN numbers.
The only context I can think of where one might need both
distinct semantics would be in configuring policy-like things.

Randy