Netconf Schema Query Mark Scott IETF 70 Vancouver December

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 Query using 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: New RPC method 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: 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

10