> On Sep 10, 2015:2:32 AM, at 2:32 AM, Juergen Schoenwaelder
> <[email protected]> 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
>> <[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
>>>
>>
>>
>
> --
> 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
