IETF Logo Mail Archive

Re: [Netconf] netconf-binary-encoding comments

Qin Wu <bill.wu@huawei.com> Mon, 09 July 2018 01:30 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC95130EEB; Sun, 8 Jul 2018 18:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sapiR2P_Uq-0; Sun, 8 Jul 2018 18:30:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF3312777C; Sun, 8 Jul 2018 18:30:28 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DD70A599D9EEA; Mon, 9 Jul 2018 02:30:24 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 9 Jul 2018 02:30:25 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.13]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0382.000; Mon, 9 Jul 2018 09:30:22 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, Andy Bierman <andy@yumaworks.com>
CC: "draft-ietf-netconf-nmda-restconf@ietf.org" <draft-ietf-netconf-nmda-restconf@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>
Thread-Topic: [Netconf] netconf-binary-encoding comments
Thread-Index: AQHUFHIPJkzJWXW1BE+UQ4og/X05xqSARWmAgAEgCICAAHApgIAACu4AgAAMegCAAAVSAIAAMZUAgAAxtwCAAAetAIADwX+w
Date: Mon, 09 Jul 2018 01:30:21 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AEEF343@nkgeml513-mbx.china.huawei.com>
References: <14395e68-eb71-7766-d4d2-4de0ea67681f@ericsson.com> <CABCOCHRJM5vTgTXcNircjcn6DCqK5fzW3E2rjMM6sb3A3Edz_g@mail.gmail.com> <79d3af9b-dd0c-833b-491f-a25a54a38559@cisco.com> <CABCOCHQfwND7uezS_ykQ4G-v_JPNqTx0Pw3hJVqTVB83XqJgzw@mail.gmail.com> <d6109edb-d54d-2e58-d830-6410f1a22013@cisco.com> <20180706172308.5ro5cjv3x7ujopsx@anna.jacobs.jacobs-university.de> <CABCOCHTj0FTzC6_96dgo8MYnPowWSqF5HRy-eU3nPvRzVLVS5w@mail.gmail.com> <70874365-9182-413D-8FD5-927941DA7E08@juniper.net> <CABCOCHS=YEP_7EC8kxU=72f-swd8wP_ixV4rfk2CG1KGtfL6jQ@mail.gmail.com> <E57B965F-F572-418A-B600-3AC150C06894@juniper.net>
In-Reply-To: <E57B965F-F572-418A-B600-3AC150C06894@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AEEF343nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lD3hpB09t831ptmSCVGs-QZnUQc>
Subject: Re: [Netconf] netconf-binary-encoding comments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 01:30:30 -0000

> Why would the unified API be considered harmful to the Internet if NMDA datastores are also present?
> I see no reason to remove existing APIs just because new ones are added.

nmda-restconf preserves the /data resource from RFC 8040.  My comment is more about the lack of information for when the client chooses to use <running> or <candidate> instead.  Maybe it's obvious, not sure, hence the comment.

[Qin]: If my understanding is correct, when :writable-running capability is supported, the client will chose to use <running>,only when <candidate> capability is supported, the client will choose to use <candidate>.

v2.23.0 | Report a Bug | By Email