Minutes from the NETMOD session, 31 July 2008 ============================================= audio archive: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch4-thurs-am.mp3 1. Session started at 9:00, blue sheets were circulated. 2. Agenda bashing - no objections raised. David H: we have two sessions this week. The first session will be higher level abstraction of the documents and how they fit together. Tomorrow's session will be a highly technical discussion of open issues. 3. David Partain presented the WG status: - WG has an aggressive deadline, all work should be finished in September 09 - Architecural document is needed, no draft is available yet, Phil and Ladislav will work on it - YANG draft is in a good shape - datatypes draft is ready for becoming WG deliverable - DSDL mapping draft will be a merger of the two existing individual drafts, to be finished in September 08. 4. Phil Shafer: NETMOD Architecture Discussion: Sharon Chisholm: Since there is no architectural draft, where can contributors send stuff? Phil: To me. Dan Romascanu: The architecture should be described in an informational draft. David P.: That's the plan. David P.: WG has to decide whether to address YIN and YANG in separate documents or not. Andy Bierman (via Jabber): In the use case#2 in th epresentation, How can an agent generate RPC error messages? Tony Finnerty: RPCs were not explained in the presentation. Balazs Lenygel: Isn't it more a question for the DSDL mapping? David P: The presentation is a tutoiral and not fully detailed. Please ask the question on the mailing list. 5. Martin Bjorklund: YANG - A Data Modeling Language for NETCONF Slide #2 Sharon: What are the reasons for and advantages of having modules and submodules? Martin: Submodules share the namespace with the main module they belong to, modules must use different namespaces. This also allows developing big modules in smaller pieces. Slide #7 Bernd Linowski: Can you model a set with YANG lists (unique elements, order not important)? Martin: Yes, that's the default. This is the high level desc, so I haven't shown it. Order by user or by system. Leif Johansson: Is unordered list different from a set? Martin: No, it is the same thing. Wes Hardaker: Keys have to be unique? Martin: Combination of keys must be unique. Slide #8 Leif: Is leaf-list still a set? Martin: Yes. Leif: But it could be useful to have repeated values, for example array of integers with non-unique entries. Andy: Values needn't be unique, there are no keys in a leaf list. Martin: In leaf-lists the value is the key, so it must be unique. A leaf list entry is uniquely identified by it's value. Have to model this in slightly different way if it's what you wanted. it must be possible to manip this list. Whith multiple entries, how will you refer to entries? David P. (as chair): Please take it to the list. Slide #11 Bernd: Inside rpc, can you have typedefs and groupings? Martin: Yang provides locally scoped typedefs and groupings Bernd: Then they can only be used in input part of RPC? Martin: They can be anywhere in the module hierarchy. Slide #12 Leif: Is the YIN representation unique? Martin: Yes, modulo whitespace and namespace prefixes. David P.: The rules how to make YIN from YANG will be in the specification. Slide #16 Tony: Is modularity in YIN different from YANG? is the intention to have mapping into one file? Martin: No, the mapping is pure syntactical, not semantic. It's exactly the same, modules in YIN correspond to modules in YANG, and similarly for submodules. Slide #21 Bernd: The instance-identifier type uses XPath. Another option would be to represent it explicitly with XML structure. Why XPath? Bernd: In yang there's a modeling feature, instance identifier. XML as XPath expression. Another option would be to encode the key value of every element of the path in XML elements and sub elements. Why was the xpath chosen and not something like this which is more xml is since it doesn't require you to understand xpath. Martin: XPath is less verbose. Bernd: But XML is supposed to be generated and read by machines, so it doesn't matter. David P. (to Bernd): good to post to mailing list and offer an alternative text if what's there is not optimal. Not going to be able to do that here now. Offer some examples for us. Suggest the alternative on the list. Leif: Primary reason is XPath is a standard. Leif: Are basic types in yang mapped to XSD types? Is it lossy? Martin: Yes, the DSDL draft have a table that shows the mapping. J?rgen Sch?nw?lder: Mapping of YANG types to XSD will be discussed later on. 6. J?rgen Sch?nw?lder: Common YANG Data Types Sharon: Are these datatypes mappable to XSD datatypes? are the xml, base data types, going to be mappable to behaviour you'd expect from base data types. ints will behave same as xml schema? Data and time will behave the same? Requirement. J?rgen: I propose the mapping be specified in an appendix of the draft, and explain how this relates or not to the OPSAWG-XSDMI defintions. Sharon: I Hope that's primary, The XSD defs used for specifying xml are more important than mapping to smiv2 ints eg. Benoit Claise: If other groups such as IPFIX come up with datatypes that are of general interest, will NETMOD WG adopt them? David P.: Definitely, send suggestions to the mailing list. Andy: I am concerned about duplications. J?rgen: This is a natural evolution, no need to get worried. 7. Sharon Chisholm and Lada Lhotka: Mapping YANG to DSDL Balazs: You have to specify what the DSDL schema is actually supposed to be used for - validation of datastores, get-config PDUs, RPCs, notifications,...? Lada: The output of the DSDL mapping can be used in principle (possibly in transformed form) for all of these purposes. The same question can be posed to YANG itself. Phil: So you can select the form of output suitable for each particular purpose, e.g., via command line options? Lada: Currently no, it would need post-processing using other tools. Command line options only allow you to select which of the schema languages are included in the output. David P: is this code available in what martin pointed to on the web already? Lada: yes. David P: you've agreed to merge two docs and take out the bits that don't have to do with mapping? And you think you'll have that done by September? Lada: Yes. David P: We like you! Lada: It's easy to promise :-) David P: Suddenly we like you less :-) Balacz: ealier we had a debate, what is DSDL describing? Data model or schema for individual ops? You have seperate schema for rpcs, so we get back to that topic. Is this something directly usefulo for ops or conceptual? Sharon: Both in DSDL as well as yang, need to make sure we specify server side conformance as well as client side. Need to specify whether individual content is valid, we need to support both of those. Hope this is supported in YANG as well as DSDL. Lada: Currently tool discards rpc notifications, not good of course, currently output of translation is schema of full translation same as yang expresses in it's main part acceptable to rpc notification. If you want YANG or DSL schema for validating netconf bus, need to apply some transformations to it to do it, but it's quite no problem. Andy Bierman via jabber: multiple roots is OK in XSD. Lada: not in XML, may not map to relative form in xml doc IIRC. Martin: when mapped to netconf BUs everything will be well formed, so there is no stand alone doc containting multiple top level nodes. Back to Balacz's question: what are we trying to define with XML schema? Both? You would have to generate one scheme for top level node and one schema for all the modules, so it doesn't solve that problem I think. Lada: conceptual tree would solve these issues, but need to look for specific examples. Balaj: need to state more clearly how many modules for... Other places one schema per module. State more clearly in next version. Lada: can use output of translator for validating. Phil: you can do it the other way: DSDL decribe a wrapper, but the config in that wrapper, may be easier. Phil: schema describe edit config etc, all the other places we use... Lada: same stuff as expressed in YANG. You will have to extract that part from the main config tree to put optional to all elements. Will require some translation of full schema. If you try to convert straight from YANG, will be no different. Phil: don't know DSDL, but thought you can turn on/off parts of the machinery. Lada: you can use command line options for translator to switch on/off parts of vocabulary. You can get it no problem. Phil: Is there some way to make the content of the rpc section extend a base netconf rpc and then you just add to that with the rpcs defined in the new module. Lada: haven't thought about this. Asked you today about example. Phil: dsdl has that ability: std netconf module describes rpc tags, notification tags, in dsdl generated from yang you describe additional tags to base module Lada: ... Not targetting specific task of validating additional... Phil: that's one of the things I want to validate with dsdl. Lada: me too. I think it's the next step David P: Let's see what they put in the draft and take it from here. David P: the draft will be the beginning of september? David P: So the answer was both, right? with a little effort, both? Lada: Up to us to decide here. 8. David Harrington - Consensus for Adoption of Drafts as WG Items YANG draft - full consensus for adopting. YIN separated from YANG? The chairs read consensus of the mailing list to be that YIN should be kept in YANG spec. A call for objections showed no objections in the room. Separate document for XML mapping? The chairs read consensus of the mailing list to be that the XML mapping should be kept in YANG spec. A call for objections showed no objections in the room. Datatypes The chairs read consensus of the mailing list to accept the schoenwaelder draft as starting point for YANG datatypes. Any objections? No objections. DSDL mapping draft will be merged from the two existing individual drafts, stuff that is not related to the mapping has to be removed. When published, the WG can talk about adopting this into WG charter. Sharon: Should the merged document be submitted as an indvidual draft first: David P.: Definitely, the WG cannot accept it as a WG item without seeing it first. True also for architecture doc. After couple of weeks we'll issue a consensus call to accept the individual draft as a starting point for the WG draft. 9. J?rgen: Data Type Issues David P: ho wmnay people have read this draft? a significant show of hands Issue #1: We have two uri types; the suggestion is to keep it in inet-types. no objections Issue #2: Allow multiple patterns as in XSD? Suggestion: YES Phil: I am for this, and it supports multiple error messages Andy: Get this from ntypes - already supported in YANG Phil: But in a hacky way. No objections in the room to supporting this. Room consensus is to allow it. Andy: This is too complicated. Phil: what's complicated about it? David P: send to mailing list Issue #3: - Define groupings along with types? Suggestion: YES, but be very conservative. Balazs: We should be really very careful with adding groupings. We could be revising the document monthly. Leif: What is the difference between grouping and typedef? Is it the modifiability of groupings? Reusable typedefs are a good idea. But groupings can be modified after definition. David P. No, grouping *currently* cannot be modified according to YANG. David P. (as contributor): I support adding groupings in a separate document as long as they are reusable. If we have things that will be reusable we should put them someplace so they can be reused. Phil: Conservative opinions are hard to get by consensus. How do keep things conservative when we often let things slide. J?rgen: One approach is to require that there be a module using it. David H.: In the MIB world, we have a web page with pointers to reusable textual conventions. That way you do not have the document revision problem. Leif: I suggest a directorate to approve reusable definitions similar to MIB doctors. David P: I like after-the-fact, because that shows it is useful, and possible used in multiple places. Sharon: After the fact it may be too late, Once it is used, it can cause backwards compatibility issues. We need to predict what types will be reused. Andy: Modelers can import just the reusable bits. No objections to adding them; Sense of the room is to support this. Issue #4: - IEEE types: coordination with IEEE required Dan: Cooperation between IETF and IEEE is usually smooth, because there are a number of people here that are also involved in IEEE 802.1, and there are official liasions to and from 802.1. Dan will be the contact person. Dave H: IEEE has adopted MIBs, but has not yet adopted YANG, so this work should be done here. Dan: other IETF WGs are using IEEE structures, so there is good reason to standardize these structures in YANG. Issue #5: Boilerplate information should be similar to IETF MIB modules, where certain information is required: contact information, organization, etc. This can be added once the draft is adopted as a WG item. Not controversial Issue#6: - Introducing other IEEE types, e.g., vlan-indexes. ... We should be sure we need them and what the representation should be. David H.: In MIBs various groups were defining them in inconsistent ways, so the IETF worked closely with IEEE to decide on the representations. Those are the definitnons I suggest be added. Dan: we should look at what TCs the IEEE has added since taking over the Bridge MIBs to make sure what we define is consistent with current IEEE standards and TC definitions. Wes: Publishing the TC-like things in IETF via RFCs is a lengthy process. If we want to make this easier, we should outsource it to IANA, much as we have done with ifTypes. David P: This is a process issue and we would need to talk to the area director Dan (AD hat off): We can outsource it, but should we? Designing textual conventions would have an impact on how it's going to be used. This needs more than one expert's view, and I would be very careful outsourcing this. Sharon: We sould make the definitions URL-accessible. Let's create a NETMOD directory and make sure the URIs resolve to URLs. We discussed this earlier and were blocked because of network traffic issues. We should try to get IANA to provide this type of support. J?rgen: We have to make sure first that we properly understand the process, and the issue might impact our ability to complete the WG deliverables by 2009. This is something to keep in mind, but let's defer it. Wes: I do agree revising an RFC is not that difficult, it is just slow. I would like to avoid the approach sometimes taken with MIB modules, where the TCs are published in little tiny MIB modules. 10. Other Discussion - David P. announced that a NETMOD wiki will be set up where all outstanding issues will be recorded and tracked. And thanks to Henrich. This will document the open issues, and the closed issues. - We will not finish all detailed discussion of issues this week. The chairs propose an interim meeting for October 8-10, on the east coast of the US, to go through open issues and close them. The dates unfortunately conflict with Yom Kippur. A show of hands shows 10-12 people in the room would attend. How many want to attend, but cannot on Oct 8-10? 3 hands How many could attend Oct 15-17 that could not attend 8-10? A number of people said it would make it harder rather than easier. Dan: We have to make sure the the interim meeting will not exclude people from the process. Ask if anybody objects. David P: Does anybody object to holdin gan interim meeting? No reponse Dan: Consider other means - voice or videoconferencing. David P: They are a bit difficult with participants in several time zones, and virtual meetings might end up excluding more people than an interim. We believe teleconferences are viable for editing conferences, but the number of attendees would seem to preclude a teleconference. Dan: Even with an interim, we should try to support alternative methods of participation. J?rgen: Whiteboard is by far the most productive tool. And even if we reach consensus, we still need to take issues to the mailing list. Sharon: We should figure out how to use Voice Conferencing effectively, to help reduce travel costs. Other SDOs are effectively doing it. There are tools to do this effectively. We should not rule these things out. David P: we have not ruled out any tools; the chairs have not discussed the possible alternatives to supplement how we work together. Dan: IESG is discussing this issue right now. They are encouraging the use of teleconferences in the IETF. Andy: what about jabber? David P: It depends a lot on what the interim host can provide for Internet connectivity. David Kessens: Some people prefer to meet virtually. How many would prefer a real face-to-face meeting (about 10), and how many would prefer a virutal meeting (about 5)? Wes: A good option is to combine face-to-face meeting with virtual means. David P: the chairs will try to ensure there are remote options available. Wes: There are some virtual whiteboards available. David P: We are looking for hosts. Please contact the chairs if you think you can host the interim. Consensus was to hold a face-to-face meeting on 8-10 October, venue will be specified later. The Thursday meeting was closed at 11:32. ------------------------------------------------------- Friday Meeting audio archive: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch5-fri-am.mp3 continuing with technical discussion started on Thursday. - Juergen issues on datatypes Issue #6: - ieee types Eric Gray is liaison + Dan 802.1p work is in progress that will redefine the existing Bridge mib modules and TCs. They have also created additional TCs. We should review these and decide which we should adopt here. Bert will send new ieee 802.1 TC MIB module to list - issue 7 Do we make IANA suggestions for namespace names? In MIBs, IANA could simply assign the next number; now we need to provide suggested names to IANA. This is just a procedural issue, so all YANG modules recommend the name for the namespace and the module. Lada suggests one URI for YANG and then subdivide for various groups Proposal to use NETMOD instead of YANG in current draft, so the namespace is not specific to the language used. Sharon: we are already doing some XSD schemas in Netconf Not Content. We should dfeine a tree and subdivide it by content. Juergen does not care so much, except that the name needs to be unique LADA and Sharon to send suggestion(s) to the mlist - issue 8 XSD translation Proposal to add XSD translations in an appendix. Sharon wants XSD types to be baked into the core of YANG, not just an appendix. We sghould not get creative with core datatypes. Juergen: it is about the new types that we create in YANG, should we put the XSD version (generated by aiutomatic translation) in an appendix of the document. This would be a courtesy for people to see them directly in the document Seems Sharon and Lada worry that this is of no use to RELAXNG (and DSDL) Juergen: But that is not the intent. This is for stuff created in the document, not the base types. Sharon: In Philadelphia, we agreed there should be an appendix for the DSDL translation, and I would like to also see an appendix for the XSD Juergen: the DSDL is the outpu tof the DSDL mapping work. David P: this work is about definition of yang types, and this would just be a courtesy to put the corresponding XSD in an appendix. The DSDL work would go in the chartered DSDL mapping document. But we are not chartered to produce a document with XSD, so this is just a courtesy, especially for the XSDMI effort in the OPSAWG WG. Lada: is this complex types? Juergen: Lada: this would not be of use to DSDL Juergen: there are a number of WGs using XSD, and this would also be a courtesy to them. It would help them understand YANG. Lada: We agreed DSDL was the other format we would use. I would prefer to publish the RelaxNG rather than XSD translation, since XSD is not in the charter. Bert: I would prefer it be available in an appendix. We define the rules about how to translate yang to XSD, right? David P: No. we are not chartered to do XSD translations. This is a simple automated translation for Juergen. Lada: I recommend doing both RelaxNG and XSD in appendices. Bert: that would be OK with me. Juergen: is there a tool available to translate to relaxNG? I do not want to have to manually add translations David H: I recommend the top of the appendix state that this is not within the scope of the WG, is non-normative, is provided solely as a courtesy, and the appendix might be removed in the future. - issue 9 - document differences Juergen wants to be very clear about the differences of the yang types and their SMIv2 'equivalents'. 3 examples discussed/presented Sharon: there is not much value to move away from the existing base/core XSD and SMIv2 types Juergen, it depends on each datatype that we look at. The Date-and-time case is clearly one where we want to deviate and use the IETF agreed RFC3339 concept. So we need to take this to the list on a case by case basis and be precise about how and why it differs. Sharon: there is not muchg value in doing SMIv2 compatibility David P: There is definitely value in preserving the information models that operators already know. Consensus call: Leif agrees as long as we also have a "faithful" definition for the old/existing SMIv2 types DBH: didn't we already discuss date-and-time on list? Isn't that a closed issue? as new chairs, we really want a chance to use our power to say "that issue is closed" ;-) Wes agrees that it is mandatory to describe/document the differences for those that we take from base XSD. We may end up defining a lot of little spcial datatypes that we would better use the standard XSD types for - issue 10 translation rules Juergen suggests to add disclaimers for bidirectional and unidirectional translations. We should be precise about which might be useable in a bidirectional way, versus unidirectional Sharon: why is this different than issue 9? Juergen wants to be precise (it is one para for the whole document). This would be described, maybe in a table, that says this type allows bidirectional mapping? dbh: are you suggesting adding a field to mark a dataype as 'equivalent' Juergen: we must define 'equivalent'; a table that says these are equivalent is all we need. Sharon still thinks this is a duplication of issue 9. Can you submit text so we can consider? Juergen: it is certainly related David P: any other comments? I think looking at the text is fine. Go ahead and add this to the document so we can consider it. - Martin YANG Open Issues -Controlling features 4 slides optional-to-implement features need a complete module for the data this could result in many small modules The capability list will be very long Proposed solutionL 2 new statements (feature and if-feature) and add an rpc get-features. You can turn on/off different features. DaveParain (DP) is this sort of an #ifdef? dbh: instead of if-feature can you use when-feature (for consistency) Martin: it is a bit different though ("if" is a compile-time decision, but "when" is a dynamic runtime decision) Lada suggests that "when" becomes first class. Using when to test for a static state (feature is/is-not supported) Martin: That is a different issue though. DP: let us not worry too much about the name now, but if we need the feature BL: thinks the idea is great, but objects to the special rpc. We should just use a simple get to determine what is supported. and objects it to being when-feature; DBH: we need to be watch out for too-many optional things. There was a discussion in SAAG ysterday about why IPsec VPNs have been less successful than SSL-VPNs, and once consieration is that there are so many options in IPsec, it is difficult for operators to deploy. If we add to many switches that vendors can turn on and off, or choose to support features or not, then netconf may become too difficult for operators to deploy, and they may just ignore netconf. The IETF is about developing interoperable vendor-neutral **standards**, and going down the road of making it easy to have lots of optional things hurts interoperablility and is going to hurt our long-term effort. DP agrees to some extent. But there is the reality vendors will also use this language and some features may apply to some devices and not others. This will eb useful to write one module that has conditional features, and the same module can be used by different divisions in the company, with different features enabled. dbh: just watch out for deployability mark: to respond to David's comment, we tend to do this with sub-modules rather than large modules with lots of conditions. Andy: is if-feature top level or nested? martin: it can be nested. If you go back a slide; oh, it is top-level. mark for andy: can you import a feature across modules: martin/dp: not sure. good question, but no answer yet Mark: I think Andy might be asking if Leif: maybe it is usefull to point out (in doc) the difference between compile time and runtime agrees with dbh that there is the risk of feature creap but you will need a feature rich language if this YANG is to be usefull acroos IETF/Internet we must decide if we want a really scaled down language or not Leif thinks you will need it DP: concludes that Leif supports the feature Leif: sort of. maybe better to be a compile-time evaluation. you need to clearly spell out when something is a compile-time versus runtime decision martin: ok need to be more clear in the document what this is Phil: it is both compile-time and run-time it may be compile-time on the device, which might support ethernet but it is runtime on the netconf server which needs to determine the ifType to see if the device supports it. on the application side, you need to query what is supported to know whether to apply the application logic. Leif: that tells me you really need a sort of a class-member concept, so you can apply compile time optimizations. so it needs more thought how we design this optional stuff I think the feature is nice, but it needs more thought. phil: support this feature two other WGs who are developing yang modules need this this is somewhat more rope, but not too complex dp: we must be carefull what we throw in. This looks reasonable to me it is a balancing act phil: it is a balancing act. You don't want to add sharp knives everywhere, but if you need a sharp knife there is no substitute. sharon: we have the concept of conditional conformance in our company schema definitions, but we find this can be done through nesting rather than needing a tag on individual elements. sharon for andy: could be handled via conformance instead of inline if-feature sharon: in my company, we found maintaining MIB conformance information in two different places within the document (the object definitions and the compliance groups) was a maintenance nightmare. martin: responding to your comments about maintaining the information in multiple places, in a container example it applies to whole container sharon: but you could, and if you make this available then it could be abused. Adding too much complexity into the model is something to be aware of. andy: how does renaming and capability into a feature really help? martin it is not really naming. It is given a capability, you can go look at sub-features for this capability. dbh: so the features would not be exposed in the capability query? martin: no, the capability is exposed and then you can go back and query the features in the capabilities. marting: we could just stick with the capabilities. However, ipfix has multiple optional pieces, and reporting every little feature makes getting a general capailities statement more difficult. It capabiities reports the general technologies available in the whole configuration, then an NMS interested in ipfix can go query for the ipfix features withuot having to get a full report of all the features supported for all the technologies on the device. sharon: I think understanding the feature set is important. As we move away from just doing device management to doing capability-based management, an NMS needs to know what sort of real world technologies the device supports so it can determine how to manage them. So it's not just a mattter of the schemas. It is translating from the schema lists into an understanding of what sort of real world technology things does this thing support. andy: agrees with DBH: try for a first solution that covers 80% of the needs. Capability+features leads to confusion. martin: problem is that WGs are starting to use this and run into problems right away. Should we just ignore them or try to address this? sharon: I think we need to consider this more. JS: is feature same as OBJECT-GROUP in SMIv2 that is optional in COMPLIANCE statements martin yes it solves the same problem: So then JS thinks it is good BL: I want to get this clarified. Can features change during runtime? Likes it. This is more fine-grained than capabilties. He does not want capabilities for each leaf Andy: This is a slippery slope. We will be adding if-if-else-if-else in a few minutes when we realize this form of macro is too simplistic. Phil: the choice is to make it a first class feature or not or 2nd class xpath-function based thing, where you can add ands, ors, and nots, which makes it both more flexible and more difficult to understand. So I would rather have this as a first-class if-feature DP: we do not have consensus yet, but the room seems receptive. Need to work it out on the list - IMPORT by revision this has been discussed on the mailing list already. let me recap. currrent mechanism: once a grouping or typedef is defined it can never be changed. Non-backwards-compatible changes could require a namespace change. suggestion for solution: allow an optional import by revision, so you specify which revision you want to import. Then you know just which version of a grouping your module will use. I would liek to add this. sharon: You don't need this if you have good backward compatibility rules. This is bad thing. And having optional content in a grouping makes this a more interesting problem. Martin: even with conditional content, you will need this. sharon: I am thinkin gbaout relaxng, and I don't see the need. Is there something about yang that makes this more necessary? martin: this is when a whiteboard would help. It was discussed in depth on the ML. Phil gives an example why this is good. Your device code imports a grouping that has one element. The grouping gets revised with a second element. My NMS imports the module with the revised grouping and thinks the device supports the new element. When the NMS tries to set the new element, the device core dumps (or whatever) Sharon thinks she needs to reread discussion on list Leif: this not a technical problem. It is a core engineering issue. Be conservative in what you send iand liberal in what you accept. You need something like this because you need to have code freezes. maybe you can do it by carefully enginreering the namespace Sharon: I DO want to get away from revision-based management Lada: IN the XML world, there is a controversy of whether to change the namespace or using a revision. DO not change the URI for every revision. WE should define the rules under which the namespace should change. And not change the namesapce too easily martin: I agree. we have not yet started writing the upgrade rules yet. Bernd: basically supports the idea if this defines different versions of a device in the network. Some difference smight be backwards compatible, while other changes are not backwards compatible. So I would like to clarify the semantics for revisions JS: this depends on the change rules that we come up with if can manage to avoid this I would prefer to avoid it. it depends on the changes rules andy: if module A imports module B and module C.1, and module B imports C.2, it that an error? (see jabber log) Bernd thinks it IS an error Martin thinks it is not Martin explains how IMPORT works... seems argument goes away. There is no recursion during imports. sharon: I can see where this could lead implemnters to do the wrong thing. Phil likes this DP: need to keep this in lock-step with comformance DP: there is no consensus yet phil: the lock-step issue is real simple. without versioning, you cannot change something once it is defined. andy: Not true Martin. uses stmt can cause this to be a conflict in A. DP: Andy pls send to mlist so we can further discuss - Revision Issue Should the revision statement be mandatory also unresolved on ML. Important for schema discovery and import revision. Currently you can not have a revision statement. Proposed solution is: make it mandatory. Bernd: supports it. You MUST have this. There is no such thing as a module that simply exists; it is always relative to the time that it exists, and you have to . Sharon: This is siilar to the REVIION clause in SLIv2. Hates that she needs to add this. It feels like a CLR, espeically in the presence of diff tools. I do not see the value JS: Thinks it is very useful. it helps identify which RFCs preceded it. DP as contributor: it is abolutely needed Wes: Could do it for IETF documents, but maybe we do not need it for vendor specific. Why force vendors to add it? Andy: import by revision is less painful... (see jabber) Lada: perhaps it could be namespace and then maybe it should not be mandatory in such cases. would not make it mandatory JS: if you have 2 modules that seem the same, then a revision helps. Bert: why are we even discussing this? how difficult is it to add a date string? DP: Humm for consensus seems a rough in favor. Take it to list - Revision is currently a date string some want more than just a date; they want a time too. Proposal is to keep it the same DP wants to keep it Dan: we have date/time in SMI. Seems fine Phil: would it be acceptable to have :stuff Leif: was gonna make same statement.: just make it an opaque string JS: Likes just the date If that is not acceptable, then I would prefer just a number (I cannot do anything with an arbitrary string Dan: It should be sortable. Prefers date and time Bernd: we must have this. But would be happy with an arbitrary string Andy: it is useful to know which is the older/newer revision Bernd: and what branch DP: don't want to rathole on this anymore; take to list - LADA on DSDL open issues (the first few slides are tutorial in nature; issues start at slide 6 - slide 6 (rpc and notification) rpc and notification statements define content of specific netconmf messages options: - generate multiple separate schemas... - one schema with multiple parts... proposal is 2nd one with special NETMOD-tree namespace Sharon: Which use case are you focusing on? is this full-schema validation, partial schema validation? get response validation? are you proposing a single DSDL schema with conditional parts depending on the operation? lada: yes, I would like one schema with all the information from the yang module, that can be used for multiple use cases. Phil: Yesterday we talked about making a base netconf DSDL module, and then the output of the mapping be an extension to that base. The DSDL base would include an rpc element. The DSDL output would define addition extensions to that base rpc mapping. That way you have both a consistent hierarchy and additional schemas. Lada: so we would not have an artifical root; we will use the netconf root to the hierarchy. Phil: that way you could generate for your configuration the valid content for both the configuration itself plus the edit-config, etc. Sharon: Maybe a third approach is to generate two schemas - one that is the most straightforward - defines the config datastore like a MIB module, plus a second schema document with a protocol operation mapping. Exactly 2 documents, no matter how many rpcs we have. I don't want users weighed down with lots of additional schemas. There seem to be no objections now. So take it to the list - slide 9: extension - need to know the semantics of extensions before we can translate them into the relaxNG schema. so maybe make a decision later. for now ignore extensions until we have some real world experience phil: so do DSDL provide hooks for constarints in other namespaces? lada: yes you can do lots of things in annotations. Some tools can be developed to understand the different types of annotations. phil: can I procvide a hook to routines in my code to force my constraints? sharon: wants to see the details of the issue, but thinks that this is possible in Schematron phil: do you want real world examples? DP: take it to the list - slide 10 (augment) - YANG issue: suggestion to clarify where the augment applies (ie. to which import) - not clear what to do in some case (see slide) - proposal: for now ignore top-level augment Andy: this is the only way a vendor can extend a module (see more in jabber) BL: we abdolutely need thie top level augment LADA: yes, but it can be done in a different way, like a vendor includes the standard definition and them modifies it. I don't know hwo the current augment can be translated into DSDL phil: I'm not a DSDL guy, but can't you use pattern replacements? lada: but I don't have the stuff in the foreign module, and I cannot import the foreign module. phil: so you cannot parse the foreign module and know how to augment? lada: we could generate the foreign module as is Martin: You can only add to top-level elements in RELAX, so the schema would have to be very flat. phil: you can only add things at the highest level granularity of the DSDL, but you can make the assumptions about the first DSDL module was generated, but we have rules that can state . lada: for purpose of name mangling, I need to bring all types of ... to top level so things can be mangled. DP: pls send mail to the list to explain the issue more and offer alternatives solutions for discussion lada: I would like to propose this augment become a part of YANG issues. Martin has this also on the list of YANG issues - slide 12 (No Root Elemenmt) - conceptual tree would solve this; propose adding conceptual tree phil: pls explain what 1st sentence in 2nd para means it seems the tools are not in sync with the RLAXNG authorities if reusable shemas are a common practice, why would the relaxNG authorities endorse it? Sharon: it shows up more as a warning than an error. If there is a problem with the thing being imported, the tools can still validate the importing module with just a warning about the imported schema. lada: essentially resolved. - slide 13 andy: are you suggesting to add an element in XML netconf PDUS? lada: no, the cnoceptual tree is just a helper to have an exact representation of an XML instance that is said to be valid. - slide 14 (Xpath and Namespaces) all names in "must" must have explicit full names. phil: that will affect the readabaility; I would rather see the tools do the expansion. lada: But if we do not do the expansions in the spec, then it will be invalid XPath. phil: so we need to define the context or rewrite the XPath during translation to DSDL. lada: the name without the explicit namespace means that the name belongs to the default namespace. DP so we need more words in YEAN spec to clarify this. lada: not sure this will/can fix it JS: phil and lada, pls both point to the specs where you believe it is right or wrong so that we (others) can check nad make up our opinion - Martin on more YANS open issues - slide 14: server variance martin: concern that including such specifics in the schema is very complicated (backwards compat, etc). sharon: other solutions outside schema are being used, may not be needed in YANG at all. suggest defer the whole feature: concern this could complicate YANG such as to slow the timeline JS: this sounds like yang 2.0; we should defer this work. Andy: agree - slide 15: server supplied values Phil: so this can be done indepndent of th emodel. We can publish 1.0 models, and deal witht the variances later. - slide 16: server supplied defaults there is no formal way to specify that the server will define a default. this can be in the description clause, or in a formalized field. DP slide 14-16 needs to be broken down in bits and pieces (even though they hang together in a way) so we can discuss them (hopefully) more easily sharon: so there should be a get config and get-config with defaults. In practice, some defaults are calculated at runtime. JS: we really need to be careful about what is in scope and what is not, if we want to finish in september 2009. With a CLI, you do not get all these details modeled. we don't need to do them now. martin: working with other WGs, they asked these questions. we need to be clear what we do and do not support in yang. Phil: but the slide presents the model of how to make models. We have deviations that can be documented ahead of time, deviations that we can provide defaults for, and things that servers do that will anger everybody. BL: most of these are server variations. But default are specific. Would like a simple statement: what can we do without going down the slippery slope that woudl delay the deliverables. DP: take it to the list - slide 17 multiple patterns skip this slide Andy" must align with how XSD processes patterns JS: we will do exactly what XSD does - slide 18 conditional content using "when" issue not resolved, there was discussion on list JS: like to see a more concrete proposal and like to know what pecicesly it menans sharon: this type of conditional should have no negative impact on Schematron lada: this can be added everywhere where you put augment andy: .. see jabber - slide 19 Why contrain keyref (mailing list raised issue) - propose: make it possible to mark a ketref to allow unsatisfied reference. Details TBD Sharon: wants an answer why she is not allowed to reference static information (??) Need more time to discuss this on the mailing list Sometimes posting to nonexisting things is OK, other times it is not Phil: if you allow to become invalid over time, how do you deal with that? We're out of time. Rest needs to go to mlist - BL: Wants a new feature: Netmod-actions RPCs and Notifications in YANG lists issue 1: see slide issue2: see slide issue 3: see slide Solution: RPCs defined in Lists Sharon is not too supportive of this wes: is OK with putting it inline. But got to be wrapped in a sort of "this is rpc tag" it is DP: pls turn slide set into text and send it to mlist - BERND: Netmod Augmentable Groupings - lada would it be an option to make it a substatement of import? - bernd: cannot say yes or no at this point DP: pls turn this into text and send to mlist as a suggested addition to Yang DBH: would be wonderfeature if I were developing product code but we are developing a standard and we need to "fix" a lot of things for that. people seem to want to add feature that let them change things after the fact. We should not make things so flexible that the standard makes no sense anymore. This is a generic comment about proposed features. DP reality needs us to be flexible. Mehmet: do not see the problem. This is a way to reduce development effort does not break any standards development DP we're out of time Andy: agrees with DBH: complicated to implement and use safely Leif agres it is complicated and dagenerous but you will need it pls go read a book on oo-programming Mark: The last 2 proposals could solve some real problems I am facing today phil: worries about mis-use (if not used correctly) DP: we're done. Thanks all. Sessions were successfull. Appreciate technical dialog. there is a tentative plan to have interim 8-10 october. Things will be divided in current issues and new features. Preference to get current things done fist. End of session