[01:44:07] --- abierman has joined
[01:44:54] --- abierman has left: Logged out
[01:45:51] --- abierman has joined
[01:47:15] --- sleinen has joined
[01:54:38] --- jschoenwae@jabber.org has joined
[01:54:43] --- ietfdbh2 has joined
[01:55:11] <ietfdbh2> good morning.
[01:57:49] <jschoenwae@jabber.org> good morning dave
[01:58:11] --- pigdog has joined
[01:59:05] <pigdog> good morning and good evening to you
[01:59:32] --- brabson has joined
[02:00:10] <pigdog> this is the netconf working group. simon is chairing. i'll be your scribe. if you have questions or comments for the group, please indicate so in this room.
[02:00:53] --- ray_atarashi has joined
[02:01:31] --- bert has joined
[02:01:31] <pigdog> simon: good morning. we have a short slot, most of which i want to dedicate to the future of this working group.
[02:01:50] <pigdog> presentations may be found at http://www.ops.ietf.org/netconf
[02:02:08] <pigdog> this is the 8th meeting of the WG (including the interim)
[02:02:27] <pigdog> looking for scribes (other than me)
[02:03:10] <pigdog> dan r. has agreed to take notes as soon as his computer boots. i'll scribe for jabber.
[02:03:37] --- jlcjohn has joined
[02:03:41] <pigdog> andy couldn't be here. watching through jabber and audio. please use the mikes and identify yourself....
[02:04:00] <pigdog> 10 minutes administrativia & misc.
[02:04:06] <pigdog> 50 minute charter update
[02:04:08] <pigdog> bashing?
[02:04:21] --- oak has joined
[02:04:24] <pigdog> no bashing.
[02:04:29] <pigdog> document status
[02:05:07] --- Yoshifumi Atarashi has joined
[02:06:17] <pigdog> all 4 wg docs (prot, ssh, beep, soap) submitted. ad feedback received.
[02:06:34] <pigdog> simon does not think we need a wg last call.
[02:07:04] <pigdog> advance separately as prot+ssh/beep+soap
[02:07:38] <abierman> are there any document issues other than boilerplate, etc.
[02:07:54] <pigdog> bert: do beep & soap separately
[02:09:08] <pigdog> andy, bert posted the review to the mailing list. he says, a few minor bugs. protocol needs an IANA considerations, and that may require discussion.
[02:09:29] <pigdog> "you may need/want a few registries"
[02:09:43] <pigdog> any other questions?
[02:09:51] <pigdog> Interoperability Testing
[02:10:09] <pigdog> MOME had an interoperability testing event last week, featuring nsis/ipfix/netconf
[02:10:24] <pigdog> 4 netconf implementations present. 2 vendors 2 academic.
[02:10:44] <pigdog> small issues getting ssh to interoperate. used ad-hoc data model.
[02:10:59] <pigdog> simon has asked the organizer to forward a summary.
[02:11:11] <pigdog> only tested ssh because it was only mandatory.
[02:11:33] <pigdog> small problems, but not with spec in simon's opinion
[02:11:56] <pigdog> 2 implementations lacked ssh transport.
[02:12:02] <pigdog> ?
[02:12:30] <pigdog> devised an ad hoc data model for the tests, but vendors didn't implement it in a compatable way.
[02:12:42] <pigdog> output: work on standard data models.
[02:13:26] <pigdog> dan. r.: are there any recommendations for what the data model should include regarding future work?
[02:13:46] <pigdog> simon: having guidelines would be helpful.
[02:14:01] <pigdog> sharon chisolm: it would be interesting to see how they described the ad hoc data model.
[02:14:13] <abierman> Did they test edit-config at all?
[02:14:40] <abierman> Interested in the 'operation' attribute in the data models
[02:14:45] <pigdog> bert: so long as there were no problem with the protocol, then we can advance.
[02:15:05] <pigdog> (xxx not advance, [be pleased with results])
[02:15:38] <pigdog> simon; i'm guessing but i think they did test edito-config
[02:16:14] <pigdog> james hueng: i was a participant. i sent a summary to Intel. I will forward a summary to the mailing list.
[02:16:54] <pigdog> james: there are different types of ssh subsystems, and it wasn't clear in the draft. one team used port forwarding and another used a command subsystem. the common model was a very simple XSD.
[02:17:16] <pigdog> ... when you do the edit-config on the machine, "it" dies.
[02:17:29] <pigdog> ... message separator wasn't used properly.
[02:17:38] <pigdog> some interactive some non interactive
[02:17:52] --- rstory has joined
[02:17:52] <pigdog> pipeline requests... how do you process them? not clear in the document.
[02:18:28] <abierman> netconf doesn't have pipelining -- 1 rpc per message or the implementation is broken
[02:18:36] <pigdog> there was one SOAP implementation. we felt it would have been easier to test. we did NOT really test edit-config.
[02:19:25] <pigdog> bert: james for pipelining, did we have it early on in our docs.
[02:19:58] <pigdog> eliot: is the specification clear that pipelining is not to be done?
[02:20:12] <pigdog> simon: we should check that off line.
[02:21:00] <pigdog> Charter Discussion
[02:21:48] --- prkj has joined
[02:21:52] <pigdog> working group is bound to a charter which is a contract. we have completed our current action items, but we have unmet goals. specifically around locking.
[02:21:56] <pigdog> same with notifications.
[02:22:04] <pigdog> notifications were dropped from the protocol.
[02:22:12] <pigdog> xml usage guidelines that the group should develop.
[02:22:30] <pigdog> very open ended. we should consider scope.
[02:23:01] <pigdog> access control lists?
[02:23:09] <pigdog> s/locking/fine grained locking/
[02:23:53] <pigdog> possible ways to go forward
[02:24:01] <pigdog> declare victory and go home?
[02:24:06] <pigdog> finish notifications?
[02:24:33] --- WEJ has joined
[02:24:45] <pigdog> go dormant until we have enough implementation experience and operating experience and then review.
[02:25:09] <pigdog> if we wish to fulfill charter goals to the letter then go to notifications.
[02:25:29] <pigdog> lastly, decide whether or not to add data modeling. and what would the scope of that work be?
[02:25:41] <pigdog> sharon will now present.
[02:26:27] <pigdog> puts on weirdo microphone that doesn't seem to work
[02:26:39] <pigdog> sharon reports that she will not sing and dance.
[02:26:44] <ietfdbh2> where are slides?
[02:27:16] <abierman> followup on pipelining -- sec. 4.2 is silent, but XSD shows <rpc> element is minOccurs=1, maxOccurs=1 (just FYI)
[02:27:27] <sleinen> http://ops.ietf.org/netconf/63/sharon/
[02:27:52] <sleinen> Or http://ops.ietf.org/netconf/63/sharon.ppt for you MS weenies...
[02:28:19] <pigdog> sharon presents outline of her talk
[02:28:30] <pigdog> netconf development- phase one complete.
[02:29:01] <pigdog> primary focus for protocol is on configuration, especially in a standards development. we indicated we weren't going to preclude other forms of management discussion.
[02:29:09] <pigdog> configuration is hard. monitoring is easy.
[02:29:21] <pigdog> so stay focused on configuration.
[02:29:53] <pigdog> but we should not do anything that precludes either configuratiion or monitoring.
[02:30:02] --- martinb has joined
[02:30:50] <pigdog> people are interested in knowing when a configuration has changed, and they wish to be told this. they also want to do security audit logs, data mirroring.
[02:31:11] <pigdog> there are other scenarios as well.
[02:31:24] <pigdog> next slide contains lots of text.
[02:32:00] --- shigeya has joined
[02:32:03] <pigdog> there is a draft available on "SMI" for netconf... don't want to create unnecessary rules, but want interoperability
[02:32:19] <pigdog> initial set of application level reusable data
[02:32:34] <pigdog> asynchronous messaging/event notification
[02:32:57] <pigdog> access control has been discussed but no mechanism.
[02:33:17] <pigdog> a method for deliverying software loads for netconf
[02:33:26] <pigdog> a method for multi-channel support
[02:33:40] <abierman> not just SW load; syncing SW reload with config reload
[02:33:42] <pigdog> some of this will need to be moved for phase 3. (phase N?)
[02:34:15] <pigdog> netcoonf events
[02:34:23] <pigdog> in phase 1 charter
[02:34:49] <pigdog> framework for netconf data model
[02:35:20] <pigdog> try not to define new CLRs. we should be careful as to what if anything gets taken forward from SNMP SMI
[02:35:32] <pigdog> Proof of concept
[02:35:34] <pigdog> Data types
[02:35:47] <pigdog> netconf reporting (could be made to be configuration)
[02:36:06] <pigdog> next steps
[02:36:19] <pigdog> propose that the netconf event and datamodel work gets added to the netconf charter as phase 2
[02:36:28] <pigdog> other work as there is interest and resources available.
[02:36:34] <pigdog> questionjs
[02:36:40] <pigdog> discussion?
[02:37:23] <pigdog> simon: we must update the charter, and that charter will receive review by AD and IESG, and IETF?
[02:37:46] <pigdog> bert: IETF call for comments happens AFTER IESG agrees that it should move forward.
[02:38:00] <pigdog> simon: what are bert's views?
[02:38:18] <pigdog> bert: normal criteria: need to have interest and all that. but first...
[02:38:42] <abierman> seems like the WG can agree on scope and need for notifications; does the room agree with this view?
[02:39:19] <pigdog> [defer andy's for just a moment]
[02:39:52] <pigdog> bert: do we have enough implementations?
[02:40:11] <pigdog> bert: not many hands.
[02:40:31] <pigdog> bert: i have an issue with not enough people having implementation experience with what we have.
[02:41:16] <pigdog> dan r: i did not raise my hand because my company does not write protocols. we are kind of expecting commercial or public domain products to become available.
[02:42:01] <pigdog> dan r: we have something proprietary that we would like to migrate to netconf. the problem is that when we go to customers, we run into issue absense of a data model.
[02:42:31] <pigdog> bert: thanks for that.
[02:43:46] <pigdog> bert: how many have actually been working with operators to see if they'll use these tools.
[02:44:21] <pigdog> bert: we got here because operators weren't using SNMP. i want to be very prudent that we not miss the operators again.
[02:45:03] <pigdog> bert: asked operators to review the work and play with this stuff and make sure we've done the right thing before we continue to develop this work.
[02:45:30] <pigdog> bert: please get operators to comment
[02:45:46] <pigdog> sharon: we have an implementation we've put in front of operators and they like the direction.
[02:47:03] <pigdog> sharon: everyone needs to support asynchronous messaging. if we don't do asynch messaging, we'll have an interoperability mess as vendors do their own thign
[02:47:25] <pigdog> eliot: please be specific about what you mean about asynch messaging
[02:47:40] <pigdog> sharon: more than just notification
[02:48:25] <pigdog> kathleen moriarty: as a customer, we have auditing standards that we have to meet. in order to get to the point where we would implement netconf, there will have to be an open standard to do rollbacks.
[02:48:46] <pigdog> ... another trend is to automate changes and rollbacks.
[02:49:54] <pigdog> ... Intrusion Prevention Systems. want central management that works with open standards
[02:50:18] <pigdog> simon: also interested in asynch messages for auditing requirements.
[02:51:52] <pigdog> k. moriarty: everything is getting looked at. sarbanes oxley. who made changes. i'm looking for changes that conflict and ability to identify who's changed what to work out conflicts. Federal Information Security Management A?? Google FISMA. required for agencies and contractors in the US government.
[02:52:01] <abierman> detailed audit logs are different than rollback; netconf provides some rollback, but no auditing
[02:52:05] <pigdog> simon: i hear demand for notifications
[02:52:58] <pigdog> simon: snmp traps and syslog is hard to integrate with configuration...
[02:53:09] <pigdog> simon: we're not the only ones having this problem.
[02:53:26] <ietfdbh2> FISMA = Federal Information Security Management Act
[02:53:43] <pigdog> simon: i agree with andy that this group could work on notifications that could work on notifications, but maybe we would dup work
[02:54:03] <pigdog> david martin: we early on decided that web services is too heavy, but web services covers some of this.
[02:54:13] <pigdog> ... we may want to look at that work.
[02:54:35] <abierman> original netconf work intended to use reliable syslog, not invent anything new
[02:54:39] <pigdog> sharon: i was involved in the syslog stuff, and i trolled through the web services stuff. the intent is not to invent unnecessarily.
[02:55:48] <pigdog> azita kia: on the data model, and that there was a lot of work done in SNMP. netconf has been successful so far, but without a data model, it's just a protocol to exchange...
[02:55:57] <pigdog> ... creating a data model is a very big task.
[02:56:16] <pigdog> ... can we do some incremental work, leveraging what was done in the SMI and MIBs?
[02:56:23] <pigdog> ... can we XMLize some of those?
[02:56:45] <pigdog> simon: that would be a way forward. mibs and snmp haven't been very successful for configuration.
[02:57:07] <pigdog> azita: just want to leverage what we have
[02:58:11] <pigdog> dave perkins: on the auditing issue, we have a management application has the identity when you do a transaction. the user who pressed the button is not captured. [proxied discussion]
[02:58:57] <pigdog> jim golvinsky [?] not having a reference data model makes protocol useless. we ended up with square integration points. i'm going to be flamed now. but...
[02:59:00] --- dem107 has joined
[02:59:23] <pigdog> ... there is a lot of work with WS...
[02:59:30] <pigdog> for notification.
[02:59:41] <jschoenwae@jabber.org> Andy, reliable syslog (I assume you mean RFC 3195) was published in Nov. 2001 - how many deployed implementations do we have after 4 years?
[03:00:01] <pigdog> glenn waters: 9:59, lovely city, nice and warm. neener.
[03:00:27] <pigdog> ... only way to build an integrated solution is to include notifications. big hole without them.
[03:01:02] <pigdog> ... for data model: we don't have a language to talk about data modeling. need that as well.
[03:01:08] <pigdog> ... need an SMI for XML
[03:01:16] <pigdog> ... need those rules to be put down in a single document.
[03:02:02] <pigdog> glenn: and we have to develop the language and then push the data model.
[03:02:30] <pigdog> daren lorn: echo andy's comment that an event system that reliable syslog would be very useful.
[03:03:24] <abierman> don't know if rfc3195 is the right choice; just want to avoid reinvention if possible
[03:03:38] --- brabson has left
[03:03:45] <pigdog> bert: in the past we've heard "i'm channeling my customer's requirements." i understand customers can't make it here, but i need to hear from them. i am willing to keep those communications private, but i'd like to hear from them.
[03:03:48] --- rstory has left: Disconnected
[03:04:00] --- shigeya has left: Logged out
[03:04:05] <pigdog> we are concluded.
[03:04:08] --- ray_atarashi has left
[03:04:11] <pigdog> [today's meeting that is]
[03:04:14] <ietfdbh2> Asking customers to come to the IETF is like asking software customers to participate in C++ standard discussions; they don't care about that low-level detail!
[03:04:22] <pigdog> that's not was he was asking.
[03:04:27] <pigdog> he wants an email.
[03:04:28] <abierman> bye, thanks for scribing Eliot
[03:04:35] <pigdog> welcomes. all the best to you guys.
[03:04:41] --- pigdog has left
[03:04:46] --- abierman has left
[03:04:52] --- ietfdbh2 has left
[03:05:21] --- Yoshifumi Atarashi has left
[03:05:42] --- martinb has left
[03:05:49] --- jlcjohn has left
[03:06:14] --- jschoenwae@jabber.org has left: Logged out
[03:06:48] --- dem107 has left: Disconnected
[03:11:40] --- bert has left
[03:15:39] --- oak has left
[03:16:46] --- WEJ has left
[03:20:52] --- prkj has left
[03:22:40] --- sleinen has left: Disconnected
[03:47:54] --- dem107 has joined
[04:43:27] --- dem107 has left
[05:06:52] --- end has joined
[05:08:01] --- end has left