On Thu, Nov 5, 2015 at 1:08 AM, Juergen Schoenwaelder < [email protected]> wrote:
> 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. > I strongly object to the change to XPath accessible tree for RPC and notifications. (page 44 - 45, bullets 3 - 5) State data MUST NOT be included in the accessible tree. E.g., rpc/input went from the <rpc> message itself to <rpc> + running + state. It should be just <rpc> + running. It is a massive change to include state data in the processing of RPC or notifications. The server has to implement the :xpath capability in NETCONF. I strongly object to the text that requires the accessible tree to be modified for processing when-stmts (3 bullets in 7.21.5). This requires massive and complicated implementation changes. IMO the most interoperable thing to do is just run the specified XPath expression on the existing conceptual document. If people use bad XPath then maybe bad things happen. YANG Doctors will prevent that in IETF modules. In reality, XPath that doesn't work usually gets fixed at some point. > > - Old function: augment mandatory nodes > > I think this is moving towards relaxing the MUST NOT rules and > to allow mandatory nodes in 'safe' augmentations. > There was some discussion about moving the 6087bis text I wrote into YANG 1.1 to make it normative. OK with me. > > - Old function: unique module names > > I think the resolution is to adopt the compromise solution. > which was what? > > - 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. > > OK with just allowing this without a new keyword. > - New feature: keyless lists and non-unique leaf-lists in config > > This seems to be dead. > good > > - New feature: change semantics of the choice and when statements > > This seems to be dead. > good > > - 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, ... > > good - YANG should describe what happens inside a conceptual datastore IMO it could be more clear that this auto-deletion applies to every datastore and is not really considered validation. If so, then it would not be instant, but rather enforced only on the 'running' config. It is really if-feature on steroids. ;-) (No I do not have suggested text right now to make this more clear) > It is unclear where we are with this. More input would be welcome. > > /js > Andy > > -- > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
