[16:29:15] dlpartain joins the room [16:29:15] dlpartain leaves the room [16:30:31] dlpartain joins the room [16:30:31] dlpartain leaves the room [16:31:36] dlpartain joins the room [16:31:36] dlpartain leaves the room [16:32:30] dlpartain joins the room [16:32:30] dlpartain leaves the room [16:33:37] dlpartain joins the room [16:33:37] dlpartain leaves the room [16:38:48] david_partain joins the room [16:38:49] david_partain leaves the room [16:43:50] david_partain joins the room [16:44:01] david_partain leaves the room [16:48:49] david_partain joins the room [17:50:48] bert joins the room [17:50:59] so I can join it seems [18:04:18] ersue joins the room [18:05:35] test test [18:12:43] bert leaves the room [18:32:41] bert joins the room [18:45:03] bert leaves the room: Replaced by new connection [18:46:38] bert joins the room [18:47:07] bert has set the subject to: NETMOD-NETCONF conf call 24 sept 2009 [18:49:57] bert leaves the room: Replaced by new connection [18:49:59] bert joins the room [18:51:13] my wireless connection is very poort here. Will be better when I get back home at 9L:45 [18:51:36] can David and/or Mehemet confirm that they see my messages? [19:02:28] ACK [19:04:48] great [19:07:21] bert leaves the room: Replaced by new connection [19:07:23] bert joins the room [19:26:52] bert leaves the room [19:33:40] bert joins the room [19:46:12] bert leaves the room: Replaced by new connection [19:46:14] bert joins the room [19:49:24] JMHWORK joins the room [19:49:34] hi all [19:49:42] Hello. [19:49:57] that must be joel [19:50:09] Yep, it is Joel. [19:50:55] y'all in the call, too? [19:51:37] No, I have not called in yet. I figured I would dial in closer to the hour. [19:51:56] same here [19:52:22] I'll dig up the call info and post it here [19:52:23] yep [19:52:30] i have it [19:52:39] i can paste in... [19:52:45] go ahead [19:52:59] NSN Voice Conference Conference ID: 18826 and PIN: 40722 Sweden: +46 8 5250 0862 (PRIMARY), +46 8 4100 9299 Help Desk: +358 7180 71850 Netherlands: +31 793465 225 Help Desk: +31 70 307 1871 USA Boston: +1 781 993 4850 Help Desk: +1 781 993 4851 USA San Francisco: +1 415 581 7650 Help Desk : +1 415 581 7651 USA Mountain View: +1 650 864 5850 Help Desk : +1 650 864 5851 Germany: Düsseldorf: +49 211 9412 4999 Help Desk: +49 211 9412 4998 Munich: +49 89 549 986660 Help Desk: +49 89 636 43801 [19:53:18] Israel: +97 29 775 1700 Help Desk: +97 29 775 1720 Czech Republic: +42 02 460 19300 [19:53:41] If anybody wants I have more . . . ;-) [19:53:54] thanks, mehmet [19:54:04] i was digging those up but you won :) [19:54:08] No issue. [19:54:54] OK, now I am the first one in the conf call [19:57:57] mbj joins the room [19:58:53] hi martin [19:59:02] hi [20:00:23] lhotka joins the room [20:00:36] andy.bierman joins the room [20:00:39] Juergen Schoenwaelder joins the room [20:01:41] andy, are you able to call in as well? [20:02:34] welcome andy [20:02:42] phil.shafer joins the room [20:09:24] sound problems [20:09:35] are you hearing? [20:09:36] mute on [20:10:05] andy, are you hearing this? [20:10:08] on the call? [20:10:09] can hear ok [20:10:12] ok [20:10:28] are you going to try to call in or something? you need to be able to talk [20:11:15] Andy: try to call in again [20:12:49] P() [20:12:57] talk [20:13:51] Clarifying question when he finishes this answer. [20:14:10] hand up for clarifying question [20:14:51] bert! [20:15:11] then joel [20:15:15] then martin [20:15:16] dromasca joins the room [20:15:18] then phil [20:17:20] phil WHAT is the "root" , just for me to be sure [20:18:07] talk [20:18:38] "root question" meaning we don't agree on what configuration is [20:18:53] ah. OK. so same as what Juergen states [20:19:15] david p... [20:23:22] So Lada, you seem to also be in favor to tackle Juergens 1st concern: clearly define what is config and what is operational state data [20:25:12] Yes, but I don't think it's a low-hanging fruit. [20:25:19] lada, i agree [20:26:18] right, nobody has claimed it is low hanging fruit. [20:27:55] talk [20:28:10] david [20:28:19] phil [20:29:05] talk [20:29:05] martin you mean the yang draft, right? [20:29:15] bert, yes [20:30:26] talk [20:30:29] talk [20:30:40] first lada, andy, then joel [20:31:49] phil [20:33:13] Withdraw my talk request. Been stated sufficiently. [20:33:23] ok, joel [20:33:51] what the server is doing != what the config is the server is operating on (regardless of defaults included or not) [20:36:19] Okay, maybe I can clarify. Talk [20:37:34] dromasca leaves the room [20:40:06] Have we defined the term "conceptual configuration" or "conceptual data model" anywhre? [20:40:13] Or is that still to be done? [20:40:19] dromasca joins the room [20:40:22] Not in the draft. [20:40:40] talk [20:40:48] just a moment, lada [20:40:48] We talk about "conceptual evaluation" [20:40:51] Juergen does this "conceptual..." help you? [20:41:05] phil, in the draft? [20:41:15] or just on email? [20:41:21] does conceptual have to do w/ defaults? [20:41:31] dan, yes [20:41:40] "con... eval..." is in the draft. "con...database" is not. [20:42:10] phil: talk [20:43:15] talk [20:46:18] talk [20:46:25] can Martin explain what server-assigned will solve? [20:46:59] sure [20:47:04] assigned-by system addresses the "uid" example on the mailing list [20:47:25] talk [20:47:34] first martin, then phil [21:04:39] talk [21:05:34] tal [21:05:35] talk [21:05:44] talk [21:06:36] talk [21:10:00] talk [21:10:32] talk [21:10:41] must expr for config=true can [21:10:43] first martin, then lada [21:10:48] can't refer to config=false [21:11:24] talk [21:11:26] phil, is that very clear in the draft? [21:13:30] ersue leaves the room [21:14:25] Bert: maybe not:The accessible tree depends on the context node:- If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children.- If the context node represents state data, the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. [21:16:04] So it seems it could be stated a tidbit clearer, at least in my view. Althoughh I am not sure about the exact text. [21:16:15] talk [21:16:17] Your short sentence seemed clearer than the lobger text [21:17:15] talk [21:18:31] talk [21:18:57] talk [21:19:30] talk [21:21:10] talk [21:21:43] ersue joins the room [21:22:22] question [21:22:30] config=false already not allowed, right? [21:23:11] talk [21:25:17] talk [21:26:14] A learned IP address isn't config data, so it just be a new/distinct node. The constraint would refer to the operational "twin" leaf, not the config "twin" leaf. [21:26:24] consider a leaf = (gold, silver, bronze). The CPE customer is allowed to read this but not set it -- other config leafs the CPE can set can have must-expr that refer to . IMO, both are config=true, but the CPE is blocked from changing via access control. So, even though it looks like should be config=false, it isn't. (maybe on the server is authorized, maybe CLI-driven only to set ). [21:27:23] Lada, do you have real-life examples where it DOES make sense? Where it gives big benefit? [21:27:40] Given some sort of access control model (yet to be defined), I agree that "service-level" is config information. [21:27:42] If not... Iprefer to leave it out I think [21:30:47] talk [21:31:28] david joins the room [21:32:01] talk [21:32:26] talk [21:33:15] talk [21:33:56] But add that explanations you are just discussing!? [21:34:35] talk [21:34:38] talk [21:36:44] Juergen? [21:37:46] dromasca leaves the room [21:38:03] dropped out and called in again [21:38:09] ok [21:38:25] yes, examples are good! [21:38:38] one for each possibility [21:39:35] I think examples will help a lot. [21:40:51] talk [21:41:09] and we obviously need to confirm on the mailong list ... [21:41:21] s/mailong/mailing/ [21:41:21] What David P. says sounds good. Let's have more detailed discussions after we write some text on the aggrements of today. [21:41:22] radical idea: toss out namespace-stmt and use long module names like Phil wants. Use the same long string in import/include/XML namespace; IANA registry has the long names, not URNs [21:41:24] we must have it out for consensus on the WG list(s) though [21:42:16] but we need namespace URIs in XML [21:42:18] xml namespace must be a URI. [21:42:28] but note that confirm is different than reopening: we ask people whether they can live with this solution [21:42:47] yes [21:42:53] yes [21:42:57] Yes from my side. I am really happy that we came that far. [21:42:57] yes [21:42:57] I [21:42:59] aye [21:42:59] Aye [21:43:01] yes [21:43:09] I like the: I [21:44:52] talk [21:45:35] talk [21:49:17] talk [21:50:24] talk [21:50:31] I have a concern [21:50:32] i agree [21:50:33] sounds good [21:51:31] what about no new NETCONF version? IMO, this design team should assume a not-backward-compatible protocol version is OK [21:52:00] phil will! [21:52:15] Just tell me what to say! [21:54:44] good night [21:54:53] bye [21:54:57] mbj leaves the room [21:55:01] phil.shafer leaves the room [21:55:02] by, thanks all [21:55:08] lhotka leaves the room [21:55:08] andy.bierman leaves the room: Logged out [21:55:36] Juergen Schoenwaelder leaves the room [21:55:44] bye all [21:55:48] david_partain leaves the room [21:56:24] Bye. [21:56:27] JMHWORK leaves the room [21:57:56] ersue leaves the room [21:59:58] bert leaves the room [22:04:18] david leaves the room