“with-defaults” capability in NETCONF Balazs Lengyel, Ericsson Andy Bierman draft-ietf-netconf-with-defaults-03 IETF-76 Hiroshima, 2009 November

Problem Different network elements handle defaults differently We want flexible and predictable behavior We must leave optionality as we can’t force the world to converge Default data may or may not be stored in the datastore

Define Default Default data: Data that is Defined as default in YANG Set or used by the network element Not set by the manager Explicit default: data set by the manager with a real management operation to its YANG default value e.g. using <edit-config>, CLI, SNMP, GUI

Examples of a Server Provided Data DEFAULT data CAN be: - documented as yang default and stored in datastore - documented as yang default and not stored in datastore Server created REAL data CAN be - documented as yang description and stored in datastore, may or may not be essential for the workings of the system - factory default setting used after initial load or delete-config Server provided data CAN NOT be: - documented as yang description and not stored in datastore

Effects of a default Is it part of the datastore? How the node really works What is returned in <get-config>/<get>? With-defaults report-all/trim/explicit Does <edit-config> create/delete succeed or fail? Intentionally left undefined to accommodate differing existing nodes Are non-presence containers present? Must/When/Reference constraints? Defaults always considered

Default Handling in the Real World Report all: All default data is always reported. Trim: Values are not reported if they match the default. Explicit: Report values if they are explicitly set. One of the above based on user choice Etc.

Thank you for your response Receive 439 emails on 10 pages of content More then 20 times the amount of the original text

Changes Changed definition of default data !!!!!!! XSD and YAM marked <CODE BEGINS>…<CODE ENDS>

Open Issues Shall we make this mandatory as report-all is important? No Shall the basic mode be configurable? Yes, add it to Netconf-Monitoring data model?

Open Issues Shall we make explicit mandatory No, it requires a change in the underlying database 1 bit of extra storage is cheap, BUT adapting an existing database and handling logic is EXPENSIVE Makes adapting existing device to Netconf much more costly Ericsson would hate you for it 

Open Issues Shall we make 3 features/capabilities instead of using parameters No this is more simple Shall we speak of operations/operation replies instead of rpcs/rpc-replies? No, other drafts/rfcs also speak about rpc- replies, why introduce new terminology Yes, it is more correct

Open Issues Shall we wait for YANG and 4741bis to make YANG mandatory? Yes: Andy, Juergen, Phil, Martin, Lada No it might take a long time especially 4741bis

Thank You