BIND 10 #1448: document basic design of stats snmp interface

[BIND 10 Development]

#1448: document basic design of stats snmp interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  naokikambe                         |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120207
                  Component:         |            Resolution:
  statistics                         |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  SNMP   |           Total Hours:  0
  stats                              |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by naokikambe):

 * owner:  naokikambe => UnAssigned


Comment:

 Some quick comments sent to bind10-dev list:
 https://lists.isc.org/pipermail/bind10-dev/2012-February/003011.html

 My thoughts to these comments are:

 > 1) I think they discuss it later on but I think you probably want to try
 > and arrange things so that other SNMP engines can be used.  For
 > people running our code in "free" settings they are likely to use
 > NET-SNMP.  For people putting our code into devices for sale
 > they might choose one of the other SNMP engines available.  It
 > would be good to try and make it easy for them to do so.  We
 > probably don't want to write the code to connect the engine to
 > our code but making the information easily available would be nice.

 Of course, I don't think we would finish implementation of the SNMP
 feature dependent on NET-SNMP. I think we might consider the independent
 daemon for the stats SNMP in next Y4. I thought my idea written in that
 document would be a temporary thing which we could make in Y3. I
 understand many issues on the stats SNMP.

 > 2) We should use our own enterprise number as the root for the
 > OIDs.  If we don't have one we should get one.  We probably want
 > to put some thought into the arrangement of the tree to support
 > bind10, dhcp10 and potentially other products.

 I think things about the enterprise OID would be out of scope in that
 document. I think the SNMP would be used for the purpose to collect
 statistics in that document. So I think we might make the SNMP feature on
 BIND 10 disabled as a default setting. Because I imagine there might be
 some users who don't really want to use it.

 > 3) In conjunction with (2) we also may need/want to provide space
 > for configuring things via SNMP.  Has the Bind10 team thought about
 > this?  I wouldn't be surprised if you decided to only provide stats
 > level information, but a small number of configuration options
 > (on, off, etc) might be useful.  When last I was involved with SNMP
 > it tended to be more used for monitoring than configuring and I don't
 > think that has really changed.  However there were exceptions cable
 > modems and US DOD being the two big ones.

 I think the SNMP-GET would be used only for SNMP interface for the
 statistics collection as well as the XML/HTTP interface in that document.
 Of course, I know that we could change some configurations of BIND 10 if
 we additionally introduce the SNMP-SET. We might fully redesign the SNMP
 interface if we get to collect another information. But I don't think that
 now.

 > 4) I'm a little iffy about the auto-generation stuff.  It is fine to
 > start with
 > but we need to make sure that the MIB OIDs don't change after they
 > have been published.  We will need to publish a MIB to allow SNMP
 > managers to gather and interpret the data.  Once we do this we can't
 > change the existing relationships.  We can deprecate them and add
 > new ones but we can't change old ones.  (This is also why we want
 > to put some thought into the layout of the OIDs.)

 Yes, I know that auto-generation is inappropriate approach. We'll resolve
 this issue in #1544.

 I'm going to leave the ticket reviewing again. But unless we have further
 comments/opinions about that document, I'd like to close this ticket and
 ask whether we should continue to develop the SNMP stats according to the
 document.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1448#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development