1 / 20

Henning Schulzrinne Dept. of Computer Science Columbia University

XCON data modeling – NETCONF, RDF and others draft-schulzrinne-sipping-emergency-req-01 draft-sipping-sos. Henning Schulzrinne Dept. of Computer Science Columbia University. Executive summary. XCON is an instance of a standard problem  avoid the IETF tendency to create one-off protocols

bikita
Télécharger la présentation

Henning Schulzrinne Dept. of Computer Science Columbia University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XCON data modeling – NETCONF, RDF and othersdraft-schulzrinne-sipping-emergency-req-01draft-sipping-sos Henning Schulzrinne Dept. of Computer Science Columbia University XCON - IETF 62 (March 2005) - Minneapolis

  2. Executive summary • XCON is an instance of a standard problem  avoid the IETF tendency to create one-off protocols • excusable a decade ago, recipe for delay now • Provide both “semantic” (tightly constrained) and user interface-oriented interface • Use XForms where user interface is needed • Consider NETCONF for object content manipulation and state retrieval XCON - IETF 62 (March 2005) - Minneapolis

  3. Data representation models • Document model • structured document • RPC model • set/get variables • Data models • RDF • NETCONF • user-interface oriented XCON - IETF 62 (March 2005) - Minneapolis

  4. “Semantic” description • Tightly described set of properties • No expectation that user interface would directly correspond to each element • No I18N issue  application maps description elements to UI elements in appropriate language • translation into other languages done by client • and may derive some parts through local policy, rather than user input • Well-defined extension policy XCON - IETF 62 (March 2005) - Minneapolis

  5. RDF • “Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web.” • describing resources in terms of simple properties and property values XCON - IETF 62 (March 2005) - Minneapolis

  6. RDF, cont’d. W3C RDF primer XCON - IETF 62 (March 2005) - Minneapolis

  7. RDF/XML example <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#“ xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#"> <contact:Person rdf:about="http://www.w3.org/People/EM/contact#me"> <contact:fullName>Eric Miller</contact:fullName> <contact:mailbox rdf:resource="mailto:em@w3.org"/> <contact:personalTitle>Dr.</contact:personalTitle> </contact:Person> </rdf:RDF> identifies the thing = subject (a URI) property = predicate value = object W3 RDF primer XCON - IETF 62 (March 2005) - Minneapolis

  8. More about RDF • Generally, “meta data” • RSS is most common usage • Also used in Composite Capabilities/Preferences Profile (CC/PP) • Has schema-like capability to describe vocabularies • Allows trees with nodes and relationships (“is-a”, “has”) XCON - IETF 62 (March 2005) - Minneapolis

  9. RDF: evaluation • Good • limited parameter-value expressiveness • type definition • tools available • Bad: • static document, does not define protocol to get/set elements • would need XCAP, XPath or similar XCON - IETF 62 (March 2005) - Minneapolis

  10. NETCONF • “The NETCONF protocol defines a simple mechanism through which a network device can be managed, configuration data information can be retrieved, and new configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal, application programming interface (API).” • http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-05.txt • Defined to run over HTTP, BEEP, UDP, … XCON - IETF 62 (March 2005) - Minneapolis

  11. NETCONF, cont’d. content configuration data operations <get-config> <edit-config> RPC <rpc> <rpc-reply> application protocol BEEP, SSH, SSL XCON - IETF 62 (March 2005) - Minneapolis

  12. NETCONF • Data = • configuration data = writable  <get-config> • state data = read-only, statistics  <get> • Leaves privacy and authentication to transport layer • Supports Xpath and subtree filtering • Supports multiple “data stores” • default <running> • <candidate> allows incremental update + commit XCON - IETF 62 (March 2005) - Minneapolis

  13. NETCONF RPC <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rock-the-house xmlns="http://example.net/rock/1.0"> <zip-code>27606-0100</zip-code> </rock-the-house> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <some-content> <!-- contents here... --> </some-content> </rpc-reply> XCON - IETF 62 (March 2005) - Minneapolis

  14. NETCONF – subtree filtering <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users/> </top> </filter> </get-config> </rpc> XCON - IETF 62 (March 2005) - Minneapolis

  15. NETCONF operations XCON - IETF 62 (March 2005) - Minneapolis

  16. NETCONF capabilities advertisement <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:xml:ns:netconf:base:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:base:1.0#startup </capability> <capability> http:/example.net/router/2.3/core#myfeature </capability> </capabilities> <session-id>4</session-id> </hello> XCON - IETF 62 (March 2005) - Minneapolis

  17. User-interface oriented • Describe suggested rendering on controlling client without client knowing meaning of controls • element names are just labels • e.g., can’t gateway to other systems based on equivalence • user interface can change at any time • Element names are text strings, not XML elements • no schema verification possible XCON - IETF 62 (March 2005) - Minneapolis

  18. User-interface oriented • Client software does not need to understand meaning of terms – just variables and prompts • includes necessary prompts and structure • needs to be translated into different languages by server • Existing work: XForms • http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors • Allows use of CSS to render on variety of devices • Allows use of JavaScript for client-side verification • Specifies type of control (“selection”), not rendering (“radio button”, “select list”) • Suggestion: allow as alternate representation XCON - IETF 62 (March 2005) - Minneapolis

  19. XForms example <h:html xmlns:h="http://www.w3.org/1999/xhtml“ xmlns="http://www.w3.org/2002/xforms"> <h:head> <h:title>Search</h:title> <model> <submission action="http://example.com/search“ method="get" id="s"/> </model> </h:head> <h:body> <h:p> <input ref="q"><label>Find</label></input> <submit submission="s"><label>Go</label></submit> </h:p> </h:body> </h:html> XCON - IETF 62 (March 2005) - Minneapolis

  20. Conclusion • If desired, XForms provides rich user interaction environment • NETCONF provides flexible configuration retrieval mechanism, with extensibility • incremental configuration + commit • stored configurations (startup, running, candidate) • XPath and subtree selection • no constraints on configuration content XCON - IETF 62 (March 2005) - Minneapolis

More Related