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

Ladislav Lhotka <lhotka@nic.cz> Thu, 21 September 2017 11:38 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE924134ACB for <netmod@ietfa.amsl.com>; Thu, 21 Sep 2017 04:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3II4kY_6FUtk for <netmod@ietfa.amsl.com>; Thu, 21 Sep 2017 04:38:51 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6435C134AD0 for <netmod@ietf.org>; Thu, 21 Sep 2017 04:38:50 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id B9A641820E76; Wed, 20 Sep 2017 16:32:14 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id D9DA81820E71; Wed, 20 Sep 2017 16:32:12 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, netmod@ietf.org
In-Reply-To: <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com>
Mail-Followup-To: Robert Wilton <rwilton@cisco.com>, netmod@ietf.org
Date: Wed, 20 Sep 2017 16:33:24 +0200
Message-ID: <87mv5p783v.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7_ya16HsJ6tQLdmTeiQJhKpqzE4>
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 11:38:55 -0000

Robert Wilton <rwilton@cisco.com> 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 <mbj@tail-f.com> writes:
>>>>
>>>>> Ladislav Lhotka <lhotka@nic.cz> 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
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>> -- 
>>>>>> Ladislav Lhotka
>>>>>> Head, CZ.NIC Labs
>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>

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