Hi, given the discussion at IETF 94, here is what I think where we are with resolving the last call comments (I am following the structure of Martin's IETF 94 slides). It would be nice to close the remining open ones as soon as possible so that Martin can produce -09. Once we have -09, we will have a second WG last call so that people can do a final check whether the edits from -07 to -09 address all the comments that were raised in a satisfying manner.
If you disagree with any of the following, please raise your voice. - New function: if-feature and default I think the resolution is to disallow default values that are depending on a feature. - New function: accessible tree in when I think the resolution is to adopt the proposed solution. - Old function: augment mandatory nodes I think this is moving towards relaxing the MUST NOT rules and to allow mandatory nodes in 'safe' augmentations. - Old function: unique module names I think the resolution is to adopt the compromise solution. - New feature: non-unique config false leaf-lists It is unclear where we are with this. While there was some discussion at IETF 94, there was no clear indication whether this change should be done or not. More input would be welcome. - New feature: keyless lists and non-unique leaf-lists in config This seems to be dead. - New feature: change semantics of the choice and when statements This seems to be dead. - Old function: make auto-delete for choice and when non-NETCONF specific Revision -08 of YANG 1.1 defines auto-deletion as a property of the NETCONF edit-config operation and the issue is whether this auto-deletion behaviour is a NETCONF specific edit-config property or a general YANG datastore validation property that equally applies to RESTCONF, COMI, ... It is unclear where we are with this. More input would be welcome. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
