[Netmod-ver-dt] Solution overview draft, delete duplicate requirements

["Rob Wilton (rwilton)" <[e-mail]>]

One item of feedback received from the mic was to not list the requirements in two places.

Currently, the solution overview draft has the following text.  I'm proposing that I just remove the section 2 (which is a rewording of the requirements), since the introduction already references the requirements.

Any objections?

Thanks,
Rob


1.  Introduction

   TODO - Fixup references to individual drafts.

   [I-D.ietf-netmod-yang-versioning-reqs] documents the requirements for
   any solution to the YANG versioning problem.  Chapter 5 lists the
   formal requirements that a complete solution requires.

   The aim of this draft is to help readers understand how the different
   solution drafts fit together, and also which drafts contribute
   solutions to particular individual requirements.  The overall
   solution comprises five individual drafts:

   1.  Module revision extensions

   2.  Module semantic version number scheme

   3.  [I-D.rwilton-netmod-yang-packages]

   4.  [I-D.wilton-netmod-yang-ver-selection]

   5.  YANG schema comparison tooling (not yet published)

   Open issues, across all of the solution drafts are tracked at
   <https://github.com/netmod-wg/yang-ver-dt/issues>.








Wilton                  Expires December 2, 2019                [Page 2]


Internet-Draft      YANG Versioning Solution Overview           May 2019


2.  Summary of requirements

   The requirements are formally documented in section 5 of
   [I-D.ietf-netmod-yang-versioning-reqs].  A shortened, non normative,
   summary of each of the requirements (using the same requirement
   numbers) is provided below to help understand how the solutions
   drafts address the particular requirements.

      Req 1.1 - MUST allow nbc updates to a module without breaking
      imports.

      Req 1.2 - MUST allow nbc updates to a module without affecting
      existing client code using only unchanged data nodes.

      Req 1.3 - MUST support import statement restricted to only some
      revisions.

      Req 1.4 - MUST allow for fixes to non-latest published modules.

      Req 2.1 - MUST be able to determine if two arbitrary versions of
      any module are backwards-compatible.

      Req 2.2 - SHOULD be able to determine if two arbitrary versions of
      any data node are backwards-compatible.

      Req 3.1 - MUST allow servers to support existing clients.

      Req 3.2 - MUST allow simultaneously support of clients using
      different (perhaps restricted) revisions.

      Req 3.3 - MAY assume clients can handle unexpected instance data
      gracefully.

      Req 4.1 - MUST provide a way to indicate if deprecated nodes are
      implemented.

      Req 4.2 - MUST be able to document the reason for data node
      lifecycle changes, and possible alternative data nodes.

      Req 4.3 - MUST be able to forewarn of future data node lifecycle
      changes.

      Req 5.1 - MUST provide guidance on how to use the new scheme.

      Req 5.2 - MUST provide, and document, an upgrade path from
      existing YANG/protocols.

      Req 5.3 - MUST consider the impact of versioning on instance data.