The desire from the co-chairs and AD anyways, is that we do not start a
requirements draft
as a result of today’s meeting (and mailing list confirmation of the outcome).
As Kent mentioned earlier
in this thread, to document this list of detailed requirements on the mailing
list. The motivation for this
versus a draft, is that waiting for a draft to completely is a drag on
progress, and we don’t want to
gate or slow things down. Putting them in a place different from the existing
draft also helps with
the perceptional issues that were raised earlier.
—Tom
> On Sep 10, 2015:8:26 AM, at 8:26 AM, Lou Berger <lber...@labn.net> wrote:
>
> 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
