Re: [Rtg-yang-coord] Operational State Modeling

On 5/15/15, 9:56 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:

>
>> On 15 May 2015, at 15:34, Christian Hopps <chopps@chopps.org> wrote:
>> 
>> 
>> Juergen Schoenwaelder writes:
>> 
>>> On Wed, May 13, 2015 at 09:13:37AM -0400, Thomas D. Nadeau wrote:
>>>> 
>>>> 	Speaking as an individual, while what Juergen says is true, that
>>>>does not mean that existing models can never be refactored.
>>>> 
>>> 
>>> Refactoring for the sake of 'it looks nicer' (for some definition of
>>> nice) likely does not meet the bar. We are talking about APIs here
>>> with multiple independent implementations and applications sitting on
>>> top of these APIs.
>> 
>> 
>> Isn't the idea to create a common standard way to access state and
>> config? If so I don't think that qualifies as "it looks nicer", rather
>> it allows for creating generic code one time that works on any model
>> including as yet unwritten ones vs. custom code for each model.
>
>Well, the existing modules do propose a way to access state and config.
>It’s not perfect and perhaps some changes in YANG are needed as well in
>order to better support the interaction of config and state.
>
>However, I agree with Juergen that the arguments presented so far in
>favour of leaf-level duplication aren’t very convincing.

If you look at the existing IGP draft models, the config state is also
present in the operational state so this proposal doesn’t represent
additional leaf nodes - just a change to the organization to place the
config and operational state adjacent to one another in the tree.

> 
>
>Lada
>
>> 
>> Thanks,
>> Chris.
>> 
>> 
>>> 
>>> /js
>> 
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>