[13:27:11] --- leinen has joined
[13:38:19] --- leinen has left
[13:48:25] --- leinen has joined
[13:49:28] <leinen> Please read the draft!
[13:50:00] <leinen> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-04.txt
[14:19:50] --- leinen has left
[17:18:12] --- leinen has joined
[20:42:07] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[20:42:12] --- swany@damsl.cis.udel.edu has joined
[20:42:22] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Logged out
[20:42:52] --- BertWijnen has joined
[20:42:52] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[20:44:00] --- pigdog has joined
[20:44:10] <pigdog> greetings... i will be your scribe
[20:44:17] <pigdog> netconf docs in auth 48
[20:44:19] --- Yoshifumi Atarashi has joined
[20:44:24] --- dbh2 has joined
[20:44:35] <pigdog> draft-ietf-netconf-notification-04.txt is open
[20:45:05] <pigdog> agenda is that draft, and if we have extra time, then NETCONF over soap
[20:45:36] <pigdog> if you have a question that you would like me to bring to the mike, please preface it with QUESTION:
[20:46:28] <pigdog> issues
[20:46:36] <pigdog> meta-issue: apparently lack of thrust
[20:46:49] <pigdog> 4th meeting, not much review
[20:47:06] <pigdog> suggested approach: reduce to include only essentials
[20:48:10] <pigdog> we would like this to be the last IETF netconf meeting working on this doc
[20:49:13] <pigdog> issue: data model
[20:50:16] <pigdog> on the one hand, we're eating our own dogfood. on the other hand, we're blocking notifications on a non-existant data model
[20:50:53] <pigdog> andy; what do we need from that document?
[20:51:26] <pigdog> sharon: we can get rid of minaccess/access
[20:51:52] <pigdog> we need someway to specify whether this is configuration data or not
[20:52:21] --- rstory has joined
[20:52:42] <pigdog> several ways of selecting notifications
[20:52:54] <pigdog> this is partly a result of merged proposals
[20:53:03] <pigdog> filters - xpath and subtree
[20:53:11] <pigdog> also ad-hoc or by reference to named profile
[20:53:56] <pigdog> not a showstopper, but not pretty
[20:54:49] <pigdog> comments on create subscription?
[20:54:56] --- rjaksa has joined
[20:55:07] <pigdog> {someone from ericcson} it's acceptable
[20:55:45] <pigdog> separate filter for each event stream is good, but today's solution is okay
[20:56:14] <dbh2> Balacz from ericsson, if I have the spelling correct.
[20:56:53] <pigdog> Why do we need streams (Andy)?
[20:58:15] <pigdog> Replay
[20:58:37] <pigdog> Retrieve stored notifications possible
[20:58:49] <pigdog> could possibly be done with a simple <get>?
[20:58:55] <pigdog> you can only replay from a given time to the present
[20:59:22] <pigdog> No combined replay / real-time (tail -f)
[20:59:34] <pigdog> solves the problem with a gap
[21:00:03] <pigdog> default Event Stream
[21:00:20] <pigdog> all servers need to provide a "NETCONF" stream but doesn't specify what it should contain
[21:01:43] <pigdog> now to sharon's issue list
[21:01:46] <pigdog> Sharon:
[21:03:48] --- nov has joined
[21:03:58] <pigdog> -03 version resolved many comments. exceptions at https://ops.ietf.org/lists/netconf/netconf.2006/msg01223.html
[21:04:26] <pigdog> why do we need all of these read only data models?
[21:04:53] <pigdog> we need to manage our own system
[21:05:36] <pigdog> questions?
[21:06:00] <pigdog> balasz: we don't have similar information on netconf basics
[21:06:30] --- weshardaker has joined
[21:06:38] <pigdog> andy: i don't see it as useful
[21:07:23] <pigdog> sharon: what other counters would be interesting?
[21:09:02] <pigdog> bert: would it be more wise to take this out of this document so that we do the monitoring for both the notifications and the base?
[21:09:12] <pigdog> simon; good suggestion
[21:09:26] --- dlpartain has joined
[21:09:29] <pigdog> simon: seems to be a separate activity
[21:09:52] <pigdog> show of hands: should we move the data modeling out?
[21:12:02] <pigdog> sense of the room seems strongly in favor of moving to a separate document
[21:12:46] <pigdog> sharon:
[21:12:49] <pigdog> transport mappings
[21:13:34] <pigdog> nobody's paid attention to the mapping
[21:13:40] <pigdog> we need that time
[21:15:19] <swany@damsl.cis.udel.edu> elliot: we're creating a nightmare if we have to write many documents every time we extend (to another transport)
[21:16:03] <swany@damsl.cis.udel.edu> elliot: let's just fix it in the document
[21:16:33] <swany@damsl.cis.udel.edu> elliot volunteers to take a look at BEEP
[21:17:05] <pigdog> soap could use Ajax Push design...
[21:17:23] <pigdog> would we block this document on extensions to SOAP?
[21:17:53] <pigdog> and the document on SOAP & AJAX hasn't even been started
[21:18:40] <pigdog> sharon: my goal is to get the right eyes on text
[21:18:49] <pigdog> simon: volunteers for soap mapping?
[21:19:00] <pigdog> (no volunteers)
[21:19:24] <pigdog> is anyone doing netconf over soap?
[21:19:28] <pigdog> one person
[21:19:57] <pigdog> hitachi
[21:20:25] <leinen> Iijima Tomoyuki
[21:21:31] <pigdog> do we need to do anything for SSH? yes, because we don't use just <rpc>, but also <notification>s
[21:22:33] <pigdog> the reason we split transport mappings out, so that they could advance separately, and it would be a pity of we put text in this document only to have it obsoleted
[21:22:40] <pigdog> dave harrington
[21:22:56] <pigdog> 1. i have coworkers in china who are sleeping now. please use the mike.
[21:23:22] <pigdog> (it's 9:00am in beijing)
[21:23:33] <pigdog> 2. i would like to see the transport mapping removed from this document
[21:24:42] <pigdog> 3. there are issues with ssh and notifications, as we are having with isms
[21:24:58] <pigdog> eliot: aren't those differences due to security model?
[21:24:58] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Dave, I do not see the issues with the SSH transport since the netconf WG did decided that they only run notifications over a channel established by the notification receiver.
[21:26:20] <pigdog> dave: the issue is with access control models because the authenticated identity has to be tied to an access control model
[21:27:26] <pigdog> dave: we took 10 years to do this.. take a look
[21:28:23] <pigdog> wes hardiger: we're wasting time on isms versus netconf
[21:29:45] <pigdog> andy: we need to remove text that is not a new normative requirement and is not a change, then we don't need to say anything
[21:30:55] <swany@damsl.cis.udel.edu> andy: this (transport) is duplicate information
[21:31:14] <swany@damsl.cis.udel.edu> eliot: there is new material related to notifications
[21:32:28] <swany@damsl.cis.udel.edu> ssh could remain in the base since it is mandatory
[21:33:24] <swany@damsl.cis.udel.edu> eliot: deprecate SOAP and BEEP now -- unreasonable to keep up
[21:34:25] <swany@damsl.cis.udel.edu> since no BEEP and SOAP people are here advocating for them, take them out
[21:34:53] <swany@damsl.cis.udel.edu> consensus is to move the transport mappings out
[21:35:20] <swany@damsl.cis.udel.edu> how many documents?
[21:37:42] <swany@damsl.cis.udel.edu> consensus to move transports out, but not on what to do with them once they are out
[21:38:35] <pigdog> instance validation
[21:39:12] <pigdog> nevermind
[21:39:24] <pigdog> rpc methods
[21:39:28] <pigdog> create-subscription
[21:39:59] <pigdog> need tail -f
[21:40:10] <pigdog> so, need optional stop time
[21:40:50] <pigdog> why stop notifications after replay?
[21:42:25] <pigdog> minAccess / config-notconfig
[21:43:22] <pigdog> rather than coming up with a whole framework, we could just fast track a small portion of the data model
[21:43:52] <pigdog> but this is no longer our problem, because we're removing the monitoring
[21:44:00] <pigdog> but we're just deferring the issue
[21:44:26] <pigdog> relationships in schemas
[21:44:30] <pigdog> no longer a problem, as well
[21:44:42] <pigdog> deferred
[21:44:53] <pigdog> cardinality of streams
[21:45:08] <pigdog> are you supposed to associated more than one stream with a single subscription?
[21:45:14] <pigdog> multiple streams per subscription.
[21:45:25] <pigdog> balasz:
[21:45:52] <pigdog> we don't say anything about how we separate these streams, are they different formats, origins, or whatever.
[21:46:16] <pigdog> if we have multiple netconf sessions for multiple streams, that would be too many
[21:46:46] <pigdog> andy:
[21:47:11] <pigdog> how would one handed magically melded arbitrary streams that have nothing to do with one another?
[21:47:31] <pigdog> sharon: streams are completely unspecified
[21:48:18] <pigdog> andy; different sources and different data models
[21:48:35] <pigdog> {and so we don't really understand the implications of subscribing multiple streams}
[21:48:58] <pigdog> if you have 10 streams do you need 10! descriptions?
[21:49:24] <pigdog> sharon: vendor will provide advice on this
[21:49:41] <pigdog> balasz:
[21:50:12] <pigdog> can live with one stream, but would like all netconf notifications on one session
[21:50:58] <swany@damsl.cis.udel.edu> dave harrington: doesn't believe that the agent should provide multiple streams together
[21:51:49] <swany@damsl.cis.udel.edu> sharon: solution seems to be to open a new session for every new use
[21:52:30] <swany@damsl.cis.udel.edu> DH: it is OK if a vendor wants to provide the ability to concatenate streams, that's good, but it shouldn't be mandated
[21:52:37] <pigdog> Dave: vendors can combine multiple streams, no need to standardize it
[21:53:11] <swany@damsl.cis.udel.edu> sharon: streams are under-specified
[21:53:38] --- swany@damsl.cis.udel.edu has left: Logged out
[21:54:19] --- joao@jabber.isc.org has joined
[21:55:22] <pigdog> Eliot: mix of syslog etc. might be an issue
[21:56:24] <pigdog> bert: start with one stream and figure out whether we could merge them later
[21:57:08] --- swany@damsl.cis.udel.edu has joined
[21:57:33] <pigdog> simon; i think bert has a good point
[21:57:59] <pigdog> device is always free to provide its own combined event stream
[21:59:06] <pigdog> show of hands: who would agree if we restrict ourselves to one event stream per subscription
[21:59:56] <pigdog> Issues - security considerations
[22:00:23] <pigdog> what needs to be there?
[22:00:33] <pigdog> dave harrington:
[22:01:01] <pigdog> {general description of what the security AD will do} so list threats and mitigations
[22:01:07] <pigdog> and here comes wes:
[22:01:36] <pigdog> 1. some people like to do different access control versus configuration / gets
[22:02:11] <pigdog> 2. you can't easily make the statement in the slides, because the identities of who are doing gets versus notifications is different
[22:02:53] <pigdog> wes: the transport issues, and you don't have symmetric identities
[22:03:31] <pigdog> dan:
[22:03:55] <pigdog> this needs to be reviewed by SAAG
[22:04:05] <pigdog> this is usually where our documents stumble
[22:04:30] <pigdog> we may have some issues related to traffic that is being created by notifications
[22:05:36] <pigdog> wes: you can get the doc reviewed by saying that there's no security in the doc ;-)
[22:05:47] <pigdog> misc detailed comments
[22:06:00] <pigdog> Not necessary to allow combining named profiles and filters
[22:06:24] <pigdog> dave harrington:
[22:06:50] <pigdog> what does this mean?
[22:07:13] <pigdog> sharon: don't need to do BOTH filters and profiles
[22:07:18] <pigdog> do one or the other
[22:07:34] <pigdog> but not both
[22:07:38] <pigdog> xsd is changed to a choice
[22:08:16] <pigdog> andy bierman
[22:08:25] <pigdog> if i want to filter on a & b, why not create a filter that does that?
[22:08:41] <swany@damsl.cis.udel.edu> create a profile that does that
[22:08:42] <pigdog> stop notifications
[22:09:35] <pigdog> need a way to do this...
[22:09:55] <pigdog> wants to remove "or some mechanism outside the scope of this spec"
[22:10:33] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Replaced by new connection
[22:10:55] <swany@damsl.cis.udel.edu> eliot: in a BEEP transport mapping you could do this easily (might involve signaling between manager and agent)
[22:11:21] <swany@damsl.cis.udel.edu> and questions whether manager/agent communication should be in the transport description
[22:12:15] <pigdog> dave harrington: this adds ambiguity
[22:12:21] <pigdog> sharon: consensus to remove it...
[22:12:51] <pigdog> capability strings in 3.1 are wrong... just corrected it
[22:12:59] <pigdog> still wrong
[22:14:10] <pigdog> andy: why is replay a capability?
[22:14:35] <pigdog> sharon: being able to query on the stream is useful, but moved outside the scope
[22:15:21] <pigdog> andy: if we can make some sort of descriptive means to say whether the agent supports replay
[22:16:29] <swany@damsl.cis.udel.edu> discussion of whether replay is optional or must be an expressed capability
[22:16:40] <swany@damsl.cis.udel.edu> eliot: is it per-agent or per-stream?
[22:17:28] <swany@damsl.cis.udel.edu> sharon: per-server mostly, but moves around
[22:17:39] <pigdog> eliot: if it is per stream, then it is NOT a capability
[22:19:55] <pigdog> simon: don't need to have this information at all because it can be in documentation
[22:20:10] <pigdog> dave harrington:
[22:20:45] <pigdog> if i implement a mib on my box and i don't implement a single object, do i have to have another object that says that?
[22:20:50] <pigdog> sharon: no
[22:20:55] <pigdog> dave: isn't that what this is?
[22:21:15] <pigdog> balasz:
[22:21:38] <pigdog> would prefer to advertise it when we ask for the streams
[22:22:11] <pigdog> misc comments
[22:22:17] <pigdog> NETCONF stream
[22:22:34] <pigdog> concern that this isn't specified well
[22:22:47] --- dlpartain has left
[22:22:55] <pigdog> this is the default
[22:22:59] <pigdog> dave harrington:
[22:23:03] <pigdog> i have a different memory
[22:23:13] <pigdog> i thought that the netconf stream was events concerning netconf operations
[22:23:24] <pigdog> sharon:
[22:23:30] <pigdog> what would stuff relating to netconf operations be?
[22:23:32] <pigdog> dave:
[22:23:35] <pigdog> i'm not certain
[22:23:46] <pigdog> andy;
[22:23:49] <pigdog> only config change
[22:24:32] <pigdog> the idea to not create a firehose
[22:25:05] <pigdog> andy; we should go that way
[22:26:11] <swany@damsl.cis.udel.edu> discussions of what the agreement was regarding events
[22:26:23] <swany@damsl.cis.udel.edu> memories compared
[22:26:33] <swany@damsl.cis.udel.edu> eliot: recalls "not just config changes"
[22:26:49] <swany@damsl.cis.udel.edu> clearly remembers it being vague
[22:26:51] <swany@damsl.cis.udel.edu> :)
[22:28:13] <pigdog> andy: right now this is a hook to provide standards-based content
[22:28:56] <pigdog> sharon: coupled with a single stream, i'm concerned about whether it's useful
[22:29:27] <pigdog> dave harrington; notes from the interim
[22:29:57] <pigdog> "there will be a special named stream to carry "NETCONF" notifications and another special stream for "SNMP" notifications
[22:30:01] --- joao@jabber.isc.org has left
[22:30:08] --- nm has joined
[22:30:14] <pigdog> simon: i don't think that's clear
[22:30:37] <pigdog> sharon: let's bring this to list?
[22:30:59] <pigdog> andy; let's not couple a stream to a particular stream to a content type in this document
[22:31:23] <pigdog> balasz:
[22:31:35] <pigdog> one reason to have a netconf stream was to have a [single mandatory]
[22:32:35] <pigdog> andy; namespaces in the element will differentiate the content
[22:33:24] <pigdog> andy; I'm starting to think that we don't have to say anything about content type...
[22:34:09] <pigdog> sharon: then we're making stream mandatory
[22:36:06] <pigdog> do we have agreement to remove it all or not?
[22:37:23] <pigdog> dan: as contributer, leave it as is
[22:37:45] <pigdog> as-is means some statement around the default
[22:38:18] <pigdog> simon: who thinks we should keep in the default?
[22:38:45] <pigdog> 7
[22:38:47] <pigdog> 8
[22:38:58] <pigdog> overwhelming consensus to keep
[22:39:06] <pigdog> what should be the content of the default?
[22:39:11] <pigdog> 1. leave it to somewhere else?
[22:39:33] <pigdog> 2. all notifications that can be rendered in netconf?
[22:40:07] <pigdog> 3. netconf protocol related events
[22:41:59] <pigdog> and should it be in the doc?
[22:42:47] <pigdog> answer last question first
[22:44:03] <pigdog> specified in this document
[22:45:20] <pigdog> replayCompleteNotification
[22:45:34] <pigdog> James Balistiere; what happens when you hit the stop time?
[22:45:43] <pigdog> sharon: you send a notification when it is completed
[22:45:54] <pigdog> take it to the list
[22:46:07] <pigdog> and then there are editorial things
[22:46:26] <pigdog> that's the end of the issues list
[22:47:05] <pigdog> andy; we need to document the schema the better
[22:47:51] <pigdog> andy: please describe the schema - SOMEWHERE
[22:48:39] <pigdog> we need to get to the point where the XSD is normative
[22:48:51] <pigdog> Balasz:
[22:49:03] <pigdog> 1. if you have a replay which ends, will you kill the session?
[22:49:28] <pigdog> wes:
[22:50:03] <pigdog> xsd normative?
[22:50:07] <pigdog> sharon: yes
[22:50:30] <pigdog> andy: text is normative for semantics, xsd is normative for syntax
[22:50:39] <pigdog> balasz; 2
[22:51:00] <pigdog> what happens when you receive an <edit-config> in the middle of the notification stream?
[22:51:45] <swany@damsl.cis.udel.edu> eliot: could use a different channel with a different profile
[22:52:04] <swany@damsl.cis.udel.edu> if you get an <edit-config> on a notification channel, that's like getting SNMP over telnet
[22:52:13] <swany@damsl.cis.udel.edu> sharon: we don't have those profiles
[22:52:24] <swany@damsl.cis.udel.edu> eliot: we can easily create them
[22:52:24] <pigdog> take it to the mailing list
[22:52:29] <pigdog> we're adjourned
[22:52:32] --- pigdog has left
[22:52:36] --- nov has left
[22:53:01] --- leinen has left
[22:54:54] --- swany@damsl.cis.udel.edu has left
[22:55:44] --- nm has left
[22:56:33] --- rstory has left: Logged out
[22:56:39] --- dbh2 has left
[22:57:56] --- BertWijnen has left
[23:00:01] --- weshardaker has left: Disconnected.
[23:10:20] --- Yoshifumi Atarashi has left
[23:13:39] --- rjaksa has left