Re: [netmod] Question on intefaces-state model

Robert Wilton <rwilton@cisco.com> Wed, 14 June 2017 10:35 UTC

Return-Path: <rwilton@cisco.com>
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 A0C1C129BE8 for <netmod@ietfa.amsl.com>; Wed, 14 Jun 2017 03:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 INkpp-ff5jLv for <netmod@ietfa.amsl.com>; Wed, 14 Jun 2017 03:35:36 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2F3129BDD for <netmod@ietf.org>; Wed, 14 Jun 2017 03:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7592; q=dns/txt; s=iport; t=1497436535; x=1498646135; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=TGANCy0AyRveJUC3Fq2Ldq9EDP+FC9q3GvcalDno0t0=; b=M+KyNaMeUY9wfckm5CTqhrz3AVEruJW4udxpC0e0f8ZhnJex5VujCNpP QL5slzFazovkWrDnHmJ3GGnj39g5ESDZYdXsc+9R2L0RlhWBwFHC8ivr2 3z8WU9p/C0vkz3ZxkSCxqlw2WYYj/qYrtFa8eSe00JrkBA2M9LWvqdrW4 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DUAAAPEUFZ/xbLJq1bAxkBAQEBAQEBAQEBAQcBAQEBAYMrgQ+BDYN2ihhzkQOWA4IRIQuFLkoCgwoYAQIBAQEBAQEBayiFGAEBAQECAQEBIQ8BBTYLDgILEAEBAwEBAQICJgICGwwiBggGCgMGAgEBiiAIEK4cgiaLPgEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaFVoFgK4J1hFQ3JoJLgmEFnkeTUIsVhnOMN4g+HziBCjAhCBsVSIcPPzaJagEBAQ
X-IronPort-AV: E=Sophos;i="5.39,340,1493683200"; d="scan'208";a="695137233"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 10:35:33 +0000
Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5EAZX7r002889; Wed, 14 Jun 2017 10:35:33 GMT
To: Ladislav Lhotka <lhotka@nic.cz>
References: <AM2PR07MB06272FF9E8BA4D00B0669F9794CE0@AM2PR07MB0627.eurprd07.prod.outlook.com> <20170612172141.GA52797@elstar.local> <CABCOCHSK1h4HQ4LgkYd_Lxp3JYzxYBMmCka64_-iVjq2N_PR7g@mail.gmail.com> <m2d1a7iutf.fsf@nic.cz> <CABCOCHS3cqEvyLaRGdk5T2TpkXGOjd_wEii-pREo3cpRwjiHHg@mail.gmail.com> <1497393323725.99784@Aviatnet.com> <EE374EEE-3566-49B6-B1A6-DE357A678279@nic.cz> <9f022715-51cf-a68a-b9fa-94d191af4891@cisco.com> <5634D470-693E-499A-BDBB-FE8BB4F2E553@nic.cz>
Cc: Alex Campbell <Alex.Campbell@Aviatnet.com>, "netmod@ietf.org" <netmod@ietf.org>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <213f4274-7fe3-5ec3-01ed-49d367130c29@cisco.com>
Date: Wed, 14 Jun 2017 11:35:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5634D470-693E-499A-BDBB-FE8BB4F2E553@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/eCyp8xfLsuSLlksrjkh4axV82-0>
Subject: Re: [netmod] Question on intefaces-state model
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: Wed, 14 Jun 2017 10:35:39 -0000


On 14/06/2017 10:46, Ladislav Lhotka wrote:
>> On 14 Jun 2017, at 11:21, Robert Wilton <rwilton@cisco.com> wrote:
>>
>>
>>
>> On 14/06/2017 09:28, Ladislav Lhotka wrote:
>>>> On 14 Jun 2017, at 00:35, Alex Campbell <Alex.Campbell@Aviatnet.com> wrote:
>>>>
>>>>
>>>> Presumably a device is free to not implement an optional config=false node if that node would never be returned in a response anyway - as this will make no externally visible difference.
>>> That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional parameter. This looks like a gap in the architecture – most of the time, YANG pretends to be something like a schema language in that it describes constraints on a valid data tree but conformance issues like what parameters a server needs to implement are something different.
>> It would surely do the same thing as if a client requested any node in a YANG data tree that doesn't exist.
> So you are saying that one server can return the parameter but another may report "404 Not Found", correct?
Yes.

