Netconf Data Model Netmod BOF – IETF 60

1. Netconf Data ModelNetmod BOF – IETF 60 Sharon Chisholm – schishol@nortelnetworks,com Randy Presuhn - randy_presuhn@mindspring.com

2. Outline • Preliminaries • Problem Statement/Overview • Charter Discussion

3. Preliminaries Administrivia Agenda Website, Mailing List BOF Status Additional Reading

4. Administrivia • Blue sheets • Minute Takers • Jabber Scribe • Instructions to Presenters • http://www.ietf.org/instructions/instructions.html

5. Agenda • Preliminaries - 15 minutes • Problem Statement/Scope Overview - 10 minutes • Framework for Netconf Data Models - Sharon Chisholm - 15 min • http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-00.txt • Netconf Data Model - Sandeep Adwanker, 20 minutes • http://www.ietf.org/internet-drafts/draft-adwankar-netconf-datamodel-00.txt • Getting to a Netconf Data Model - Andrea Westerinen - 10 minutes • http://standards.nortelnetworks.com/netconf/docs/GettingToANetConfDataModel.txt • Netconf Architecture Model – Ray Atarashi et al. - 10 minutes • General Discussion - 15 minutes • Charter Discussion and Wrap-up - 10 minutes

6. BOF Coordinates • Web page • (which has a reference to the mailing list, archives, papers and presentations with proposed solutions): • http://standards.nortelnetworks.com/netconf/ • Mailing List • The mailing list address is netconfmodel@lyris.nortelnetworks.com • To subscribe to the list send an email to lyris@lists.nortelnetworks.com - with the words "subscribe netconfmodel" (no quotes) in the body of the message (no subject necessary). • MAIL ARCHIVES are maintained at the following URL: http://standards.nortelnetworks.com/archives/netconfmodel.html

7. BOF Status • Held Bar BOF for Netconf Data Model discussions during IETF 59 • Mailing List since March 2004 • Three Individual Internet Drafts, one informal discussion paper

8. Additional Reading • Netconf Configuration Protocol http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-03.txt • "On the Difference between Information Models and Data Models", RFC 3444 http://www.ietf.org/rfc/rfc3444.txt

9. Problem Statement & Overview Netconf layering Problem Statement Building Blocks for Content Strategy Requirements & CLRs Discussed Deliverables

10. Netconf Layering Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | <get-config>, <edit-config> | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | <rpc>, <rpc-reply> | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+

11. Problem Statement • netconf working group is chartered to produce a protocol for network configuration • the data models to be used with this new protocol are outside the scope of that discussion. • netconf architecture proposes to be independent of data definition and data model, • need to start talking about data models in more concrete terms to ensure there really aren't implications for either the protocol or the models as a result of combining them into system to provide management functionality. • Need agreed to common ways of specifying compliance, maintaining backwards compatibility, defining relationships, naming, identification, access control, etc. • In addition, many feel that the identification or creation of standard data models for use in netconf is critical for both the success of the protocol and the benefit of the industry.

12. Building Blocks for Content Tools for Creating Content W3C XML Schema Framework for Netconf Data Models ‘SMI for Netconf’ Meta-model or Information Model Netconf Data Types Content Standard Data Models Proprietary Data Models

13. Strategy • Applicable to all content – IETF & Proprietary • Leverage existing technology • Prioritize on delivering the ‘Framework’ Document • Capture requirements without rat holing • Framework • We focus syntax restrictions on those that enable interoperability, implementability, parsability, backwards compatibility, readability, and other 'bilities' as required. • We should do a gap analysis compared to existing W3C XML methods and only innovate as necessary. • We should be careful to not create CLRs. • We should capture both our use of W3C XML methods to meeting specific requirements as well as our own innovations • We should evaluate our innovations for possible inclusion back into W3C XML specifications

14. Requirements & CLRs • CLRs • rules that get introduced with the best intensions, but later are felt to either place unnecessarily limiting restrictions on the solution or waste review cycles to ensure compliance. • Requirements • Necessary to understand to ensure reasonable solution and to form common understanding of goals. • Historically has caused delays or working group death • Proposal • Capture need being met by each introduced portion of netconf data model along with the solution. Benefits include: • Puts requirements in context of the proposed solution which should help keep focus • Documents reasoning behind all introduced rules to hopefully prevent creation of CLRs or to provide the historical context to deal with the in the future

15. Discussed Deliverables • Data Types • Minimal set of core data types for use in network elements • IP Address, etc • Syntax • SMI equivalent • compliance, backwards compatibility, etc • Meta Modeling • Framework to ensure • Consistency, • Constraints beyond syntax • Referential Integrity? • Individual data models combine together into a cohesive whole • Well defined relationships • Solution could range from a BCP or design patterns to a full fledged information model • Mappings to other solutions, like SNMP

16. Charter Discussion Proposed Charter Next Steps

17. Proposed Charter The Netconf Data Model Working Group would be charted to provide an initial framework to create XML data models for use with the Netconf protocol. Abstract information models on which all XML data models would be based may also be discussed. The working group will also produce some initial XML data models as proof of concept examples, as well as to meet specific industry need. The network configuration (netconf - http://www.ietf.org/html.charters/netconf-charter.html ) working group in the IETF is chartered to produce a protocol for network configuration. The data models to be used with this new protocol are outside the scope of that discussion. Even though the netconf architecture proposes to be independent of data definition and data model, it is critical to start talking about data models in more concrete terms to ensure there really aren't implications for either the protocol or the models as a result of combining them into system to provide management functionality.

18. Proposed Charter - Continued In addition, many feel that the identification or creation of standard data models for use in netconf is critical for both the success of the protocol and the benefit of the industry. The working group will complete these tasks: Define a 'Framework for Netconf Data Models' Document [Exact Title TDB] Define a 'Netconf Data Model for system, interfaces and physical entities' The working group will consider existing definitions, including: o Netconf Protocol Work o W3C XML Schema o Existing Information Models (SNMP, CIM from DMTF, SID from TMF, etc)

19. Proposed Charter Goals & Milestones • Done Bar BOF IETF 59 • June 2004 Initial draft of Framework document • Aug 2004 Netconf Data Model BOF at IETF 60 • Sept 2004 Version of Framework document as Working Group document • Mar 2005 Working Group Last Call On Framework document • Oct 2005 Working Group Last Call on Complex Data Types document(s)

20. Next Steps • Do you think this is an area worth working on? • Are you personally willing to invest time providing content, editing, reviewing, etc? • Should we charter a working group with this charter?