OPS Open Area Meeting Dan Romascanu and Ron Bonica - chairing 1. Note well, agenda bashing, note takers, blue sheets - 5 min 2. SNMP to SYSLOG mapping - Juergen Schoenwaelder - 10 min http://www.ietf.org/internet-drafts/draft-marinov-syslog-snmp-01.txt 3. NETCONF Data Modeling Language Proposals - how they meet the key requirements? 20 min each 3.1 http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-08.txt 3.2 http://www.ietf.org/internet-drafts/draft-bjorklund-yang-requirements-00.txt 3.3 http://www.ietf.org/internet-drafts/draft-ersue-netconf-kalua-dml-00.txt 3.4 http://www.ietf.org/internet-drafts/draft-mahy-canmod-dsdl-00.txt 4. Open Microphone - 25 min DR: Dan Romascanu RB: Ron Bonica RP: Randy Presuhn AB: Andy Bierman L: Bernd Linowski LJ: Leif Johanson MS: Martin Storch R: Rohan Mahy DH: Dave Harrington AC: Alex Clemm SC: Sharon Chisholm Phil: Phil Shafer 2. SNMP/Syslog by Alex Clemm DP: I think this is a good idea SC: there is related work in OPSAWG. I think sending syslog is separate from generating SNMP traps, and think there is a problem with layering. RB: as contributor, most implementations generate a syslog message when they send a trap. This does not require an implementation to do anything different than they currently do? AC: no, this is just the mapping. DR: Do people agree this should be done in OPSAWG? DH: I support this in OPSAWG; however, development of SDEs should be considered for a new WG for syslog data modeling since there are a number of SDEs being proposed in various IETF venues. 3.2 YANG in a Nutshell (Phil) -Semantics and syntax slide At the syntax layer, there are more complicated ways of expressing the semantics. To ferret out the semantic from the syntactic format is difficult. There are multiple expressions of the semantics, including odu, validation XSD, etc. -Slide: Easy -Slide: model Yang can be seen as the infrastructure inside a device to build a management plane. Can generate different data models as needed for different nm interfaces Being able to use the IM inside and outside the box gives you a big payoff -Slide constraints If must is violated, the netconf error codes are all encoded in yang -Slide extensibility Conditional augments If augmented internally, the namespace remains the same When augmented externally, namespaces can differentiate base from augmentation -Slide grouping Grouping is represented as part of model that uses the grouping -Slide rpc Defines methods with input and output parameters -Slide tools 2 validators, that also generate XSD Rohan: SMI-to-Yang is uni or bi-directional? Phil: Uni-directional Chris Newman: if a model came from elsewhere in IETF could the data model be translated to yang? Phil: there is not currently a tool for this, but it could be developed. However, we are trying to push people to a common representation (subset) of xml rather than trying to make YANG fit every type of XML/XSD. If the data model is consistent with YANG expectations, this could work; if the data model is not consistent with YANG design constraints, then no. MS: How does translation deal with row pointers and other translations that include OIDs. DP: we can look on the web site to see the answer -Slide unite Emile: is there any plan to have YANG generate to SMI? Phil: this could be done. It is not in the scope of what we want to do now. DH: Translation from SMI-to-YANG-to-MIB would probably not be lossless. AB: protocol creep like rowpointers, etc need to be worked out. That might require a consistent approach to NM Phil: if the way you encode in XSD and my code generates XSD differently. SC: my concern is on the instance naming. The netconf protocol accepts any type of XML. Will this limit the valid XML content on the sire. Phil, DP: absolutely  thats what standardization is about AB: what matters is that there is high level interoperability by agreeing on the knobs RP: I think you may have it backwards. YANG limits the kinds of models it can define, but that does not prevent the netconf protocol from carrying xml models not defined by YANG. 3.1 Using XML Schema (Sharon) (NdLib proposal) -Slide concept Map automatically takes the XML data model to generate XSD -Slide syntax Much of the requirements are met by XSD off-the-shelf tools -Slide DHCP schema Phil: complex types can be extended? SC: yes; it is the preferred way to make things extensible AB: is this a free tool? SC: it is an inexpensive tool used by many people (~$100US) R: it does not need to be perfect XSD; it can be done incrementally AB: it seems like this adds a buy tools requirement to review an I-D SC: this Is not required. You can read the tags directly DP: If you want to use those tools, you can use YANG tools to generate the XSD (Alex continues the presentation) -Slide data definition syntax It has native support for a meta-model -Slide proposed meta-model L: constraints are tied to attributes and references; what can cross references refer to? -Slide reuse MS: inheritance ? how that mixes with xml schema extensions and restriction levels? Is there any semantic link that AC: in general, one would map to the other; you do not have inheritance MS: does this mean the two always have to go hand in hand? TJ: added some clarifying information Alex: -Slide library definitions -Slide reuse of library SC: can you go back and define how relationships are defined? AC: Two different ways to represent relationships? parent/child or constraints -Slide strengths Leverage existing rather than reinventing everything Phil: what does unique compliance model mean? How do I know if a device complies to all aspects of a model? Phil: its not the high level that needs compliance; it?s the leaves RP: I think this approach for versioning is something really useful to get outside the box of how versioning was done in SMI, GDMO, and CIM. This seems to be an O-O approach, and your versioning is a lot simpler SC: a more concise summary is available in the slides posted in meeting materials 3.3 Kalua (Linowsky and Martin) Provides modeling for payload of netconf Tries to integrate IM and DM features in one language -Slide basics Model is expressed in xml XML can generate XSD, which can then be used for validation -Slide features -Slide complex -Slide modules -Slide module releases AB: isn?t releases more of a vendor issues rather than a standards issue? L: we think this better models reality AB: so this is something used by vendors, not SDOs R: if I go from one release to another? If a vendor makes no difference between product releases, does the schema need to be updated anyway? Does release go back, or only forward? L: only forward MS takes over the presentation -Slide classes Phil: when you say attribute, you mean a member of a class, right? Not an XML attribute? MS: yes -Slide class inheritance -Slide reference R: I noticed this does m:m relationships. One of the problems of translating into XML is this creates a tree relationship. MS: the source identifies the key attributes, and a m:m relationship will have a structure in the target definition, so everything maps to the source side of the definition. R: so the managed object has multiple locations? RP: can you represent relationships with more than two roles? L: no we do not support that because most people do not understand those relationships MS: referential constraint is applied on a class level. -Slide calculated Does not impose a referential constraint; it is up to the client to evaluate relationship -Slide typed AB: I am having a hard time comparing the various esoteric features each presentation wants to focus on. 3.4. DSDL Proposal (Rohan) -Slide what is -Slide why -Slide infotype -Slide keys -Slide xslt Back to slide 6 - extensibility To be easily extended, then the design should be broken into replaceable chunks of pattern -Slide met nearly all -Slide schema -Slide semantics vs syntax Phil: bottom-up forces you to lose info translating from syntax to semantics. The uniqueness of keys and keyrefs slides get lost translating to higher-level, right? R: this can all be done using existing tools 4. Open Microphone DR - Strawpoll - Who in room is not an author and has read all documents? Around 8 Who liked the XSD proposal? - 4 YANG - 5 Kalua - 0 DSDL - 5 RP: I raised my hands for different aspects of different proposals I like the meta-model of the XSD model I like the DSDL expressive power without special annotations I like YANG for readability R: I like readability of YANG and versioning of XSD Kaushik: There were aspects of proposals that made sense. Do we look at those aspects and converge rather than competing against Chris Newman: readability of YANG, but disliked some discontinuity between standard languages and YANG; I liked DSDL and XSD because they are not gratuitously different than standards. Can we take YANG and create a mapping between the standard models, and I know how to bring models from other parts of the IETF. RonBonica: I think this might be a beauty contest with two winners - one at a high level, another at a low level for interoperability. Standardizing a mapping between might be best WesH: we started down this path with multiple goals with competing issues. Every one takes a decent step forward. But we need to optimize readability, then taking complexity forward is problematic. I am well-versed in this stuff, but somebody fresh out of college would not be able to read these. As far as write-ability goes, we don?t seem to be going forward for DM writers by adding a huge array of extra fields and relationships. I think this is not going toward improved readability and writability. The fact there are four real proposals is a promising sign. DR: we have asset of core requirements and some extra requirements. We have a group of proposals that meet at least part of the requirements. We will try to get some direct feedback from operators, and try to get the DHCP scenario modeled by each approach and have operators look at them. We can have more discussion tomorrow between 4 and 5 in the IESG breakout room.