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.
Thanks,
Acee
>
>
>/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
