ryandgoulding/Netconf Usability And Robustness Discussion Summary

## Netconf Usability And Robustness Discussion Summary
High level discussion summary:

* Distinguish between NETCONF protocol issues and YANG schema conformance in the payload.
* Loose mode for both is strongly desirable.
* Especially to support devices that may not yet have a model, or it's known to be incomplete.
* For schema conformance loose mode, consider making it a per-model tweak.
* Loose mode should only apply when violations are not structurally ambiguous. Data that cannot be deserialized by a reasonably tolerant parser should always be rejected. This means bad XML (syntactically broken - unbalanced nesting, missing >'s and so on) should probably not be accepted, but semantic issues (not passing yang schema checks, like elements not passing type tests or whole data structures not being defined in the schema at all) should be tolerable. Likewise NETCONF transport issues that are not ambiguous should be tolerable too.
* ODL northbound should always be well behaved; passthrough must be carefully considered, possibly with a separate endpoint (to make its use explicit in apps)
* Expect end users to come up with esoteric conditions down the road; when stuff is in production things need to work, even if it's sometimes kludgy. Especially during the next few years with much legacy equipment deployed the need for tolerance in protocols is that bit greater.
	High level discussion summary:

	* Distinguish between NETCONF protocol issues and YANG schema conformance in the payload.
	* Loose mode for both is strongly desirable.
	* Especially to support devices that may not yet have a model, or it's known to be incomplete.
	* For schema conformance loose mode, consider making it a per-model tweak.
	* Loose mode should only apply when violations are not structurally ambiguous. Data that cannot be deserialized by a reasonably tolerant parser should always be rejected. This means bad XML (syntactically broken - unbalanced nesting, missing >'s and so on) should probably not be accepted, but semantic issues (not passing yang schema checks, like elements not passing type tests or whole data structures not being defined in the schema at all) should be tolerable. Likewise NETCONF transport issues that are not ambiguous should be tolerable too.
	* ODL northbound should always be well behaved; passthrough must be carefully considered, possibly with a separate endpoint (to make its use explicit in apps)
	* Expect end users to come up with esoteric conditions down the road; when stuff is in production things need to work, even if it's sometimes kludgy. Especially during the next few years with much legacy equipment deployed the need for tolerance in protocols is that bit greater.