Re: [Netconf] a couple zerotouch-21 issues

[Mahesh Jethanandani <[e-mail]>]

> On May 8, 2018, at 12:25 PM, 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.)

In the interest of time, and the need to publish this document sooner than later, my vote would be for b). I agree that a non-normative example is better than no example at all, however evolved or not evolved the current example is.

Thanks.

Mahesh // as contributor.

> 
> 
> 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
> 
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf