headers
Wijnen, Bert (Bert | 15 Feb 2004 23:41
Picon
Favicon

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

Juergen responds to me:

> 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.
> 
Mmm...

> 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?
> 
Well, in the case of InterfaceIndexOrZero a ..OrZero seem logical because
it is the interface number or zero. 
In the case of VlanIdOrNone, to me it makes sense because it is an
identifiere or no identifier (none). But I could live with VlanIdOrNone.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 16 Feb 2004 00:03
Picon
Favicon

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

> 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
(Continue reading)

Permalink | Reply | 1003 comments |
headers
Andrew Smith | 16 Feb 2004 01:13
Picon
Favicon

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

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: bridge-mib-admin <at> ietf.org [mailto:bridge-mib-admin <at> ietf.org] On
Behalf Of Wijnen, Bert (Bert)
Sent: Sunday, February 15, 2004 3:04 PM
To: 'Juergen Schoenwaelder'; Wijnen, Bert (Bert)
Cc: bridge-mib <at> ietf.org
Subject: RE: [Bridge-mib] FW: Please review and comment:
draft-ietf-ops-vl anid-tc-mib-00.tx t

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Juergen Schoenwaelder | 16 Feb 2004 12:49
Picon
Picon

Re: FW: Please review and comment: draft-ietf-ops-vl anid-tc-mib-00.tx t


>>>>> 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
Permalink | Reply | 0 comments |
headers
Juergen Schoenwaelder | 16 Feb 2004 12:56
Picon
Picon

Re: FW: Please review and comment: draft-ietf-ops-vl anid-tc-mib-00.tx t


>>>>> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Presuhn | 26 Feb 2004 21:04
Picon

Re: FW: Please review and comment: draft-ietf-ops-vl anid-tc-mib-00.tx t

Hi -

> From: "Wijnen, Bert (Bert)" <bwijnen <at> lucent.com>
> To: "'Juergen Schoenwaelder'" <schoenw <at> ibr.cs.tu-bs.de>; "Wijnen, Bert (Bert)" <bwijnen <at> lucent.com>
> Cc: <bridge-mib <at> ietf.org>
> 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
...
>        SYNTAX            Integer32 (0 | 1..4094)
>
> 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
Permalink | Reply | 1001 comments |

Gmane