Re: DECnet MIB question (3)

[[e-mail]]

Hi,

Sorry for the delay in responding, things have been a bit hectic here.
I asked Mark Sylor in our architecture group for an opinion on a couple
of the points detailed below.  He was also able to give me some relevant
history.

In any case, it looks like John Shriver and Art Berggreen have said
basically the same things that I would have said.  There are a couple of
items that I would like to add and rather than parse through all the
mail messages here are the 4 topics:

1.  Zero Counters on a per circuit basis.

There was a question about being able to zero counters on a per circuit
basis.  You correctly observe that the way the MIB is written, this is
not possible.  The reason is that the original DECNet specification
prevented this.  The rationale was that the people who developed the
specs wanted the various counters to have the same relative time base,
especially items like packets and bytes sent.  By doing this they would
be able to get true measures of average packet size by dividing bytes by
packets sent (for example).  I know that 'technically' it could be done
differently, but I think it would add a lot more complexity that is
really not needed.  In any case, that is why it was done that way.


2.  On the two Adjacency Listen Timers.

Mark points out that: "There's only one Listen Timer for an adjacency.
It is read only.  The NETMAN 4.0 spec mistakenly listed it as a
characteristic in the circuit parameter table, it should have been a
status, but in either case, it is a read only value, one per adjacency."

Based on every-ones comments, I propose that we remove phivAdjEntry 9
from the MIB when we move to draft status.  It is really not necessary
if we modify phivAdjEntry 4 to have the following description.  It is
the same as in the current MIB, except that the description calls it a
read-only value:

     phivAdjListenTimer OBJECT-TYPE
           SYNTAX INTEGER (1..65535)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This read-only value determines the maximum number of seconds
               allowed to elapse before Routing receives some message
               (either a Hello message or a user message) from the
               adjacent node on the circuit. It was agreed during
               Routing initialization with the adjacent Routing layer.
               This parameter is qualified by ADJACENT NODE."
           ::= { phivAdjEntry 4 }


3.  The index for adjacencies.

Mark Sylor points out that: In DECNet Phase IV, (at least in the NICE
protocol and in the NCP utility) an adjacency does have what corresponds
to two indices. One is the name of the circuit, one is the node address
of the adjacent node.

I just wanted to underscore what John had sent in a previous note about
the adjacency index.  I believe that this was discussed (either on the
mailing list or at one of our working group meetings - don't remember
which).  The simple, single index does allow for unique identification,
if not as tidy as the tuple would be - and does have the advantages that
John Shriver pointed out.  It is clear the current description should be
reworded to be:

	"A unique index value for each known adjacency."

4.   phivCircuitOrigQueueLimit.

Mark Sylor wrote to me about this and said:

>>> Yes, the Originating Queue Limit is a per circuit attribute. Each circuit
>>> could have a different value. On the other hand, I don't recall any
>>> implementations that actually implement it, unless the RSX-11M version did.
>>> It is defined, and could be implemented, perhaps this is a good one to make
>>> optional.

Based on this, it seems like the current definition in the MIB is more a
reflection of reality.  If people felt strongly that they wanted it, I
suppose it could be added to a table, but that would be very messy
(until SMP is available), since I assume that people would want to
retain it's current read-write access.  If people wanted to make it
read-only, it would be a somewhat simpler matter to make it an
additional entry in the circuit parameters table.

Hope this stuff helps.

/jon


	------------------------------------------
	Jon Saperia, Digital Equipment Corporation			
	Internet: [e-mail]
	508-496-8333/9929     voice/fax