DECnet IV MIB issues...

[Don Dewar <[e-mail]>]

I see that the DECnet Phase IV MIB working group is starting up the
effort to make the MIB a DRAFT.  Before that happens I would like
answer to the following four questions.

Some time ago I asked what the value of
phivAdjCircuitEtherServPhysAddr should be for those stations that do
not include their actual hardware addresses in the hello messages.
The issue is that since the node address used to identify a DECnet IV
station is derived that node address is not the "physical address" of
the device.  In fact, for those devices that operate in promiscuous
mode and pick off their DECnet node address in software, their network
interface is still probably programmed with their MAC address.  I saw
two possible answers for this question; either use the DECnet node
address (ie. AA 00 04 xx xx xx) or just leave it all zeros (ie. 00 00
00 00 00 00).  The problem with setting it to the DECnet address is
that some nodes would show up with DECnet addresses while other would
show up with the "real" mac addresses.  I think this might be
confusing.  In addition, it is redundant information, since the
adjacency table entry already has the "phivAddr" of the node in it.  I
have received one response that believes that the DECnet node address
should be used.  I believe it should be left to zeros.  Jon Sapiera
et. al. did not have an answer for this question and asked that I
solicit suggestions from the net.  Please let me know what you think.

I am confused between the use of phivLineState vs.
phivCircuitCommonState.  They both claim to represent the network
managment operational state of the their respective entries, yet, one
is read-only, while the other is read-write.  And they are opposite of
what I would think.  phivLineState is read-only and yet I would think
you would want a user to be able to disable a line for a protocol
since that represents the physical entity they have control of.
phivCircuitCommonState is read-write, but it represents a more logical
entity that I would expect the user to not have control of.  The
descriptions of these items in the MIB is not very 


Why do not any of the standard protocol MIBs define any optional
filter groups?  By not doing so, every vendor that supplies protocol
filters must define their own MIB.  Can the DECnet IV MIB define some
rudimentary filters.

I saved this question for last because it is the most controversial,
but I think it is important.  I once proposed implementing a DECnet
phase IV router that could be multpile level 2 routers in one device,
something I am told Cisco has implemented.  We abandoned the idea
because it is explicitly called out as taboo somewhere in the DECnet
specs and because a consulting firm thought it was not really useful.
However, we might still do that, but the DECnet IV MIB as it stands
today would not support such a beast very well.  Would it be useful
for the MIB to support this?  Or am I about to get flamed?!?!?

    Coral
  @@@@@*@**
  @@*@@**@@     Don Dewar
  *@@**@@@@     Coral Network Corporation, Westboro, MA
  @***@@@@@     Internet: [e-mail]
  @@**@@@@@     Phone:    [phone]
  *********     Fax:      [phone]
  Networks