[08:48:52] --- rstory has joined
[08:57:37] --- sleinen has joined
[09:00:12] --- kazuya has joined
[09:01:14] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[09:03:04] --- ray_atarashi has joined
[09:03:18] --- irino has joined
[09:04:17] --- yoshfuji has joined
[09:04:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> meeting started
[09:04:36] <j.schoenwaelder@jabber.eecs.iu-bremen.de> agenda bashing and the usual stuff going on
[09:04:49] <yoshfuji> Slide: Administrativia
[09:05:18] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Interim Meeting
[09:05:23] <yoshfuji> Slide: Internim Meeting
[09:06:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Submitted Drafts
[09:06:54] --- dbh2 has joined
[09:08:20] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Active Drafts
[09:10:02] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: need to understand and prioritize requirements
[09:10:33] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: distinguish between "in use today" and "what we like to have in the future"
[09:11:30] <yoshfuji> Additional Agenda?
[09:11:39] <yoshfuji> Slide: Agenda
[09:13:15] <yoshfuji> * NETCONF role in the Network Management System
[09:13:33] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Hideki Okita starts his presentation
[09:13:44] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Starting Point
[09:13:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Modern Technologies
[09:14:19] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Layer Devide Problem
[09:14:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Protocol vs. API
[09:15:31] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: API Trial
[09:16:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Contents of Architecture Draft
[09:18:25] --- bert has joined
[09:18:57] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Do not understand all the arrows?
[09:19:48] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: No agreement what the role is that netconf plays.
[09:20:38] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BW: In the ID, the dashed arrow does not exist. Why?
[09:21:09] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Event Notification Concern
[09:22:30] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: NETCONF System Demonstration
[09:23:16] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Conclusions
[09:25:11] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: What do you mean by closer collaboration?
[09:26:01] <j.schoenwaelder@jabber.eecs.iu-bremen.de> HO: People do not read the other area's drafts
[09:26:31] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Lack of XML is not holding the Internet back
[09:28:11] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: To build NM applications, you need technology experts, protocol experts, database experts and GUI experts.
[09:29:13] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: Network management applications can hurt networks if they are not designed well and it is important to include the cost on the network in the evaluation.
[09:30:15] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Concerns about the integration of applications and networks
[09:30:47] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sharon is next presenter...
[09:30:58] --- Yoshifumi Atarashi has joined
[09:31:15] <yoshfuji> Still forcusing on configuration.
[09:31:23] <yoshfuji> * Netconf Data Model Framework
[09:31:37] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Netconf Data Model Framework
[09:31:41] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Outline
[09:31:51] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Status
[09:34:40] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: What I've found I need
[09:37:03] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Have thought about multi-vendor data organization?
[09:37:11] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Use namespaces.
[09:37:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: What is a reasonable structure for organizing data?
[09:38:42] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Strike balance between structure and organic growth.
[09:38:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: I have seen CLIs organically...
[09:39:27] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: No answers yet in the draft
[09:39:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Need an answer for these questions if we want standard data models
[09:40:54] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Conformance is much more than MIN/MAX access - having a single conformance statement is problematic
[09:42:12] <j.schoenwaelder@jabber.eecs.iu-bremen.de> WH: The hard part are references - and think of them from an implementation point of view
[09:43:21] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Are there implementors in the room? Yes.
[09:43:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Do implementors have an opinion on Sharon's draft?
[09:45:06] <j.schoenwaelder@jabber.eecs.iu-bremen.de> RE: Have no opinion on Sharon's draft - we have a central database which takes care of references.
[09:45:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Phil Shafer is next presenter
[09:46:08] <yoshfuji> * draft-shafer-netconf-syslog-00.txt
[09:46:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: SYSLOG over NETCONF
[09:46:48] <sleinen> http://www3.ietf.org/proceedings/06jul/slides/netconf-4.ppt
[09:47:15] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Event Stream
[09:48:18] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: System Components
[09:48:51] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Two RPCs
[09:49:38] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: get-syslog-streams
[09:49:47] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: get-syslog-events
[09:50:01] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: get-syslog-events reply
[09:50:19] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: insert-convincing-argument-here
[09:50:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Issues
[09:51:26] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: get-syslog-stream vs. get
[09:53:04] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Cost of filters
[09:53:49] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Cost of filters (cont)
[09:54:34] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: It is not implementation complexity which concerns me, but interoperability
[09:55:05] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Concerns about data on a device that does not show up in a <get>
[09:55:50] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: The question is additional vs instead-of RPCs
[09:55:58] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: SYSLOG specific
[09:56:07] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Use of RPCs
[09:56:54] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Complete Data Model
[09:57:25] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Conclusions
[09:58:33] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BL: SYSLOG is not everywhere widely used
[09:59:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: SNMP notifications are nice because they have format
[10:00:40] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BL: Likes to be able to transfer other notification content - not just SYSLOG
[10:01:19] --- woj has joined
[10:01:20] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: What is a configuration related notification? SL and AB think the only notification is a configuration change notification
[10:02:14] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Concerned about a lack of a common vision of the scope of NETCONF
[10:03:25] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: Need in addition a device change notification plus a configuration mismatch notification
[10:04:27] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: There is no end if you include fault/failure information
[10:05:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Operators grab configurations, some do this triggered by traps
[10:05:55] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: A simple SNMP trap might be sufficient to get this done
[10:06:55] <j.schoenwaelder@jabber.eecs.iu-bremen.de> WH: Does not understand the purpose of the discussion?
[10:08:13] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: I am properly ahead of the agenda - are we heading too far away from notification?
[10:08:44] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC is on stage again...
[10:08:54] <yoshfuji> * NETCONF Event Notifications
[10:10:26] <bert> Slode: Key Features
[10:10:34] <bert> s/Slode/Slide/
[10:11:06] --- dromasca has joined
[10:12:13] --- dromasca has left: Disconnected
[10:12:26] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Netconf Layers
[10:12:56] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: An Architecture
[10:13:48] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Message Flow
[10:14:35] --- woj has left
[10:14:46] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Message Format
[10:15:23] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Requirements
[10:17:36] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Requirements (2)
[10:18:57] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Requirements (3)
[10:19:49] --- ray_atarashi has left: Replaced by new connection
[10:20:12] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: requirement 17 on SC's slide is about the uniqueness of the session ID / subscription ID
[10:20:47] --- ray_atarashi has joined
[10:22:26] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Discussion concerning the scope and usefulness of a subscription ID
[10:24:48] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Requirements (4)
[10:25:58] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Issues - Big
[10:25:59] <yoshfuji> :w
[10:26:38] <yoshfuji> (oops.. ":w" is accident for other window...)
[10:27:06] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Issues - Less Big
[10:29:28] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: XPATH can be used to specify relationship to a configuration piece
[10:29:46] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Concern is how to correlate the information
[10:30:28] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: NETCONF already supports XPATH - why not use the same mechanism?
[10:31:22] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Move towards the requirements discussion
[10:31:30] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Slide: Requirements list (1/2)
[10:32:11] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Not sure whether notifications really have to look like configuration
[10:32:46] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Difficult to do
[10:33:04] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: We must make it easy to map things, not necessarily the same
[10:33:46] <sleinen> Juergen on the same issue: as an implementor, I call a function called syslog() and that's it
[10:34:10] <sleinen> (JS): If you have to identify the configuration that the issue refers to, I wouldn't have a clue how to implement that.
[10:36:12] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Can we agree that it is sufficient to be able to name something that causes the notification?
[10:37:17] <j.schoenwaelder@jabber.eecs.iu-bremen.de> WH: Encourage coders to supply information but do not require it
[10:38:31] <j.schoenwaelder@jabber.eecs.iu-bremen.de> PS: Complexity is the translation of a standard model to a device model is hard. Translating backwards is even harder.
[10:40:17] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BL: All that is needed is naming - once you have names, it is easy
[10:40:52] <j.schoenwaelder@jabber.eecs.iu-bremen.de> ??: Is there a feature to select verbose or compact notifications?
[10:40:58] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Not in the current draft
[10:42:09] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Level of content is not important to see what needs to be done on the protocol
[10:42:19] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: We are here to solve the configuration problem
[10:43:33] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Detail what goes into a notification is not in our charter
[10:44:33] --- kazuya has left
[10:46:07] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DR: Is the analysis of the requirements goal of this meeting?
[10:46:24] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: Without discussing the requirements we will not move forward
[10:47:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Need to understand (a) what a requirement means and (b) whether we think it is important
[10:47:50] <j.schoenwaelder@jabber.eecs.iu-bremen.de> PS: First do a meta discussion? What is the problem we have to solve
[10:49:55] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: We define an SNMP MIB with a configuration change notification and we declare success (and have early lunch)
[10:50:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> The requirements have been numbered on the SLs slide and I have just updated the web page to match
[10:51:43] <j.schoenwaelder@jabber.eecs.iu-bremen.de> There is no consensus in the room that the notification work needs to be done
[10:52:09] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BW: Concerned that we do not focus on a simple solution
[10:52:58] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: Why are the two mutually exclusive?
[10:53:25] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: I believe there is value in both, an SNMP MIB and NETCONF notifications
[10:53:55] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BW: Right now, NETCONF is simple to implement - make sure it stays simple
[10:54:34] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: Let the market decide
[10:55:21] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Are we doing a piece in an existing management system or are we doing a totally new system? There does not seem to be agreement
[10:56:02] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: Agree that the WG does not agree on the scope
[10:58:46] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DR: Work will happen if there is interest. For this WG, consensus is important and working within the charter. What is the tension of the room to make progress? Does not have to be the minimum common ground. May well be a sub-optimal starting point.
[10:59:31] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Do we have to standardize first or do we first wait until people have implemented something that has proven to work?
[11:01:06] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DR: Need to leave room before taking a decision concerning the scope of the charter
[11:01:51] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DR: Try to make the standards complete for useful deployment
[11:02:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DH: Operators did not complain about SNMP notifications or SYSLOG being inadequate at the IAB network management workshop
[11:03:05] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DH: Likes the idea to get some SNMP notifications done and then wait whether more work is needed
[11:05:10] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DP: How high to we raise the implementation bar? In the past, implementations were required after Proposed Standard
[11:06:52] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: There are existing implementations for carrying notifications over NETCONF. Implementations do not interoperate and that is why we are here.
[11:07:20] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Some operators are saying that I do not have to replace SYSLOG to configure my device.
[11:07:52] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: There are problems in the industry that need to be solved and this is why we have the ID
[11:09:09] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BW: In the past, we have tried to address the problems identified by the industry but things are not widely deployed. Begin able to implement is not a sufficient condition for success.
[11:10:04] <j.schoenwaelder@jabber.eecs.iu-bremen.de> WH: People have different needs. The only thing to do in such a situation is to support more than one requirement.
[11:11:20] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: SNMP has a subscription model but it is too hard to use.
[11:12:01] <j.schoenwaelder@jabber.eecs.iu-bremen.de> WH: At some point in the future NETCONF will have notifications.
[11:12:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BL: Why not put SC's document on a diet and move along?
[11:13:19] <j.schoenwaelder@jabber.eecs.iu-bremen.de> BL: We want configuration related data embedded in notifications and SYSLOG might not be the ideal choice.
[11:23:02] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Straw poll between #1 no notifications, #2 mechanism to channel notifications but not specifying structure, #3 full notification architecture including the definition of notification formats
[11:23:39] <j.schoenwaelder@jabber.eecs.iu-bremen.de> The consensus in the room was in favour of option #2
[11:23:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC: Can we still define event meta data and where do we stop? Are even classes in?
[11:24:23] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: I think event classes are out of scope if you pick #2, but in scope if you pick #3
[11:25:15] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: All we need is a PDU which conveys a notification and does not expect a response
[11:27:03] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SC and AB discuss how the WG ID should be changed; not clear there is full aggreement
[11:28:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> PS: If we do not care about the content, why are we doing this?
[11:29:03] <j.schoenwaelder@jabber.eecs.iu-bremen.de> AB: Probably to reuse the secure channel and things like that
[11:29:35] <j.schoenwaelder@jabber.eecs.iu-bremen.de> PS: Why are we driving this? Should SYSLOG not worry about SYSLOG formats?
[11:30:37] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DH: There was a need between the chairs and ADs involved and the conclusion was that NETCONF is not the right place to worry about SYSLOG content. The proper approach would be to have a SYSLOG WG chartered to do this work.
[11:32:59] <j.schoenwaelder@jabber.eecs.iu-bremen.de> SL: It would help if both drafts can be revised to be more content independent.
[11:33:26] --- rstory has left: Logged out
[11:33:36] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Meeting closes - the interim is on two hours in the delta hotel (st charles room)
[11:33:38] --- irino has left
[11:34:00] <yoshfuji> ***END***
[11:34:13] --- yoshfuji has left
[11:34:19] --- bert has left
[11:35:00] --- dbh2 has left
[11:35:51] --- ray_atarashi has left
[11:39:57] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Logged out
[11:41:23] --- kazuya has joined
[11:41:30] --- kazuya has left
[11:51:20] --- Yoshifumi Atarashi has left
[11:56:06] --- sleinen has left
[13:19:23] --- Hideki has joined
[13:41:30] --- bert has joined
[14:12:58] --- sleinen has joined
[15:27:03] --- Hideki has left
[16:28:04] --- dbh2 has joined
[17:16:06] --- bert has left: Replaced by new connection
[17:16:07] --- bert has joined
[17:34:47] --- bert has left
[18:02:53] --- dbh2 has left
[18:22:44] --- sleinen has left