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

[Ladislav Lhotka <[e-mail]>]

Robert Wilton <[e-mail]> writes:

> 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?

So, for example, duplex and duplex-state? And <operational> will
have both as siblings?

>
> 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.

This should be quite typical: a config leaf is optional and if it is not
configured, the system sets it to some value (as in the case of
router-id). But in state data it is mandatory so that the client can see
what the system chose.

Lada

>
> 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
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67