[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf Re: Instance amplification in Diffserv MIB




I am resubmitting the following on behalf of Andrew Smith, whose
email address has recently changed.



------- Forwarded Message


From: Andrew Smith <andrew@allegronetworks.com>
To: "'Robert Moore/Raleigh/IBM '" <remoore@us.ibm.com>
Cc: "''diffserv@ietf.org ' ' '" <diffserv@ietf.org>,
        "'snmpconf@snmp.com'"
	 <snmpconf@snmp.com>
Subject: Instance amplification in Diffserv MIB
Date: Tue, 14 Nov 2000 14:15:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C04E88.5FF367C0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C04E88.5FF367C0
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,

[Apologies for the cross-posting to snmpconf but this is of relevance there,
I think. Besides, there's not much traffic on that list right now :-)]

I think this is the usual 'C' discussion case of "do you use a subroutine or
place the code inline?". Sometimes one is best, sometimes the other,
depending on how you see it being used. i.e. we could come up with other
examples where hard-coupling the meter entries and the configuration value
entries is *more* efficient. 

Now I must admit that I hadn't noticed until now (a list of "-04 to -05
changes" would have helped) that the -05 MIB now totally decouples the
diffServTBMeterTable from the diffServTBMeterTable - the indexing is no
longer common: if you do this then, of course, you have to allow independent
parent/child row creation.

If you hard-couple the two tables with common indexing, as it was in the -04
draft, then the first part of your argument below is somewhat moot - whether
a "column" is placed in the parent table or in the child table does not
really affect the implementation complexity or the "number of entries"
involved - in your example it would not be 200 entries it would be 100
entries with the columns split between 2 tables sharing common indexing (the
child effectively "AUGMENTS" the parent table entry although that is not the
right SMI syntax to use). I'd argue that, in fact, that is less complex for
the agent (far less spaghetti-pointer-interdependance-checking for the
agent) and only marginally less efficient in protocol operations.

The second part of your argument does hold though - if you want to change
all of the values for all of the meters at once then it is much more
protocol-efficient to have a single MIB variable instead of having to change
each instance. So, is this going to be the most common operational scenario?
I don't know. But I don't think that this "low-level" "raw" Diffserv MIB
needs to be optimised for protocol efficiency - that is a job for the
snmpconf work - this Diffserv MIB is already far too clumsy to be
protocol-efficient for configuration usage on a box with more than a handful
of interfaces.

What you are arguing here is a need for some sort of "templating" capability
for these objects: this is something that was discussed at length in the
early snmpconf meetings (I wasn't at the last one so I don't know if this is
still a goal) and was being called "instance amplification". The problem, in
brief was "how do we apply a template of values for config parameters
(columns) to a whole collection of instances (table entries)?" and there
were hopes that snmpconf work would produce some sort of generic solution to
this problem. What you are describing here is a local solution for this
problem for this particular MIB, so I would ask you and Harrie to comment on
whether we are duplicating effort here or just moving this solution from
being a snmpconf work item to being a part of this diffserv MIB? If the
latter then that's just fine but we do need to check for consistency with
the solutions being worked on in snmpconf (yes Brian, that would mean a
two-way dependency between these work items). If the former then I think
that the duplication of solutions would be a Bad Thing. 

[Maybe someone can put my mind at rest on this - I must apologise for having
missed out on recent snmpconf happenings - I'm trying to catch up though]


Andrew Smith



-----Original Message-----
From: Robert Moore/Raleigh/IBM
To: Andrew Smith
Cc: 'Harrie Hazewinkel '; ''diffserv@ietf.org ' '
Sent: 11/13/00 10:24 AM
Subject: RE: [Diffserv] draft-ietf-diffserv-mib-05.txt posted

Andrew,

I don't think this is what Harrie was talking about.  The case
he mentioned is not multiple daughters for one parent -- it's
multiple parents sharing one daughter.

We discussed this at some length at the snmpconf interim in
Knoxville.  The idea is that if you have, say, 100 interfaces
where you need meters that are configured in exactly the same
way, you'll need 100 meter instances (because these represent
operational information as well as configuration values), but
only 1 daughter entry to provide the configuration values for
all of the meters.  Not only does this result in fewer entries
overall (101 rather than 200), it makes it easy to reconfigure
all of the meters at the same time.

Kwok and I will be publishing an Internet-Draft this week with
two textual conventions that capture generalized versions of
the DiffServ MIB's "next" pointers and "specific" pointers.
We expect these textual conventions to be put on the standards
track through the snmpconf WG, at which point they can be
referenced by the next version of the DiffServ MIB.

So my answers to issues 23 and 31 are different from yours:

23. Daughter entries can exist independently of their
    parent entries.

31. In the sense the question was asked:  The linkage from
    parent to daughter should be a RowPointer, rather than
    an OID that points to the table root.  Really, though,
    these pointers should use the syntax StaticRowPointer
    (coming later this week, in a draft that's going to be
    called either draft-moore-snmpconf-tcs-00.txt or
    draft-ietf-smnpconf-tcs-00.txt).

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



Andrew Smith <andrew@allegronetworks.com>@ietf.org on 11/10/2000
02:02:29
PM

Sent by:  diffserv-admin@ietf.org


To:   "'Harrie Hazewinkel '" <harrie@covalent.net>
cc:   "''diffserv@ietf.org ' '" <diffserv@ietf.org>
Subject:  RE: [Diffserv] draft-ietf-diffserv-mib-05.txt posted





Harrie,

I am only referring to the case(s) in the current MIB where indexing is
common between parent and child i.e. it is a pure inheritance
relationship
(the child object represents the parent object extended with extra
properties). This forces there to be either zero or one daughters for
any
parent. Are you proposing that we need to allow for greater than one
daughter object for such cases? If so then there are other indexing
changes
e.g. to diffServTBMeterTable that you need to propose.

I think the WG consensus on the intent of current MIB is as follows
(please
correct me if I'm wrong, somebody): if a vendor implements their own
diffServXXMeterTable they have a choice: either they extend the
token-bucket definition in diffServTBMeterTable (in the case where they
consider their new meter to be a sub-type of token-bucket meter) or else
they extend the base diffServMeterTable instead. But you have to pick
one -
you cannot say "my new meter is a bit like a TB meter but I don't want
to
use property XX, I want my own property YY which is in my private MIB".
For
that you have to extend the base diffServMeterTable table and
(potentially)
replicate those properties that you do want to steal from
diffServTBMeterTable in your own MIB.

Andrew

-----Original Message-----
From: Harrie Hazewinkel
To: Andrew Smith
Cc: 'diffserv@ietf.org '
Sent: 11/9/00 1:06 PM
Subject: Re: [Diffserv] draft-ietf-diffserv-mib-05.txt posted

Hi,

Comments in line.

> Andrew Smith wrote:
>
> Brian asked for arguments on the open issues.
>
> Issue 23:
> > (23) Do daughter entries of derived table entries need to exist
> >      independently of the parent?  Examples are
> >      diffServMeterEntry/diffServTBMeterEntry,
> >      diffServActionEntry/diffServCountActEntry and
> >      diffServAlgDropEntry/diffServRandomDropEntry (assume they must
be
> >      independent of the equivalent entry in diffServMeterTable which

> >      points at the TB table - needs diffServTBMeterStatus: daughters

> >      must be created explicitly by manager).
>
> I've argued all along that the current solution (-05 draft) makes a
> manager jump through such hoops as to make this attempt at
> object-oriented MIB design too complex to be of much use. My opinion
> is that, in nearly all cases, there is no need to have the daughter
> entry exist if the parent is deleted and vice-versa.

You make an assumption that 1 parent can have only 1 daughter.
I would argue parents could share daughters.
Like in real life, parents come in packages of 2 (father/mother). :-))

Maybe it is wrong to have the entries mapped onto a parent daughter
paradigma. IMHO, multiple entries (top-level) could share a
parameter (detailed) entry.

> There is no need
> to have independent RowStatus variables with all their associated
> complexity (I believe that about 80% of the
> implementation/testing/maintenance complexity for a table with
> row-create/delete capabilities is in the RowStatus column). Of course
> the real solution is to redesign SMI to increase its OO capabilities
> but that is not a topic for this WG. But within the constraints of
> SMIv2 I think that we can do a better job than the current draft. The
> main argument I've heard against this approach is that "that's not how
> we've done MIBs in the past". I'm still waiting for some technical
> counter-arguments.

I don't know what precise thing you are goaling for here.

>
> For specific proposed changes for, e.g. diffServTBMeterTable, we
> should go back to what was intended in the -03 draft: the last
> paragraph of the DESCRIPTION for diffServTBMeterTable should read:
>
> "Entries in this table share indexing with those in the base
> diffServMeterTable: they appear in this table whenever an base entry
> that shares the same indexing and has a diffServMeterSpecific value
> that points to this table comes into existence. They disappear either
> when the base entry does or when the base entry's
> diffServMeterSpecific value no longer points to this table."

I understand your point here, but what happens if a vendor comes
up with his own detailed diffServXXMeterTable that provides
parameters for his implemented meter. Then in as well the
diffServTBMeterTable and diffServXXMeterTable the same index
can be used and its parameters can conflict with each other.

I understand the complexity grows, but with a 'specificPointer'
(not index sharing) we are sure there is only 1 entry
providing parameters for a table.

By using the 'specificPointer' in a table instead of indexing
it could well be that the detailed (daughter) entries are
shared among parents.
With other words, 2 diffServMeterEntries could have the
same diffServTBMeterEntry for its parameters. IMHO,
there is no need to duplicate the diffServTBMeterEntry.

Having both a specific pointer and a shared index the
data in the MIB can be ambiguous. So the only possibility is
selecting or a specific pointer or a shared index.
As described above, I believe having the specific pointer
makes it totally unambiguous.

>
> I think this is the only instance of a parent/daughter table like this
> in this MIB module although others could arise in other MIBs that
> tried to use the base tables in this Diffserv MIB.
>
> Issue 31:
> > (31) When inheritance is needed and parent/daughter share indexing,
the
> >      parent often points to the daughter using a "Specific"
attribute
> >      e.g. diffServMeterSpecific, diffServActionSpecific,
> >      diffServAlgDropSpecific. If this is a RowPointer and points to
the
> >      associated row in the daughter's table, there is redundant
> >      information which gives scope for additional error cases. So,
> >      wherever possible, should we remove this redundant information
by
> >      making the "Specific" attribute point only to the base of the
> >      daughter table and make it an OBJECT IDENTIFIER? The con is
that
> >      this is an unusual use of MIB pointers (point at table base,
not
> >      individual entries).
>
> Again, I've argued all along that allowing the provision of redundant
> information is the root of most evil (i.e. complexity) in handling
> error cases.

Yes, the redudancy creates unambiguous data in the MIB. (see above)

> And again I've only heard a Luddite counter-argument. For
> specific changes, go back to the -04 draft description/syntax for e.g.
> diffServMeterSpecific (there's a separate discussion of whether the
> syntax should then be RowPointer or OBJECT IDENTIFIER but let's leave
> that for now).

I agree, selecting a RowPointer or OBJECT IDENTIFIER is
less important. I would say select OBJECT IDENTIFIER which
can be a RowPointer, but a RowPointer can not be an OBJECT IDENTIFIER.
The RowPointer is a subset with restricted semantics.

Harrie
0- Harrie Hazewinkel ---------------------------------------0
 mailto:harrie@covalent.net            phone:+1-415-536-5221
0-----------------------------------------------------------0

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/



------_=_NextPart_001_01C04E88.5FF367C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Instance amplification in Diffserv MIB</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob,</FONT>
</P>

<P><FONT SIZE=3D2>[Apologies for the cross-posting to snmpconf but this =
is of relevance there, I think. Besides, there's not much traffic on =
that list right now :-)]</FONT></P>

