Re: [netmod] Comments on NMDA-04

Andy Bierman <andy@yumaworks.com> Fri, 29 September 2017 16:46 UTC

Return-Path: <andy@yumaworks.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 05AF11321C7 for <netmod@ietfa.amsl.com>; Fri, 29 Sep 2017 09:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 DKDuKgvuqcuY for <netmod@ietfa.amsl.com>; Fri, 29 Sep 2017 09:46:19 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F91126E64 for <netmod@ietf.org>; Fri, 29 Sep 2017 09:46:18 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id m199so206275lfe.3 for <netmod@ietf.org>; Fri, 29 Sep 2017 09:46:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fb3tlEgZCr7clsK9JBx33XWQBn5cbL/CudRHX3usPik=; b=lgC50tr+kAq62LCYyGrAKtwxotwT4gmY7pwPVWudOfqIwUbaFmUBXuhdwU+gRyQcOR 3zTv03Qi/lHZkl1kHZCHAiYk0AMYNLQ1p4zmwpP4xP2mp33wRv4z4L1xCZHjNHSd4krR /aDWWwv1XboqCdgJw0ooDOP702GZCWNGPBfNk6sacQyqzYEQC1AWboNDkNdYoJZ0ne03 UAcB50S6Vo1PsLVRVgxNhaj76NbVu8X5D9jV3BXxAvfkO1hnTtUSkhwWVmt8LOcMZ8+h uwPcVpIYOZxJ6XEx0OQp5RsSeM/uc+Lg3qTG0ZsLgIz6hqyf3E0xRYP7EGKdACrkbu/7 +bYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fb3tlEgZCr7clsK9JBx33XWQBn5cbL/CudRHX3usPik=; b=QfifSn7siwwyHcHvAXnoXkM1JKyrkkX9izqmQV7aJkvMUnrPMQkwRPXrVr9iqheXft 908uPVQ9cy6GlMTuY5m2nyxlTajgSI5dqfMJWhcVXMcDOITU8jetgU79K8gfUB0T3EEj w5E0KWOoUSI5di3LZY0RKfQT9H6pIosJeZnR56TILEsKHDkFQs4Lrdc2v8WMW/l/3g2o 3zFjoIGuBjRFGvIrLJYL3CAAziQJihb5Qij+/XX3qVMOXThLm+fMuNpFYkKXHUDQhCOi Ca4ljsnJ1K7YGFghWsBLdvsFXDQIc6YaB7MXde17MTRDMXgtppe6uNn5/LTMjfkUgiem MLxw==
X-Gm-Message-State: AHPjjUgxjeAQBr2ZlFDGRFeW20zENvflEy4kOd7tr39CfdsC/DyobNKh H+FesH/KVGfRBuJudXVVVW0DO8n4qMBotMpqHtFm9g==
X-Google-Smtp-Source: AOwi7QBxbASqOYW2JB8sQTzmGkcwpttxDNnlrxqReEuvLPy8O4jcRWz2h7FuUq7XLv5i2iki2wwTRidDI6AQ6OVRbVo=
X-Received: by 10.25.142.9 with SMTP id q9mr1443098lfd.89.1506703577041; Fri, 29 Sep 2017 09:46:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 29 Sep 2017 09:46:15 -0700 (PDT)
In-Reply-To: <bfebbf31-a241-2409-e126-770711e7e635@cisco.com>
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com> <bfebbf31-a241-2409-e126-770711e7e635@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 29 Sep 2017 09:46:15 -0700
Message-ID: <CABCOCHRGMH=Djab4T4+Tgth2-WZykREhK=3uEu_XX1JmuYS=wQ@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Balazs Lengyel <balazs.lengyel@ericsson.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f50707e0d76055a56c3be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/E3LQnRuHseGia52pxR2gGxk5RQc>
Subject: Re: [netmod] Comments on NMDA-04
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: Fri, 29 Sep 2017 16:46:22 -0000

On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton <rwilton@cisco.com> wrote:

> Hi,
>
> Regarding the issue "Is it allowed to violate uniqueness of key values?",
> https://github.com/netmod-wg/datastore-dt/issues/10
>
> We have discussed this further, and would like to extend the text in the
> draft to explicitly allow key uniqueness to be violated!
>
>
so we can rubber-stamp buggy servers?
I do not agree this is needed.



