Tom,
On 9/10/2015 8:52 AM, Nadeau Thomas wrote:
> 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
This works as long as we break this seemingly endless requirements
discussion cycle that keeps coming up when try to discuss solutions.
>From my perspective we already have documented operator requirements
that seem to have at least have 'rough' consensus. Namely:
draft-openconfig-netmod-opstate-01: Sections 3, 4, 5.
(note, which doesn't require specific convention-based or
protocol-based solution)
draft-openconfig-netmod-model-structure-00: Section 1.1
(note, which does *not* include a requirement for /device)
On 9/10/2015 8:21 AM, Kent Watsen wrote:
> Yes, we must have a list of requirements that everyone agrees to. We
> will subsequently put it into an email to the WG for final on-list
> consensus.
So should I/someone extract the mentioned section and send it to the
list now so that there's no ambiguity of what is being ased for folks to
agree to in the meeting?
Thanks,
Lou
PS The last time I tried to capture an issue on this list I was
basically told to write a requirements draft, now the answer is the
opposite...
>
>> 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
