Return-Path: <0100016b9eb005f6-11af1cb0-f3ba-4ad6-9b49-88965e668f56-000000@amazonses.watsen.net> 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 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 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)" , Juergen Schoenwaelder , "netmod@ietf.org" , "Zhangwei (SS)" , Yangang , "netconf@ietf.org" To: "Fengchong (frank)" References: <5756FB984666AD4BB8E1D63E2E3AA3D001ED5E20@dggemm513-mbx.china.huawei.com> <20190628085014.ljxh73fcmiu6iqx7@anna.jacobs.jacobs-university.de> <5756FB984666AD4BB8E1D63E2E3AA3D001ED6082@dggemm513-mbx.china.huawei.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: Subject: Re: [netconf] =?utf-8?b?W25ldG1vZF0g562U5aSNOiAgcGxzIGNsYXJpZnkgZ2V0?= =?utf-8?q?__operation?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 15:24:32 -0000 --Apple-Mail=_D008D752-5B94-4375-B5CB-7EC4BCA650F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. =20 > This will delay the deployment of the IETF model in the industry.=20= > Anyway, even if vendor implements NMDA, the network manager/ = controller or client tools may not support NMDA client.=20 > A non-NMDA client only support get/get-config, it still has no way = to retrieve system-controlled data. >=20 > 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 --Apple-Mail=_D008D752-5B94-4375-B5CB-7EC4BCA650F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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

= --Apple-Mail=_D008D752-5B94-4375-B5CB-7EC4BCA650F9--