> We have thought of several cases where it is possible that duplicate
> entries could appear, and we don't want to force any overhead on the device
> to guarantee that this does not occur, nor do we want to force
> synchronization between configuration processing and what is reported in
> <operational>.  Of course, in normal circumstances this constraint, like
> the others, should not be violated.  This is already stated in the draft.
>
> Examples of where uniqueness of list keys could be violated include:
> 1) If a device is internally paging the results back for a long list, then
> it is possible that a entry could have been reported near the beginning of
> the list, then moved, and then reported again at the end of the list.
>


The data is question is simply part of an <rpc-reply> and it is subject to
the validation
requirements for RPC replies only.  Note also that the payload to represent
an arbitrary
configuration datastore has to be done with anydata or anyxml.  RPC reply
validation
rules for these nodes do not extend to contents of the anydata instance.


2) If the list being stored somewhere in the system has become corrupted
> and contains duplicate entries.  It is better to return truth.
>


It is better to fix the buggy server.
Again, a representation of some portion of a datastore in an <rpc-reply>
has nothing to do with the YANG validation of a datastore within a server.




> 3) On a distributed system where the list is being constructed from
> multiple nodes (e.g. linecards or peer devices) then if a list entry is
> moved from one node to another then it is again possible that an entry
> could be reported in both places (or neither) for a short interval before
> the system becomes consistent again.
>


Once again, this is an <rpc-reply> representation, not the validation of a
datastore
within a server.




Andy



> Proposed text:
>
> OLD:
>
>    <operational> SHOULD conform to any constraints specified in the data
>    model, but given the principal aim of returning "in use" values, it
>    is possible that constraints MAY be violated under some
>    circumstances, e.g., an abnormal value is "in use", or due to remnant
>    configuration (see Section 4.3.1).  Note, that deviations are still
>    used when it is known in advance that a device does not fully conform
>    to the <operational> schema.
>
>    Only semantic constraints MAY be violated, these are the YANG "when",
>    "must", "mandatory", "unique", "min-elements", and "max-elements"
>    statements.
>
> NEW:
>
>    <operational> SHOULD conform to any constraints specified in the data
>    model, but given the principal aim of returning "in use" values, it
>    is possible that constraints MAY be violated under some
>    circumstances, e.g., an abnormal value is "in use", the structure of
>    a list is being modified, or due to remnant configuration (see
>    Section 4.3.1).  Note, that deviations are still used when it is
>    known in advance that a device does not fully conform to the
>    <operational> schema.
>
>    Only semantic constraints MAY be violated, these are the YANG "when",
>    "must", "mandatory", "unique", "min-elements", and "max-elements"
>    statements; and the uniqueness of key values.
>
> Again, if there are no objections, I will apply this change.
>
> Thanks,
> Rob
>
>
> On 14/09/2017 16:44, Balazs Lengyel wrote:
>
>> See below !
>>
>>
>> On 2017-09-14 16:32, Martin Bjorklund wrote:
>>
>> CH 4.4.)  "Validation is performed on the contents of <intended>."
>>>> This to me means that default data is not considered at validation
>>>>
>>> Note that RFC 7950, section 6.4.1, says:
>>>
>>>     In the accessible tree, all leafs and leaf-lists with default values
>>>     in use exist (see Sections 7.6.1 and 7.7.2).
>>>
>>> So defaults are taken into account when intended is validated.
>>>
>> BALAZS: Yes the two seem to contradict each other. This can be understood
>> in your way, however the current text is not clear enough. I would add:
>> Validation is performed on the contents of <intended> (EXTENDED WITH
>> DEFAULT CONFIGURATION).
>>
>>> which would be a backwards incompatible change. Also if validation
>>>> does not consider system configured data that would allow cases like
>>>> multiple interfaces named lo0. One from <intended> one from system
>>>> configuration. IMHO while it is OK to violate uniqueness because of
>>>> remnant data, the above violation of uniqueness seems a bad idea.
>>>>
>>> If your system adds data to <running>, or to <intended>, it will be
>>> validated.
>>>
>>> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
>>>> should not be.
>>>>
>>> Agreed.  Note that the draft explicitly lists the constraints that can
>>> be violated, and uniqueness of keys is not listed.
>>>
>> BALAZS: If that is the intent I would propose to explicitly state it. For
>> me it was non-trivial.
>> Can a a choice statement be violated? Having to existing branches at the
>> same time? It seems a semantic constraint to me. IMHO yes.
>> Can an if-feature be violated? If  support has just changed and we have
>> some remnant config, I can very well imagine it violated.
>>
>> Also here could you change
>> If a node in  <operational> does not meet the syntactic constraints then
>> it cannot   be returned
>> to
>> If a node in  <operational> does not meet the syntactic constraints then
>> it MUST NOT be returned
>>
>>> /martin
>>>
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>