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?