IETF
eman@jabber.ietf.org
Monday, March 11, 2013< ^ >
nevil.brownlee has set the subject to: IETF 85
Room Configuration
Room Occupants

GMT+0
[14:36:01] davidalanreid joins the room
[14:36:19] davidalanreid leaves the room
[15:44:32] ietfdbh joins the room
[16:36:53] nevil joins the room
[16:54:18] aluchuk joins the room
[16:55:04] moulchan@cisco.com joins the room
[16:55:51] davidalanreid joins the room
[16:57:31] moulchan@cisco.com leaves the room
[16:58:18] Juergen joins the room
[17:01:57] moulchan@cisco.com joins the room
[17:05:36] <moulchan@cisco.com> pls share the slides on WebEx
[17:06:39] <nevil> John Parello is presenting the Framework draft
[17:09:03] benoit.claise joins the room
[17:09:53] Floris joins the room
[17:11:38] <nevil> now on 'rreorganisng sections' slide
[17:16:56] <Juergen> I support what Brian says about energy management. We also need to agree on the objective of Energy management. Today we say the objective is "saving energy". this seems to be too narrow.
[17:29:24] <Juergen> The MUST says so right now. But with this new input, let's discuss it agian-
[17:30:23] Jürgen Schönwälder joins the room
[17:40:53] <moulchan@cisco.com> ENERGY-OBJECT-CONTEXT-MIB
[17:41:04] <ietfdbh> there is a potential for confusion because "context" is a reserved word for snmpv3.
[17:44:24] <moulchan@cisco.com> the table is not rowstatus now
[17:45:04] <Juergen> Hi Bruce, shall I talk about the Battery MIb over Skype?
[17:45:40] <nevil> Juergen - Bruces says yes, please
[17:46:06] <Juergen> OK, Bruce, please go online with Skype
[17:47:00] <benoit.claise> yes, perfect
[17:47:10] <moulchan@cisco.com> yes, perfect
[17:47:20] moulchan@cisco.com leaves the room
[17:50:37] moulchan@cisco.com joins the room
[17:52:19] <ietfdbh> In energy-monitoring-mib doc, the MIB identification is Energy-Object-MIB but the objects use an "eo" prefix. RFC4181 has recommended naming conventions that the object prefixes should mirror the MIB name, so objects should be "energyObject". If an application told an operator the object is eoXXX, the eo is not meaningful. With a prefix of energyObject, the operator can tell that the MIB to look in for details is the ENERGY-OBJECT-MIB.
[17:53:50] <moulchan@cisco.com> there is an FRU MIB
[18:02:28] Juergen leaves the room: Replaced by new connection
[18:02:29] Juergen joins the room
[18:05:44] <ietfdbh> if I do an RFC/ID search the Energy Object Context MIB comes up. If I search for energy monitoring, the power and energy monitoring MIB doc comes. If I search for FRU, or FRU-MIB, nothing comes up. Thanks for the example of a MIB with bad naming ;-)
[18:06:48] <benoit.claise> I just sent an email to EMAN: http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ENTITY-FRU-CONTROL-MIB
[18:09:23] <ietfdbh> which slide are we on?
[18:09:49] <benoit.claise> "management protocols & data models"
[18:09:58] <ietfdbh> thx
[18:11:16] <benoit.claise> next slide Dave
[18:14:58] aluchuk joins the room
[18:17:48] <Juergen> Do you have a proposal for a better integration of the battery?
[18:22:41] <Juergen> The relationship of devic
[18:23:05] <Juergen> On slide 10: the relationship between device and battery is given by the entity MIB.
[18:24:17] <Juergen> The energy object MIb gives you means to model a battery as a separate object.  This object will have the same index in the entity MIB as a battery in the battery MIB
[18:28:07] <ietfdbh> My experience is that UML seems to encourage a full-blown model of possible managed obejcts; SNMP/SMI encourages developing only necessary objects to minimize the impact on devices. Devices are not designed to do management; they are designed to provide functionality and management shows the critical config/operational values. There was (is?) an IP-CONFIG MIB that was designed from a full-fledged info model developded elsewhere, and it ended up being the largest IETF MIB ever published. I don't know if anybody ever implemented it fully.
[18:34:15] <Juergen> In SMI the battery MIB is well linked. Why not modelling it by direct 1-n relationship between device and battery in UML? In SMI it is already there.
[18:36:50] <ietfdbh> I only meant to point out that different languages, whether for info models or data models, can significantly impact the design. Not only can a limited language like SMI constrain the possible info models to be considered, using something like UML can lead to info models that are hard to represent in standards, such as MIB modules or YANG modules or IPFIX models.
[18:37:45] <ietfdbh> I can take this to the list rather than tying up the meeting.
[18:39:32] <nevil> Yes, that will be a good topic to discuss on the list, thanks
[18:41:34] <ietfdbh> The mic is rather noisy; is the speaker holding it in front of their mouth, or attaching it to their shirt?
[18:42:26] <nevil> holdit near mouth
[19:00:32] Jürgen Schönwälder leaves the room
[19:00:58] aluchuk leaves the room
[19:02:26] Floris leaves the room
[19:09:30] benoit.claise leaves the room
[19:10:59] fvdabeele joins the room
[19:15:09] nevil leaves the room: offline
[19:32:01] davidalanreid leaves the room
[20:19:49] moulchan@cisco.com leaves the room
[20:34:58] Juergen leaves the room
[20:48:49] fvdabeele leaves the room: Replaced by new connection
[20:48:49] fvdabeele joins the room
[20:54:31] fvdabeele leaves the room: Replaced by new connection
[20:54:34] fvdabeele joins the room
[20:57:17] fvdabeele leaves the room
[21:49:11] ietfdbh leaves the room