NETCONF Light
Motivation
• To support devices unable to implement the full NETCONF protocol
– The “-00” draft noted hardware-based resource constraints (i.e. very small devices)
– The “-01” draft added software-based constraints such as phased development and NETCONF facades on 3rd-party devices (i.e. adapters)
Note: there isn’t consensus on the WG list for recognizing “phased development” as a motivator on IETF standards, thus it’s recommended to remove this aspect from the draft.
Proposal• A YANG module that can be advertised instead of base:1.1
– declares support for the following reduced set of operations:• get-config (without subtree filtering)• copy-config• close-session
– defines the following set of features to achieve equivalency to base:• subtree-filtering• edit-config• delete-config• locking• get• kill-session
All standard NETCONF rules apply, for instance:•If a client uses an RPC that isn’t supported, return "operation-not-supported”•Optional capabilities can be advertised in <hello>
Not a “base” revision
Open Issues
• TLS/DTLS– The current draft notes that:
“it might be necessary to choose a different mandatory to implement secure transport protocol for NETCONF Light.”
• Naming– The name “light” seems diminutive for a definition that may eclipse
“base” in time…– Maybe something like “init” or “lcd” (lowest common denominator)?
• Standard or Experimental– What does the working group decide?
Next Steps
1.Update draft to– Reflect new reduced base– In “Motivation” section, replace phased-development
text with text regarding device adapters2.Resolve open issues– TLS/DTSL– Naming– Standard/Experimental
3.Publish -02 for ratification
Questions?