Re: Adjacency index

[[e-mail]]

Bob wrote:

>Right.  I didn't think of that.  Actually, we may have done something truly
>bizarre and indexed by a useful integer but returned the circuit index for the
>allegedly corresponding MIB object.  Or maybe not.  That's academic.  In any
>case the MIB is decidedly broken and it seems marking the table obsolete and
>replacing it with the double indexed one is the right answer.

I am not sure that the current mib could not be fixed (and retain the
single index) as we discussed or is 'decidedly broken' - that discussion
is somewhat academic though.  I believe we have reached an informed
consensus on this issue.  To use some of Bob's words we will "Do what's
right" and when turn to draft we will obsolete the existing Adjacency
table with the single index even though that means more work for
developers.  The consensus is that it is not a hard task and at least
one person who has implemented it has said they would be willing to do
the recoding.  By doing this now rather than later - we can give people
a heads up.  Before I put in the table in it's entirety I have two
questions which we need to get clearly answered:

	Where should I put the new table in the MIB, at the end of the
Adjacency group so as to leave all the existing OID's the same? Or
should I overlay the new table onto the old and just have some ASN.1
comments explaining what we did?  Since I am not at all sure about this,
I have copied Chuck and ask that he let us know since apparently this
has come up recently with other MIBs.  The one item that makes things
simpler in this case is that all that is in the adjacency group is the
table in question, so if we need to obsolete the entire group, that will
be no different that making the table obsolete.  That then would leave
the question of where to insert the new group.

	The second is about phivAdjCircuitIndex.  Why I was thinking
about using the same value as the index out of the circuit table is that
management stations might want to collect other circuit information when
looking at adjacency (in this case, obviously they would have to get the
circuit name - which is in the circuit table).  The idea here was that
we would have something that is conceptually similar to the new augments
function in the SMP proposal.  Several other tables in this MIB (e.g,
Link and DDCMP) also use CircuitIndex as well.  I do not have hard
opinions about this, if the majority want to keep it simple and just
have the circuit names with an object identical to the one we have in
the circuit table, I am happy to do that, in fact I use that in the
example below.  The side benefit of doing this is that you can get all
the adjacency information for a given circuit together (at least that is
how I would tell and agent implementer to do it).  Please note that this
would be a variable length index which I think is better coded as an
OCTET STRING rather than DisplayString for this purpose since the first
octet of the index will the length.  I think it has to be this way given
the variable length of circuit names.  Also I changed the name of the
object to be phivAdjCircuitName which I think is more generally
descriptive of this object when used this way.  If we elect to use and
index, I would change the name again.

So, I hope we are done on this issue.  I would like to hear if anybody
feels this is an undue hardship (which I do not think) and what their
preference for the coding of the index should be.  I will leave it to
Chuck Davin to comment about where to put the new and deprecated tables.


       phivAdjTable OBJECT-TYPE
           SYNTAX SEQUENCE OF PhivAdjEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
               "The Adjacency Table."
           ::= { adjacency 1 }

       phivAdjEntry OBJECT-TYPE
           SYNTAX PhivAdjEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
               "There is one entry in the table for each adjacency."
           INDEX  { phivAdjCircuitName, phivAdjNodeAddr }
           ::= { phivAdjTable 1 }

       PhivAdjEntry ::=
           SEQUENCE {
               phivAdjCircuitName
                   OCTET STRING,
               phivAdjNodeAddr
                   PhivAddr,
               phivAdjBlockSize
                   INTEGER,
               phivAdjListenTimer
                   INTEGER (1..65535),
               phivAdjCircuitEtherServPhysAddr
                   OCTET STRING,
               phivAdjType
                   INTEGER,
               phivAdjState
                   INTEGER,
               phivAdjPriority
                   INTEGER,
               phivAdjExecListenTimer
                   INTEGER (1..65535)
            }

       phivAdjCircuitName OBJECT-TYPE
           SYNTAX OCTET STRING
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "The name of the circuit over which the adjacency is
               realized.  This combined with the phivAdjNodeAddr give
               a unique index into this table."
           ::= { phivAdjEntry 1 }

       phivAdjNodeAddr OBJECT-TYPE
           SYNTAX PhivAddr -- OCTET STRING (SIZE (2))
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "The address of the adjacent node."
           ::= { phivAdjEntry 2 }

       phivAdjBlockSize OBJECT-TYPE
           SYNTAX INTEGER
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This read-only parameter is the block size that was
               negotiated with the adjacent Routing layer during Routing
               initialization over a particular circuit. It includes the
               routing header, but excludes the data link header. This
               parameter is qualified by ADJACENT NODE."
           ::= { phivAdjEntry 3 }

       phivAdjListenTimer OBJECT-TYPE
           SYNTAX INTEGER (1..65535)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This 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 }

       phivAdjCircuitEtherServPhysAddr OBJECT-TYPE
           SYNTAX OCTET STRING ( SIZE (6) )
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This parameter indicates the Ethernet physical address
               of an adjacent node that is being serviced on this
               circuit. This parameter is a qualifier for SERVICE
               SUBSTATE."
           ::= { phivAdjEntry 5 }

       phivAdjType OBJECT-TYPE
           SYNTAX INTEGER {
               routing-III (1),
               nonrouting-III (2),
               area (3),
               routing-IV (4),
               nonrouting-IV (5)
           }
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This parameter indicates the type of adjacency.

               For adjacent nodes, this is a read-only parameter that
               indicates the type of the reachable adjacent node.
               NOTE: The routing-III and nonrouting-III values are
               incremented by one compared to the standard DECnet
               values in order to maintain compliance with RFC 1155)"
           ::= { phivAdjEntry 6 }

       phivAdjState OBJECT-TYPE
           SYNTAX INTEGER {
               initializing (1),          -- Ethernet one-way
               up (2),                    -- Ethernet two-way
               run (3),                   -- The eight DDCMP/X.25 states
               circuit-rejected (4),
               data-link-start (5),
               routing-layer-initialize (6),
               routing-layer-verify (7),
               routing-layer-complete (8),
               off (9),
               halt (10)
           }
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This value indicates the state of a router adjacency.
               On adjacencies over a circuit of type
               (phivCircuitCommonType) Ethernet, CI, or FDDI, with an
               adjacent node of type (phivAdjType) ROUTING IV or AREA,
               this variable is the state of the Ethernet
               Initialization Layer for this adjacency, and can have
               values INITIALIZING or UP. (See Section 9.1.1 of
               DECnet Phase IV Routing Layer Functional Specification.)

               On adjacencies over a circuit of type
               (phivCircuitCommonType) Ethernet, CI, or FDDI, with an
               adjacent node of type (phivAdjType) NONROUTING IV,
               this variable will always take on the value UP.

               On adjacencies over a circuit of type
               (phivCircuitCommonType) DDCMP POINT, DDCMP CONTROL,
               DDCMP TRIBUTARY, DDCMP DMC, or X.25, this variable is
               the state of the Routing Layer Initialization Circuit
               State. (See section 7.3, ibid.)  It can have values
               between RUN and HALT.

               On adjacencies over a circuit of type
               (phivCircuitCommonType) OTHER, this variable may be
               used in a manner consistent with the Initialization
               Layer used on that circuit."
           ::= { phivAdjEntry 7 }

       phivAdjPriority OBJECT-TYPE
           SYNTAX INTEGER (0..255)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "Priority assigned by the adjacent node for this
               circuit."
        ::= { phivAdjEntry 8 }

       phivAdjExecListenTimer 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."
           ::= { phivAdjEntry 9 }