Re: [Netconf] a couple zerotouch-21 issues

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> 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.)

If it wasn't for the timing issue, I'd vote for (d); I think that is
the proper thing to do.  But I really want to see this draft
published, so I think it is best to do (e).  We can always do (d) in a
future bis version, or in a future separate document.


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

I have made this comment in my earlier reviews of this document, so I
support this change.


Regarding the yang-data reference, I suggest you change the draft to
use rc:yang-data, and split the current "zerotouch-information" into
two separate rc:yang-data "redirect-information" and
"onboarding-information".


/martin



> 
> 
> Any thoughts, especially with regards to issue #1?
> 
> 
> Kent // contributor
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>