[01:56:21] --- RoyArends has joined
[01:56:58] --- RoyArends has left
[01:59:05] --- RoyArends has joined
[01:59:05] --- RoyArends has left
[17:15:14] --- sleinen has joined
[17:17:40] --- rpayne has joined
[17:19:51] --- SharonChisholm has joined
[17:23:57] --- pigdog has joined
[17:24:07] <pigdog> andy bierman speaking
[17:24:23] <pigdog> does anyone want jabber minutes?
[17:25:38] <SharonChisholm> I can jabber log, but not for the portions that I'm speaking
[17:26:41] <SharonChisholm> Wes is going to go first (agenda bash change)
[17:26:55] --- pigdog has left
[17:27:00] <SharonChisholm> Netconf Protocol: Security Considerations
[17:27:10] <SharonChisholm> Authentication and Access Control
[17:27:10] --- Eliot Lear has joined
[17:27:36] <SharonChisholm> There is inherent access control now, people may not realize this
[17:27:47] <SharonChisholm> "The authentication process ..."
[17:28:17] <SharonChisholm> This implies that all netconf operations/data must be mapable to existing acccess control specifications
[17:28:33] <SharonChisholm> must be checked against both
[17:29:00] <SharonChisholm> (the standardized model to come as well as the existing stuff)
[17:29:14] <SharonChisholm> existing access control systems aren't network based
[17:29:51] <SharonChisholm> recommendation: let's drop this requirement
[17:30:27] <SharonChisholm> replace with "Netconf MUST NOT be implemented without a suitable access control <something>"
[17:31:03] <SharonChisholm> elliot - i would like to comment, but ...
[17:31:08] <SharonChisholm> wes - wait until end ..
[17:31:49] <SharonChisholm> andy - like the first part to remove the text, but "MUST NOT " ... what does a suitable <thing> mean?
[17:31:54] --- Tove has joined
[17:32:31] <SharonChisholm> eliot - this is a misinterpreation of the text or our text is unclear. The intentions was that it should be possible for the CLI and netconf ... it should be possible for them to be consistent
[17:32:38] <SharonChisholm> wes - what it says is very different
[17:32:51] <SharonChisholm> wes - how do you make the consistent without for them to be the same
[17:33:03] <SharonChisholm> eliot - it should be possible for them to be the same than they must be the same
[17:33:09] <SharonChisholm> New issue
[17:33:19] <SharonChisholm> Netconf Protocol Chaining
[17:33:28] --- sakai has joined
[17:33:32] <SharonChisholm> Some operations work on remote datasets
[17:33:45] <SharonChisholm> copy-config and URL based : ftp, http
[17:33:52] <SharonChisholm> recommendation - <missed>
[17:33:59] <SharonChisholm> netconf locking: DOS
[17:34:10] <SharonChisholm> global locks means global lock-outs
[17:34:25] <SharonChisholm> this is a known issue
[17:34:38] <SharonChisholm> point is that locks add insecurity if granted to peons
[17:34:49] <SharonChisholm> netconf operations: micro versus global
[17:34:56] <SharonChisholm> netconf assumptions
[17:35:04] <SharonChisholm> conf stores are always shared
[17:35:16] <SharonChisholm> IE, there is not one candidate per user
[17:35:50] <SharonChisholm> Andy - some text in the candidate section ... if candidate config is not global, there would be a capavbility extension
[17:36:04] <SharonChisholm> wes - designed to be a group oriented protocol ... ok, but ramification
[17:36:19] <SharonChisholm> graphical picutre in prety colours
[17:36:49] <SharonChisholm> consider policy: user p1 can only edit var1, can't edit var2; user p2 can edit var2
[17:37:10] <SharonChisholm> <example continues>
[17:37:28] <SharonChisholm> global operations add complexity to the ACM
[17:37:54] <SharonChisholm> andy - that would be coupled to the user's ability to retreive the config
[17:38:13] <SharonChisholm> randy - desc between what they can see with get config compared to what is there
[17:38:40] <SharonChisholm> wes - want them to be able to validate, but errors should not disclose info that user doesn't have permision to see
[17:39:11] <SharonChisholm> wes - policy control plays into this <missed some stuff>
[17:39:45] <SharonChisholm> The example is showing users being able to do things that they shouldn't really have permission to do
[17:39:47] <sleinen> Slides are now up on the Web: http://www.ops.ietf.org/netconf/60/
[17:39:59] <SharonChisholm> we are in a position where we can't do role-based management
[17:40:24] <SharonChisholm> recommendation: "Netconf 1.0o MUST NOT be used in restricted-role environments" or Fix the problems
[17:40:47] <SharonChisholm> andy - serial access is not a DOS
[17:40:57] <SharonChisholm> wes - if they can lock ... they can attack
[17:41:08] <SharonChisholm> wes - need to recognize and document the problem
[17:41:31] <SharonChisholm> wes - i think in the future we will do partial locking and other things which will fix the problem.
[17:41:49] <SharonChisholm> wes - we have deferred this is fine. But we need to make sure people understand
[17:42:15] <SharonChisholm> eliot - i think there is another possibility here . why can't p1 discard changes? Is this the candidate config
[17:42:55] <SharonChisholm> wes - discard changes applies to candidate. if the root user and does not get a lock, and peon one says roll back it will undue changes that it doesn't ... and the root user does not role back
[17:43:23] <SharonChisholm> andy - why would the root user not lock? We already said if you don't lock, you do it at your paril(sp)
[17:43:30] <SharonChisholm> eliot - agree with wes.
[17:43:36] --- jis has joined
[17:43:58] <SharonChisholm> eliot - another approach to dealing with discard changes is ... use locking
[17:44:15] <SharonChisholm> wes - trying to sayl that if you don't use locking, peons can mess you up
[17:44:36] --- aen has joined
[17:44:51] <SharonChisholm> wes - final issue - it is not clear what happens to global operations if you can only get the lock on one data thing (source or target).
[17:44:59] <SharonChisholm> wes - the security considerations can capture this
[17:45:04] <SharonChisholm> Sharon presenting ...
[17:45:14] <Eliot Lear> eliot jabbering
[17:45:53] <Eliot Lear> sharon is presenting a netmod BoF report
[17:46:07] --- dinakar has joined
[17:46:17] --- ray_atarashi has joined
[17:46:38] <Eliot Lear> sharon: brief outline of talk
[17:46:49] <Eliot Lear> "coordinates" - web page is
[17:46:58] <Eliot Lear> http://standards.nortelnetworks.com/netconf
[17:47:10] <Eliot Lear> mailing list is netconfmodel@lyris.nortelnetworks.com
[17:47:17] <Eliot Lear> to subscribe, lyris@lists.nortelnetworks.com
[17:47:31] <Eliot Lear> layering discussion
[17:47:52] <Eliot Lear> do upper layer stuff to provide further interoperability
[17:48:07] <Eliot Lear> data models are explicitly out of scope in this group (NETCONF)
[17:48:10] <Eliot Lear> thus the NETMOD bof
[17:48:19] <Eliot Lear> (problem statement)
[17:48:30] <Eliot Lear> what are common ways of specifying compliance?
[17:48:36] <Eliot Lear> backwards compatability
[17:48:46] <Eliot Lear> how do we deal with access control?
[17:48:50] <Eliot Lear> how do we describe relationships?
[17:49:12] <Eliot Lear> "some people feel these models are critical to the success of netconf"
[17:49:18] <Eliot Lear> (building blocks)
[17:49:28] <Eliot Lear> looking at W3C XML schema..
[17:49:33] <Eliot Lear> two initial drafts
[17:49:36] <Eliot Lear> one is SMI for NETCONF
[17:50:00] <Eliot Lear> some sort of meta model or abstract data model will drive
[17:50:32] <Eliot Lear> andy bierman: picture needs an arrow from standard data models to proprietary data models
[17:50:35] <Eliot Lear> sharon agrees
[17:51:05] <Eliot Lear> (BoF Summary)
[17:51:11] <Eliot Lear> four presentations and lots of discussion
[17:51:32] <Eliot Lear> presentations will be in proceedings
[17:51:39] <Eliot Lear> lots of discussion and interest
[17:51:49] <Eliot Lear> strong interest in leveraging existing technologies
[17:52:03] <Eliot Lear> thus some evaluation needs to be done
[17:52:13] <Eliot Lear> sharon: charter needs fine tuning
[17:52:20] <Eliot Lear> volunteers needed to work on the effort
[17:52:42] <Eliot Lear> *PLEASE* offer your services to Sharon Chisolm
[17:53:17] <Eliot Lear> andy bierman: we need subject matter experts to do some of this work
[17:53:44] <Eliot Lear> sharon's email address is schishol AT SIGN nortelnetworks DOT com
[17:53:51] <Eliot Lear> (replace caps with appropriate stuff)
[17:54:15] <Eliot Lear> (potential impact on netconf protocol)
[17:54:24] <Eliot Lear> Removal of Section 7 of the protocol draft?
[17:54:25] --- suz-isc has joined
[17:54:36] --- suz-isc has left
[17:54:51] <Eliot Lear> move the restrictions into another place, particularly syntactic
[17:55:08] <Eliot Lear> naming and identification may have impact, but sharon doesn't know what
[17:55:11] <Eliot Lear> (yet)
[17:55:13] <Eliot Lear> Randy:
[17:55:38] <Eliot Lear> one of its proposals used XPATH extensively. maybe worth noting
[17:55:41] <Eliot Lear> Sharon:
[17:56:24] <Eliot Lear> move netconf-state data model to a different document?
[17:56:33] <Eliot Lear> Andy Bierman: chicken and egg problem
[17:56:40] --- becarpenter has joined
[17:56:46] <Eliot Lear> to put this stuff in the protocol draft would be presumptuous
[17:56:58] <Eliot Lear> but would otherwise delay the protocol
[17:57:05] <Eliot Lear> Randy:
[17:57:21] --- keitaro has joined
[17:57:29] <Eliot Lear> "I would suggest that the names CANDIDATE-CONFIG and RUNNING-CONFIG
[17:57:37] <Eliot Lear> ... be simply names, and not built-ins
[17:57:39] <Eliot Lear> "
[17:58:11] <Eliot Lear> Andy: take it to the list, but we did go through this once, and the result was based on ease of validation by having them be elements
[17:58:26] --- sakai has left: Replaced by new connection
[17:58:26] <Eliot Lear> Sharon: let's not gate the protocol on the data model...
[17:58:47] <Eliot Lear> Sharon: and that's pretty much it. Questions?
[17:59:26] <Eliot Lear> Andy Bierman: open issues
[17:59:39] <Eliot Lear> Retrieval filtering
[17:59:59] <Eliot Lear> we need a mandatory to implement mechanism
[18:00:06] <Eliot Lear> either subtree filtering
[18:00:13] <Eliot Lear> it's undocumented other than in an email
[18:00:27] <Eliot Lear> and then there's an XPATH subset that juergen did a week after
[18:00:46] --- dem107 has joined
[18:00:48] <Eliot Lear> pros for subtree is that it's fully specified and not hard to do
[18:00:57] <Eliot Lear> downside: it's netconf specific filtering mechanism
[18:01:07] <Eliot Lear> xpath subset: it's a subset of something well implemented
[18:01:22] <Eliot Lear> if you buy into the assumption that everyone will need to know XPATH anyway, then this saves time
[18:01:34] <Eliot Lear> downside is that it's also NETCONF specific because it's a subset
[18:01:57] <Eliot Lear> tools might not limit themselves to our arbitrary subset of the standard
[18:02:41] <Eliot Lear> Wes: might not vendors augment this stuff anyway?
[18:03:02] --- nov has joined
[18:03:11] <Eliot Lear> andy: we are trying to get people to do full xpath, what's to stop them from deciding on their own what the subset is going to be?
[18:03:36] <Eliot Lear> andy doesn't really like either solution, but on small or medium sized devices, this will be an issue.
[18:04:14] <Eliot Lear> Andy; we've otherwise done a good job of keeping the protocol usable for small platforms
[18:04:35] <Eliot Lear> Andy: just to be able to specify the name space is a form of filtering
[18:04:58] <Eliot Lear> wes: if the data model goes forward and produces something, whatever it is it would be nice if all of those align
[18:05:10] <Eliot Lear> decision points
[18:05:21] <Eliot Lear> - full sport for XPATH
[18:05:29] <Eliot Lear> indicated by the #xpath capability
[18:05:42] <Eliot Lear> choose mandatory-to-implement filter
[18:05:53] <Eliot Lear> show of hands
[18:06:25] <Eliot Lear> about 1/3 - 1/2 the room says YES; nobody says NO
[18:07:31] <Eliot Lear> simon leinen: this pushes us too far down the "separate engine" world as we have in SNMP - assumes XML-based configuration
[18:07:44] <Eliot Lear> simon: what do the junoscript people think?
[18:07:59] <Eliot Lear> do you find it feasible to implement it in an efficient way?
[18:08:49] <Eliot Lear> rob enns: from the juniper perspective, there is an internal form of the configuration that gets accessed by the parser.
[18:09:14] <Eliot Lear> so we don't have a standard XPATH implementation, so we use a parser that is integrated with the CLI's parser. this keeps the XML close to the CLI
[18:09:40] <Eliot Lear> it's only on the last stage that there's a difference.
[18:11:06] <Eliot Lear> randy: help me understand: as the netconf protocol is currently defined, if someone does a get-config it needs to generate an XML representation of the entire config. so it's not clear to me why if it's capable of generating and accepting an XML representation, why the internal representation matters
[18:12:10] <Eliot Lear> Phil Schafer: we favor substree filtering, and we haven't had a request to do XPATH. subtree filtering is simple and efficient
[18:12:27] <Eliot Lear> Sharon: XPATH has a lot more potential for solving other problems and use of third party software.
[18:12:57] <Eliot Lear> Sharon: I'm concerned that we'll end up with a one-off solution that has growing complexity
[18:13:38] <Eliot Lear> Andy: We use this XML representation for edit config. to use a completely different representation for get-config filtering imposes a requirement that the operator understand how to map between them. this raises the bar. Why do that?
[18:14:25] <Eliot Lear> Andy: the issue that concerns me (again) is the resources on small and medium devices. someone told me that it's not unusual to need 10x the memory of an expression to process a request
[18:14:38] <Eliot Lear> Andy; i don't want to mandate it everywhere because it is cost prohibitive.
[18:15:07] <Eliot Lear> Andy: but we should evolve to it, and so that's why we have the capability because over time the memory constraints won't be a factor
[18:15:26] --- becarpenter has left: Replaced by new connection
[18:15:27] --- becarpenter has joined
[18:15:27] --- becarpenter has left
[18:15:36] <Eliot Lear> (???) can we handle this on the client side?
[18:16:13] <Eliot Lear> Andy: any more discussion?
[18:16:39] <Eliot Lear> Randy: it sounds like to me the choice is primarily figuring out for these low capability boxes whether they are so limited in their capabilities that none would be realistic
[18:17:08] <Eliot Lear> Andy: none should really have an asterisk to indicate that you have namespace based filtering
[18:17:46] <Eliot Lear> Randy: we have a quantum leap between none and XPATH. Do we have that sort of quantum leap in devices capabilities?
[18:18:48] <Eliot Lear> Simon: I would miss this sort of capability. i would not be very happy if my choice was only full configurations and XPATH processing
[18:19:01] <Eliot Lear> Simon: i'm pretty sure subtree filtering would be useful
[18:19:20] <Eliot Lear> Simon: the benefit of having XPATH for tools is not as important
[18:19:53] <Eliot Lear> rob enns: agree with simon. NETCONF has the ability to deal with partial configs, but if we can't do that for retrieval, it's a loss.
[18:20:07] <Eliot Lear> Andy: agrees. was in operator requirements
[18:20:51] <Eliot Lear> vote on mandatory to implement - 10 - 20
[18:21:19] <Eliot Lear> sorry- none - 0 subtree 18 - 20 and XPATH subset 4
[18:21:41] <Eliot Lear> we'll be prepared to look at the netmod working group produces
[18:22:15] <Eliot Lear> Rollback
[18:22:28] <Eliot Lear> WG agreed to address rollback and retrieval filtering at IETF 59
[18:22:38] <Eliot Lear> sharon takes over
[18:22:54] <SharonChisholm> Need to undo efits or commits to the <running> configuration ...
[18:23:04] <SharonChisholm> Rollback Definition
[18:23:19] <SharonChisholm> per session ring buffer
[18:23:39] <SharonChisholm> restores entire configuration to previous state; not a per-session restore operation
[18:23:52] <SharonChisholm> #rollback capability
[18:24:03] <SharonChisholm> randy - would that include pieces of information that this user does not have access to
[18:24:30] <SharonChisholm> andy - it is an internal snapshop - if there are changes in the database ... yes ... I see where you are going ... don't want to go into security discussion right now.
[18:25:11] <SharonChisholm> wes - my only question is .. if it stated 6 times in the document that using locking is good., not using is bad. Why is locking not explicit>
[18:25:16] <SharonChisholm> andy - tried that
[18:25:17] --- becarpenter has joined
[18:25:55] <SharonChisholm> eliot - one problem is after we get through the data model discussion, the next topic is granular locking. we will need some transition. we might not want to make locking mandatory now and address in next round
[18:26:06] <SharonChisholm> wes - <suggestion on partial locking>?
[18:26:14] <SharonChisholm> eliot - i could live with that
[18:26:25] <SharonChisholm> #rollback capability
[18:26:44] <SharonChisholm> indicates the <checkpoint> <discard-checkpoint> and <rollback> operations are supported
[18:27:07] <SharonChisholm> <checkpoint> - whatever steps are taken to get back to this state (not counters ... configuration)
[18:27:29] <SharonChisholm> if buffer is full, the oldest restore opeation is deleted
[18:27:45] <SharonChisholm> <rollback> this restores the running configuration
[18:28:10] <SharonChisholm> phil - confused ... per session ring buffer but it is global restoration ... never know when what you save gets dicscarded
[18:29:00] <SharonChisholm> andy - not what I mean ... if you use locking ... if you checkpoint the data ... you will get back to where you check pointed ... if you don't use locking ... user A ... user B ... user B wants the changes to stick. user A rollback ... you nuke his changes
[18:29:11] <SharonChisholm> andy - that is without locking ...
[18:29:28] <SharonChisholm> phil - you said it was per session, but you can affect other people's changes
[18:29:59] <SharonChisholm> andy - if you create a checkpoint ... only my session can restore with my checkpoint operation ... not one ring buffer that everyone can use
[18:30:19] <SharonChisholm> andy - if I start up my session ... checkpoint ... checkpoint .. checkpoint ... I'm the only one who can use these
[18:30:49] <SharonChisholm> wes - from security good. from a usage perspective ... what happens when you make changes that prevent you from accessing that session. then you can't access those checkpoints
[18:30:55] <SharonChisholm> andy - yeah, I see ...
[18:31:35] <SharonChisholm> Sue H. - on that last point ... just want to clarify wes' question ... is the session locking on whole data model
[18:31:39] <SharonChisholm> andy - yes
[18:32:04] <SharonChisholm> sue - so you have two sessions ... botha ttached the the box. both making changes ... no locking ... or are you assuming locking from one of these sessions?
[18:32:30] <SharonChisholm> andy - if no body uses locking and concurrent changes are being done .. just like CLI ... potential to step on other people's changes ...
[18:32:35] <SharonChisholm> sue - all or nothing?
[18:33:03] <SharonChisholm> andy - intend to have partial locking in the future ... problem is it across all protocols ... need mapping from SNMP, CLI, Netcongf ...
[18:33:37] <SharonChisholm> Sue - question is just a clarification ... locking .. then you lock everything, two people can't do a rollback. either one session or the other ....
[18:34:03] <SharonChisholm> andy - we should have text here that says that rollback will fail if there is a lock already held on the configuration
[18:34:26] <SharonChisholm> sue - if you are engaging in unsafe playground and things change underneath them, are you going to warn them?
[18:34:32] <SharonChisholm> sue - error reports?
[18:34:45] <SharonChisholm> andy - probably not
[18:35:47] <SharonChisholm> sue - require indication in the software that there has been a problem or the simple approach that it is your fault
[18:36:03] <SharonChisholm> andy - I think the latter ... we would have to think about the text
[18:36:13] <SharonChisholm> sue - might make all the operators to go into locked mode.
[18:36:20] <SharonChisholm> andy - or administrative models
[18:37:12] <SharonChisholm> simon - i would suggest a minimum courtesy would be to invalidate those checkpoints so you at least get an error message when you try to roll back to these invalid points.
[18:37:40] <SharonChisholm> wes - it might be easier to solve some of the earlier problems if we make the ring buffer tied to the user. makes cleanup harder but has other bennefits
[18:37:57] <SharonChisholm> andy - we don't have it exposed in the protocol to identify users ... need to give some thought
[18:38:06] <SharonChisholm> andy - need to think about it on the list
[18:38:51] <SharonChisholm> eliot - going bask to sue's point, in the case when you don't use locking and the element is to detect that something bad as happened. there is nothing to prevent the ne from reporting, we are just not standardizing it.
[18:38:59] <SharonChisholm> <discard-checkpoint> operation
[18:39:15] <SharonChisholm> deletes a slot in the ring buffer or to nuke them all.
[18:39:34] <SharonChisholm> open issues
[18:40:04] <SharonChisholm> - want to make a per session parameter ... if people dont' have write, don't need them. some users get more?
[18:40:14] <SharonChisholm> - do we need to put that in the capabilities exchange
[18:40:25] <SharonChisholm> Rollback Decision Points
[18:40:35] <SharonChisholm> - Should we add this ferature
[18:40:42] <SharonChisholm> count - 10
[18:41:03] <SharonChisholm> object - 6
[18:41:06] <SharonChisholm> prety close
[18:41:21] <SharonChisholm> eliot - no consensus - leave it out
[18:41:46] <SharonChisholm> Randy - would suggest that more suggestion of this on the mailing list is appropriate . I think this proposal is more complicated than it needs to be to get the job done
[18:41:58] <SharonChisholm> randy - simple transaction <something> would be closer to the way humans work
[18:42:20] <SharonChisholm> andy - no you completed the transaction ... configured one side of link ... doing the other ... then need to roll back
[18:42:42] <SharonChisholm> randy - have not finihsed the overlal transaction ... need to look at how distributed transactions are done
[18:42:58] <SharonChisholm> randy - <detailed example>
[18:43:23] <SharonChisholm> andy - question was, should we do a rollback feature, not whether we needed this particular version
[18:43:35] <SharonChisholm> randy - my objection was to this proposal
[18:43:44] <SharonChisholm> andy - that was not the quetsion ...
[18:43:53] <SharonChisholm> randy - then i withdraw my objection
[18:44:11] <SharonChisholm> phil - we had a rollback feature ... we removed it because we could not remove it (previous ietfs)
[18:44:23] <SharonChisholm> steve - we couldn't agree because of named configurations
[18:44:32] <SharonChisholm> andy - this isn't named configurations
[18:44:45] <SharonChisholm> andy - we had thrown it out, but it got raised again
[18:45:06] <SharonChisholm> wes - is there a difference between a URL command and a copy command ...
[18:45:17] <SharonChisholm> andy - this gets around the fact we don't have named configurations
[18:45:56] <SharonChisholm> andy - a named configuration should in theory be applied to any operaiton .. that was contensious(sp)
[18:46:22] <SharonChisholm> q - one possible approach to resolve all this would be to keep the interaction with the box really simple ... and assume everything else is done outside of the box.
[18:46:49] <SharonChisholm> q - this could all become complex ... small boxes ...
[18:46:56] <SharonChisholm> andy - that is why this is all optional...
[18:47:36] <SharonChisholm> q - confused by randy's comments ... think these are two different types of rollback
[18:48:43] <SharonChisholm> john - locks and rollbacks is one way of doijng the rollback model that randy is talking about ... the simpler approach would be to have a transaction approach without having the ability to do more complicated things ,... thinking the locking model is more superior in may ways ...
[18:48:51] <SharonChisholm> <I think I got that wrong>
[18:49:06] <SharonChisholm> andy - I agree, I put out an email in march ... to do more implicit locking.
[18:49:19] <SharonChisholm> andy - died on the vine
[18:49:42] <SharonChisholm> john - maybe we should be looking at that model more careful. maybe when you wrote it up, we didn't understand the issues
[18:50:01] <SharonChisholm> randy - granularity of locking mechanism will become invisible ... that would be good
[18:50:41] <SharonChisholm> andy - sounds like it should go back to the list for more discussion ... not necessarily dead
[18:50:51] <SharonChisholm> andy - want to get to working group last call soon .. running out of time
[18:50:55] <SharonChisholm> ----
[18:51:01] <SharonChisholm> Default Operation
[18:51:20] <SharonChisholm> current draft does not properly support scoped edit-config operations
[18:51:43] <SharonChisholm> ... merge is the default ...
[18:51:55] <SharonChisholm> default operation can't always be merge
[18:52:07] <SharonChisholm> - modify a node in the data model without touching any of its ancestors
[18:52:40] <SharonChisholm> default opeation is sometimes 'none'
[18:52:59] <SharonChisholm> - tells the agent that I better find an exact match or this opeartion should fail
[18:53:10] <SharonChisholm> default operation is sometimes 'replace'
[18:53:30] <SharonChisholm> - useful for loading previously saved configuration data as an opaque XML block
[18:54:04] <SharonChisholm> decision points
[18:54:20] <SharonChisholm> wes - different ideas .. have a parameter without a default
[18:54:42] <SharonChisholm> andy - no that doesn't work .. if I just say at the top level that I just want to do a replace .. then the agent doesn't know where I want to start doing the replace
[18:55:20] <SharonChisholm> wes - exactly ... I'm not saying to take that out. I want to take out the defaultOp is mandatory
[18:56:05] <SharonChisholm> wes - sometimes defaults make perfect sense ... if I accidently type in a file name on a command line, I hope the default operation isn't remove. We may not want a defauilt value for an operation
[18:56:36] <SharonChisholm> andy - high level question .... should we solve this this ... concensus ....
[18:56:43] <SharonChisholm> concensus to fix it that is
[18:57:11] <SharonChisholm> phil - insted of calling it defaultOp .. why not call it operation and default to merge
[18:57:20] <SharonChisholm> wes - my proposal is to call it operation and not have a default
[18:57:35] <SharonChisholm> andy - don't care what it is called.
[18:57:53] <SharonChisholm> sue - just for clarification ... you could have multiple of these?
[18:58:01] <SharonChisholm> andy - no ... there is just one in the edit config command
[18:58:42] <SharonChisholm> andy - the processing model is that you are starting from the top level mode and you are applying an operation as you go down. there could be an operation in there that overrides the operation that is at the very top which is merge
[18:58:58] <SharonChisholm> andy - how do we deal with the fact that there is this overriding operation at the top level?
[18:59:49] <SharonChisholm> andy - change the name to opeartion ... adding that parameter ... show of hands ... about 10
[18:59:54] <SharonChisholm> objections? 0
[19:00:10] <SharonChisholm> andy - so we will add it and call it operations
[19:00:12] <SharonChisholm> ---
[19:00:24] <SharonChisholm> Default Configuration Target
[19:01:03] <Eliot Lear> no defaults for <lock> and <unlock>
[19:01:05] <Eliot Lear> no objections
[19:01:17] <Eliot Lear> application mapping general issues
[19:02:06] <SharonChisholm> Discussion about whether to align to titles of the various drafts
[19:02:08] <Eliot Lear> title of docs is inconsistent
[19:02:38] <Eliot Lear> Eliot: I have no problem with any of the changes that Andy mentioned
[19:03:08] <Eliot Lear> Andy would like more consistency between drafts as far as document section
[19:03:26] <Eliot Lear> Andy:
[19:03:27] <ray_atarashi> h
[19:03:53] <Eliot Lear> NETCONF over SOAP is HTTP-centric. separate SOAP generic and SOAP/HTTP
[19:04:57] <Eliot Lear> Andy; app developers want a SOAP header
[19:05:27] <Eliot Lear> (???) the nice things about standards is that there are so many of them.
[19:05:54] <Eliot Lear> Sharon: can we merge these choices to two?
[19:06:04] <Eliot Lear> - SSH
[19:06:16] <Eliot Lear> - and something else
[19:07:42] <Eliot Lear> sharon: you'd like neither HTTP or BEEP to show up in the SOAP doc..
[19:08:19] <Eliot Lear> Andy: {long tirade over why NETCONF/HTTP sucks rocks}
[19:08:35] <Eliot Lear> Andy: but Ted isn't here now, so it's hard to go farther
[19:10:08] <SharonChisholm> q - <discussion liaison from W3C> I agree that idealling it should work ... there is a documetn that describes how netconf works over soap .. there is a document for soap over beep ... there might be interoperability considerations .. idealing that should be all
[19:10:15] <SharonChisholm> andy - simon says we use soap 1.1
[19:10:33] <SharonChisholm> eliot - someone just told me there is soap over jabber
[19:10:58] <SharonChisholm> eliot - now let us look at the compatility matrix .... <too scarey to put in writing>
[19:11:14] <SharonChisholm> eliot - it is a long list of protocols
[19:11:30] <SharonChisholm> andy - isn't that the case for all soap things
[19:11:49] <SharonChisholm> eliot - people who need to do the coding .... you have just exploded the complexity
[19:12:06] <SharonChisholm> andy - netconf over soap is optional. netconf over ssh is mandatory
[19:12:13] <SharonChisholm> andy - that reduces the complexity
[19:12:32] <SharonChisholm> q - you have said soap, but your second bullet is talking about soap over beep.
[19:12:39] <SharonChisholm> andy - we have run into issues ... it matters
[19:12:45] <SharonChisholm> q - why are we removing http?
[19:12:55] <SharonChisholm> andy - not. just need to separate the text.
[19:13:09] <SharonChisholm> andy - ideally these would not be in this document
[19:13:24] <SharonChisholm> randy - is there any plan to do a formal liaison to w3c
[19:13:29] <SharonChisholm> andy - no, but there will be
[19:13:43] <SharonChisholm> andy - will there be a volunteer>
[19:13:51] <SharonChisholm> brian - also want to talk to oasis
[19:14:12] <SharonChisholm> q - would be glad to get this stuff. especially if it deals with soap (the w3c guy)
[19:14:26] <SharonChisholm> andy - sounds like an issue that we need to resolve to soap 1.2
[19:14:33] <becarpenter> NETCONF over SSH|BEEP|(SOAP over HTTP|BEEP)
[19:14:39] <SharonChisholm> andy - don't want to repeat the asn.1 snapshot thing.
[19:14:43] --- jis has left: Disconnected
[19:15:20] <SharonChisholm> <there are also the various versions of those protocols >
[19:15:44] <SharonChisholm> andy - want updates to documents ...
[19:15:57] <SharonChisholm> andy - want to get to wg last call on all the documents within a month
[19:16:08] <SharonChisholm> andy - i know all the authors are going to say no problem
[19:16:21] <SharonChisholm> andy - so no one has a problem to start a working group last call.
[19:16:31] <SharonChisholm> andy - we may well find problem s...
[19:16:36] --- Eliot Lear has left
[19:16:44] --- becarpenter has left
[19:16:52] --- dem107 has left
[19:16:54] <SharonChisholm> andy - put in minutes that we wilm get to working group last call within a month and new drafts within two weeks
[19:16:58] --- aen has left
[19:17:02] --- nov has left
[19:17:07] <SharonChisholm> andy - thanks for coming and see you on the mailing list
[19:18:14] --- ray_atarashi has left
[19:18:50] --- Tove has left
[19:35:06] --- dinakar has left: Disconnected
[19:40:56] --- SharonChisholm has left: Disconnected
[19:57:12] --- rpayne has left: Disconnected
[20:04:06] --- sleinen has left: Disconnected
[21:44:00] --- SharonChisholm has joined
[21:48:24] --- SharonChisholm has left
[22:56:13] --- keitaro has left: Disconnected