On Wed, Sep 09, 2015 at 10:16:06PM +0200, Benoit Claise wrote: > 2. The requirements. > If there are still clarifications needed around the requirements in > draft-openconfig-netmod-opstate-01 section 4, or around the requirement > that the YANG models need some sort of hierarchy > (draft-openconfig-netmod-model-structure), like for the routing models, > ... tomorrow interim meeting is your chance, or between now and then on > the mailing list.
For the record (since I won't be able to join the call): I disagree with some of the details in the description of the requirement in section 4.5. I agree with the part that says that it should be possible to 'easily' locate the operational state corresponding to configuration state (and I would add that 'easily' means both for humans and machines). I would go even further to say that it should not just be 'easy' but also be 'robust'. What I disagree with is the part that suggests every 'selector' should be encoded in the schema path. Note that I am talking about the schema used on a device, I am not talking about the schema used within an NMS. /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
