IETF Logo Mail Archive

[netmod] RFC 6022 Query

Rohit R Ranade <rohitrranade@huawei.com> Wed, 21 December 2016 09:10 UTC

Return-Path: <rohitrranade@huawei.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 6E31112952C for <netmod@ietfa.amsl.com>; Wed, 21 Dec 2016 01:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.32
X-Spam-Level:
X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lF4p0eKkZbUV for <netmod@ietfa.amsl.com>; Wed, 21 Dec 2016 01:10:47 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025EC12950B for <netmod@ietf.org>; Wed, 21 Dec 2016 01:10:46 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXL80179; Wed, 21 Dec 2016 09:10:44 +0000 (GMT)
Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 21 Dec 2016 09:10:02 +0000
Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.221]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Wed, 21 Dec 2016 17:09:49 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] RFC 6022 Query
Thread-Index: AdJbafmzui97K1h8RsGEGmV5TDm5HA==
Date: Wed, 21 Dec 2016 09:09:49 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.242.206]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B01191ADGGEMA502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.585A4714.03BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6ede5ad682ff051e2ff38df9a1e8a5d3
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/k8hIM4VLGCWf6A2AEeK5MndH5DA>
Subject: [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:10:49 -0000

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. 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

v2.23.0 | Report a Bug | By Email