<P><FONT SIZE=3D2>I think this is the usual 'C' discussion case of =
&quot;do you use a subroutine or place the code inline?&quot;. =
Sometimes one is best, sometimes the other, depending on how you see it =
being used. i.e. we could come up with other examples where =
hard-coupling the meter entries and the configuration value entries is =
*more* efficient. </FONT></P>

<P><FONT SIZE=3D2>Now I must admit that I hadn't noticed until now (a =
list of &quot;-04 to -05 changes&quot; would have helped) that the -05 =
MIB now totally decouples the diffServTBMeterTable from the =
diffServTBMeterTable - the indexing is no longer common: if you do this =
then, of course, you have to allow independent parent/child row =
creation.</FONT></P>

<P><FONT SIZE=3D2>If you hard-couple the two tables with common =
indexing, as it was in the -04 draft, then the first part of your =
argument below is somewhat moot - whether a &quot;column&quot; is =
placed in the parent table or in the child table does not really affect =
the implementation complexity or the &quot;number of entries&quot; =
involved - in your example it would not be 200 entries it would be 100 =
entries with the columns split between 2 tables sharing common indexing =
(the child effectively &quot;AUGMENTS&quot; the parent table entry =
although that is not the right SMI syntax to use). I'd argue that, in =
fact, that is less complex for the agent (far less =
spaghetti-pointer-interdependance-checking for the agent) and only =
marginally less efficient in protocol operations.</FONT></P>

