1. 1 Weijing Chen wchen@labs.sbc.com Keith Allen kallen@labs.sbc.com XML Network Management Interface (draft-weijing-netconf-interface-01.txt) NETCONF Interim Sept 8-10, 2003

2. 2 Operating and Data Model XML Schema: Standard CLI Proprietary Interface Components: Protocol Operations: Message XML Schema, Capabilities XML Schema Protocol Transport: SOAP, WDSL, HTTP, BEEP, SSH Operating XML Schema More general purpose More specific

3. 3 Processing Flow: XML Schema Validator XPath Parser Protocol Message XML Schema Operating/Data Model XML Schema Device Infoset XML Document Application w/ XPath w/o XPath Error Condition XSL Processor Web-based Application XSL Template Note: In additional to structured document (text), XML provides rich set of tools to easy application and presentation development.

4. 4 XML Schemas Operations.XSD Type: Action (nop/create/delete…) Category (all/config/state) Element: get-request any get-response any perform-request any perform-response any abort-request abort-response any notif any notif-confirm any Capabilities.XSD Element: capabilities notification yes,no model-schema URLs notif-schema URLs Operating.XSD Element: device candidate-config source locked-by any startup-config source locked-by any running-config source locked-by any named-config source content

5. 5 Protocol Operations: get <get-request messageId="message id" category="all/config/state" subordinate="all/direct"/>... any <get-response messageId="message id">... any... any... any

6. 6 Protocol Operations: get config <get-request messageId= "105" category="config" subordinate="all/direct" xmlns=operating.xsd/> <running/startup/candidate xmlns=example.xsd> any <config xmlns=example.xsd> any text/xml

7. 7 Protocol Operations: get state <get-request messageId= "105" category="state/all" subordinate="all/direct" xmlns=operating.xsd/> <running/startup/candidate xmlns=example.xsd> any <state xmlns=example.xsd> any text/xml

8. 8 Protocol Operations: perform <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/>... any <perform-response messageId="message id">... any... any... any

9. 9 Protocol Operations: perform (edit config) <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/ xmlns=operating.xsd> <running/startup/candidate xmlns=example.xsd> any <config xmlns=example.xsd any

10. 10 Protocol Operations: abort <abort-request messageId="message id of targeted request"/> <abort-response messageId="message id of targeted request">... any... any... any

11. 11 Protocol Operations: notification <notif messageId="message id">... any <notif-confirm messageId="message id">... any... any... any rfc3195 match- expression

12. 12 Protocol Operations: copy config ftp://example.com/configs/testb ed-dec10.txt text <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/ xmlns=operating.xsd> <named-config action="copy" name="ftp://example.com/configs/test bed-dec10.txt"> running

13. 13 Protocol Operations: delete config <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/ xmlns=operating.xsd>

14. 14 Protocol Operations: lock, unlock <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/ xmlns=operating.xsd>

15. 15 Protocol Operations: commit, discard-change <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/ xmlns=operating.xsd>

16. 16 Protocol Operations: validate <perform-request messageId="message id" transaction="stop-on-error/ continue-on-error/ rollback-on-error"/ xmlns=operating.xsd>

17. 17 Protocol Operations: rpc vs. request/response, no kill-session, code in the response no progress

18. 18 This draft vs. WG I-D General vs. specific –No assumption about the device except it must be IP-capable. –Vs. Route-like device Explicit vs. implicit –Option is explicitly stated by XML schema. Operating.XSD –Vs. option is implicitly inferred from URL. http://ietf.org/xmlconf/1.0/base http://ietf.org/xmlconf/1.0/base#lock http:/example.net/router/2.3/core#cool-feature Formal vs. informal –Protocol message can be validated by XML schema. –Vs. whether a device supports an option cannot be checked by XML schema. It must be checked by upper layer application through capabilities URL inferring.