[07:54:28] smc joins the room
[07:54:36] smc leaves the room
[07:58:16] andy joins the room
[08:00:15] dlpartain joins the room
[08:01:09] <dlpartain> audio ok?
[08:01:27] <andy> working -- but distorted
[08:02:03] DavidAlanReid joins the room
[08:02:40] <andy> about the same
[08:04:51] sharon joins the room
[08:05:37] Juergen Schoenwaelder joins the room
[08:07:19] <sharon> Issue #6
[08:09:11] <sharon> bert - IEEE is doing some redo work of MIB modules. Still use some of our TCs from bridge MIBs, but they have their own
[08:09:20] <sharon> bert - good to send pointer to mailing list
[08:10:13] <sharon> Issue #7
[08:11:06] <sharon> those who defien the module will suggest a name rather then iana coming up with their own
[08:11:20] <sharon> Lada - should have one namespace for all netmod work
[08:11:30] <sharon> Lada - then subdivide it
[08:13:16] <sharon> lada and sharon will send suggestion to mailing list
[08:13:37] <sharon> issue #8
[08:16:57] Juergen Schoenwaelder leaves the room: Disconnected
[08:18:08] <sharon> [there might be an argument to put some DSDL here, but I'll take that to the mailing list. I think both approaches, make sense]
[08:19:22] bert joins the room
[08:20:17] <sharon> Issue 9
[08:21:10] <sharon> (cont)
[08:21:37] <sharon> (cont)
[08:22:40] <sharon> wes - 128? Is this for all other BER encoding?
[08:22:46] <sharon> dave p - that is from the SMI
[08:26:09] <sharon> general approach - document and then fight it out
[08:26:39] <sharon> l* - going to run into trouble if you need to choose between the two approaches
[08:27:07] <sharon> so then do separate SMI in that case , like opswg
[08:27:16] <sharon> take specific details to the list
[08:28:56] <sharon> wes - XML Schema data types should be the default. Even if we need to keep in things like negative years, because the bennefits of this restricution are not worth the cost
[08:29:17] <sharon> a - to stay consitent with RFC 3339
[08:29:22] <sharon> dave p - take to mailing lsit
[08:29:57] <sharon> wes - an example. In general,  we are creating CLR if we don't want to use base datatypes
[08:30:07] <sharon> dave p - let's look at where it is different and debate those
[08:30:10] <sharon> Issue #10
[08:33:35] <sharon> end of data type
[08:34:04] Juergen Schoenwaelder joins the room
[08:34:42] <sharon> Martin - Yang Open Issues
[08:34:52] <sharon> Controlling Features
[08:36:23] <sharon> Andy - are you awake? Dave P keeps looking over my shoulder to see if you are saying anything?
[08:37:10] <sharon> if-feature
[08:37:15] <andy> yes -- awake -- just
[08:38:18] <sharon> I think this is conditional conformance
[08:38:28] <sharon> dave h - 'when feature'
[08:39:03] <andy> if feature-stmt top-level or allowed to be nested?
[08:41:04] <andy> can features be imported into another module or are they just local?
[08:41:54] <sharon> mark is queuing for andy
[08:42:25] <sharon> dave h - too many optioins a bad thing
[08:42:29] <andy> this could also be handled with conformance rather than inline and scattered in the module
[08:42:58] <sharon> [I think separate conformance is much more complicated]
[08:43:29] <sharon> dave h - don't want to make it too easy to make things too optional
[08:43:40] <andy> how does renaming a capability into a feature really help?
[08:44:21] <sharon> dave p - thinks vendors would like this
[08:46:25] <andy> I agree with DaveH -- we should try for a simple solution to cover 80% of all needs.  Nested features, plus capabilities == confusion
[08:54:34] <andy> this is a slippery slope -- you will be adding #if, #elif, and #else in a few minutes when you realize this form of macro is too simplistic
[08:59:23] <andy> mix in must-stmt and when-stmt and this seems complicated to figure out what a module really requires
[08:59:52] <sharon> [interest in problem, but not sold on solution seems to be the consensus to me]
[09:03:46] <andy> if mod A imports B and C.1, and B imports C.2, this is an error, right?
[09:06:50] <sharon> [namespace versus versions versus backwards/forwards compatibility]
[09:08:14] dbh2 joins the room
[09:08:56] dbh2 leaves the room
[09:09:26] <andy> module A is attempting to import 2 versions of C
[09:11:09] <andy> not true Martin -- uses-stmt can cause this to be a conflict in A 
[09:11:14] <sharon> [if we can do this without, then better]
[09:12:48] <sharon> revision 1(2)
[09:13:09] <andy> import by revision is less painful that conformance by enumeration, I agree with Phil
[09:15:11] <sharon> andy - is that for this issue?
[09:15:18] <andy> yes
[09:15:33] <sharon> andy - but isn't this just description text
[09:15:40] dbh2 joins the room
[09:15:55] <andy> module needs some version ID or the namespace URI has to keep changing, which is bad
[09:16:49] <andy> oops -- I got your ? backwards
[09:18:07] <sharon> j - date portion is very useful
[09:19:27] <andy> yangdiff --difftype=revision will auto-generate the revision-stmt
[09:19:34] <sharon> [agree]
[09:19:52] <sharon> [rough hum consensus was mandatory]
[09:20:58] <sharon> revision 2(2)
[09:21:59] dlpartain leaves the room
[09:23:05] <andy> it is useful to know which is the older and which is the newer revision -- duh
[09:23:42] <sharon> andy  - did you want me to say that at the mike?
[09:24:35] <andy> Juergen pointed out why we need the revision date -- I agree with you that the description clause is not very useful
[09:25:40] <sharon> ---
[09:25:42] <sharon> DSDL
[09:26:43] <sharon> slide 6
[09:29:06] <andy> ietf.org seems to be down -- I cannot get the slides
[09:31:24] <sharon> he sent an email to the list with his own website for these
[09:31:58] <sharon> <http://staff.cesnet.cz/~lhotka/NETMOD/yang2dsdl.pdf>  Slide 15

[09:32:10] <sharon> [ignore the sldie 15. it's a cut and paste]
[09:33:03] <andy> thanks
[09:33:54] <andy> is this going to be on the test? :-)
[09:34:04] <sharon> yes
[09:34:11] <sharon> slide 9
[09:34:26] lengyel joins the room
[09:36:07] <andy> not that XSD matters anymore, but it is no big deal to stuff the extensions into <appinfo> elements
[09:38:12] <sharon> [you can do that in Relax, but the question is what off-the-shelf tools can do with it]
[09:38:34] <andy> slide 10: this code is hard, but not impossible ;-)
[09:38:37] <sharon> "augment" slide
[09:39:17] <andy> this is the only way for a vendor to augment a standard YANG module
[09:39:30] <sharon> andy - 1 or 2?
[09:41:21] <andy> 1 or 2 what?
[09:41:29] <sharon> andy - never mind
[09:41:44] <sharon> andy - i sat down and no one had a comment on your comment
[09:42:16] <sharon> phil <something about patterns>
[09:42:40] <sharon> need to parse other module to do translation
[09:42:59] <dbh2> it was unclear whether you preferred style #1: uses foo; augment some/container, or style#2: uses foo { augment ...}
[09:43:39] <sharon> martin - can only add to top level patterns?
[09:44:09] <andy> I was looking at a different slide deck, with a different slide 10 :-(
[09:44:22] <sharon> <restrictions on what you can add to in DSDL?>
[09:44:34] <sharon> [I have not run into these restrictions]
[09:44:50] <sharon> <this might put limitations on the mapping>
[09:45:09] <sharon> lada - <namespace mangaling and putting things to top level of schema>
[09:45:26] <sharon> "mapping augements is difficult in DSDL" will be the topic of the mail
[09:45:54] <sharon> oops. I hadn't realized the numbering had changed. Sldie 10 is "augment"
[09:46:19] <sharon> this is a yang issue
[09:46:36] <sharon> slide 12 "No Root Element"
[09:47:25] <sharon> phil - explain what that means
[09:47:55] <andy> are you suggesting adding an element into the XML (NETCONF PDUs)?
[09:49:52] <andy> Is this a different problem than the <config> container needed  for the file generated by copy-config?
[09:50:04] <andy> yes - mult. roots
[09:50:13] <sharon> "multi root elements"
[09:50:16] <sharon> slide 13
[09:51:04] <sharon> slide 14 "XPath and Namespaces"
[09:52:20] <sharon> phil - I think this will effect the readability of the yang module must statement; rather have the tool do it
[09:53:43] <sharon> <whether xpath in yang is compliant to xpath; phil says yes; lada less certain>
[09:54:02] <sharon> not member of namespce
[09:54:12] <sharon> dave p - sounds like we need to add text to yang draft
[09:54:20] <sharon> dave p - similar to what phil just said
[09:55:03] <sharon> j - each point to the spot in the specification hat supports their view
[09:55:30] <sharon> ---------
[09:56:09] <sharon> Martin (encore)
[09:56:46] <sharon> "server variance"
[09:56:59] <sharon> slide 14
[10:00:24] <sharon> sharon - do it in verbs
[10:00:31] <sharon> juergen - project management - defer
[10:00:42] <andy> agree with Juergen
[10:04:13] <andy> platform-specific details could be generated in a device schema -- outside the scope of YANG -- like Martin's overlay idea
[10:08:43] <sharon> <separate these into two issues>
[10:10:31] <sharon> slide #17
[10:10:37] <sharon> "multiple patterns"
[10:10:39] <sharon> skipped
[10:10:47] <sharon> slide 18 - conditional content
[10:11:28] <andy> multiple patterns -- need to align with how XSD types process patterns
[10:13:39] <sharon> "conditional content" slide 18
[10:13:47] <sharon> (oops, we were alreadt there)
[10:13:53] <sharon> see juergen run!
[10:14:00] <andy> I think patterns in the same type are ORed together, then ANDed with ancestor type patterns; I will check the XSD spec
[10:15:03] <sharon> "why constrain keyref" 19
[10:18:24] <andy> smidump is already generating YANG modules with notifications that have keyrefs pointing at the config.
[10:19:40] <sharon> -------
[10:19:56] <sharon> Balazs
[10:20:08] <sharon> NETMOD Augmentable Grouping
[10:20:22] <sharon> Sorry. Wrong one. 
[10:20:38] <sharon> "RPCs and Notifications inside lists in Yang"
[10:20:55] <Juergen Schoenwaelder> Andy, you seem to be right. http://www.w3.org/TR/xmlschema-2/#src-multiple-patterns says that multiple pattern are combined as if they appeared in a single ·regular expression· as separate ·branch·es. And now I recall that we dropped multiple pattern in Stockholm since essentially you can always easy combine A and B as (A)|(B). With that insight, adding multiple pattern is not solving the problem pointed out on the mailing list. I will post a message about this to the list.
[10:21:05] <sharon> Issue 2.
[10:22:10] <sharon> Issue 3
[10:22:38] <sharon> solution - RPCs define in list
[10:23:14] <sharon> RPC in LIst - XML

[10:23:41] <sharon> rpc/operation in list - xml
[10:24:20] <sharon> notifications inside lists
[10:25:33] <sharon> notifications are content so inline good; rpc line not so good
[10:25:59] <sharon> --------
[10:26:16] <sharon> Augmenting Yang Grouping
[10:26:17] <andy> do not agree there is a problem to solve here; nesting rpc and notification jsut makes YANG more complicated; it is not an OO DML
[10:26:18] <sharon> Slide 2
[10:27:06] <sharon> andy - you if you are gooing to defin BGP specific notification content, there is no harm in nesting it in <bgp>. Then you can have the same definition used for a <get>
[10:27:40] <andy> keyref can handle this too
[10:27:51] <sharon> andy - comment to presenter or to me?
[10:27:59] <andy> you
[10:28:00] <sharon> slide 3
[10:28:10] <lengyel> I would hate to define restart-node, restart-interface, restart-ospf, restart file-transfer side by side.
[10:28:17] <andy> augment a grouping -- just make a new grouping and use the old grouping
[10:28:35] <sharon> b - then don't ;-)
[10:28:49] <sharon> "potential issue"
[10:28:56] <lengyel> Please also say how to handle the subagent stuff. 
[10:29:23] <sharon> b -> the intesresting question is whether there are additional parameters
[10:29:49] <sharon> b-> we just try to avoid that with good naming strategy
[10:30:13] <sharon> lada - <reference to previous statemetns of augment>
[10:30:22] <sharon> a - would need to look at implecations
[10:30:47] <sharon> dave p - turn into suggestion to mailing list
[10:31:17] <sharon> dave h - if product feature, this would be lovely. But standards should be fixed. People should not be able to change things after the fact
[10:31:40] <sharon> [it occurs to me that I have the same method of indicating that someone is speaking or that I am speaking to them in jabber]
[10:32:05] <sharon> dave h - it was a general comment.
[10:32:22] <sharon> M - don't see the problem.  we don't break developing standards here
[10:32:28] <andy> agree with DaveH -- this is complicated to implement and use safely
[10:32:30] <sharon> M - maximize reuse. 
[10:32:39] <lengyel> There are a number of people who don't hate OO even if we know that YANG is not and will not be OO. Ericsson, Nokia siemens, partly Nortel(?), Alex Chlem (?), etc. So saying "if it smells of OO kill it" is a too strong statement.
[10:33:23] <sharon> l - complicated but may need it
[10:33:34] <sharon> l - aspect oriented programming. read a book on it
[10:33:43] <andy> we are reinventing OO in YANG!
[10:33:43] <sharon> l - language designs sholud do that
[10:34:04] <Juergen Schoenwaelder> Something like "affects _all_ modules" really scares me.
[10:34:05] <sharon> a - powerful feature; must be explained
[10:34:50] <andy> I am not convinced N will be large enough to warrant this power tool
[10:34:54] <sharon> mark - both this and B's stuff could solve actual problems he is trying to solve
[10:35:26] <sharon> phil - effecting stuff you don't control
[10:36:12] <sharon> dave h - an example where we have reached this. MPLS from IETF. ITU added stuff. 'incompatible"
[10:36:30] <sharon> --------------
[10:37:06] <sharon> <wrap up> <interim meeting 8-10th>
[10:37:39] <sharon> <current> <new features>
[10:37:43] <sharon> done!
[10:37:59] andy leaves the room: Logged out
[10:38:02] sharon leaves the room
[10:38:07] Juergen Schoenwaelder leaves the room
[10:38:12] DavidAlanReid leaves the room
[10:39:21] dbh2 leaves the room
[10:40:04] lengyel leaves the room
[10:48:45] bert leaves the room