Hi, recent discussions show that 6020(bis) text about extensions isn't sufficiently clear about the scope and semantics of extensions. IMO this needs to be fixed and so I propose to add the following item to YANG 1.1 issue list. Comments and additional solutions are welcome.
Lada ------------------------------------------------------------------------ * NEW :Yxx: clarify conformance wrt extensions ** Description YANG extensions as defined in RFC 6020 have no limits on scope – they can possibly modify YANG language, datastore semantics or even the NETCONF protocol. However, from the text in RFC 6020 it is unclear whether extensions appearing in YANG modules advertised by a server are mandatory to implement: "If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler." ** Solution Yxx-01 Extensions appearing in the server's model are an integral part of the server-client contract. That is, the server MUST implement them, and the client SHOULD terminate the session if it doesn't implement any of the extensions. ** Solution Yxx-02 Develop a mechanism for negotiating extensions. ** Solution Yxx-03 Make extensions optional. This means that extensions won't be allowed to change YANG language, NETCONF protocol, and validity of datastores and protocol messages. ------------------------------------------------------------------------ -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