<P><FONT SIZE=3D2>The second part of your argument does hold though - =
if you want to change all of the values for all of the meters at once =
then it is much more protocol-efficient to have a single MIB variable =
instead of having to change each instance. So, is this going to be the =
most common operational scenario? I don't know. But I don't think that =
this &quot;low-level&quot; &quot;raw&quot; Diffserv MIB needs to be =
optimised for protocol efficiency - that is a job for the snmpconf work =
- this Diffserv MIB is already far too clumsy to be protocol-efficient =
for configuration usage on a box with more than a handful of =
interfaces.</FONT></P>

<P><FONT SIZE=3D2>What you are arguing here is a need for some sort of =
&quot;templating&quot; capability for these objects: this is something =
that was discussed at length in the early snmpconf meetings (I wasn't =
at the last one so I don't know if this is still a goal) and was being =
called &quot;instance amplification&quot;. The problem, in brief was =
&quot;how do we apply a template of values for config parameters =
(columns) to a whole collection of instances (table entries)?&quot; and =
there were hopes that snmpconf work would produce some sort of generic =
solution to this problem. What you are describing here is a local =
solution for this problem for this particular MIB, so I would ask you =
and Harrie to comment on whether we are duplicating effort here or just =
moving this solution from being a snmpconf work item to being a part of =
this diffserv MIB? If the latter then that's just fine but we do need =
to check for consistency with the solutions being worked on in snmpconf =
(yes Brian, that would mean a two-way dependency between these work =
items). If the former then I think that the duplication of solutions =
would be a Bad Thing. </FONT></P>

<P><FONT SIZE=3D2>[Maybe someone can put my mind at rest on this - I =
must apologise for having missed out on recent snmpconf happenings - =
I'm trying to catch up though]</FONT></P>
<BR>

<P><FONT SIZE=3D2>Andrew Smith</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Robert Moore/Raleigh/IBM</FONT>
<BR><FONT SIZE=3D2>To: Andrew Smith</FONT>
<BR><FONT SIZE=3D2>Cc: 'Harrie Hazewinkel '; ''diffserv@ietf.org ' =
'</FONT>
<BR><FONT SIZE=3D2>Sent: 11/13/00 10:24 AM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Diffserv] =
draft-ietf-diffserv-mib-05.txt posted</FONT>
</P>

<P><FONT SIZE=3D2>Andrew,</FONT>
</P>

<P><FONT SIZE=3D2>I don't think this is what Harrie was talking =
about.&nbsp; The case</FONT>
<BR><FONT SIZE=3D2>he mentioned is not multiple daughters for one =
parent -- it's</FONT>
<BR><FONT SIZE=3D2>multiple parents sharing one daughter.</FONT>
</P>

<P><FONT SIZE=3D2>We discussed this at some length at the snmpconf =
interim in</FONT>
<BR><FONT SIZE=3D2>Knoxville.&nbsp; The idea is that if you have, say, =
100 interfaces</FONT>
<BR><FONT SIZE=3D2>where you need meters that are configured in exactly =
the same</FONT>
<BR><FONT SIZE=3D2>way, you'll need 100 meter instances (because these =
represent</FONT>
<BR><FONT SIZE=3D2>operational information as well as configuration =
values), but</FONT>
<BR><FONT SIZE=3D2>only 1 daughter entry to provide the configuration =
values for</FONT>
<BR><FONT SIZE=3D2>all of the meters.&nbsp; Not only does this result =
in fewer entries</FONT>
<BR><FONT SIZE=3D2>overall (101 rather than 200), it makes it easy to =
reconfigure</FONT>
<BR><FONT SIZE=3D2>all of the meters at the same time.</FONT>
</P>