>
>> RESTCONF has special semantics if a GET request is for a specific leaf rather than a parent container, but I just regard this as a mistake in the specification (i.e. the "restconf default handling" thread on the NETCONF alias).
> Defaults are another can of worms. If we have an optional config false parameter with a default defined in YANG and the server doesn't implement the parameter (and hence doesn't send it), can the client assume that the server actually has the default value?
Not in any way that is reliable.  I.e. sometimes the client may make 
this assumption and just be wrong!

One of the key themes running through the NMDA work has been to try and 
get more integrity and consistence between the data that is being returned.

So, in the NMDA world, I think that there are really only two 
"with-default" options that are robust and most useful:

(1) For the candidate/running/status datastores, where the content of 
the datastore is controlled by the client, then the explicit mode is the 
sane default choice.  I.e. generally you should get out exactly what you 
put in.

(2) For the operational state datastore, the report-all mode is the sane 
choice, because this is the only one that allows a client to detect that 
a server is choosing to return no value rather than the default value.

I do appreciate that the other with-defaults options can be used to 
either minimize the amount of data being transferred (potentially at the 
expense of data accuracy), or provide a consolidated view of the 
configuration (e.g. to avoid the client constructing the same combined 
view itself).  But I think that the client should have to opt in if they 
want to see these, and the normal behaviour should be to favour 
correctness and explicitness.

Hence, I wish there had been more consistency with the normal choice of 
default mode in the standard rather that leaving it up to the server 
implementation to decide, thus requiring that clients have to cope with 
a mismash of default handling flavours.

Rob

>
> Lada
>
>>
>>>> However, if the model states or implies that the node is present under certain conditions (for example, the node is always present for Ethernet ports), and the device can meet those conditions (i.e. it has an Ethernet port), then the device must implement the node or it does not conform to the model.
>>> Right, this could be written in a description, but I've been assuming it is not the case.
>>>
>>> Lada
>> Rob
>>
>>>>
>>>> Alex
>>>>
>>>> From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
>>>> Sent: Wednesday, 14 June 2017 7:30 a.m.
>>>> To: Ladislav Lhotka
>>>> Cc: netmod@ietf.org
>>>> Subject: Re: [netmod] Question on intefaces-state model
>>>>
>>>>
>>>> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>> Andy Bierman <andy@yumaworks.com> writes:
>>>>
>>>>> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
>>>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>>
>>>>>> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia -
>>>>>> BE/Antwerp) wrote:
>>>>>>> We have a question regarding the statistics container as defined in the
>>>>>>> interfaces-state model.  This container defines one mandatory leaf
>>>>>>> (discontinuity-time) while all other leafs are optional.  What is the
>>>>>>> rationale behind this leaf being mandatory and not an optional field?
>>>>>>>
>>>>>>> It does not make a lot of sense to return a discontinuity-time value and
>>>>>> no
>>>>>>> counters if none of the counters are relevant for a specific interface.
>>>>>>>
>>>>>>> Another alternative could be to add, via a deviation, a when clause to
>>>>>> the
>>>>>>> container indicating for which ifType(s) the container is (or is not)
>>>>>>> present. But that would lead to not supporting the IETF interfaces model
>>>>>> to
>>>>>>> the full extent.
>>>>>>>
>>>>>> The discontinuity-time is relevant for _any_ counter associated with
>>>>>> an interface, regardless whether the counter is defined in the
>>>>>> interfaces model or elsewhere. I have a hard time to imagine an
>>>>>> interface that has zero counters.
>>>>>>
>>>>>>
>>>>> The mandatory-stmt is very confusing for config=false nodes. Mandatory=true
>>>>> means
>>>>> an <rpc-reply> must contain an instance of the mandatory leaf.
>>>> I don't think it is that confusing. RFC 7950 defines what a valid data
>>>> tree means and "mandatory" are among the constraints.
>>>>
>>>> I agree though that in terms of a management protocol it means different
>>>> things for config true and false data, but this is true also for default
>>>> values and maybe other YANG concepts as well.
>>>>
>>>>> Mandatory=false does not mean optional-to-implement although it sure
>>>>> looks that way for config=false nodes.  Only if-feature can make a node
>>>>> optional to implement.
>>>> I don't think this interpretation is supported by any text in the YANG
>>>> spec. State data nodes that are optional needn't be implemented.
>>>>
>>>>
>>>> RFC 7950, sec 5.6  (Conformance) does not support your interpretation.
>>>> It defines basic behavior, optional (via features), and deviations as the only mechanisms affecting conformance.
>>>>
>>>>
>>>> Lada
>>>>
>>>>
>>>> Andy
>>>>   
>>>>>   /js
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>> --
>>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>>>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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, CZ.NIC Labs
>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>
>>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
> .
>