[16:39:22] lhotka joins the room [16:40:19] lhotka leaves the room [18:38:05] phil.shafer joins the room [18:38:22] Welcome!!! [19:06:05] david_partain joins the room [19:06:05] phil.shafer leaves the room [19:17:59] mbj joins the room [19:18:14] howdy martin [19:18:18] hej [19:18:34] shall we write something in swedish for permanent ietf logs? :-) [19:19:15] a simple greeting should be ok [19:27:05] david_partain has set the subject to: Working on the YANG FAQ [19:27:09] lhotka joins the room [19:27:37] greetings lada! [19:28:30] Hi! [19:28:43] andy joins the room [19:29:40] howdy andy! [19:29:49] hi David [19:30:15] we'll start in a couple of minutes to give slackers a moment to get into the chat room [19:30:36] Sure. [19:31:43] My plan is quite simple: I'll paste in the wiki markup of the question and answer (if there is one) and we'll (1) see if we all get it and (2) see if we agree. if there's no answer in the wiki, i'm hoping someone here will have one to start the discussion. [19:32:09] i'm still expecting at least Jürgen and Phil [19:33:34] bert wijnen joins the room [19:33:50] hi bert [19:33:55] we're gonna start in a sec [19:34:00] Hi David (and others) [19:34:03] phil.shafer joins the room [19:34:37] i declare quorum [19:34:44] hopefully others will show up [19:34:58] so, thanks for humoring me on this experiment. let's do some work.... [19:35:09] question 1 from the wiki, with no answer there... [19:35:16] == Why doesn't YANG support XML attributes? == #why-no-xml-attributes [19:35:28] anyone have a strawman? [19:35:50] (note that i'm going to take the logs of this session and create the answer on the wiki) [19:35:56] YANG is not an XML schema language [19:36:13] seems simple enough to me... others? [19:36:38] lada? [19:36:45] I think the answer should be that elements are more flexible [19:36:58] YANG defines leafs, lists w/ keys etc which are encoded into XML. YANG uses XM elements for data, and some attributes for meta-data. [19:37:03] XML namespaces are also handled differently in attributes [19:37:28] ok. more? [19:37:38] is the question why we don't *encode* into XML attributes? [19:37:48] Also, for true data (as opposed to metadata) elements are the recommended representation. [19:37:57] NETCONF operation attribute cannot work on another attribute, just an element [19:38:29] and martin's clarification question? [19:38:34] To Martin: yes, that's how I understand the Q. [19:39:03] We treat elements as data and attributes as non-data (ops, decorations, etc) [19:39:08] i don't remember if this question came from yang-central.org or andy's list (both were put on the FAQ list) [19:39:17] ok. then I think we have the answer now. [19:39:51] ok. that seems like we can synthesize something out of that. going once [19:39:55] twice [19:40:04] gone! next question [19:40:26] dbh2 joins the room [19:40:29] == Why doesn't YANG support the xs:list data type? == #why-no-xs-list xs:list in XSD is a simple type, which can be assigned to elements. For example, if such a list for an element "mibs" contains the values "rmon", "alarm", and "rmon2", it would be encoded in XML as: {{{ rmon alarm rmon2 }}} The problem with this is that XPath expressions cannot be used to check individual elements of the list. This is a problem both in '''must''' expressions in the YANG modules themselves, and also when tools like XSLT are used to manipulate NETCONF data. To illustrate this problem, suppose the element "foo" above contains "alarm" and "rmon2": {{{ alarm rmon2 }}} If we write an XPath expression which checks if "rmon" is present: {{{ substring(mibs, "rmon") }}} this XPath expression returns true. This is a well-known problem with xs:list in XML in general, and usually it is recommended to use markup instead. In YANG, there is a separate keyword '''leaf-list''' which is used instead. [19:40:59] Is that an open question? [19:41:07] no [19:41:13] i just want to make sure we all agree [19:41:19] or if anyone wants clarification [19:41:19] going once? [19:41:22] twice [19:41:28] gone! [19:41:32] next question [19:41:33] the bits data type is essentially an xsd:list [19:41:52] i guess it wasn't gone :-) [19:42:02] I think that YANG is YANG, there are many features in XSD and RNG and ... that are different. [19:42:23] yes, clearly, but people are going to ask these questions (they have in the past) [19:42:40] David, you should wait a bit, I am no a fast typer. :) [19:42:45] so it's easiest if we can provide the answer easily [19:42:51] ok, lada. sorry :-) [19:42:53] YANG's control mechanisms (delete) make xsd:list painful. [19:43:03] I can have pattern and length on a leaf-list, but I have to enumerate all the bits [19:43:17] to phil: s/YANG/NETCONF/ ? [19:43:25] Both. [19:43:30] Hi, [19:43:32] (meaning insert also) [19:43:58] Is this an open issue? If so, it should be discussed on the netmod mailing list. [19:44:18] is what an open question? [19:44:27] bits is a special case... the data modeller has control over all the enumerations, so he can make sure he doesn't run into the xpath issue. [19:44:38] Are there any cases where xs:list would be needed and it cannot be modelled in YANG? [19:44:57] re: control: not if he wants rmon and rmon2 (for example) [19:45:13] Hard to say -- YANG forces leaf-list instead [19:46:05] also for bits; the delete/create thing is not as important as for leaf-lists (b/c there is a known, limited numer of bits) [19:46:12] Thise who ask this should provide some use cases, otherwise it's hard to answer. [19:46:14] Many of these are design choices. We need to explain our choice, but in the end it's just a decision. Why is the US flag red white and blue. There are [19:46:18] Juergen Schoenwaelder joins the room [19:46:32] ... reasons but it could just as easily been other colors. [19:47:01] ok... so i have no idea where we are on an answer given all of this [19:47:11] so for bits we said we could live with the substring restriction; the xs:list encoding gives us other advantages (a leaf is always encoded as one XML element) [19:47:11] The ordered-by user mechanisms could be applied to xsd:list as well as leaf-lists, but they are not [19:48:07] you mean apply orderd by user to bits? a bit set is not ordered. [19:48:12] xsd:list limits content to non-whitespace, since it's whitespace delimited. [19:48:31] It is OK to leave out xsd:list [19:48:40] and we don't manipulate the contents of a bitset, we just replace it. [19:48:49] just like in SNMP [19:49:08] Ok? Sure, but we need an explanation suitable for the FAQ. [19:49:36] i think the current answer is fine, but we also need to mention why bits are encoded as xs:list [19:50:05] martin: if you can provide some reasonable additional text to why bits are done as they are, we should be done? [19:50:10] bit names are not allowed to have whitespace, unlike enum names [19:50:33] the main reason IIRC was that with this encoding, all leafs are encoded as one XML element [19:51:03] exactly the sort of thing we're trying to capture here [19:51:22] so, we done on this one? lada? [19:51:27] going once.... [19:51:32] yes [19:51:37] going twice [19:51:40] gone! [19:51:52] == Why doesn't YANG support reusable complex data types? == #why-no-reusable-complex-types YANG supports reusable groupings. Everything that can be done with a complex type, and more, can be done with groupings. Balazs: not fully true [19:52:08] I think we have to defer this question [19:52:12] Anyone know Balazs' issue? [19:52:19] until the whole groupings discussions are done [19:52:27] about augmenting groupings... [19:52:38] that's the primary issue, i think [19:52:56] So move on? [19:53:03] i'll ask Balazs to be a bit more ... verbose in his comment [19:53:03] yes [19:53:05] we move on [19:53:06] the thing is that the question is hard to answer if we don't have a defintion of what a complex type is [19:53:17] == Why doesn't YANG use the RelaxNG instance qualifiers (?, *, +) instead of leaf-list? == #why-not-rng-instance-qualifiers The alternative here would be to drop '''leaf-list''', and just have '''leaf''', but with instance qualifiers. We believe there is a value in giving different names to different concepts. In this case, the two concepts are simple values and arrays of values. YANG supports min-elements and max-elements, which give more control than ?, +, and *. [19:53:25] I would personally point to the fact that e.g., RELAX NG doesn't support complex types either. [19:53:53] thanks, lada [19:53:54] Just definitions of named patterns [19:54:06] which is sort of similar to groupings [19:54:10] that's also in the logs now, so i'll try to add something to that effect. [19:54:45] XSD supports a data type which contains simple content or complex content (more elements) [19:54:59] leaf-list and leaf behave quite differently. A leaf doesn't need to support insert, ordered-by, etc. [19:55:04] (so, are we still on the complex types question?) [19:55:15] yes [19:55:40] thanks, andy. noted [19:55:47] is the question why we don't have *XSD* complex type? [19:55:50] there are problems with completely abstract data chunks in YANG, so groupings is fine [19:56:04] no, i don't think the question is about XSD complex types [19:56:15] andy? [19:56:22] You cannot really refine a complex type like you can a grouping/uses [19:56:23] YANG defines types as the contents of a leaf. We don't overload the word to mean "groups of nodes". [19:57:39] Weren't "complex types" supposed to be that OO approach suggested by some? [19:57:41] For me, Q3 is adequately answered until Balaz tells us what is wrong with the answer. [19:57:45] i think we need to get input from people like mehmet and balazs before we can make much more progress here [19:57:54] andy: it seems you have some definition of complex type, since you say that they cannot be refined. I still don't know if we talk about XSD complex types or something else. [19:58:00] i agree with Jürgen [19:58:21] I meant XSD complex type. We have some reasons to write down why it is not supported [19:58:24] i will take an action item to get them to help here [19:58:36] this discussion needs to happen on the mailing list, not here [19:58:44] hold on one sec [19:59:06] we're holding... [19:59:12] in XSD a complexType is necessary ro define elements under an element. We don't need that. [19:59:16] ((muzak)) [19:59:25] 1 reason we have groupings is to refine the uses. Done instead of OO approach [19:59:58] ok, folks. closing the discussion... [20:00:05] ok [20:00:06] next question [20:00:20] == Why doesn't YANG use the RelaxNG instance qualifiers (?, *, +) instead of leaf-list? == #why-not-rng-instance-qualifiers The alternative here would be to drop '''leaf-list''', and just have '''leaf''', but with instance qualifiers. We believe there is a value in giving different names to different concepts. In this case, the two concepts are simple values and arrays of values. YANG supports min-elements and max-elements, which give more control than ?, +, and *. [20:00:32] lada, that's yours... [20:00:39] to answer :-) [20:00:54] (repeating) leaf-list and leaf behave quite differently. A leaf doesn't need to support insert, ordered-by, etc. [20:00:55] i think the answer's good [20:01:06] current answer is OK: min/max provide more control [20:01:10] I don't thins so but hang on ... [20:02:36] The qualifiers are analogical to min/maxOccurs, it has hothing to do with the difference between list and leaf-list. [20:03:03] Again, it's a design decision. [20:03:27] I must admit that the first time I heard about leafs, leaf-lists and lists of leafs, I was somewhat confused. We need to keep in mind that others might have the same first time surprise. I don't know a better name for leaf-list - but if there would be a good proposal, I would like to adopt it. ;-) [20:04:01] yes, the name is confusing [20:04:25] The design was keyed by the fact that lists are different that non-lists. By calling out lists (and leaf-lists) as a first-class language construct, the meaning it clear, [20:04:39] ... not implement in other statements. [20:04:43] leaf-list is the only construct that is encoded in N XML siblings, not just 1 tree like everything else [20:05:18] "leaf" + "list"; what could be less confusing that "leaf-list" ? [20:05:26] so, let's capture that "design decision" in the faq answer [20:05:29] Well, lists too, except that they are encoded in richer subtrees [20:06:08] i'm happy we've got enough to go with [20:06:28] going once (lada, just bang on your keyboard in protest if i'm too fast) [20:06:34] twice [20:06:35] no - a list construct really represent 1 row (ala insert, key); a leaf-list represents N siblings; there is no list-list [20:06:56] gone! [20:07:03] The different is that lists have keys, but leaf-list are their own keys. [20:07:05] but that wouldn't change if we had * [20:07:09] (thanks for the clarification, andy) [20:07:46] In RELAX NG, lists and leaf-lists are translated exactly in the same way. [20:08:08] lada, do you mean in the mapping? [20:08:16] Yup. [20:08:17] But is that a good thing? [20:08:31] that's a different discussion, mr. shafer :-) [20:08:33] Sure, why not? [20:08:42] that is not correct XML for a list [20:09:07] i'd like to talk about the mapping separately (on the list, please) [20:09:12] more on this question? [20:09:15] During design, we talked about "say what you mean, mean what you say". By making these first class language constructs, we've done this. [20:09:15] 5 [20:09:22] 4 [20:09:26] Why not, it's always of something [20:09:36] (guess there's more) [20:09:40] offline I guess [20:09:46] A leaf isn't a leaf unless it's got a "*". It's a leaf. You see the word leaf and know [20:09:49] online, but on the list... [20:09:50] ... what to expect. [20:10:10] phil's point is clarity, i think [20:10:23] 3 [20:10:24] also, to *really* answer the question we need an alternative proposal... [20:10:28] Let's discuss it somewhere else. [20:10:32] 2 [20:10:36] 1 [20:10:39] next! [20:10:44] == What are the differences between P and NP containers and why should I care? == #presence-and-non-presence-containers [20:10:46] The grammar is richer, in that you know that "ordered-by" cannot appear under "leaf". [20:10:46] (no answer) [20:10:59] P containers have a meaning of their own. Just by appearing, they conveya specific meaning. NP containers are organizational, collecting relatednodes under an umbrella node. [20:11:05] we're now on andy's question [20:11:24] you're quoting something. that's cheating [20:11:34] the difference seems to be focused on an empty container [20:11:36] I cheat. So? ;^) [20:12:05] andy: can you elaborate? [20:12:06] I would say the opposite; it's focused on the meaning of the container. [20:12:33] Does the container (with or without content) mean something? If so, "P". [20:13:07] I think the draft says an NP container with all optional children is mandatory. [20:13:30] I don't think so. [20:13:37] An NP container w/ mandatory children is mandatory; and only optional children makes it optional [20:13:38] that would be wrong [20:13:49] martin, you have an action to check [20:14:24] There is a useful distinction -- mandatory children will not make a P container mandatory [20:14:26] if we're finding things that aren't clear in the draft(s), that must go to the list [20:15:13] to andy: yes, but I understand it's on purpose [20:15:28] I just want YANG newbies to understand P vs NP -- it is not that obvious [20:15:43] ok, so would someone summarize changes to phil's suggested answer (the cheating one) above? [20:15:44] NP containers are ephemeral; they can come and go with no effect [20:16:36] i'll pull together something out of what's been written [20:16:40] 5 [20:16:43] you mean empty NP containers? they have effect if they have child nodes [20:17:07] Sure, they can't "go" is they have children. [20:17:13] s/is/if/ [20:17:31] 4 [20:17:37] 3 [20:17:42] 2 [20:17:46] 1 [20:17:49] next! [20:17:56] == Why doesn't YANG support nested key leafs? == #nested-key-leafs [20:18:00] Good question :) [20:18:07] i thought you'd say that [20:18:09] " nested key leafs" == deep keys? [20:18:16] yes [20:18:17] i think so. andy? [20:18:18] I think so [20:18:24] it's your question [20:18:28] yes -- like deep unique statmenet nodes [20:18:29] The issue is buffering. Shallow keys must appear first. Deep keys mean unknown buffering requirements. [20:18:53] that seems like an implementation issue [20:19:04] deep unique does not have buffering issues, since it's commit time, right? [20:19:17] how so? [20:19:21] with deep keys, NETCONF's subtree filtering cannot be used [20:19:43] Why not? [20:20:09] cannot be used to get a list entry, given its keys [20:20:21] because subtree filtering is kind of broken and will go away in favor of XPath some day [20:20:26] b/c of the way subtree filteringg works [20:20:37] You know my opinion about NETCONF's subtree filtering... [20:20:43] If I have a list of documents and each document is keyed by the first and last paragraph in the document, I have to buffer the entire document to find the [20:20:57] ... keys to start adding the text to the database. [20:21:33] buffering would not become an implemention choice, but an implementation requirement [20:21:42] so what? You should validate the whole thing before adding it the DB anyway [20:22:14] *that's* an implementation issue [20:22:27] we don't buffer, and we do validate [20:22:32] same here [20:22:36] Would it help to say that keys SHOULD go first in complex data types, that is image name before the image? [20:22:58] But this can't be depended on. [20:23:18] But your YANG tools know where the keys are, no? [20:23:21] JS, if that's something we want to recommend, it must go to the mailing list... [20:23:31] The deep structures I use mean that I can't send just the keys from the deep structures, I have to send the whole thing. [20:23:54] SO YANG does not need deep keys ever because 2 implementations do not buffer. Saving about 1-5 MB? [20:24:05] I don't think we're here to do design work, just to answer the questions. [20:24:10] exactly [20:24:25] design discussions have to be on the mailing list [20:24:35] Then the answer is that this remains an open question. [20:24:37] YANG, right now, doesn't support "deep keys" [20:24:39] just wondering the the FAQ answer is... [20:24:41] and yes, we do run on rather memory constrained systems... [20:24:51] Same here. [20:25:11] I guess it's a good topic for the interim meeting. [20:25:14] phil: who was your same here to? [20:25:36] So the answer is "concerns over buffering and memory constraints" [20:25:55] the chairs are going to be pretty insistent that ideas that are changes to YANG need to be brought up on the mailing list in advance of the meeting, but we'll to _that_ on the list [20:26:19] and the answer also includes "NETCONF subtree filtering is broken" [20:26:21] same here re: memory constraints. [20:26:42] I don't agree w/ subtree filtering being broken. [20:26:49] that's what was said abo ve [20:26:50] ditto [20:26:52] above [20:26:57] ok, i misunderstood [20:27:22] emile joins the room [20:27:34] and the answer also includes "because of the way NETCONF subtree filtering works" [20:27:42] right? [20:27:48] can we move to the next? [20:27:50] 5 [20:27:56] 4 [20:28:00] 3 [20:28:04] 2 [20:28:08] 1 [20:28:09] subtree filtering is highly constrained -- it cannot support retrieval of level N if the keys are not at level N+1 [20:28:34] constrained, yes. Broken, no. [20:28:39] i'm happy [20:28:42] 0! [20:28:44] next [20:28:50] == Why does YANG require list keys to be encoded first in all NETCONF PDUs? == #why-keys-first-in-netconf-pdus [20:28:56] same answer - buffering [20:29:00] (welcome, emile) [20:29:17] more? [20:29:24] andy? [20:29:41] no -- buffering is the reason [20:29:49] next! [20:29:51] == Why can't a leaf be used more than once in the same key? == #leaf-in-key-more-than-once [20:29:57] hello every body [20:30:02] I don't understand [20:30:23] what would it mean to say that the key is "ifIndex and ifIndex"? [20:30:37] answer: because it makes no sense to key on the same leaf twice. [20:31:10] i like Martin's clarification [20:31:18] you see it now, lada? [20:31:44] see what? [20:31:45] yes, but I too don't know why someone should want it [20:31:58] it was andy's question. andy? [20:31:59] (sorry, understand the question...) [20:32:17] It is used in MIBs with external keys -- [ addrType, srcAddr, addrType, destAddr] [20:32:33] but we don't have external keys [20:32:34] What does it mean? [20:32:45] In SMIv2 it can be supported -- not really in XML [20:32:51] we have a leaf of type keyref per external key [20:33:00] we have external keys via keyref [20:33:28] can you explain what it means in a mib to key off addrType twice? [20:33:29] SMIv2 stuffs the instance IDs at the end of the OID -- NETCONF/XML has nothing like that [20:33:53] so maybe the question should be rephrased to "How do I do external keys (like in SMIv2) in YANG?" [20:34:17] 2 instances of 1 object type [20:34:18] So the answer is "you don't need to because YANG doesn't need it"? [20:34:21] phil: different instances of addrType [20:34:30] you use keyrefs [20:35:04] I sit accuarte to say that in SMI, we don't have structs, so we have to spell out the indivudal elements of a struct, whereas YANG supports struct-like thinsg, so doesn't do this? [20:35:13] YANG is fine without it -- just thought the Q should be answered [20:35:32] (hang on dbh2, let's get back to that) [20:35:46] As a MIB Doctor, I havbe to admit I don't know what external keys means, so saying that SMI supports external keys kind of throws me. [20:36:18] s/external keys// [20:36:23] [[ I've got a hard stop in 10 minutes ]] [20:36:35] For opthers coming from an SMI background, it will probabyl be less than useful to describe this in terms of external keys. [20:36:36] INDEX { somethingNotPartOfThisEntry, somethingNotPartOfThisEntry} [20:36:36] RMON2 protocolDirLocalIndex -- banned by the MIB Fussies -- put into RMON2 by Steve W just to irk everybody [20:36:52] andy, what do you think the answer is? phil wrote: "it just doesn't make sense, silly" and then we started in on external keys in smiv2, which we support in yang using keyrefs... [20:37:24] let's end this question then quit, phil [20:37:45] that'll be 75 minutes [20:37:47] It is considered bad DM practice to reuse the key name I guess [20:38:00] seems a reasonable answer [20:38:28] So does saying you shouldn't do it qualify as a CLR? [20:38:36] i think we should add a question about "external keys" in SMI and keyrefs for the SMI folks (and get David to help us write it in a way SMIv2 people understand) [20:38:48] Nope, is an FLR (fine little rule) [20:39:17] I meant "clarifyng language rule". of course. [20:39:23] can we do one more? [20:39:26] We have no way in XML to distinguish 2 instances of the same key in a list. [20:39:44] good point, andy [20:39:45] Each key has 1 value, not N [20:40:06] and in YANG? [20:40:15] I can do more than one more question. [20:40:46] Unless you make bits part of a key - then you have multiple values. Can bits be part of a key? [20:41:09] in YANG each key represents a separate leaf. You would have srcAddrType and destAddrType [20:41:20] sure. that's not multiple values. [20:41:27] JS's question needs to go to the list... [20:41:37] if we had leaf-list as keys, that would be multiple values. [20:41:56] So I can't make a leaf-list a key? [20:41:59] no [20:42:04] bits is allowed -- only empty is not allowed [20:42:21] so the only restriction on keys is empty, which leads us to the next question... [20:42:36] ok [20:42:39] one more, phil [20:42:44] 5 [20:42:46] 4 [20:42:46] wait. I didn't understand what answer was reached. [20:42:54] i don't think one was [20:42:56] Currently, you can have bits as a key, since it's one node. [20:43:07] we're not talking about the question, though [20:43:19] we're talking about what is allowed to be in keys [20:43:24] and that's not the question [20:43:35] can you repeat the question then? [20:43:41] I think we have an answer, right? [20:43:45] Move on? [20:43:48] yes [20:43:51] I'm afraid you'll count down while I search for the question. [20:43:53] == Why can't a leaf be used more than once in the same key? == #leaf-in-key-more-than-once [20:44:30] SMIv2 encoded position-dependent instance IDs YANG/XML uses named IDs [20:44:36] the other stuff (about bits, leaf-lists, etc. in keys) is separate [20:44:47] Answer: two identical keys mean the same as just one. [20:44:56] the answer is: it doesn't make any sense. if you're looking for "external keys", YANG uses keyrefs [20:45:09] i like martin's answer [20:45:10] no -- it is an error to list the same key more than once! [20:45:26] yes, since it doesn't make any sense [20:45:30] And the answer is that it makes no sense, since keying it twice would be equivalent to keying it once. Allowing it allows the user to think they are doing something that doesn't make sense, so it's an error. [20:45:31] fine [20:45:34] yes, andy's right (his no was directed at lada, i think) [20:45:45] ok [20:45:58] we have an answer [20:46:08] you're off, phil? [20:46:11] Sorry, gentlemen, but I've got to run. See you later...... [20:46:16] the rest, 15 more minutes? [20:46:16] phil.shafer leaves the room [20:46:20] Yes, I meant I made no sense. [20:46:21] ok [20:46:29] ok.. next [20:46:33] ok [20:46:40] == Why doesn't it make sense to use the type 'empty' in a key? == #empty-in-key [20:46:53] only one value possible? [20:47:04] I think we should change this so it is allowed (yes it should go to the list) [20:47:10] :-) [20:47:12] +1 [20:47:17] no! [20:47:29] I can see it makes sense not on its own, but in combination w/ other keys [20:47:35] it does not translate to CLI or conf file! [20:47:42] It can be a placeholder [20:47:46] then it's like having an int and a boolean [20:47:48] whoa, folks [20:47:59] no more debate on this. [20:48:00] an example where it makes sense? [20:48:12] on the list then? [20:48:12] please, martin, take your proposal to the list [20:48:27] with, as Jürgen suggests, an example [20:48:32] ok [20:48:36]