<P><FONT SIZE=3D2>Kwok and I will be publishing an Internet-Draft this =
week with</FONT>
<BR><FONT SIZE=3D2>two textual conventions that capture generalized =
versions of</FONT>
<BR><FONT SIZE=3D2>the DiffServ MIB's &quot;next&quot; pointers and =
&quot;specific&quot; pointers.</FONT>
<BR><FONT SIZE=3D2>We expect these textual conventions to be put on the =
standards</FONT>
<BR><FONT SIZE=3D2>track through the snmpconf WG, at which point they =
can be</FONT>
<BR><FONT SIZE=3D2>referenced by the next version of the DiffServ =
MIB.</FONT>
</P>

<P><FONT SIZE=3D2>So my answers to issues 23 and 31 are different from =
yours:</FONT>
</P>

<P><FONT SIZE=3D2>23. Daughter entries can exist independently of =
their</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; parent entries.</FONT>
</P>

<P><FONT SIZE=3D2>31. In the sense the question was asked:&nbsp; The =
linkage from</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; parent to daughter should be a =
RowPointer, rather than</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; an OID that points to the table =
root.&nbsp; Really, though,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; these pointers should use the =
syntax StaticRowPointer</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; (coming later this week, in a =
draft that's going to be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; called either =
draft-moore-snmpconf-tcs-00.txt or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; =
draft-ietf-smnpconf-tcs-00.txt).</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>Bob Moore</FONT>
<BR><FONT SIZE=3D2>IBM Networking Software</FONT>
<BR><FONT SIZE=3D2>+1-919-254-4436</FONT>
<BR><FONT SIZE=3D2>remoore@us.ibm.com</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Andrew Smith =
&lt;andrew@allegronetworks.com&gt;@ietf.org on 11/10/2000</FONT>
<BR><FONT SIZE=3D2>02:02:29</FONT>
<BR><FONT SIZE=3D2>PM</FONT>
</P>

