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

Robert Wilton <> Thu, 21 September 2017 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 703EE134677 for <>; Thu, 21 Sep 2017 02:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CozLmMpz-0F9 for <>; Thu, 21 Sep 2017 02:38:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D06C134661 for <>; Thu, 21 Sep 2017 02:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6078; q=dns/txt; s=iport; t=1505986690; x=1507196290; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=E0cuIz+hXfHjI+unDSoxaAJwlqKDQHD2Jr6wms9pwzw=; b=PmcnPs0ngD4praHOzAIevKJb6RDObohy2eNA/2VjodiuflUV97MPA2J6 U76QD9yGclSlev3uGCWbGF7MapICGTHwCrt4OWGQ59P7W3c9fFFOBQhdl ww2PbdwNYyHhk5IINqZ8jZvtN/ADKgG7uhw36t9p4EztmjsH1i9unn0oB 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQA9h8NZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEW4ng3aLFJBMK5g7CieFFAKFMRUBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIw8BBVEJAhgCAiYCAlcTBgIBAReKEAgQiTudZoInin4BAQEBAQUBAQEBA?= =?us-ascii?q?QEdBYEOgh2DU4FkK4J9iA6CYAWKI4cUgWiNdIddjHqCE4Vqg1qHJI1jh1eBOTU?= =?us-ascii?q?igQ0yIQgcFYdmPzYBhmErghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,424,1500940800"; d="scan'208";a="655807910"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 09:38:08 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v8L9c7BR028675 for <>; Thu, 21 Sep 2017 09:38:08 GMT
References: <> <> <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Thu, 21 Sep 2017 10:38:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 09:38:45 -0000

On 20/09/2017 15:33, Ladislav Lhotka wrote:
> 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?
Here I presume you are thinking that the configurable value for duplex 
is "full/half/auto", but the operational value is "full/half"?

The solution here is really to model auto-negotiation on/off as a 
separate leaf (which also more closely reflects the actual behaviour of 
the auto-negotiation protocol).  Then for duplex both the space for both 
the configured and operational leaves are the same, i.e. both taking 
"full/half", and hence only a single leaf is required to model both the 
optional configured value and the operational value.

A concrete example of the Ethernet interface YANG structured this way is @

>> 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.
Yes, I agree that this scenario is very likely, but I think that the 
solution here is just to not mark the leaf as mandatory.

It is interesting to consider what "mandatory" exactly means in the 
<operational> datastore.  Given that the mandatory constraint may be 
violated in <operational>, then my interpretation is that it means that 
a correct implementation SHOULD always return a mandatory node (if it is 
in scope).  But a client has no way to force a device return this data 
(except perhaps shouting at the vendor :-), and so it seems that a 
robust client would need to be able to cope with the fact that the 
device is not behaving nicely and isn't returning the data regardless of 
any mandatory keyword specified in the schema.

To further expand on this, a device is required to ensure that 
configuration datastores are valid, and hence all mandatory constraints 
are enforced, or a config change would be rejected, but I don't think 
that many devices are going to validate operational. They will just 
return the current state of the system back to the client, and let the 
client deal with any unexpected inconsistencies.

Also, what about all the regular config false nodes in the schema that 
are not marked as mandatory?  Is a device always required to return 
those leaves (if they are in scope)?  If a device is never going to 
return those leaves then it should use a deviation to remove them, but 
is that actually required?

Is seems that possibly the most useful use of mandatory in the context 
of operational is for something like an IP address/prefix length 
pairing, i.e. to indicate that the data really doesn't make any sense 
unless both address and prefix are provided.

When the next version of YANG is specified, perhaps we should consider 
allowing an extra options to mandatory to that it only applies to the 
state datastores?  if so, we could add this to the YANG.Next issue tracker?

So, in conclusion, I think that the NMDA modelling advice for mandatory 
on config true nodes might be to only use it when the node is mandatory 
in configuration datastores.

If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.