[Netconf] a couple zerotouch-21 issues

[Kent Watsen <[e-mail]>]

A couple Last Call comments were re-raised off-list and, since the
draft is still waiting for shepherd write-up, there's an opportunity
(according to the shepherd/chair) for us to do something if desired.
Here are the issues:


1) should the "zero touch device data model" in Section 8 be normative
   or non-normative and, if normative, what should its contents be?

   Please note that a non-normative module allows for the keystore 
   (or maybe trust-anchors now) reference to be informational, so 
   this draft won't blocked in the MISREF state for as long as it
   takes for those other works to get published.  [ps: this draft
   also has a normative ref to yang-data-ext, which we thought was
   going to be a shoo-in, but now seems to be stalled in NETMOD WG]

   Options:

     a) leave as is (non-normative)

     b) just move the section to an Appendix (still non-normative)

     c) make a tiny normative module, having just the config true 
        leaf "enabled" and its parent container. (normative, but
        avoids the MISREF, but maybe too simple?)

     d) make roughly what's there now be normative (this will cause
        this draft to block on those others works in progress). [we
        would likely also want to improve it some: perhaps convert
        the idevid node to a keystore-reference and also perhaps 
        make the whole module config true to support pre-staging]

     e) remove it (note, this module was added at the very end via
        a Last Call comment.  It was essentially thrown into the
        draft as an afterthought.  It has value, but it's limited.)


2) should the "script" typedef codify any signaling mechanism?

   Currently, the description statement for "typedef script" on page
   34 says:

          No attempt is made to standardize the contents, running
          context, or programming language of the script, other than
          that it can emit an exit status code and stderr/sdtout.

   And then goes on to describe how positive exit status codes means
   "warning" and negative exit status codes means "error" and how the
   output can be sent to bootstrap server.

   The idea is to rewrite this text to just talk about "warnings" and
   "errors" instead of exit status codes and, likewise, to just
   talk about "output" instead of "stderr/stdout" specifically.

   Note: this update seems like common sense to me, and somewhat 
   editorial, so, I'll plan to make this change unless someone 
   specifically objects to it.


Any thoughts, especially with regards to issue #1?


Kent // contributor