> On 08 Jan 2016, at 13:57, Acee Lindem (acee) <a...@cisco.com> wrote:
>
> Hi Martin, et al,
>
> On 1/8/16, 2:54 AM, "Martin Bjorklund" <m...@tail-f.com> wrote:
>
>> Hi,
>>
>> "Acee Lindem (acee)" <a...@cisco.com> wrote:
>>>
>>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>>>
>>>>
>>>>> On 23 Dec 2015, at 04:06, Kent Watsen <kwat...@juniper.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>>>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>>>>>
>>>>>>
>>>>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>>>>> <j.schoenwael...@jacobs-university.de> wrote:
>>>>>>>
>>>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>>>>
>>>>>>>> I hope that nobody disagrees that the operational state design and
>>>>>>>> how
>>>>>>>> to structure the models are the two blocking factors to publish
>>> YANG
>>>>>>>> models. If you disagree or don't see this, let me know, I should
>>>>>>>> communicate better.
>>>>>>>
>>>>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>>>>> factor that should stop us from publishing models. There seem to be
>>>>>>> ways to address the requirements without having to block all work
>>> or
>>>>>>> to redo what that we have published. But sure, if you make it a
>>>>>>> blocking factor, it will be one.
>>>>>>
>>>>>> I agree with Juergen. It is not clear to me how the proposed split
>>>>>> between intended and applied configuration is supposed to affect the
>>>>>> data models we are working on.
>>>>>
>>>>>
>>>>> As I understand it, solution #1 affects the models themselves,
>>> whereas
>>>>> solutions #2 and #3 are transparent to the models.
>>>>
>>>> Then #1 looks like a non-starter to me.
>>>
>>> I’d like to point out that we also have the requirement to allow
>>> retrieval
>>> of derived-state along with intended-config and applied-config. This
>>> will
>>> require modification to most of the existing YANG drafts as most now
>>> have
>>> separate trees for config and operational state.
>>
>> I don't agree with the conclusion that changes are needed due to this
>> requirement.
>>
>> Solution #1 ("openconfig") requires changes to handle applied config.
>> Solution #2 ("kent's") does not.
>>
>> Both solutions #1 and #2 use separate nodes for derived state.
>>
>> It might appear as #1 and #2 are very different in their handling of
>> derived state, since #1 put all config false nodes directly under the
>> config true nodes, whereas #2 in some cases have a top-level
>> "xxx-state" config false node.
>>
>> But in fact #2 allows the solution in #1 as one special case. The
>> reason that RFC 7223 has a separate list for derived state interfaces
>> is to allow for non-configured interfaces to be monitored. If this
>> was not a requirement, all config false nodes could (would) have been
>> defined in the config true interface list.
>
> I see that this is discussed in the latest version of
> draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
> the operational state in the same subtree as the config state if it would
> not exist if not configured. Is “appropriate” a recommendation?
>
> Careful consideration needs to be given to the location of
> operational state data. It can either be located within the
> configuration subtree for which it applies, or it can be located
> outside the particular configuration subtree. Placing operation
> state within the configuration subtree is appropriate if the
> operational values can only exist if the configuration exists.
>
>
> However, we currently have many YANG models in progress where the config
> and state trees are separate subtrees. If we all agree with the opstate
> requirement for derived state, perhaps it is time to get the word out and
> modify these models.
I don't think that we all agree. :-)
Lada
>
> Thanks,
> Acee
>
>
>
>>
>>
>> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
