Netconf Schema Query

1. Netconf Schema Query Mark Scott markscot@nortel.com IETF 70 Vancouver December 2007 http://www.ietf.org/internet-drafts/draft-scott-netconf-schema-query-00.txt

2. Goal • Add NETCONF capability to: • Advertise list of supported schemas • Advertise supported versions of schemas • Advertise availability/location of schemas • Scope • Response does not return actual schema • Standard retrieval mechanism can be defined later • Does not imply/expect particular schema format • naming and versioning would need to be standard though

3. Why? • This capability would facilitate dynamic handling between managers and agents • allowing manager to better adapt to agents specific capabilities • This functionality would facilitate ‘feature discovery’ by managers based on schemas and versions present on the device at any given time • today most managers use statically defined schema today • or using proprietary schema advertisement • This work compliments other work underway • Schema language (XSD, RelaxNG, Yang) • Standard data models (monitoring schema)

4. Benefits • Manager wouldn’t have to know specific schema of a target device in advance of managing it • Facilitates dynamic data model handling • ideally manager could adapt to advertised capabilities • minimally, a subset of capabilities could be supported based on what schemas the manager can support • Improves interoperability • and should speed integration efforts • Improves backwards and forwards compatibility • Manager better able to manage based on agent’s specific capabilities

5. Overview • Two operation options proposed • Specialized RPC <list-schema> • Query using <get> • Response same for both • Information to identify the schemas • List of supported schema • Version of each supported schema • Information to facilitate retrieval, if required • Location of each supported schema

6. New Operation: <list-schema> • New RPC method <list-schema> • Lists supported schema • optional ‘Identifier’ parm used to query a specific schema • Benefits • Supports dynamic schema queries • Example: new module added to device; agent sends configuration change event to manager • if req’d, manager queries agent for associated schema • manager doesn’t need pre-knowledge of subtree/path • Could provide context sensitive responses • Security requirements may wish to limit advertisement • Better support for hitless schema patching • Minimizes data exchange between manager and agent

7. Existing: <get> • <get> schema list • ‘schemaList’ data model is queried using subtree or XPath filter • Benefits • Does not require a new operation • Depending on the model can achieve most of the same goals as the dedicated operation • Hierarchical schemas could be complex though(?) • If schema to support a particular interface type is located in the hierarchy of that interface type would the interface have to exist before you could query the schema? • What if manager wanted a complete list of all schemas on the device without having to walk the tree?

8. Changes since IETF 69 • Some dialogue on the mailing list but no updates to draft yet • Some points raised to date • Why not add this to capabilities exchange? • want to allow for re-execution during session • Capabilities, schema versions, etc may change in a session • client may only want to query specific schema or none at all • it increases verbosity of the hello message • Not especially concerned today about performance implications; though we do have cases where many short-lived sessions get created so verbose hello message parsing is not desirable • Bigger concern is security implications of exposing this in the hello message exchange • wish to limit access to schema info during the session (ie: limit hello msg contents to reduce security exposures)

9. Next steps • Get alignment across WG on: • Which design option to pursue • Update the draft and publish as working group document • My product is committed to implementing this draft to • help validate the content • to support our hitless patching strategy