Re: [netmod] 答复: pls clarify get operation

Kent Watsen <kent+ietf@watsen.net> Fri, 28 June 2019 15:24 UTC

Return-Path: <0100016b9eb005f6-11af1cb0-f3ba-4ad6-9b49-88965e668f56-000000@amazonses.watsen.net>
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 B18BA12044A; Fri, 28 Jun 2019 08:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 U8Wp1MtO7_in; Fri, 28 Jun 2019 08:24:27 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D905112042B; Fri, 28 Jun 2019 08:24:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1561735464; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ROV6shBJGwiJ2fRIK2YgntD42UfCap761OLs7Hh4/kM=; b=DFFKAmS5BbVeJSvMvMmDcyTxrAI7ToG4RY6d5xNnkXgYyGufqBl7jqPZKI1IPx2D q9EUkpJ9VYfwmFE+DJIDEJ8uilArJiaX2lck6JB0e0HWO4p69WN1P1tK3RKpZAvawEP WGF9JDU3TVaq0sY+yV/oH81Sp59qE77GcTZp5EVo=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016b9eb005f6-11af1cb0-f3ba-4ad6-9b49-88965e668f56-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D008D752-5B94-4375-B5CB-7EC4BCA650F9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 28 Jun 2019 15:24:24 +0000
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D001ED63C8@dggemm513-mbx.china.huawei.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>, "Zhangwei (SS)" <zhangwei70@huawei.com>, Yangang <yangang@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
To: "Fengchong (frank)" <frank.fengchong@huawei.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D001ED5E20@dggemm513-mbx.china.huawei.com> <BYAPR11MB2631D3A01E398ADDBB294588B5FC0@BYAPR11MB2631.namprd11.prod.outlook.com> <20190628085014.ljxh73fcmiu6iqx7@anna.jacobs.jacobs-university.de> <5756FB984666AD4BB8E1D63E2E3AA3D001ED6082@dggemm513-mbx.china.huawei.com> <BYAPR11MB2631B6688BB094D93BACAD6AB5FC0@BYAPR11MB2631.namprd11.prod.outlook.com> <5756FB984666AD4BB8E1D63E2E3AA3D001ED63C8@dggemm513-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.28-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gD2gva7UDK0bUl7sVan8zpgA-ag>
Subject: Re: [netmod] 答复: pls clarify get operation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Jun 2019 15:24:32 -0000

Hi Frank,

>    I think IETF solution: migrate to NMDA is unrealistic. The cost of migration to NMDA is too expensive, If the entire industry migrates to NMDA, the time will be long.

Does Huawei wish to be a leader or a follower?   If servers support both, the clients will quickly adapt.  As for myself, a server I'm working on only supports NMDA.  


>    This will delay the deployment of the IETF model in the industry. 
>    Anyway, even if vendor implements NMDA, the network manager/ controller or client tools may not support NMDA client. 
>    A non-NMDA client only support get/get-config, it still has no way to retrieve system-controlled data.
> 
>    Generation config false copy for IETF YANG model is not reasonable, because published IETF standard YANG should not be changed, moreover, this is not friendly to the client or the server.


Some drafts already publish a "state" module in their Appendix and, when they do, there is a completely standard non-NMDA IETF solution.  I don't know if this strategy is being followed universally but, if not, then I don't believe the IETF would object at all to the publication of drafts for missing state models in drafts that only assumed NMDA.

Your message seems to wish for some automatic universal support in the protocols for converting NMDA models to non-NMDA models.  Whilst that would be possible, and you're welcome to submit a draft for it, it seems that the solution would entail protocol extensions that non-NMDA clients/servers would also have to be updated to support, at which point I'd argue that they would be better off supporting NMDA, which provides a superior solution.

Kent // contributor