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

Ladislav Lhotka <> Thu, 21 September 2017 11:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE924134ACB for <>; Thu, 21 Sep 2017 04:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3II4kY_6FUtk for <>; Thu, 21 Sep 2017 04:38:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6435C134AD0 for <>; Thu, 21 Sep 2017 04:38:50 -0700 (PDT)
Received: by (Postfix, from userid 109) id B9A641820E76; Wed, 20 Sep 2017 16:32:14 +0200 (CEST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id D9DA81820E71; Wed, 20 Sep 2017 16:32:12 +0200 (CEST)
From: Ladislav Lhotka <>
To: Robert Wilton <>,
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Mail-Followup-To: Robert Wilton <>,
Date: Wed, 20 Sep 2017 16:33:24 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Sep 2017 11:38:55 -0000

Robert Wilton <> 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 <> writes:
>>>>> Ladislav Lhotka <> 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.


> 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
>>>>>> -- 
>>>>>> Ladislav Lhotka
>>>>>> Head, CZ.NIC Labs
>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>> _______________________________________________
>>> netmod mailing list

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