Re: [netmod] RFC 6022 Query

Rohit R Ranade <rohitrranade@huawei.com> Fri, 23 December 2016 05:15 UTC

From: Rohit R Ranade <rohitrranade@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [netmod] RFC 6022 Query
Thread-Index: AdJbafmzui97K1h8RsGEGmV5TDm5HP//fzkA//yf0cA=
Date: Fri, 23 Dec 2016 05:15:33 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B011C87@DGGEMA502-MBX.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6B01191A@DGGEMA502-MBX.china.huawei.com> <20161221.102852.1273087448152459126.mbj@tail-f.com>
In-Reply-To: <20161221.102852.1273087448152459126.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TEIP0OcUSveTly9juFSqGUJAqMw>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] RFC 6022 Query
Precedence: list

Ok Got it.

2.1.1.  The /netconf-state/capabilities Subtree

   The /netconf-state/capabilities subtree contains the capabilities
   supported by the NETCONF server.  The list MUST include all
   capabilities exchanged during session setup still applicable at the
   time of the request.

Q1 : So "/netconf-state/capabilities" is specifically for client to periodically check the capabilities and will be mainly used if the Server does not support netconf-capability-change[RFC 6470] notification ?
Q2 : Currently  YANG module loading / unloading can add/delete capabilities. Is there any other scenario where capabilities can be added/deleted/modified ? 

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 21 December, 2016 17:29
To: Rohit R Ranade
Cc: netmod@ietf.org
Subject: Re: [netmod] RFC 6022 Query

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

[netmod] RFC 6022 Query Rohit R Ranade
Re: [netmod] RFC 6022 Query Martin Bjorklund
Re: [netmod] RFC 6022 Query Rohit R Ranade