XSD BoF notes - July 26, 2007 Notes by Andy Bierman goals: - need for MIB access? - need for XML and XSD representation? - background - start with separate data and protocols - then developed modular data models - case for MIB access - 20 years of MIB and instrumentation development and should not ignore it - not cost-effective to redo this work - great value in interoperable data, such as counters for specific error conditions - case for XSD/XML access - around 2006, strategy for multi-protocol; right tool for the task (SNMP, NETCONF, syslog) - NETCONF could be the convergence point, since it has notifications and can also access MIB data - need to convert SNMP varbinds (type, OID, value) to XML elements (tag, value) - the data type is always string, need the XSD to determine any more data type information - MIB data is validated via MIB module - MIB data encoded as XML is validated against XSD - similar validation problem converting MIB data to an SQL database; XML to SQL conversion tools exist, and it would be useful to leverage those tools - SNMP has strict security requirements; cascading vulnerabilities can occur if there are other protocols that can access the MIB data with weaker security than SNMP - operators can configure access control rules for access to the MIB data; other protocols that access the MIB need to respect the operator-configured access controls - if VACM configured by an operator, then that configuration should be enforced by other protocols that access MIB data as well - should a WG be formed? - could be independent submissions - not all documents presented should become WG documents - should use libsmi since it is already done; not clear how widely used libsmi is - romascanu-datatypes should be used to map SMI data types and some important TCs - a WG would produce documents with wider community input than if it was done as individual RFCs - need more XSD expertise to finish these drafts - many protocols using XML and MIB access via XML should work for any of them, not just NETCONF - XSD must reflect all the restrictions that SMI can describe - should try to get read-only access first, then try read-write later if needed - proposed documents - XSD data types for management information - combine SMI and important TCs in one document - need to decide what to translate from the SMI to XSD - security requirements for MIB access - decide on cross-protocol security requirements - decide if new protocols need to be as strict about security as SNMP; many new protocols not required to have access control for example; - should decide based on current operational needs, not what was done in the past for SNMP - accessing MIBs using NETCONF - assumes protocol extensions are needed, but not clear; - perhaps map to existing protocol operations could be done instead of creating new operations - should be done in NEE WG - resources - need authors, reviewers, and prototype implementers - this WG would focus on defining the requirements for multi-protocol access to MIB data (not just NETCONF) but not actually define a solution - this work could make it easier for NETCONF newbies to understand NETCONF, XML, and XSD - (Andy B.) concern raised about specific protocol operations impact on the SMI data model conversion >> Yan Li slides on 3 drafts - data types based on RFC 4181 (list of common TCs) - shows mapping of some SMI types to XSD types - hardwired SMI syntax would get mapped to a string with patterns in many cases, such as addresses - OID data type maps to anyUri (Xpath string) - need to determine exactly what gets mapped (OID or something else) - problem data types include TestAndIncr, RowStatus, and StorageType - (Sharon C.) comment that romascanu-datatypes is more NETCONF specific than the SMI to XSD conversion document - SMIDUMP document - data type conversions not exactly the same as romascanu-datatypes mappings - SMIdump XML instance document structure described - scalar objects - row index components as attributes - row columns as elements - motivation - need NETCONF data model now and this will get some standard data models sooner than any other approach - accessing MIB approach - use smidump format - use new capability - use and operations - open issues - vs. - max-repititions - comments Andy B.: how much SNMP should be in the solution? don't want OIDs, max-repetitions, etc. Sharon: agrees, no VACM, etc. part of the solution Bob Natale: wants to have a protocol-indepedent WG did you look at schematron drawings as a mapping source? No. - review of proposed charter http://www3.ietf.org/proceedings/07jul/slides/xsdmi-0.txt use case 1) take SNMP concepts and use them in other protocols use case 2) access MIB data with other protocols Bob Natale: what is the difference btween these 2 use cases? (1) seems to be a subset of (2) Dave H. (1) could identify and focus on problem areas like a RowPointer translation in different protocols use case 3) security requirements; not a solution; just understand the protocol-independent threat model use case 4) special verbs for NETCONF access to the MIB could be done in NEE WG - comments Sharon: issue of NETCONF read-only access to MIB data comes up should not be the only NETCONF data model, which should be independent; Don't want SNMP imposing requirements on the NETCONF solution; general OPS area could work on security requirements. Andy: want specific solutions to progress; data naming and data organization will be protocol-specific Sharon: Dave: customers hate OIDs; developers convert in the SQL database to another format. But cusomer sometimes needs to see the OID to verify the data is exactly what they expect Dan R.: Are these charter timelines based on need for more editors? (yes) These are supposed to be proposed standard, but this is a general approach, so how can interoperability on the wire be tested? Bert W. : SMI as example, does not have to be on-the-wire to be standards track Combine data types and TCs in 1 document Sharon: NETMOD views romascanu-datatypes in its scope not this WG. Concern about document ownership Dan R.: not a problem merging 2 documents (data types and TCs) Concern about theoretical natue of work and not focused on a protocol solution; 12 to 16 months may be too much time; need more resources to finish faster Andy: want datatypes work done ASAP; could split work into pieces, not all-or-none Dave Perkins: wants database types to be considered in conversion Naming mapping is hard. Dave Poll: data types work should be done? (13 for, 0 against) Balazs: Concern that data types would be limited to only these datatypes. Sharon: forbid people from editing translation output in the IETF (want just algorithmic translation) Concern about too much time debating how to tweak the translation? Ron B,: How many people will be willing to work on these documents themselves? (31 people in the room, 1 on jabber) Dave Poll: MIB module translation to XSD? (9 for, 0 against) Dave Poll: Sec. Req. for accessing MIB data? (3 for, 4 against) Dan R: 29 people, if you take out responible AD and IAB member present. Dave Poll: Who is willing to write the documents? (1 - Bob Natale) Dave Poll: Who is willing to review the documents? (many) Bert, Andy, Samanth, Benoit C., Paul A., Sharon, Dave Perkins, Dave Partain, Balazs, Martin, Juergen Q., Bob N., Mahmet, Hideki Dan: Ron is concerned about not enough resources to form a WG right now. Continue comments on ops-nm list. Dave: Concern about doing work in other WGs that have too much focus on NETCONF, rather than protocol independent