Hi,
On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwil...@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
>
>> Andy Bierman <a...@yumaworks.com> wrote:
>>
>>> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwat...@juniper.net>
>>> wrote:
>>>
>>> I think it is better to have a human decide what is in the module
>>>>> instead of relying on a pyang plugin to generate some additional module
>>>>> that follows some simplistic pattern.
>>>>>
>>>> It may be simple, but I’m thinking that’s only because it’s not tricky
>>>> ;)
>>>>
>>>>
>>>> The client and server developers still need to know about this
>>> auto-generated module
>>> and implement it. Operators might have to know about it to use it.
>>>
>> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long term
> format (i.e. combined config and state tree) with the model designer being
> able to assume the existence of the operational state datastore.
>
>
I am not convinced this "new format" has solved anything.
Don't you need separate description-stmts in every node for each
datastore? What does the value mean if pre-configured? configured?
operational? Will the auto-generated objects be exactly correct
and never need any alterations or additional text?
They still need to be used by developers and YANG tools.
Is is that realistic to force the config structure and operational structure
to be the same? Seems it is quite common to monitor data structures
with additional keys or different keys. This is completely unsupported
so separate /foo and /foo-state trees will still exist.
IMO this combination of trees needs to be proven.
Take ietf-interfaces and show how much better it will work
if the /interfaces and /interfaces-state trees were combined.
Andy
The tooling would be there to statically generate the extra foo-state
> config false node modules for servers that don't support the operational
> state datastore. This could be done once, and the extra foo-state modules
> committed to the github YANG respository in the same way that models are
> extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be
> usable both by new client/servers that support an operational state
> datastore, and also by existing NETCONF client/servers that don't implement
> an operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to make it
> easier for folk to migrate, and to not slow down the model writing effort.
> Otherwise, it may be hard to get a protocol model writer to design the YANG
> model in a way that is not fully usable on any current devices.
>
> As an illustration, an RFC published combined ietf-interfaces model may
> look like this:
>
> module: ietf-interfaces-combined
> +--rw interfaces
> +--rw interface* [name]
> +--rw name string
> +--rw description? string
> +--rw type identityref
> +--rw enabled? boolean
> +--rw link-up-down-trap-enable? enumeration {if-mib}?
> +--ro oper-status enumeration
> +--ro last-change? yang:date-and-time
> +--ro if-index int32 {if-mib}?
> +--ro phys-address? yang:phys-address
> +--ro higher-layer-if* interface-ref
> +--ro lower-layer-if* interface-ref
> +--ro speed? yang:gauge64
> +--ro statistics
> +--ro discontinuity-time yang:date-and-time
> +--ro in-octets? yang:counter64
> +--ro in-unicast-pkts? yang:counter64
> +--ro in-broadcast-pkts? yang:counter64
> +--ro in-multicast-pkts? yang:counter64
> +--ro in-discards? yang:counter32
> +--ro in-errors? yang:counter32
> +--ro in-unknown-protos? yang:counter32
> +--ro out-octets? yang:counter64
> +--ro out-unicast-pkts? yang:counter64
> +--ro out-broadcast-pkts? yang:counter64
> +--ro out-multicast-pkts? yang:counter64
> +--ro out-discards? yang:counter32
> +--ro out-errors? yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
> +--ro interfaces-state
> +--ro interface* [name]
> +--ro name string
> +--ro description? string
> +--ro type identityref
> +--ro enabled? boolean
> +--ro link-up-down-trap-enable? enumeration {if:if-mib}?
> +--ro oper-status enumeration
> +--ro last-change? yang:date-and-time
> +--ro if-index int32 {if:if-mib}?
> +--ro phys-address? yang:phys-address
> +--ro higher-layer-if* if:interface-ref
> +--ro lower-layer-if* if:interface-ref
> +--ro speed? yang:gauge64
> +--ro statistics
> +--ro discontinuity-time yang:date-and-time
> +--ro in-octets? yang:counter64
> +--ro in-unicast-pkts? yang:counter64
> +--ro in-broadcast-pkts? yang:counter64
> +--ro in-multicast-pkts? yang:counter64
> +--ro in-discards? yang:counter32
> +--ro in-errors? yang:counter32
> +--ro in-unknown-protos? yang:counter32
> +--ro out-octets? yang:counter64
> +--ro out-unicast-pkts? yang:counter64
> +--ro out-broadcast-pkts? yang:counter64
> +--ro out-multicast-pkts? yang:counter64
> +--ro out-discards? yang:counter32
> +--ro out-errors? yang:counter32
>
> Servers that support operational-state would just implement
> ietf-interfaces-combined
>
> Servers that don't support operational-state could implement
> ietf-interfaces-combined and ietf-interfaces-combined-state, probably not
> implementing the duplicate config false leaves under the interfaces config
> tree. Deviations could also be auto-generated to remove the config false
> leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what
> types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm not actually
> proposing immediately changing that model. I was more thinking about IETF
> protocols that in the process of working on their YANG models.
>
> Rob
>
>
> Exactly. I agree that this is a real hack. Implementations can use
>> whatever transformation tricks they want in order to comply with
>> different standards, but the standard modules should be very clear.
>>
>
>
>
>
>
>>
>> /martin
>> _______________________________________________
>> 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
