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

Re: Review of draft-ietf-snmpconf-bcp-07




Glen,

Thanks very much for the detailed review as well as the 
impression the document left you with. 

Below are some comments... 

Regards,
Mike


On Fri, Jan 11, 2002 at 08:11:58PM -0500, Glenn Waters wrote:
>First, I have a hard time with the classification of this document as a BCP.
>There is some BCP content but there is also content that is Experimental,
>Informational, and, some which should be put into a standard. I point out
>some of those sections as I went through.

>[page 10]
>	Object descriptors (the "human readable names" assigned to object
>identifiers [5]) defined in standard MIB modules should be unique across
>all MIB modules.  
>
>Not sure that this is possible, desirable, or required. I think that being
>unique within a MIB module is just fine. Besides, vendors MIBs will likely
>use a name that is being used by some other module.

The experts I spoke with have said this isn't good to do.
Also I know of one implementation (hp openview xnmloadmib) where such things
will cause import errors.

Granted enterprise mib modules may have overlaps, so the problem remains. 
sming should fix this.

>[page 10]
>	Secondly, management
>	applications can be pointed at specific subtrees for fault or
>configuration, causing a more efficient retrieval of data and a simpler
>management application with potentially better performance.
>
>I don't get this point which is in the section called "Naming MIB Modules
>and Managed Objects". How does naming objects have anything to do with the
>OID tree structure?

I'll take a stab at this, though Jon or Wayne should chime in.

Many folks assume there is a relationship between the names and the branches
of the oid tree. The example above goes into one specific approach
to grouping information with a given name. Would it be useful
to have a real example? 

>[page 27]
>	An example of such an object from the OSPF Version 2 MIB [27] is the
>	global ospfAdminStat:
>
>	    ospfAdminStat OBJECT-TYPE
>		SYNTAX   Status
>		MAX-ACCESS   read-write
>		STATUS   current
>		DESCRIPTION
>		   "The  administrative  status  of  OSPF  in  the
>		   router.   The  value 'enabled' denotes that the
>		   OSPF Process is active on at least  one  inter-
>		   face;  'disabled'  disables  it  on  all inter-
>		   faces."
>	       ::= { ospfGeneralGroup 2 }
>
>This object does not seem to match the discussion from the previous
>paragraphs. The point that I get from the section is that you are describing
>how to activate parts of a configuration. It seems that this object is
>activating a process which uses some configuration. I thought that you would
>present an object that controls some part of the configuration.

I see your point, the above object does activate the whole config
and not a part of it. I will find a better example from a standard mib
module.

>----
>
>[page 32]
>	INFORM PDUs, as opposed to TRAP PDUs, have an inherent advantage
>when
>	the concern is the reduction of unneccessary messages from the
>system
>	generating the NOTIFICATION-TYPE data.
>
>I don't understand what the inherent advantage is. This statement could use
>some clarification.

Jon, can you augment paragraph 3 of 3.10.2 ?

In the code I've seen, you have two cases: 
1) a given event occurs either slower than can be delivered
to manager station or faster.
In the slow case, there isn't anything "reduction"
as the agent didn't care and the manager which may
or may not have seen the event eventually polled for
status and took care of the problem anyway.

2) In the fast case, an inform will just cause a backup
of messages in the agent, and some events will be dumped 
(queue full) before being sent. I guess this is a
"reduction" of traffic on the wire :-)