Subject: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

From: Nadeau Thomas <[email-masked]>
Date: Wed, 16 Dec 2015 08:12:56 -0500

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

	Tom/Kent

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 28 Dec 2015 10:30:14 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Dec 28, 2015 6:24 AM
>To: Robert Wilton <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>On Wed, Dec 23, 2015 at 10:05:46PM +0000, Robert Wilton wrote:
>> 
>> Personally, ignoring all the backwards compatibility issues, I would 
>> prefer that interfaces and interfaces-state were a combined single list 
>> (as proposed by OpenConfig).  E.g. something along the lines of:
>>  - the system can still provide an operational list of discovered 
>> interfaces so that clients can know what is there.
>>  - but management agents would be expected to explicitly configure 
>> (i.e. create an entry for) all interfaces for which it wanted to 
>> retrieve data for.
>>
>
>A clear separation of config from operational state is one of the
>outcomes of the IAB workshop documented in RFC 3535 and it is one of
>the key foundations of both NETCONF and YANG. Config and operational
>state have different and _independent_ lifetimes - you can have config
>for resources that are not present and you can have operational state
>for resources that are present but not configured. In addition, the
>data models for operational state are often not the same as the data
>models for configuration. Merging all things back into a single list
>with a single keying (naming) structure gets us back into the mess we
>were in with SNMP.

This assumes that separation of config from operational state
is best represented in naming.   I think trying to get one's naming architecture to simultaneously and consistently encode too many
aspects of whatever is being modelled brings some of the messiness that concerns you. Perhaps it's finally time to consider what the intended
semantics of the NETCONF / YANG naming architecture really are,
to stop trying to overload them further, and figure out what means
are appropriate for all those other semantics folks have tried to
foist onto naming.

Randy