BIND 10 #916: implement a prototype for stats snmp interface

[BIND 10 Development]

#916: implement a prototype for stats snmp interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  naokikambe
  naokikambe                         |                Status:  closed
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:         |            Resolution:  fixed
  statistics                         |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  10
Feature Depending on Ticket:  SNMP   |           Total Hours:  30.00
  stats                              |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by naokikambe):

 * status:  reviewing => closed
 * totalhours:  0.75 => 30.00
 * resolution:   => fixed


Comment:

 Hello

 Replying to [comment:12 vorner]:
 > Yes, mostly because the gen-mibfile.py and generally the thing that
 because it looks like the list of statistics is considered static in more
 or less dynamic bind10, which feels strange.
 >
 > I guess SNMP doesn't support a way to push the change of list actively.
 But it must be able to answer a query „give me list of variables“ and the
 answer could be different for future queries.
 >
 > What I fear is, user will start up for the first time, it will create
 some statistic list for him, then disables auth and enables resolver.
 Provided the first list was correct, it now must be wrong. So it would
 make sense to me to delay the creation of the list for the time the list
 of variables is requested.
 >
 > But that might be just my preference. Maybe the problem I see wouldn't
 be issue in real life anyway.

 Yes, we might need to consider the creation timing of the MIB file.
 The names in MIB can be duplicated in real life as you mentioned
 above. That might be issue. We should consider about naming the
 statistics item in both the spec file and the MIB file.  Anyway, the
 MIB file might be installed by user hands into another SNMP client
 which we never know. We cannot control such situation. We might need
 to keep the tool {{{gen-mibfile.py}}} somewhere for the MIB recreation.

 > So, then, you probably can close this ticket whenever you feel like it,
 I guess, and keep the branch around. Maybe the branch could be renamed to
 some experiments/something so it is not deleted on some cleanup?

 Thank you for suggestion. I've locally merged that with the master and
 pushed to the remote experimental branch, and then I've
 deleted the existent branch. So I'm closing the ticket.

 Best

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