Re: [netmod] RFC 6022 Query

Martin Bjorklund <mbj@tail-f.com> Wed, 21 December 2016 09:29 UTC

Return-Path: <mbj@tail-f.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 4F684129489 for <netmod@ietfa.amsl.com>; Wed, 21 Dec 2016 01:29:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 J1AfhMP-1jkW for <netmod@ietfa.amsl.com>; Wed, 21 Dec 2016 01:28:59 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA87129458 for <netmod@ietf.org>; Wed, 21 Dec 2016 01:28:55 -0800 (PST)
Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 487051AE030A; Wed, 21 Dec 2016 10:28:54 +0100 (CET)
Date: Wed, 21 Dec 2016 10:28:52 +0100
Message-Id: <20161221.102852.1273087448152459126.mbj@tail-f.com>
To: rohitrranade@huawei.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CecracLxuJIRUk00i96ApvqS0v4>
Cc: netmod@ietf.org
Subject: Re: [netmod] RFC 6022 Query
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 21 Dec 2016 09:29:00 -0000

Hi,

Rohit R Ranade <rohitrranade@huawei.com> wrote:
> Hi All,
> 
> /netconf-state/schemas ==> Will be used to retrieve the list of
> schemas in the device.
> <get-schema> will be used to get the actual schema file-content based
> on the contents of the schema list.
> 
> Q1: Section 2.1.3 has the below statement for "version":
> 
> For YANG data models, version is the value of the most recent YANG
>       'revision' statement in the module or submodule, or the empty
>       string if no 'revision' statement is present.
> 
> This clearly means that all the revisions of a YANG module will not be
> listed.

No.  See the paragraph above the quoted one:

      Multiple versions MAY be
      supported simultaneously by a NETCONF server.  Each version MUST
      be reported individually in the schema list, i.e., with same
      identifier, possibly different location, but different version.

The text just means that for YANG module (in both formats 'yang' and
'yin') the version will contain the current revision for that version
for the module.

I hope this clarifies the rest of your questions below.


> If a device has the YANG and YIN format for all the modules,
> then the YIN format is shown with all the revisions, but the YANG
> format will be shown with the highest revision only.
> What is the logic behind this difference in behavior ? YANG is reader
> friendly while YIN is operation(xml parsing) friendly. I feel it is a
> valid scenario to have both these format in the device.
> 
> Q2: Since all the revisions are never shown for YANG in the schema
> list, there is no mechanism to extract the lower revisions using
> <get-schema>. The <hello> response from server also shows only the
> highest revision.
> One scenario for lower version usage : The import statement allows
> import by revision. Consider ModuleA imports SubModuleB with a lower
> revision. The user will never be able to get the lower revision file
> of SubModule B ?  If some content has been deleted / modified in the
> latest revision of SubModule B it will cause confusion.
> 
> With Regards,
> Rohit


/martin