I think another question is if the current *requirements* text good /close
enough for a -00 wg document....
Lou
On September 10, 2015 8:20:34 AM Nadeau Thomas <tnad...@lucidvision.com> wrote:
On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de> wrote:
Yes, in my view, section 4.5 goes a bit too far in making a certain
solution part of the requirement.
The solutions that have been written up have different properties in
terms of data modeling impact, device implementation impact, NMS
implementation impact and backwards compatibility impact. Furthermore,
we need to acknowledge that not all devices are asynchronous. These
aspects need to be taken into account when selecting a solution.
What is needed is clarity what the requirements are that we find
agreement on. I believe it is possible to tweak the text in section 4
to something people can agree on. But as it is written in -01, I do
not think we are there yet.
Is it that you disagree with the specifics of what is written
so that minor refinements would satisfy your need for clarity, or do you
believe there are entire requirements that either do not exist, or should
be removed from section 4.5? If the case is the former, please be constructive
and provide proposed changes to the text; if the latter, please specify
that as well.
—Tom
/js
On Wed, Sep 09, 2015 at 10:12:58PM -0400, Lou Berger wrote:
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
<j.schoenwael...@jacobs-university.de> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