<P><FONT SIZE=3D2>Sent by:&nbsp; diffserv-admin@ietf.org</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>To:&nbsp;&nbsp; &quot;'Harrie Hazewinkel '&quot; =
&lt;harrie@covalent.net&gt;</FONT>
<BR><FONT SIZE=3D2>cc:&nbsp;&nbsp; &quot;''diffserv@ietf.org ' '&quot; =
&lt;diffserv@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp; RE: [Diffserv] =
draft-ietf-diffserv-mib-05.txt posted</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Harrie,</FONT>
</P>

<P><FONT SIZE=3D2>I am only referring to the case(s) in the current MIB =
where indexing is</FONT>
<BR><FONT SIZE=3D2>common between parent and child i.e. it is a pure =
inheritance</FONT>
<BR><FONT SIZE=3D2>relationship</FONT>
<BR><FONT SIZE=3D2>(the child object represents the parent object =
extended with extra</FONT>
<BR><FONT SIZE=3D2>properties). This forces there to be either zero or =
one daughters for</FONT>
<BR><FONT SIZE=3D2>any</FONT>
<BR><FONT SIZE=3D2>parent. Are you proposing that we need to allow for =
greater than one</FONT>
<BR><FONT SIZE=3D2>daughter object for such cases? If so then there are =
other indexing</FONT>
<BR><FONT SIZE=3D2>changes</FONT>
<BR><FONT SIZE=3D2>e.g. to diffServTBMeterTable that you need to =
propose.</FONT>
</P>

