Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Robert Wilton <[e-mail]>]

On 19/09/2017 15:07, Ladislav Lhotka wrote:
> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>> Hi Lada,
>>
>>
>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>> Martin Bjorklund <[e-mail]> writes:
>>>
>>>> Ladislav Lhotka <[e-mail]> wrote:
>>>>> Hi,
>>>>>
>>>>> I support the adoption but I propose two conceptual changes:
>>>>>
>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>> necessary to carry along the deprecated baggage. If readability is
>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>
>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>>>>> to be used
>>>>> in areas where NMDA is an overkill, such as open source home
>>>>> routers.
>>>> Why wouldn't NMDA be appropriate in an open source home router?  Note
>>>> that the new model really just have a single tree instead of two
>>>> trees, so the data that needs to be instrumented is more or less the
>>>> same.
>>> It is quite likely that some parts of the data models will be
>>> implemented only as configuration but not state data. In the "old style"
>>> modules it is easy to add a deviation for the node(s) under -state but
>>> in NMDA style this is not possible because we only have one node.
>> The new YANG library allows different sets of modules to be available
>> for <conventional> datastores vs <operational>.   The operational
>> datastore can also have different features supported and different
>> deviations vs the conventional datastores.
> OK, I missed the 7895bis draft, sorry. Then there could be differences in
> mandatory/optional (e.g. a node is optional in configuration but mandatory in
> state data) or the data type of a leaf can differ. How can these be handled?
If the data type of the leaf can differ, then normally this should be 
modeled as two separate leaves.  Do you have a concrete example of this?

If some data is mandatory in config, but not necessarily mandatory in 
<operational> then normally it can be marked as mandatory true, since 
optional is allowed to violate this constraint if necessary, but 
implementations would generally be expected to conform to the constraint 
if possible.

For the reverse case, we can't express that.  I think that you would 
have to leave out the "mandatory: true" constraint.  Again, can you 
provide a concrete example of this please?  That makes it a bit easier 
to reason about.

Thanks,
Rob


>
> Lada
>
>> So, the device can make the same deviations to remove the state leaves
>> from <operational>.  Or if they don't want to support the module in
>> operational at all then a device could just list it as being supported
>> in the conventional datastores and not <operational>.
>>
>>> There are subtle differences in the schemas for configuration and state
>>> data that the NMDA concept doesn't address. If you want another example,
>>> ietf-routing-2 has the "router-id" leaf that is conditional via the
>>> "router-id" feature. If this feature is not supported, router-id cannot
>>> be explicitly configured (it is assigned by the system) but in state data
>>> "router-id" needs IMO be present in any case. But the if-feature
>>> isn't able to differentiate between configuration and state data if
>>> there is only one node for both.
>> The new YANG library also supports this:
>>
>> The "router-id" feature would be disabled for the conventional
>> datastores, but enabled for <operational>.
>>
>>>> In fact, if we claim that the new architecture is not appropriate for
>>>> some devices I think we have failed, especially if the conclusion is
>>>> that we need to maintain two versions of all modules going forward.
>>> I am not asking for this but, on the other hand, if NMDA versions used a new
>>> module name and namespace (my item #1, which is what ietf-routing-2
>>> does), then I don't see any pressing need for obsoleting the old style
>>> modules.
>> I think that creating a "-2" versions of these models at this time might
>> be a mistake.  I actually think that the "deprecate state leaves" ->
>> "obsolete state leaves" -> "delete state leaves" path is a better choice.
>>
>> Thanks,
>> Rob
>>
>>
>>> Lada
>>>
>>>> /martin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> NMDA
>>>>> implementors should be aware of the new modules but there is no need to
>>>>> eradicate the old data models.
>>>>>
>>>>> #2 applies also to other modules for which the NMDA version is underway.
>>>>>
>>>>> Lada
>>>>>
>>>>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>>>>    
>>>>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>>>>>> All,
>>>>>>
>>>>>> This is start of a two week poll on making
>>>>>> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>>>>>> send email to the list indicating "yes/support" or "no/do not
>>>>>> support".
>>>>>> If indicating no, please state your reservations with the
>>>>>> document.  If
>>>>>> yes, please also feel free to provide comments you'd like to see
>>>>>> addressed once the document is a WG document.
>>>>>>
>>>>>> The poll ends Oct 2.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Lou (and Kent)
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> -- 
>>>>> Ladislav Lhotka
>>>>> Head, CZ.NIC Labs
>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod