Juergen,
It sounds like you are agreeing with the requirements but not the solution.
I think this is a valuable distinction, i.e., that it's possible to agree
with one but not the other. I'd also like to point out that the first part
of the discussion is limited to requirements only so we can focus on the
former before delving in to the latter .
Lou
On September 9, 2015 6:01:20 PM Juergen Schoenwaelder
<[email protected]> wrote:
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