<P><FONT SIZE=3D2>I think the WG consensus on the intent of current MIB =
is as follows</FONT>
<BR><FONT SIZE=3D2>(please</FONT>
<BR><FONT SIZE=3D2>correct me if I'm wrong, somebody): if a vendor =
implements their own</FONT>
<BR><FONT SIZE=3D2>diffServXXMeterTable they have a choice: either they =
extend the</FONT>
<BR><FONT SIZE=3D2>token-bucket definition in diffServTBMeterTable (in =
the case where they</FONT>
<BR><FONT SIZE=3D2>consider their new meter to be a sub-type of =
token-bucket meter) or else</FONT>
<BR><FONT SIZE=3D2>they extend the base diffServMeterTable instead. But =
you have to pick</FONT>
<BR><FONT SIZE=3D2>one -</FONT>
<BR><FONT SIZE=3D2>you cannot say &quot;my new meter is a bit like a TB =
meter but I don't want</FONT>
<BR><FONT SIZE=3D2>to</FONT>
<BR><FONT SIZE=3D2>use property XX, I want my own property YY which is =
in my private MIB&quot;.</FONT>
<BR><FONT SIZE=3D2>For</FONT>
<BR><FONT SIZE=3D2>that you have to extend the base diffServMeterTable =
table and</FONT>
<BR><FONT SIZE=3D2>(potentially)</FONT>
<BR><FONT SIZE=3D2>replicate those properties that you do want to steal =
from</FONT>
<BR><FONT SIZE=3D2>diffServTBMeterTable in your own MIB.</FONT>
</P>

<P><FONT SIZE=3D2>Andrew</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Harrie Hazewinkel</FONT>
<BR><FONT SIZE=3D2>To: Andrew Smith</FONT>
<BR><FONT SIZE=3D2>Cc: 'diffserv@ietf.org '</FONT>
<BR><FONT SIZE=3D2>Sent: 11/9/00 1:06 PM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Diffserv] =
draft-ietf-diffserv-mib-05.txt posted</FONT>
</P>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Comments in line.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Andrew Smith wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Brian asked for arguments on the open =
issues.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Issue 23:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (23) Do daughter entries of derived table =
entries need to exist</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 independently of the =
parent?=A0 Examples are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 =
diffServMeterEntry/diffServTBMeterEntry,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 =
diffServActionEntry/diffServCountActEntry and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 =
diffServAlgDropEntry/diffServRandomDropEntry (assume they must</FONT>
<BR><FONT SIZE=3D2>be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 independent of the =
equivalent entry in diffServMeterTable which</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 points at the TB table - =
needs diffServTBMeterStatus: daughters</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 must be created explicitly =
by manager).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I've argued all along that the current solution =
(-05 draft) makes a</FONT>
<BR><FONT SIZE=3D2>&gt; manager jump through such hoops as to make this =
attempt at</FONT>
<BR><FONT SIZE=3D2>&gt; object-oriented MIB design too complex to be of =
much use. My opinion</FONT>
<BR><FONT SIZE=3D2>&gt; is that, in nearly all cases, there is no need =
to have the daughter</FONT>
<BR><FONT SIZE=3D2>&gt; entry exist if the parent is deleted and =
vice-versa.</FONT>
</P>

<P><FONT SIZE=3D2>You make an assumption that 1 parent can have only 1 =
daughter.</FONT>
<BR><FONT SIZE=3D2>I would argue parents could share daughters.</FONT>
<BR><FONT SIZE=3D2>Like in real life, parents come in packages of 2 =
(father/mother). :-))</FONT>
</P>

