[09:44:00] --- weshardaker has joined
[09:44:00] --- weshardaker has left: Lost connection
[09:44:00] --- weshardaker has joined
[09:45:42] --- weshardaker has left
[12:01:54] --- leinen has joined
[12:06:33] --- Yoshifumi Atarashi has joined
[12:07:08] --- Yoshifumi Atarashi has left
[12:07:28] --- leinen has left
[14:04:29] --- leinen has joined
[18:18:24] --- BertWijnen has joined
[18:18:46] <leinen> Andy called this meeting to check what our standardization opportunities are in data modeling ("low-hanging fruit")
[18:18:52] --- sivaram7 has joined
[18:19:13] <leinen> May have to first agree about what the problem is that we should solve.
[18:20:11] <leinen> A schema for commonly used data types (IP addresses etc.) was already agreed as a useful thing to standardize
[18:21:05] <leinen> Asking WGs to throw out their existing MIBs and replace them with XML Schemas sounds like a non-starter
[18:21:20] <leinen> Bert: But is this also true for configuration?
[18:21:33] <leinen> Bert: SOME MIBs do have configuration capabilities, but many don't.
[18:21:46] <leinen> Bert: And those that have it might have done it in a weird way.
[18:22:11] <leinen> David Partain: ...or they might not; or they might have found a perfectly good way
[18:22:19] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[18:22:28] <leinen> Hallo Jürgen
[18:22:47] <leinen> DanR: What does "map MIBs cleanly" mean?
[18:23:05] <BertWijnen> Good evening Juergen
[18:23:18] <leinen> Andy: At a minimum: If we define an XML type called InetAddress, it should semantically be equal to what InetAddress means in MIBs
[18:23:54] <leinen> Andy: All that historical baggage (e.g. counters where only difference between readings are defined) are part of the deal
[18:23:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Hello you guys. Just in case, my skype ID is j.schoenwaelder (how boring)
[18:25:00] <leinen> [DanR and DavidP trying to understand each other]
[18:25:15] <leinen> DanR: This is the same we did when we transitioned from SMIv1 to SMIv2
[18:25:42] <leinen> DavidP points out that you could use an SMIv1 MIB with SNMPv2 or even SNMPv3
[18:26:18] <leinen> DanR and DaveH disagree about whether SMIv1 MIBs really aren't used anymore
[18:26:52] <leinen> DaveP tries to call Juergen over Skype
[18:27:10] --- dbh2 has joined
[18:27:13] <leinen> Andy: We had talked about this "SMI for NETCONF"
[18:27:38] <leinen> Andy: Juergen has discussed this on the list - instance naming, and what instances are.
[18:28:07] <leinen> Andy: In SNMP, instances are in rectangular tables. In XML we could do arbitrarily nested structures.
[18:28:22] <leinen> Andy: How do we manage the transition from SMIv2 tables to "rich" data structures
[18:28:36] <leinen> Sharon: Leveraging existing MIBs is a useful goal.
[18:29:12] <leinen> Sharon: But we shouldn't let that get in the way of making a good/intuitive way of specifying things for XML
[18:29:23] <leinen> DanR: Life will be stronger than any plan.
[18:30:05] <leinen> DanR: When we start developing data models that require these structural features this will come naturally.
[18:30:38] <leinen> Sharon mentions inventory management as an area where they used nested XML models.
[18:31:27] <leinen> Andy: An object/method-oriented API may be much closer to the terms in which operators think about their tasks
[18:32:06] <leinen> Andy: schemas for configuration must support something like XML schema's "choice"
[18:32:34] <leinen> Andy: Not like the SNMP way of doing things, having separate tables that are instantiated in different rows.
[18:33:32] <leinen> Andy: That's just an example of an XML feature useful for configuration that doesn't show up in SMI except maybe in a DESCRIPTION clause
[18:34:26] <leinen> Sharon: Suggests to start a list of issues we're talking about
[18:34:49] <leinen> Andy starts a list:
[18:34:51] <leinen> Goals
[18:35:18] <leinen> reuse of SNMP stuff (to the greatest extent that makes sense; not slavishly)
[18:35:59] <leinen> Andy: Scope of the discussion: What is achievable?
[18:37:28] <leinen> Andy: Primary goal: Create a workable Application Programmer Interface that makes vendors and operators say, "wow, this is relly easier than the old way."
[18:37:48] <leinen> Sharon: Something that would require them to learn new technology might also be problematic
[18:39:09] <leinen> DaveH presents his diagram of the IETF Management Framework
[18:39:25] <leinen> protocol column: SNMPv1 -> SNMPv2 -> SNMPv3 -> Netconf
[18:40:00] <leinen> Replaces SNMPv3 -> Netconf with both in a common box since they may supplement each other
[18:40:14] <leinen> Next column about data modeling schemes
[18:40:17] <leinen> SNMPv1 <-> SMIv1
[18:40:24] <leinen> SNMPv2/3 <-> SMIv2
[18:40:35] <leinen> Netconf -> (Netconf) "SMIv3"
[18:41:09] <leinen> Third column: SMIv1 MIB modules -> SMIv2 MIB modules -> SMIv3 MIB modules
[18:41:17] <leinen> Andy remembers the SMIng effort
[18:41:25] <leinen> DaveH: This is RFC 1052
[18:42:04] <leinen> DavidP explains the historical background (SNMPv1/CMIP/SNMPv2)
[18:44:45] <leinen> DanR: Will we still be using SNMPv3 to retrieve counters?
[18:45:06] <leinen> DaveH: If we keep them in tables as we used to, we can retrieve them with SNMP
[18:45:15] <leinen> DaveH: You could also retrieve them with NETCONF
[18:45:53] <leinen> Balasz: Sticking with the "counter" topic - NETCONF might never be efficient enough to retrieve all counters
[18:46:49] <leinen> Andy: The XML code running in routers could well be much more efficient than the SNMP/BER code
[18:50:40] <leinen> Andy: Operators have a more operation-oriented view of their interactions with devices
[18:51:14] <leinen> Sharon: We seem to be moving away from a "suitcase" protocol (original NETCONF idea) by adding specific RPCs ("create-loopback-interface")
[18:54:13] <leinen> Sharon: If we go into that direction, we may need an additional fourth column... "verb design guides" for protocol developers?
[18:54:35] <leinen> Andy argues that protocol designers already know what their (configuration) operations are
[18:55:28] <leinen> DaveH: We'll still need some guidelines
[18:55:43] <leinen> Andy: First guideline: "Here are some standard common data types, don't reinvent your own."
[18:56:15] <leinen> Sharon: You can get the same thing with verbs...
[18:57:04] <leinen> Balasz: Data types are needed even if we go to "verbs" (as parameters). We could agree to define the data types as a first step.
[18:57:43] <leinen> Balasz: Operators love the configuration file and love editing it.
[18:58:11] <leinen> Balasz: At Ericsson we have the rule that everything that can be achieved with verbs should also be achievable (possibly in a clumsy way) by editing the configuration.
[18:58:36] <leinen> Andy: It's a lot easier to agree upon function+outcome than to agree on the "MIB" objects that represent the outcome in data.
[18:59:52] <leinen> Sharon: Can vendors extend the parameters to these verbs?
[18:59:59] <leinen> Andy and DavidP thinks they'll have to.
[19:00:49] <leinen> Andy: The data modeling mechanism should have an easy way for specifying vendor-added things, whether in verbs or in data.
[19:01:14] <leinen> DavidP agrees that if we don't offer this we're dead in the water.
[19:01:35] <leinen> Andy explains this based on the concept of the "general MIDI" interface
[19:02:03] <leinen> Andy: although low-level MIDI controls are different between vendors, there's an agreed-upon set of standard "instrument" settings.
[19:03:12] <leinen> DaveH stops the discussion and asks what the basic model will be.
[19:03:23] <leinen> DaveH: SNMP has access to all the data in the system.
[19:03:38] <leinen> DaveH: With an object-oriented interface there's the concept of "private" data
[19:04:52] <leinen> Will all data go into a global pool, or will we define "private data"
[19:05:36] <leinen> DaveH draws C++ example
[19:08:39] <leinen> discussion about "public data" interface vs. hidden implementation
[19:09:24] <leinen> Balasz: Why do we have to care about these invisible implementation details?
[19:09:51] <leinen> Bert: We have to worry because it may be very hard to map to the public structure - see the SNMP example
[19:10:27] <leinen> Bert: According to Phil, NETCONF works well for them because their public data model matches the structure of the implementation well.
[19:10:53] <leinen> DaveH: If we're standardize the XML data, we'll force vendors to map their internal data to it.
[19:28:32] <leinen> [sorry for not keeping up with the transcript]
[19:55:33] <j.schoenwaelder@jabber.eecs.iu-bremen.de> i am still here - what was the question?
[19:55:52] <leinen> Do we want to use RelaxNG to specify data models?
[19:55:52] <j.schoenwaelder@jabber.eecs.iu-bremen.de> have the philosophers concluded something?
[19:58:19] <dbh2> We are discussing human-friendliness, and how unfriendly XSD is. Should we go to a standard that is easier to read, or develop our own easy0to-read DM language?
[20:00:22] <leinen> DaveH: Should we suggest to the mailing list to use RelaxNG as our data modeling language until we find obstacles against its use?
[20:00:34] <leinen> DanR: Can we find a stuckee to write up an example?
[20:00:47] <leinen> Andy: Jürgen had done that for some traces he did
[20:00:57] <leinen> DanR: What kind of data model?
[20:01:22] <leinen> Andy: The data he wanted from his SNMP collection project.
[20:01:48] <leinen> Balasz: Suggests to formulate the base protocol in RelaxNG compact and see how readable it is.
[20:02:07] <leinen> DavidP: Yes, it's hard for me to discuss this until I see what RelaxNG looks like.
[20:02:17] <leinen> Andy: It's still document-oriented.
[20:02:46] <j.schoenwaelder@jabber.eecs.iu-bremen.de> relax ng example?
[20:02:53] <leinen> Yes please!
[20:02:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> too long ago ...
[20:36:14] --- sivaram7 has left
[20:40:42] <leinen> Simon will post modeling "challange" to the mailing list (classifier part of the diffserv information model in RFC3290)
[20:40:52] <leinen> ^lla^lle
[20:41:24] <leinen> DanR will revise his (expired) I-D with standard data type definitions
[20:45:57] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Replaced by new connection
[20:47:59] --- dbh2 has left
[20:48:55] --- BertWijnen has left
[21:04:32] --- leinen has left
[21:22:41] --- dbh2 has joined
[21:41:44] --- BertWijnen has joined
[21:55:18] --- BertWijnen has left
[21:55:47] --- dbh2 has left
[22:10:37] --- leinen has joined
[23:09:28] --- leinen has left