idnits 2.17.1 draft-johansson-netconf-owl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2008) is 5890 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 376, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-presuhn-rcdml-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Johansson, Ed. 3 Internet-Draft Stockholm university 4 Intended status: Informational March 11, 2008 5 Expires: September 12, 2008 7 NETCONF Configuration Data Modeling using OWL 8 draft-johansson-netconf-owl-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 12, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document outlines an approach for a NETCONF data modeling 42 language based on the W3C Web Ontology Language (OWL). 44 Table of Contents 46 1. Introduction and Basic Terminology . . . . . . . . . . . . . . 3 47 2. Information modeling using OWL . . . . . . . . . . . . . . . . 3 48 3. Building protocols using OWL and RDF . . . . . . . . . . . . . 6 49 4. Advanced concepts . . . . . . . . . . . . . . . . . . . . . . 7 50 4.1. Your own RDF serialization . . . . . . . . . . . . . . . . 7 51 4.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 7 52 5. NETCONF using OWL . . . . . . . . . . . . . . . . . . . . . . 8 53 5.1. Some of the NETCONF Requirements . . . . . . . . . . . . . 8 54 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 59 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 Intellectual Property and Copyright Statements . . . . . . . . . . 12 63 1. Introduction and Basic Terminology 65 The NETCONF working group has identified the need for a configuration 66 data modeling language . This document outlines an approach to 67 fulfill these requirements using the Web Ontology Laguage 68 [W3C.CR-owl-ref-20030818] (OWL). The OWL can be thought of as an 69 information modeling language with the expressive power of UML but 70 with a comparatively simple textual representation. 72 2. Information modeling using OWL 74 The Web Ontology Language (OWL) is a language for describing 75 information and models based on the Resource Description Framework 76 (RDF). Both RDF and OWL are W3C specifications. The OWL can be 77 thought of as the schema language for RDF-based data in much the same 78 way as LDAP schema is the modeling language describing LDAP-based 79 data. 81 A single OWL model (collection of OWL modeling elements) is called an 82 "ontology" and can be thought of as an OWL module. The OWL is 83 inherently extensible and has the expressive power of common modeling 84 languages like UML but with a much simpler textual representation of 85 models. 87 There are several existing implementations of OWL today all of which 88 support validation of OWL ontologies. 90 The OWL comes in three variants: OWL-Lite, OWL-DL and OWL-Full. A 91 complete description of the differences can be found in OWL Web 92 Ontology Language Guide [W3C.CR-owl-guide-20030818] section 1.1. 93 Most information modeling applications use OWL-DL which has enough 94 expressive power for most modeling needs while remaining relatively 95 easy to implement in modern programing languages. From the point of 96 view of a programmer OWL-DL can be viewed as a OO meta-model with 97 support for multiple inheritance: i.e there is a class concept and a 98 property (aka class member) concept. Classes have class members. 99 Class members (properties) has a domain and a range. The domain is a 100 class. The range is either a primitive type (all XML Schema types 101 are OWL primitive types) or another class. 103 The OWL is based on the Resource Description Framework 104 [W3C.PR-rdf-primer-20031215] (RDF) which provides the data 105 representation underlying both OWL and OWL class instances. This 106 means that an OWL schema (a collection of classes and properties) is 107 expressed as RDF as is any OWL class instance. In other words the 108 OWL is a "self hosting" extension of RDF. There are several ways to 109 represent RDF in textual form: N-Triples, N3 or RDF/XML any of which 110 is able to carry the full expressive power of OWL. 112 Before this gets too abstract we present a small example in the 113 approximate domain of NETCONF: the switch ontology, this time 114 represented using RDF/XML for the simple reason that this alternative 115 is by far the easiest to understand for the layman: 117 118 124 125 126 Example switch ontology 127 128 130 131 132 134 137 138 139 140 141 142 143 1 144 145 146 148 149 150 151 153 154 155 156 158 159 160 161 163 164 This example illustrates a few of the notable aspects of OWL as a 165 modeling tool. We have defined 4 classes - Port, PortCollection, 166 Layer2Element and Switch. A Switch inherits from both Layer2Element 167 and PortCollection and an anonymous class which restricts the port 168 attribute defined on PortCollection to having at least 1 port. In 169 plain English this means that a Switch is a Layer2Element and a 170 PortCollection with at least 1 port. In fact this sentence is a 171 reasonably good "English serialization" of the Switch model element. 172 This can be made more precise by studying the semantic foundations of 173 RDF and OWL. 175 The PortCollection can be thought of as an "abstract" class or 176 interface whereas the Switch is a concrete class which adds 177 specification details to both Layer2Element (which is included here 178 only to illustrate multiple inheritance) and PortCollection. Most 179 modern OO languages are easily able to build models from OWL meta- 180 models - i.e transform the meta-model given by an OWL schema into a 181 native model. This process is especially simple for languages which 182 natively support multiple inheritance in some form or another: eg 183 Ruby, Perl or Python but even more restrictive languages like Java 184 can easily emulate multiple inheritance through the use of the 185 factory/interface/implementation pattern. 187 3. Building protocols using OWL and RDF 189 In the same way that OWL can be used to model information it can be 190 used to model the representation of operations, if not their 191 semantics. This is analogous to using ASN.1 to model both protocol 192 elements and the objects operated upon by the protocol elements. The 193 result becomes inherently transport-neutral: anything which can send 194 messages using any of the serialiations of RDF can be used as the 195 transport of an OWL-based protocol. 197 The mental model to strive for is that the messages transported by a 198 "OWL-driven" protocol are RDF graphs - i.e structured data in RDF 199 form represented using some serialization of RDF (eg N-triples). 200 This graph may support several ontologies (eg multiple versions of 201 the sam protocol but we'll get back to that), i.e may express 202 relationships between individuals of multiple (possibly related) OWL 203 schema. By selecting (a set of) ontologies it is possible to create 204 a native object representation of the message. 206 +------------------------------------------+ 207 | Object | Message abstraction | 208 +------------------------------------------+ 209 | Ontology | Protocol description | 210 +------------------------------------------+ 211 | RDF Graph | Protocol message | 212 +------------------------------------------+ 214 This approach lends itself very well to implementation in modern 215 agile "duck-typed" programming languages but can also be done 216 (typically by employing code-generation) in strongly typed languages. 218 Naturally this isn't the first (or probably last) time a formal 219 language has been used to define information models and protocols 220 with varying results. One notable difference between OWL and related 221 efforts (eg ASN.1, XML Schema, Relax-NG, XDR) is that OWL has the 222 full expressive power of UML which means that there is little nead to 223 "dumb-down" the wire-representation of the objects modeled in the 224 application in order to meet the limitations of the interface 225 description language: i.e the application native information model 226 can be used more or less straight away as a basis for an OWL/RDF 227 model for the applications remoting needs. 229 4. Advanced concepts 231 4.1. Your own RDF serialization 233 Defining a new serialization of RDF is always an option if any of the 234 existing serializations are found to be lacking in some respects. 235 For instance it may be a good choice to use RDF/XML as a 236 serialization for protocol messages but the (lack of) readability of 237 XML may lead one to define a separate serialization for use when 238 defining ontologies for a given application. 240 As long as a full serialization is defined then almost all of the 241 drawbacks of defining a DSL (Domain Specific Language) are addressed 242 without adding too much complexity to a protocol definition or 243 information model. 245 4.2. Versioning 247 Managing multiple versions of the same information model can be 248 challenging. The OWL has a few constructs which helps with this job, 249 notably (again) multiple inheritance and the fact that an RDF graph 250 can support multiple ontologies concurrently. There are also owl 251 constructs such as the owl:equivalentProperty and owl:equivalentClass 252 relationships which allows one (version of) an ontology to be related 253 to another in a mashine-readable way. 255 5. NETCONF using OWL 257 The approach to using OWL as a basis for NETCONF configuration data 258 modeling would be to define a basic NETCONF ontology containing 259 concepts which are common to any NETCONF configuration model. Next 260 define ontologies for NETCONF operations and NETCONF notifications 261 (as identified in the requirements) and finally agree on standard RDF 262 serialiations for NETCONF models - eg use RDF/XML always or use RDF/ 263 XML for protocol messages and a custom serialization (to be defined) 264 for NETCONF models. 266 5.1. Some of the NETCONF Requirements 268 This is not an exhaustive treatise of the list of requirements found 269 in [NETCONFREQS] but rather an attempt to single out the requirements 270 where the choice of OWL has a signifficant impact 272 3.1.1 - Notification Definitions. By definiting a NETCONF 273 notification ontology. 275 3.1.4 - All Base Operations. By defining a NETCONF operations 276 ontology and related semantics. 278 3.1.5 - Define new NETCONF Operations. Define another NETCONF 279 operations ontology extending the base NETCONF operations 280 ontology. 282 3.1.5 - Separation of Operations and Payload. Even if OWL is 283 expressed in RDF and OWL ontologies are by definition valid RDF 284 this won't cause any confusion, mainly because we have limited 285 ourselves to OWL-DL where there is a clear separation between 286 model elements and instances. 288 3.1.7 - Error Annotation. Multiple inheritance allows one to tie 289 annontations in any form to any model element simply by making 290 everything that needs annotation inherit from an annotation class. 292 3.2.1 - Human Readable. Arguably humans can read RDF. If a 293 counter-example is produced then a custom RDF serialiation may be 294 in order. 296 3.2.4 - Document Information. Ontologies have metadata natively - 297 RDF is after all a metadata representation mechanism. 299 3.2.5 - Ownership and Change Control. Everything in RDF is 300 identified using URIs, including the ontologies themselves. 301 Ownership and Change control is exercised via control over the 302 namespaces involved. 304 3.2.6 - Dependency Risk Reduction. The version of OWL and RDF 305 used in an ontology are referenced explicitly by default. 307 3.2.8 - Internationaliation and Localization. All RDF literals 308 are language-tagged by default. 310 3.3 - Resusability Requirements. OWL by construction is modular. 311 References between OWL ontologies (modules) are the norm. 313 3.4.3 - Validation. Validation of RDF against an OWL schema is 314 readily available. Tools for validation of OWL schema can be 315 readily found on the Internet. 317 3.5.1 - Human-Readable Semantics. RDF is based on the notion of 318 statements of the form subject relation object which can be 319 spelled out as propostitions of the form "Something has relation X 320 to Something else". This makes it almost an automatic process to 321 produce a plain text version of an ontology even if readability 322 may require extra effort. Apart from that the standard 323 documentation constructs built into OWL provide means to include 324 documentation in the ontology. 326 3.5.2 - Basic Types. All XML Schema types are primitive types of 327 OWL 329 3.5.3 - Opaque Data. The owl:Thing class is the superclass of all 330 classes. Properties with range owl:Thing are essentially defining 331 opaque data properties of a class. 333 3.5.4 - Keys. Each object in an RDF graph is uniquely identified 334 by its URI. The concept of a key is not native to RDF but can be 335 easily represented in OWL either by using the owl: 336 InverseFunctionalProperty to declare a property unique or by 337 defining a class whose properties are the (compound) key of any 338 superclass of that key-class. 340 3.5.5 - Relationships. OWL supports all types of relationships 341 1:1, 1:n, or m:n. Since all relationships in OWL use URIs as 342 identifiers there is no ambiguity when resolving relationship 343 identifiers 345 3.5.8 - Characterize Data. Define two classes - ConfigurtionData, 346 StatusData with no properties, these classes act as markes on 347 classes allowing an implementation to make the destinction. 349 3.5.10 - Formal Constraints. Support for most of these 350 requirements are either native or can be implemented in the model. 352 3.6.1 - Language extensibility. OWL is versioned and expressed in 353 terms of RDF it is quite possible to extend both RDF and OWL. 355 3.6.2 - Model Extensibility. OWL has native constructs which can 356 be used to express how one model extends, imports and is 357 compatible with another model. This also applies in part to 3.6.3 359 3.6.3 - Instance Data Extensibility. Since the ontology URI is 360 normally part of (as the base URI of) the URIs of the model 361 elements in the ontology it is easy to include ontology version 362 informaiton in all types. 364 6. Acknowledgements 366 7. IANA Considerations 368 This memo includes no request to IANA. 370 8. Security Considerations 372 9. References 374 9.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 9.2. Informative References 381 [NETCONFREQS] 382 "Requirements for a Configuration Data Modeling Language", 383 . 386 [W3C.CR-owl-guide-20030818] 387 Smith, M., Welty, C., and D. McGuinness, "OWL Web Ontology 388 Language Guide", W3C CR CR-owl-guide-20030818, 389 August 2003. 391 [W3C.CR-owl-ref-20030818] 392 Dean, M. and G. Schreiber, "OWL Web Ontology Language 393 Reference", W3C CR CR-owl-ref-20030818, August 2003. 395 [W3C.PR-rdf-primer-20031215] 396 Manola, F. and E. Miller, "RDF Primer", W3C PR PR-rdf- 397 primer-20031215, December 2003. 399 Author's Address 401 Leif Johansson (editor) 402 Stockholm university 403 Stockholm, SE-10691 404 Sweden 406 Phone: +46 8 162000 407 Email: leifj@it.su.se 409 Full Copyright Statement 411 Copyright (C) The IETF Trust (2008). 413 This document is subject to the rights, licenses and restrictions 414 contained in BCP 78, and except as set forth therein, the authors 415 retain all their rights. 417 This document and the information contained herein are provided on an 418 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 419 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 420 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 421 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 422 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 423 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 425 Intellectual Property 427 The IETF takes no position regarding the validity or scope of any 428 Intellectual Property Rights or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; nor does it represent that it has 432 made any independent effort to identify any such rights. Information 433 on the procedures with respect to rights in RFC documents can be 434 found in BCP 78 and BCP 79. 436 Copies of IPR disclosures made to the IETF Secretariat and any 437 assurances of licenses to be made available, or the result of an 438 attempt made to obtain a general license or permission for the use of 439 such proprietary rights by implementers or users of this 440 specification can be obtained from the IETF on-line IPR repository at 441 http://www.ietf.org/ipr. 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 this standard. Please address the information to the IETF at 447 ietf-ipr@ietf.org. 449 Acknowledgment 451 Funding for the RFC Editor function is provided by the IETF 452 Administrative Support Activity (IASA).