<P><FONT SIZE=3D2>Maybe it is wrong to have the entries mapped onto a =
parent daughter</FONT>
<BR><FONT SIZE=3D2>paradigma. IMHO, multiple entries (top-level) could =
share a</FONT>
<BR><FONT SIZE=3D2>parameter (detailed) entry.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; There is no need</FONT>
<BR><FONT SIZE=3D2>&gt; to have independent RowStatus variables with =
all their associated</FONT>
<BR><FONT SIZE=3D2>&gt; complexity (I believe that about 80% of =
the</FONT>
<BR><FONT SIZE=3D2>&gt; implementation/testing/maintenance complexity =
for a table with</FONT>
<BR><FONT SIZE=3D2>&gt; row-create/delete capabilities is in the =
RowStatus column). Of course</FONT>
<BR><FONT SIZE=3D2>&gt; the real solution is to redesign SMI to =
increase its OO capabilities</FONT>
<BR><FONT SIZE=3D2>&gt; but that is not a topic for this WG. But within =
the constraints of</FONT>
<BR><FONT SIZE=3D2>&gt; SMIv2 I think that we can do a better job than =
the current draft. The</FONT>
<BR><FONT SIZE=3D2>&gt; main argument I've heard against this approach =
is that &quot;that's not how</FONT>
<BR><FONT SIZE=3D2>&gt; we've done MIBs in the past&quot;. I'm still =
waiting for some technical</FONT>
<BR><FONT SIZE=3D2>&gt; counter-arguments.</FONT>
</P>

<P><FONT SIZE=3D2>I don't know what precise thing you are goaling for =
here.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; For specific proposed changes for, e.g. =
diffServTBMeterTable, we</FONT>
<BR><FONT SIZE=3D2>&gt; should go back to what was intended in the -03 =
draft: the last</FONT>
<BR><FONT SIZE=3D2>&gt; paragraph of the DESCRIPTION for =
diffServTBMeterTable should read:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Entries in this table share indexing with =
those in the base</FONT>
<BR><FONT SIZE=3D2>&gt; diffServMeterTable: they appear in this table =
whenever an base entry</FONT>
<BR><FONT SIZE=3D2>&gt; that shares the same indexing and has a =
diffServMeterSpecific value</FONT>
<BR><FONT SIZE=3D2>&gt; that points to this table comes into existence. =
They disappear either</FONT>
<BR><FONT SIZE=3D2>&gt; when the base entry does or when the base =
entry's</FONT>
<BR><FONT SIZE=3D2>&gt; diffServMeterSpecific value no longer points to =
this table.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>I understand your point here, but what happens if a =
vendor comes</FONT>
<BR><FONT SIZE=3D2>up with his own detailed diffServXXMeterTable that =
provides</FONT>
<BR><FONT SIZE=3D2>parameters for his implemented meter. Then in as =
well the</FONT>
<BR><FONT SIZE=3D2>diffServTBMeterTable and diffServXXMeterTable the =
same index</FONT>
<BR><FONT SIZE=3D2>can be used and its parameters can conflict with =
each other.</FONT>
</P>

<P><FONT SIZE=3D2>I understand the complexity grows, but with a =
'specificPointer'</FONT>
<BR><FONT SIZE=3D2>(not index sharing) we are sure there is only 1 =
entry</FONT>
<BR><FONT SIZE=3D2>providing parameters for a table.</FONT>
</P>

<P><FONT SIZE=3D2>By using the 'specificPointer' in a table instead of =
indexing</FONT>
<BR><FONT SIZE=3D2>it could well be that the detailed (daughter) =
entries are</FONT>
<BR><FONT SIZE=3D2>shared among parents.</FONT>
<BR><FONT SIZE=3D2>With other words, 2 diffServMeterEntries could have =
the</FONT>
<BR><FONT SIZE=3D2>same diffServTBMeterEntry for its parameters. =
IMHO,</FONT>
<BR><FONT SIZE=3D2>there is no need to duplicate the =
diffServTBMeterEntry.</FONT>
</P>

