http://standards.nortelnetworks.com/netconf/ PG 1

Netconf Data ModelNetmod BOF – IETF 60

Sharon Chisholm – schishol@nortelnetworks,com

Randy Presuhn - randy_presuhn@mindspring.com

PG 2

Preliminaries Problem Statement/Overview Charter Discussion

Outline

http://standards.nortelnetworks.com/netconf/ PG 3

Preliminaries

AdministriviaAgenda

Website, Mailing ListBOF Status

Additional Reading

PG 4

Administrivia

Blue sheets Minute Takers Jabber Scribe Instructions to Presenters

http://www.ietf.org/instructions/instructions.html

PG 5

Agenda

1. Preliminaries - 15 minutes2. Problem Statement/Scope Overview - 10 minutes3. Framework for Netconf Data Models - Sharon Chisholm - 15 min

http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-00.txt

4. Netconf Data Model - Sandeep Adwanker, 20 minutes http://www.ietf.org/internet-drafts/draft-adwankar-netconf-

datamodel-00.txt5. Getting to a Netconf Data Model - Andrea Westerinen - 10 minutes

http://standards.nortelnetworks.com/netconf/docs/GettingToANetConfDataModel.txt

6. Netconf Architecture Model – Ray Atarashi et al. - 10 minutes7. General Discussion - 15 minutes8. Charter Discussion and Wrap-up - 10 minutes

PG 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

PG 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

PG 8

Additional Reading

1. Netconf Configuration Protocol http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-03.txt

2. "On the Difference between Information Models and Data Models", RFC 3444 http://www.ietf.org/rfc/rfc3444.txt

http://standards.nortelnetworks.com/netconf/ PG 9

Problem Statement & Overview

Netconf layeringProblem Statement

Building Blocks for ContentStrategy

Requirements & CLRsDiscussed Deliverables

PG 10

Netconf Layering

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

PG 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.

PG 12

Building Blocks for Content

Framework for Netconf Data Models ‘SMI for Netconf’

W3C XML Schema

Netconf Data Types

Meta-model orInformation Model

Standard Data Models Proprietary Data ModelsCon

tent

Too

ls f

or

Cre

atin

gC

onte

nt

PG 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

PG 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

PG 15

Discussed Deliverables

1. Data Types Minimal set of core data types for use in network elements

IP Address, etc2. Syntax

SMI equivalent compliance, backwards compatibility, etc

3. 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

4. Mappings to other solutions, like SNMP

http://standards.nortelnetworks.com/netconf/ PG 16

Charter Discussion

Proposed Charter

Next Steps

PG 17

Proposed Charter

The Netconf Data Model Working Group would be charted to provide an initialframework to create XML data models for use with the Netconf protocol.Abstract information models on which all XML data models would be based mayalso be discussed. The working group will also produce some initial XML datamodels as proof of concept examples, as well as to meet specific industryneed.

The network configuration (netconf -http://www.ietf.org/html.charters/netconf-charter.html ) working group in theIETF is chartered to produce a protocol for network configuration. The datamodels to be used with this new protocol are outside the scope of thatdiscussion. Even though the netconf architecture proposes to be independentof data definition and data model, it is critical to start talking aboutdata models in more concrete terms to ensure there really aren'timplications for either the protocol or the models as a result of combiningthem into system to provide management functionality.

PG 18

Proposed Charter - Continued

In addition, many feel that the identification or creation of standard datamodels for use in netconf is critical for both the success of the protocoland 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 Worko W3C XML Schemao Existing Information Models (SNMP, CIM from DMTF, SID from TMF, etc)

PG 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)

PG 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?

PG 21