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 3 rd -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

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 adapters 2.Resolve open issues – TLS/DTSL – Naming – Standard/Experimental 3.Publish -02 for ratification R

Questions?