Subject: [manet] Mib v8 review

From: Justin Dean <[email-masked]>
Date: Tue, 26 Jul 2011 11:03:38 -0400

Below is my review of version 8 of the NHDP MIB document.  This most recent
version has addressed many of my concerns and nearly all of the comments
this go around are related to cleaning up terminology which was mucked up by
the changes.  Great work guys.

Justin Dean

Section 5.3

s/in [RFC6130]/of [RFC6130]/

Two constructs, i.e., TEXTUAL CONVENTIONs, are defined in support of the
tables in the State Group.

Two constructs, i.e., TEXTUAL CONVENTIONs, are defined to support the State
Group tables.

You guys use….

"virtual neighbors and neighbor interfaces."

then later use

"address sets, virtual interfaces and virtual routers"

Suggest you use the same order and terminology (also slightly confused on
where the "address sets" came from as the rest of this section is talking
about 2 constructs)

Section 5.4

"That means that there is a change in the set of corresponding Link Tuples
of for that Neighbor Tuple…."

"A change in the set of Link Tuples corresponding to the appropriate
Neighbor Tuple…"

"A 2-hop neighbor is said to become "nbrup" when"

"A 2-hop neighbor becomes "nbrup" when"

Section 7

"A locally arbitrary unique identifier associated with a discovered NHDP
neighbor virtual interface."

"An arbitrary, locally unique identifier associated with a virtual interface
of a discovered NHDP neighbor."

Cut the below as it isn't really important and only adds confusion (all
addresses of a 2 hop neighbor which are being advertised by NHDP will be
discovered)

"Due to the nature of the NHDP protocol, it may not be possible for the
local router to determine all 2-hop neighbor addresses associated with a
single interface."

"Further, the local router may not know if two distinct address sets belong
to the same interface on a 2-hop neighbor or to two different interfaces."

"Due to the nature of the NHDP protocol, the local router may not know if
two distinct addresses belong to the same interface of a neighbor or to two
different interfaces"

Note: you guys keep switching between "virtual neighbor interface" and
"neighbor virtual interface" I suggest you s/neighbor virtual
interface/virtual neighbor interface/

"A locally arbitrary unique identifier associated with an NHDP discovered
virtual per router."

"An arbitrary, locally unique identifier associated with a virtual router of
a discovered NHDP neighbor (one or two hop)."

Note:same thing with mixing terminology of "virtual peer router"  "virtual
router" "virtual neighbor"  I suggest you use "virtual neighbor" as NHDP
nodes are not always routers.  Also suggest replacement of all instance of
router with neighbor or node.

"Given the nature of the NHDP protocol, the local router may have identified
multiple virtual routers which in fact are one and the same."

Due to the nature of the NHDP protocol, the local router may identify
multiple virtual neighbors  which in fact are on and the same.  Two hop
neighbors with more than one advertised address will exhibit this behavior.

RFC5148 does not include the []

[RFC 4001] has a space in it

Note: the description of the constructs in the nhdpStateObjGrp section is
quite good.  Needs to be updated with consistent terminology.

In definition of nhdpDiscRouterIndex OBJECT-TYPE

"The NHDP router ID (locally created) of a neighboring router."

"The NHDP neighbor index (locally created) of a neighboring node." (key
point is removal of ID)

"discovered discovered"

"discovered"

Note: the descriptions of the AddrPrefixLen Objects is obtuse and should be
cleaned up.  Multiple sentences will help here.

Indicates the number of leading one bits that form the

          mask to be logical-ANDed with the address

          used as the table index to determine

          the row match from this table and

          to determine the network address to which

          this interface is attached.

Note in nhdpDiscNeighborNibNeighborSetUpTime you use single quotes around
nbrup and nbrdown where before you used double

in nhdpDiscNeighborNibNeighborSetReachableLinkChanges

"That means that here is a change in the set of corresponding Link Tuples of
that Neighbor Tuple…"

Replace with similar wording which was used in section 5.4

"A change in the set of Link Tuples corresponding to the appropriate
Neighbor Tuple…"

Section 8

This is really the only section which has some correct usages of the word
"router" and "routing" it also has some incorrect ones.  NHDP nodes!=router
but routers can be NHDP nodes.