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

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



On Friday 11 January 2002 08:59 pm, Michael MacFaden wrote:

> Glen,
>
> Thanks very much for the detailed review as well as the
> impression the document left you with.
>
> Below are some comments...
>
> Regards,
> Mike
>

Glen, thanks also for your comments. This also gives me a chance to say 
where we are on revisions to the document. We have recieved comments on 
the most recent version for Bert in a handwritten form, David Partain, and 
Rand P who posted to this list some time ago.  We are happy to work on 
your comments as well. I do have some comments on them and rather than 
starting multiple threads, I have replied to the comments Mike made.

We did spend quit a lot of time on Thursday going over the handwritten 
notes that Bert provided. Some were specific and detailed, others were 
not. David Partain was also very thorough and even gave us a diff.  Our 
goal is to work through these over the next week or so.

Not to the comeents on the comments.


> 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.
> >
We have discussed this point in the past at some length. This is a hard 
call here, but at some point in the future if more work is done in this 
area and we need standardization, that can happen. I still feel BCP is the 
best general description.

With regard to your comments about configuraiton with SNMP. Yes, it does 
add complexity but in my experience now with at least 4 implementations of 
systems that use SNMP as a configuration method, it is just not as hard as 
many people that have not done it indicate. These implementations include 
products that range from shipping bandwidth management products in quite 
small footprints to very large router types of products. Much of the work 
is in the design of the MIB Objects. Done following some of the principles 
in the BCP, it makes the task easier and the resulting product more useful 
at least for those of us that wish to write sophisticated management 
applications. This is really not too relevant to the BCP at this point 
except to say that people can and do build products successfully this way.

> >[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.

Mike, is quite correct in my experience with applications. His example of 
HP is one. I had a similar experience with the SUN product not that long 
ago.  

>
> >[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?

Glen/Mike When constructing a management application to work with an 
agent, if the counters for a particular part of the sub system fall 
withing a single branch like the acmeFooStatistics group, then with a 
single OID, I can tell the system to retrieve all the data needed to know 
about Foo statistics without having to put into the manager several OIDs. 
It is just good organization of data. 
>
> >[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.
>

Mike please pass that on to use and we will be sure to include it.
> >----
> >
> >[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 ?

Yup, you folks are quite correct. Wayne and I talked about this the other 
day. We have some new words.
>
> 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 :-)

-- 
Jon Saperia                         
				
saperia@jdscons.com
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/