Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]

Robert Wilton <rwilton@cisco.com> Thu, 28 September 2017 10:26 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 01314134668 for <netmod@ietfa.amsl.com>; Thu, 28 Sep 2017 03:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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: 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 VABra4POAJFm for <netmod@ietfa.amsl.com>; Thu, 28 Sep 2017 03:26:36 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267E41321DF for <netmod@ietf.org>; Thu, 28 Sep 2017 03:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10365; q=dns/txt; s=iport; t=1506594396; x=1507803996; h=subject:from:to:references:message-id:date:mime-version: in-reply-to; bh=QRkC6BOWzi6bk6f2TssWofvntbLhgWlGMZXav/OSllg=; b=g5jC2894sFUqA3m1X9093Db/aDUmH0g40SJxN6ua0kjgkqCImNo9CoCh smY1P27RoiGZmnAxmGRAFTsqtOOkTi9AN6v+0WMtCd+X0TPQy8spwgKjn jlXof+9dp9a9vZnuebO6F+TK748jDKYHvlCAvWtdYyXo2F+AqUh/PrbWx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CsAAA4zcxZ/xbLJq1dGQEBAQEBAQEBAQEBBwEBAQEBhEBuJ44XdJA+IpBthT4OggQKGAEMhEdPAoUmGAECAQEBAQEBAWsohRkBAQEDAQFsGwsSBi4nIg4GAQwGAgEBii0QqT8niloBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMrg1OBaisLgnKEUQESAQmGCQWYT4hWh16NAYtbhyuNc4dZgTkfOEJBCzIhCB0VSYVPgU8/NoYPDRgHghUBAQE
X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208,217";a="656063647"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 10:26:33 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8SAQXWn019600; Thu, 28 Sep 2017 10:26:33 GMT
From: Robert Wilton <rwilton@cisco.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>, Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com> <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
Message-ID: <fd8c5c6e-4644-4418-4f91-5a18468e3bbd@cisco.com>
Date: Thu, 28 Sep 2017 11:26:33 +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: <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
Content-Type: multipart/alternative; boundary="------------CCB37260CFEBBD5130108C8C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yT1aq6CbNZKcVL4DGMH1rmMFaYc>
Subject: Re: [netmod] Adding system configuration to running [was: Re: 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: Thu, 28 Sep 2017 10:26:39 -0000

Hi,

This is regarding the question as to whether it should be allowed for a 
system to manipulate <running>:

This issue isn't really specific to the NMDA architecture, and there is 
no consensus on whether this should be allowed.

Hence, the proposal is that the NMDA architecture draft be completely 
silent on this, neither endorsing this behaviour, not restricting it.  
Hence no changes to the NMDA architecture draft are required for this issue.

However, I have added an FAQ entry to clarify that this being is not 
prevented, but pointing out some of the potential downsides to a device 
doing this.  The FAQ entry is 
https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q9

Unless I hear otherwise, I propose closing this issue 
(https://github.com/netmod-wg/datastore-dt/issues/8). Comments/review of 
the FAQ text is also welcome.


Thanks,
Rob



On 14/09/2017 18:08, Robert Wilton wrote:
>
>
>
> On 14/09/2017 16:35, Balazs Lengyel wrote:
>>
>> See below!
>>
>> On 2017-09-14 16:32, Martin Bjorklund wrote:
>>> Hi Balazs,
>>>
>>> Thanks for your review.  Comments inline.
>>>
>>> Balazs Lengyel<balazs.lengyel@ericsson.com>  wrote:
>>>> Hello,
>>>>
>>>> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>>>>
>>>> General) The system often adds data to the <running> or <intended>
>>>> datastore already not just to <operational>: e.g.
>>>>
>>>> UC1: I have a server configured in running. I need to bind it to an
>>>> ip-address. The ip-address might be the local loopback address,
>>>> however if that is only added to <operational>, validation will
>>>> fail indicating that the server is bound to a non-existent
>>>> address. How to handle this?
>>>>
>>>> UC2: I have a set of capabilities set by the system
>>>> e.g. supported-reporting-intervals. I need to configure a job that
>>>> MUST use one of these intervals. If the supported-reporting-intervals
>>>> are only added to <operational> I can not validate the
>>>> selected-interval in my configured job.
>>>>
>>>> My proposal is to allow the system to add data to running as
>>>> well. Actually I think that is a more relevant case then adding
>>>> configuration just to <operation>.
>>> I think the consensus is that in general it is a bad idea if servers
>>> (spontaneously) add data to <running>.  However, there is nothing in
>>> the new or old architectures that prohibits this.
>> BALAZS: I strongly disagree.  I know others are also adding stuff to 
>> running as well.
>> IMHO the above use cases are real and used and actually important for 
>> us.
>> I would like to see them included in some way.
> I basically agree with Martin here.
>
> The architecture is cleaner if <running> is only written by the 
> client.  This avoid requiring clients tracking unexpected changes to 
> running, and opens up the possibility of validating configuration off 
> the box.  Ideally extra stuff should be added into <intended> and then 
> become visible in <operational>.
>
> I understand that some systems add data to <running>, and this is 
> fine.  But I think that it is better for an architecture document to 
> be silent on this point.
>
> Thanks,
> Rob
>
>
>>
>> regards Balazs
>> -- 
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  
>>
>>
>> _______________________________________________
>> 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