[07:59:23] --- mbj has joined
[08:42:38] --- pascal_Hennequin has joined
[09:05:45] --- pascal_Hennequin has left
[09:21:05] --- pascal_Hennequin has joined
[09:30:19] --- RogerC has joined
[09:42:50] --- ray_atarashi has joined
[09:51:32] --- djfrett has joined
[09:56:52] --- ray_atarashi has left
[09:57:27] --- ray_atarashi has joined
[09:58:38] --- sleinen has joined
[09:58:58] --- djfrett has left: Lost connection
[10:03:32] <sleinen> Shane Kerr will take notes for the minutes
[10:04:55] <sleinen> NETCONF "version 1" ready for approval by the IESG
[10:05:02] --- pascal_Hennequin has left
[10:05:04] --- dbh2 has joined
[10:05:15] <sleinen> remaining open issue: port(s) assignment question
[10:05:40] <sleinen> Do we even need a separate NETCONF port number for NETCONF over SOAP?
[10:06:07] <sleinen> Wes Hardaker: Same reason as for SSH; we want to be able to filter separately in firewalls.
[10:06:51] <sleinen> Andy doesn't know whether this is a real concern. What are the current SOAP practices today wrt port numbers?
[10:07:09] <sleinen> Sharon isn't sure whether Wes' argument applies so much to SOAP
[10:07:29] <sleinen> The important thing to me is to have a separate port for SSH
[10:07:36] --- mikemlb has joined
[10:08:30] <sleinen> Wes: implementations will support configuration of a different port, such as the standard SOAP-over-HTTP port
[10:08:38] --- rstory has joined
[10:09:14] <sleinen> David Black: You can always say that a port is a default in the absence of configuration
[10:09:27] <sleinen> Might be useful to have separate ports in case there are multiple SOAP engines on a box.
[10:10:09] <sleinen> Wes: Should ask operators whether they want to be able to filter NETCONF separately.
[10:10:43] <sleinen> Andy: Start discussion on whether we should ask for a well-known (<1024) port or a >=1024 port.
[10:11:35] <sleinen> Heard arguments "<1024 port doesn't really add security", but none that they could hurt.
[10:13:17] <sleinen> Margaret: problem was raised that <1024 requires agent to run with higher privileges (for a short time at least)
[10:14:00] --- LOGGING STARTED
[10:14:48] --- rjc has joined
[10:15:52] --- djfrett has joined
[10:15:55] --- simon.leinen has joined
[10:16:22] <simon.leinen> Sense of the room: Ask for well-known port(s)
[10:17:16] --- sleinen has joined
[10:17:20] --- sleinen has left
[10:18:12] <simon.leinen> Any comments to asking IANA for this new registry?
[10:18:26] <simon.leinen> Dan Romascanu: Does this change the documents in the approval stage?
[10:18:33] <simon.leinen> Andy: No, this is separate.
[10:19:32] <simon.leinen> Sharon: How does this compare to people using their own private namespaces for experimentation?
[10:19:52] --- djfrett has left: Lost connection
[10:20:04] <simon.leinen> Andy: This provides a centrally managed namespace for experimental extensions, with the assumption that people want others to implement them.
[10:20:55] <simon.leinen> Sharon: Expects extensions to go from private namespace to experimental to IETF - have to support three versions
[10:21:34] --- yushun has joined
[10:22:18] <simon.leinen> Andy: I'll try to keep half-baked/unimplemented extensions out of the WG.
[10:22:39] <simon.leinen> Sharon: Benefit of this namespace is to allow shared experimentation?
[10:23:15] --- bert has joined
[10:23:16] <simon.leinen> Ralph Webber: IMS(?) work looking at layering above RPC layer. An experimental namespace might be a good place for them to start.
[10:23:40] --- JackBurbank has joined
[10:24:12] <simon.leinen> Andy: Other WGs could also define namespaces under the NETCONF base - standards action is required, but not necessarily in this WG here.
[10:24:38] <simon.leinen> Andy feels lukewarm support for this request. Sharon seems to find private namespaces sufficient.
[10:24:59] <simon.leinen> But this would be a way to lower the bar for getting stuff into this WG.
[10:25:06] <simon.leinen> Would show that you're not the only one interested in this.
[10:25:38] <simon.leinen> Andy might just ask for this registry personally.
[10:25:51] <simon.leinen> Bert: There's a template for this; might require expert review.
[10:26:16] <simon.leinen> Andy isn't sure whether we have enough interoperable implementations to see where the problems are.
[10:26:59] <simon.leinen> Sharon: Thinks this is a very good idea. We are trying to see some (minor) ambiguities in the specs.
[10:27:49] --- dbh2 has joined
[10:29:02] <simon.leinen> Dave Harrington: If we have this implementation guide, what happens if it broke the standard?
[10:29:22] --- JackBurbank has left: Lost connection
[10:29:30] <simon.leinen> DaveH: What if the WG decides there's a conflict between the protocol spec and the implementation guide?
[10:29:47] <simon.leinen> Andy: Sometimes you will have to change the protocol spec over time.
[10:30:12] <simon.leinen> DaveH: Sharon just talked about ambiguities that might require such modifications
[10:30:32] <simon.leinen> Eliot: Confused... if the implementation guide supposed to contain normative text?
[10:30:55] --- dbh2 has left: Replaced by new connection
[10:31:03] <simon.leinen> Andy: No.
[10:31:39] <simon.leinen> DaveH: Interesting question what "normative" means if you have a normative text that is ambiguous, and an informational (impl guide) that clarifies what to do...
[10:32:23] <simon.leinen> Eliot: Let's do this guide, but if we find we have to modify normative text, let's rev the standard documents.
[10:32:28] <simon.leinen> DaveH concurs
[10:33:00] <simon.leinen> Wes: If we cannot agree about a way to pass around error responses in an interoperable way, then this sounds like an issue for the normative text.
[10:33:23] --- dennis_f has joined
[10:33:35] <simon.leinen> Show of hands shows that very few (~5) have read and are familiar with this draft.
[10:33:54] <simon.leinen> Andy had a conversation with Phil Shafer (who couldn't be here) on how to get people interested in this.
[10:34:00] --- dennis_f has left: Lost connection
[10:34:01] --- dennis_f has joined
[10:35:50] <simon.leinen> Discussion about mixing notifications with configuration conversations on the same channel (as some CLIs do)
[10:36:24] --- bert has left
[10:36:26] <simon.leinen> Eliot: Important that the *direction* of the connection is suitable for the type of device being managed
[10:36:55] <simon.leinen> In BEEP it would be natural to use separate channels because BEEP can multiplex those.
[10:37:04] <simon.leinen> Should take advantage of this.
[10:38:07] <simon.leinen> Sharon: ... Should think about future extensions such as "notifcation replay", which could happen on the same channel.
[10:38:56] <simon.leinen> Sharon: We tried the "never-ending RPC reply" approach and discarded it for engineering reasons (see mailing list)
[10:39:20] --- bert has joined
[10:39:37] <simon.leinen> Andy: There are clear disadvantages to "head-of-line blocking", where long RPCs (such as asking for the entire configuration of a large device) hold up notifications for an extended period of time.
[10:41:40] <simon.leinen> Andy: Is the reason for notifications being on the same channel that they are correlated to the configuration actions?
[10:41:48] <simon.leinen> Sharon: No, I didn't say that.
[10:43:05] <simon.leinen> Dave Perkins: If you have a separate channel for notifications and configuration, there will be spurious configuration changes just for the activation/deactivation of events.
[10:43:33] <simon.leinen> Andy argues that this is independent on whether there are one or two channels.
[10:43:57] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[10:44:32] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Logged out
[10:45:41] <simon.leinen> [By the way, current slides are on: http://www3.ietf.org/proceedings/06mar/slides/netconf-0.ppt]
[10:45:47] <simon.leinen> [current slide: #10]
[10:46:02] --- dennis_f has left: Lost connection
[10:47:11] <simon.leinen> More discussion about advantages and drawbacks of separate channels or not between Andy and Sharon
[10:47:59] <simon.leinen> Sharon gives an example.
[10:48:27] --- Yoshifumi Atarashi has joined
[10:48:47] <simon.leinen> Establish connection to device; look at events from past five minutes and get current events (asynchronously)
[10:48:57] <simon.leinen> Having these on a single connection makes things easier.
[10:50:35] <simon.leinen> Andy: Head-of-line blocking is bad, no convincing arguments for single channel
[10:50:35] --- ray_atarashi has joined
[10:51:04] <simon.leinen> Sharon: You can always use a separate connection if you're worried about blocking
[10:51:47] <simon.leinen> Rob Enns: Only benefit is you're burning one less socket endpoint on your manager
[10:52:29] --- sivaram has joined
[10:52:47] <simon.leinen> Andy: Won't good applications use a separate connection anyway?
[10:52:54] --- joshlitt has joined
[10:53:05] <simon.leinen> Rob: Yes, unless we add something like application-level chunking to the protocol.
[10:53:08] --- bert has left: Replaced by new connection
[10:53:22] --- bert has joined
[10:53:59] <simon.leinen> Sharon: To get out of this deadlock, we should maybe write up PlanA/PlanB pros and cons.
[10:54:50] --- dennis_f has joined
[10:55:56] --- Eliot has joined
[10:55:58] <simon.leinen> DaveH: We should look at how notifications might be used to help us decide this.
[10:56:19] --- rs-jabber has joined
[10:56:53] <simon.leinen> ??? on head of line blocking: Why does having notifications on a separate connection prevent head-of-line blocking? Router priorities?
[10:59:11] <simon.leinen> Andy: Different timescales - blocking due to long RPCs can be on the order of minutes, while other kinds of blocking will only amount to (milli)seconds.
[10:59:49] <simon.leinen> Andy: Next question: Layering of notifications [bottom of slide 10]
[11:00:38] <simon.leinen> Sharon: Three options: (1) remove RPC layer for notifications, (2) do as it is done in the draft ("one-way RPC"), (3) keep the layer but call it differently, "one-way message" or so
[11:01:07] --- joshlitt has left: Logged out
[11:01:22] <simon.leinen> Andy opines we should look at what has to go into the packet to derive the layering model.
[11:02:40] <simon.leinen> Sharon: Main justifications for the additional layer: Can use the same layering; get message-ID etc.; you can more easily replace with RPC headers if required - see discussion on mailing list
[11:02:46] <simon.leinen> [slide #11]
[11:04:19] <simon.leinen> Subscription vs. endless RPC reply
[11:04:40] --- dennis_f has left: Lost connection
[11:04:41] <simon.leinen> Is modify-subscription really needed?
[11:05:23] <simon.leinen> Andy: Could start up a new connection with new subscription, before tearing down the old one.
[11:05:25] --- dbh2 has joined
[11:05:47] --- mikemlb has joined
[11:05:53] --- dennis_f has joined
[11:05:53] --- dennis_f has left: Lost connection
[11:06:10] <simon.leinen> Sharon: Concerns about the NMS (manager) side. Managing 20'000 devices, these additional connections may be too costly.
[11:06:23] <simon.leinen> Notification Configurability [slide 12]
[11:07:08] --- dennis_f has joined
[11:07:11] <simon.leinen> Three ways to filter notifications: (1) set of event classes, (2) subtree/XPath content filter, (3) named profiles
[11:07:20] <simon.leinen> Andy: Do we really need all these?
[11:08:29] <simon.leinen> Multiple subscriptions on the same connection.
[11:08:33] <simon.leinen> Andy: What are these useful for?
[11:09:22] <simon.leinen> Sharon: Very little additional cost. Useful e.g. for short-lived subscription to additional events.
[11:10:27] <simon.leinen> Andy: We definitely need more people to look at this.
[11:10:48] --- quinn has joined
[11:11:31] <simon.leinen> Wes: At some point we have to say something about filtering vs. access control too. So far everyone can see all notifications.
[11:12:30] <simon.leinen> Eliot reminds that NETCONF is based on one connection -> one set of credentials
[11:12:42] <simon.leinen> Notification Message [slide 13]
[11:14:37] <simon.leinen> Andy: Why would I classify an event with multiple classes? Isn't that broken?
[11:15:30] <simon.leinen> Sharon: Different ways of combining aspects
[11:17:56] --- Eliot has left
[11:18:53] <simon.leinen> Andy suggests to use a list of strings instead... RelaxNG has this, Sharon would like to see something "more" standard :-)
[11:19:02] <simon.leinen> Event Classes [slide #14]
[11:19:23] --- bert has left: Replaced by new connection
[11:19:25] --- bert has joined
[11:20:17] <simon.leinen> Andy: "metrics" seems way out of scope - that's what IPFIX is for.
[11:20:28] <simon.leinen> "Asynchronous performance metrics are not in our charter."
[11:21:10] <simon.leinen> Sharon: Two options: Either have a list of things that NETCONF implementations (as opposed to NETCONF RFCs) will be doing, or have an extension mechanism.
[11:21:21] <simon.leinen> Or put in a bit disclaimer that this is out of scope for NETCONF.
[11:22:43] <simon.leinen> Andy: Why do we need a heartbeat? Shouldn't TCP do that for us? [keepalives] Sharon: This is on a higher level (application)
[11:23:04] --- dennis_f has left: Lost connection
[11:23:22] <simon.leinen> Rob Enns: This is a data model discussion. Why do you feel we should be doing a data model for notifications here? Can we do this better than other bodies?
[11:24:19] <simon.leinen> Sharon: Intention was to separate data model from protocol. But we found that this small amount of bleeding (event classes) between data model and protocol would justify the cost.
[11:25:19] <simon.leinen> Other Notification Issues [slide #15]
[11:25:39] <simon.leinen> Transport specific details have to be fleshed out.
[11:25:47] <simon.leinen> Security considerations as well.
[11:26:15] <simon.leinen> Normative model for monitoring subscriptions etc. doesn't follow draft modeling rules.
[11:26:48] <simon.leinen> Should this even be in this document?
[11:27:04] <simon.leinen> Sharon: Heard from people that missing data model for monitoring NETCONF itself is a gap.
[11:27:35] --- rvdp has joined
[11:28:59] --- venaas has joined
[11:29:08] <simon.leinen> DaveH: Not trying to push SNMP... but you could use that existing data modeling language to define monitoring information, until NETCONF has bootstrapped itself to the point where we can really define data models in it.
[11:29:32] <simon.leinen> Sharon: Some of these implementations don't necessarily implement SNMP.
[11:30:33] <simon.leinen> DaveH: Maybe instrumentation requirements for NETCONF could be put into the implementation guide.
[11:33:19] <simon.leinen> Andy: Relation to SYSLOG (Appendix C) might be moved to the normative part.
[11:34:33] <simon.leinen> Andy: Need more people to look at this...
[11:34:47] <simon.leinen> Sharon: Offers to hold an informal meeting later this week.
[11:35:06] <simon.leinen> Andy: Asks for other issues - data model, access control etc.
[11:35:46] <simon.leinen> Sharon has de-prioritized data model work in favor of notifications, so there haven't been any updates lately. Encourages discussion on mailing list or at this meeting. Input on access control would be most welcome!
[11:36:51] <simon.leinen> Dan Romascanu: Concerning both data models and access control: If you have been experimenting with this [Andy did access control], it would be very useful to share this on the list.
[11:37:05] <simon.leinen> Andy wants to finish his code first...
[11:37:48] <simon.leinen> Andy finds that applying access control is impossible to do in one pass
[11:38:05] <simon.leinen> because of the way partial documents are used in edit-config
[11:38:22] <simon.leinen> and the requirement of finding multiple errors
[11:38:29] --- dbh2 has left: Replaced by new connection
[11:38:29] --- dbh2 has joined
[11:38:29] --- dbh2 has left
[11:38:56] <simon.leinen> Andy about access control - initially started with fine-grained access control model from SNMP
[11:39:43] <simon.leinen> container concept can be used for both resume-after-error and access control... trying to find out whether that level of granularity is sufficient
[11:40:11] --- Suz has joined
[11:40:13] <simon.leinen> Sharon: There is some discussion on access control in the (individually submitted) netconf-model draft
[11:42:46] <simon.leinen> No other questions, we're done.
[11:42:53] <simon.leinen> Read the notifications draft! It's not that long.
[11:42:57] --- rjc has left
[11:43:09] --- sivaram has left
[11:45:24] --- simon.leinen has left
[11:45:26] --- rvdp has left
[11:45:27] --- bert has left: Replaced by new connection
[11:45:28] --- bert has joined
[11:46:00] --- Suz has left
[11:46:24] --- venaas has left: Logged out
[11:51:07] --- rs-jabber has left
[11:52:14] --- Yoshifumi Atarashi has left
[11:52:32] --- ray_atarashi has left
[12:18:29] --- mikemlb has left: Logged out
[12:22:28] --- bert has left
[12:27:20] --- dennis_f has joined
[12:27:20] --- dennis_f has left: Lost connection
[12:32:53] --- dennis_f has joined
[12:33:36] --- dennis_f has left
[12:33:53] --- yushun has left
[12:59:30] --- LOGGING STARTED
[13:03:30] --- LOGGING STARTED
[13:42:33] --- quinn has joined
[14:03:17] --- sleinen has joined
[14:03:24] --- sleinen has left
[14:27:17] --- rstory has joined
[14:27:47] --- rstory has left
[16:35:50] --- quinn has left
[17:47:30] --- brabson has joined
[17:47:39] --- brabson has left