Re: [Netconf] 答复: How to specify a namespace in a options/get/head/delete request

Jan Lindblad <janl@tail-f.com> Mon, 31 July 2017 07:48 UTC

Return-Path: <janl@tail-f.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 D3792131EB8 for <netconf@ietfa.amsl.com>; Mon, 31 Jul 2017 00:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vVS6tIFwc1Z3 for <netconf@ietfa.amsl.com>; Mon, 31 Jul 2017 00:48:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A280128961 for <netconf@ietf.org>; Mon, 31 Jul 2017 00:48:54 -0700 (PDT)
Received: from [10.147.40.80] (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9B6161AE0471; Mon, 31 Jul 2017 09:48:51 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jan Lindblad <janl@tail-f.com>
In-Reply-To: <0bc61647-ebda-1a4c-a0ec-f5d51f1942d2@alumni.stanford.edu>
Date: Mon, 31 Jul 2017 09:48:47 +0200
Cc: netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2708698-F090-4E5D-A805-C75E65F85E14@tail-f.com>
References: <244417CB9E0F1F4A8D41313D09799166FE02AA@dggemm513-mbx.china.huawei.com> <CALAkb6cZtth7WT27v-Uz2Kj60YcLgzekjV7H=kPUzsdbVEGSBA@mail.gmail.com> <244417CB9E0F1F4A8D41313D09799166FE05D7@dggemm513-mbx.china.huawei.com> <CBDAF9FA-A743-4361-9FAE-921A86356E99@nic.cz> <194C4B51-5619-47AA-AC47-ED023992ECC3@juniper.net> <20170728141341.GA29649@elstar.local> <09008DE4-2237-4E8A-94AE-82F53449A62D@juniper.net> <20170728163712.GA29981@elstar.local> <0bc61647-ebda-1a4c-a0ec-f5d51f1942d2@alumni.stanford.edu>
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xzZ1AzJ1rUDwAx_VVQgKlA7QscM>
Subject: Re: [Netconf] 答复: How to specify a namespace in a options/get/head/delete request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
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, 31 Jul 2017 07:48:56 -0000

Use cases where support for multiple versions of hardware, software, services, ... are required are quite common, in my experience. The good news is that this is well within reach for NETCONF+YANG without any sort of extensions or tweaking. What you seem to forget is that the version of the YANG model description of an object is quite separate from the version of the object that it describes. 

It's trivial to make a YANG model has a list of line cards with a choice of linecard-xyz-v13 and linecard-xyz-v14. And in the next version of the YANG model, extend the model to also include linecard-xyz-v12.

/jan

> On 7/28/2017 9:37 AM, Juergen Schoenwaelder wrote:
> ...
>> Lets not turn a simple statement into a complex nightmare. RFC 7950
>> said: A server MUST NOT implement more than one revision of a module.
>> What is the reason to relax this simple and clear statement? Just
>> because we can is not a good reason.
> 
> Back in the 1980's I encountered systems (both telco and internet) that
> could be simultaneously populated with multiple versions of a given kind
> of card, and in some cases the management properties of these versions
> differed, though usually in ways easily handled through inheritance in
> OO models.  But support for such configurations has long been considered
> beyond the scope of netconf - if one needed to do it, then rather than
> "revising" the module one would create a new one which would bear a
> remarkable resemblance to the old one, and presumably fork any module-
> specific management software accordingly.
> 
> Randy
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>