<P><FONT SIZE=3D2>Having both a specific pointer and a shared index =
the</FONT>
<BR><FONT SIZE=3D2>data in the MIB can be ambiguous. So the only =
possibility is</FONT>
<BR><FONT SIZE=3D2>selecting or a specific pointer or a shared =
index.</FONT>
<BR><FONT SIZE=3D2>As described above, I believe having the specific =
pointer</FONT>
<BR><FONT SIZE=3D2>makes it totally unambiguous.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I think this is the only instance of a =
parent/daughter table like this</FONT>
<BR><FONT SIZE=3D2>&gt; in this MIB module although others could arise =
in other MIBs that</FONT>
<BR><FONT SIZE=3D2>&gt; tried to use the base tables in this Diffserv =
MIB.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Issue 31:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (31) When inheritance is needed and =
parent/daughter share indexing,</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 parent often points to the =
daughter using a &quot;Specific&quot;</FONT>
<BR><FONT SIZE=3D2>attribute</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 e.g. diffServMeterSpecific, =
diffServActionSpecific,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 diffServAlgDropSpecific. If =
this is a RowPointer and points to</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 associated row in the =
daughter's table, there is redundant</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 information which gives =
scope for additional error cases. So,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 wherever possible, should =
we remove this redundant information</FONT>
<BR><FONT SIZE=3D2>by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 making the =
&quot;Specific&quot; attribute point only to the base of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 daughter table and make it =
an OBJECT IDENTIFIER? The con is</FONT>
<BR><FONT SIZE=3D2>that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 this is an unusual use of =
MIB pointers (point at table base,</FONT>
<BR><FONT SIZE=3D2>not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;=A0=A0=A0=A0=A0 individual entries).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Again, I've argued all along that allowing the =
provision of redundant</FONT>
<BR><FONT SIZE=3D2>&gt; information is the root of most evil (i.e. =
complexity) in handling</FONT>
<BR><FONT SIZE=3D2>&gt; error cases.</FONT>
</P>

<P><FONT SIZE=3D2>Yes, the redudancy creates unambiguous data in the =
MIB. (see above)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; And again I've only heard a Luddite =
counter-argument. For</FONT>
<BR><FONT SIZE=3D2>&gt; specific changes, go back to the -04 draft =
description/syntax for e.g.</FONT>
<BR><FONT SIZE=3D2>&gt; diffServMeterSpecific (there's a separate =
discussion of whether the</FONT>
<BR><FONT SIZE=3D2>&gt; syntax should then be RowPointer or OBJECT =
IDENTIFIER but let's leave</FONT>
<BR><FONT SIZE=3D2>&gt; that for now).</FONT>
</P>

<P><FONT SIZE=3D2>I agree, selecting a RowPointer or OBJECT IDENTIFIER =
is</FONT>
<BR><FONT SIZE=3D2>less important. I would say select OBJECT IDENTIFIER =
which</FONT>
<BR><FONT SIZE=3D2>can be a RowPointer, but a RowPointer can not be an =
OBJECT IDENTIFIER.</FONT>
<BR><FONT SIZE=3D2>The RowPointer is a subset with restricted =
semantics.</FONT>
</P>

<P><FONT SIZE=3D2>Harrie</FONT>
<BR><FONT SIZE=3D2>0- Harrie Hazewinkel =
---------------------------------------0</FONT>
<BR><FONT SIZE=3D2>=A0<A =
HREF=3D"mailto:harrie@covalent.net";>mailto:harrie@covalent.net</A>=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 phone:+1-415-536-5221</FONT>
<BR><FONT =
SIZE=3D2>0-----------------------------------------------------------0</=
FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>diffserv mailing list</FONT>
<BR><FONT SIZE=3D2>diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/diffserv"; =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/diffserv</A></FO=
NT>
<BR><FONT SIZE=3D2>Archive: <A =
HREF=3D"http://www-nrg.ee.lbl.gov/diff-serv-arch/"; =
TARGET=3D"_blank">http://www-nrg.ee.lbl.gov/diff-serv-arch/</A></FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C04E88.5FF367C0--

------- End of Forwarded Message