Subject: [Netmod-ver-dt] New text for example 1 in appendix

From: "Wubo (lana)" <[email-masked]>
Date: Wed, 26 Feb 2020 07:16:09 +0000

Hi all,

Here is the summary for the changes:

1.       Cleaned  up example 1 text

2.       Deleted 2 non-default schemas reported in YANG library

3.       Cleaned  up the common packages used in previous version.

4.       Added YANG library example after schema selection

Please check the changes in the attached file.

Thanks,
Bo

发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2020年2月25日 23:09
收件人: [email-masked]
主题: [Netmod-ver-dt] Today's meeting minutes

I think that this is the conclusion from today’s meeting, please send anything that I’ve missed.

Aim to get updated text by Wed’s evening, Rob will merge on Thurs, hopefully review and post on Friday.

Bo:
-          Clarify or give a better explanation of schema-set earlier in the document.
-          Clean up example 1 in appendix.

Jason:
-          Provide text about what sessions, i.e. cannot change schema in a session, kicking clients off if the session is changed, and what we are discussing in the first half of today’s meeting.

Reshad:
-          Improve/expand RESTCONF text, e.g. define what the path is used to access the RESTCONF resources, highlight that this applies to all NETCONF resources, RPCs, datastores, etc.

Rob:
-          Delete RPC from model, section 6, and check other text
-          Fix up intro text in section 10.
-          Process nits/other comments raised by Reshad/Jason
-          Improve the second appendix example, perhaps remove custom schema from the example.

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 26 Feb 2020 16:36:19 +0000

Hi Bo,

I’ve taken your example and refined it a bit more.   Does this look okay?

A.1.  Supporting older versions of a schema

   To facilitate an easier migration path for clients, a server may
   choose to support older versions of a schema, for example this might
   be done to minimize impact on clients if non-backwards-compatible
   changes have been made between schema versions.

   It is expected that the server can dynamically translate from the
   older schema version to the latest, but this is not possible in all
   cases (e.g., if support for some functionality has been removed from
   the server), when deviations against the old schema version may be
   required to accurately describe the supported functionality.

   This example illustrates a device that is capable of supporting three
   different versions of its vendor-schema, reported in '/schema-set-
   selection/schema-set':

      [email-masked], the device defaults to the latest version of
      the schema

      [email-masked], a preceding NBC software version

      [email-masked], a preceding NBC software version

   Schema selection data from the operational state datastore:

   <?xml version="1.0" encoding="utf-8"?>
   <rpc-reply
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
     <data>
       <packages>
         <package>
           <name>vendor-schema</name>
           <version>3.0.0</version>
           <!-- package modules elided -->
         </package>
         <package>
           <name>vendor-schema</name>
           <version>2.1.0</version>
           <!-- package modules elided -->
         </package>
         <package>
           <name>vendor-schema</name>
           <version>1.4.5</version>

Wilton, et al.           Expires August 29, 2020               [Page 22]

Internet-Draft            YANG Schema Selection            February 2020

           <!-- package modules elided -->
         </package>
       </packages>
       <schema-set-selection>
         <schema-set>
           <name>[email-masked]</name>
           <datastore>
             <name>ds:running</name>
             <package>
               <name>vendor-schema</name>
               <version>3.0.0</version>
             </package>
           </datastore>
           <datastore>
             <name>ds:operational</name>
             <package>
               <name>vendor-schema</name>
               <version>3.0.0</version>
             </package>
           </datastore>
           <compatible-with>[email-masked]</compatible-with>
           <compatible-with>[email-masked]</compatible-with>
         </schema-set>
         <schema-set>
           <name>[email-masked]</name>
           <datastore>
             <name>ds:running</name>
             <package>
               <name>vendor-schema</name>
               <version>2.1.0</version>
             </package>
           </datastore>
           <datastore>
             <name>ds:operational</name>
             <package>
               <name>vendor-schema</name>
               <version>2.1.0</version>
             </package>
           </datastore>
           <compatible-with>[email-masked]</compatible-with>
           <compatible-with>[email-masked]</compatible-with>
         </schema-set>
         <schema-set>
           <name>[email-masked]</name>
           <datastore>
             <name>ds:running</name>
             <package>
               <name>vendor-schema</name>

Wilton, et al.           Expires August 29, 2020               [Page 23]

Internet-Draft            YANG Schema Selection            February 2020

               <version>1.4.5</version>
             </package>
           </datastore>
           <datastore>
             <name>ds:operational</name>
             <package>
               <name>vendor-schema</name>
               <version>1.4.5</version>
             </package>
           </datastore>
           <compatible-with>[email-masked]</compatible-with>
           <compatible-with>[email-masked]</compatible-with>
         </schema-set>
       </schema-set-selection>
     </data>
   </rpc-reply>

   The client may configure the device to instead use an earlier version
   of the schema-set, [email-masked]'.  By configuring only a
   single selectable schema-set, and making it the default, means that
   this can be the only schema-set that clients use to interact to the
   device using.  On committing this configuration change, all existing
   NETCONF sessions (that were previously interacting using vendor-
   [email-masked]) will be closed, and clients need to reconnect, at which
   point they will interact with schema-set [email-masked], and
   also see the contents of YANG library updated to reflect the
   datastore-schema reported in [email-masked].

   Configuration a new default selectable schema:

   <?xml version="1.0" encoding="utf-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <schema-set-selection>
       <selectable>[email-masked]</selectable>
       <default>[email-masked]</default>
     </schema-set-selection>
   </config>

A.1.1.  Variation - Multiple selectable schema-sets

   The client may wish to interact with multiple different versions of
   the schema at the same time.  E.g., this could be achieved with the
   following configuration:

Wilton, et al.           Expires August 29, 2020               [Page 24]

Internet-Draft            YANG Schema Selection            February 2020

   Configuring multiple selectable schema:

   <?xml version="1.0" encoding="utf-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <schema-set-selection>
       <selectable>[email-masked]</selectable>
       <selectable>[email-masked]</selectable>
       <default>[email-masked]</default>
     </schema-set-selection>
   </config>

   As before, by default clients will use the [email-masked], but
   by using NETCONF capabilities exchange, or through use of the
   RESTCONF path that may select [email-masked] instead.  Clients
   could also explicitly select [email-masked], even though it is
   also the default schema-set.

Thanks,
Rob

From: Wubo (lana) <[email-masked]>
Sent: 26 February 2020 07:16
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: New text for example 1 in appendix

Hi all,

Thanks,
Bo

发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2020年2月25日 23:09
收件人: [email-masked]<mailto:[email-masked]>
主题: [Netmod-ver-dt] Today's meeting minutes

Bo:

  *   Clarify or give a better explanation of schema-set earlier in the document.
  *   Clean up example 1 in appendix.

Jason:

  *   Provide text about what sessions, i.e. cannot change schema in a session, kicking clients off if the session is changed, and what we are discussing in the first half of today’s meeting.

Reshad:

  *   Improve/expand RESTCONF text, e.g. define what the path is used to access the RESTCONF resources, highlight that this applies to all NETCONF resources, RPCs, datastores, etc.

Rob:

  *   Delete RPC from model, section 6, and check other text
  *   Fix up intro text in section 10.
  *   Process nits/other comments raised by Reshad/Jason
  *   Improve the second appendix example, perhaps remove custom schema from the example.

Thanks,
Rob