Re: [Netconf] a couple zerotouch-21 issues

Hi Kent,

> Kent Watsen, May 8, 2018 3:25 PM
> 
> 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.)

(a), (b), & (e) all seem reasonable to me.  Although if (a) or (b), a fix the single container yang-data question in NETMOD would seem to be needed anyway.  Has that been resolved?   If not, per the NETMOD yang-data threads, it doesn't seem like the choice in the yang-data is something which is trivial to resolve.  If that is the case, it seems like Martin's proposal to do (e) delivers something quickly, which would be helpful.   

Note: Also in the model, listing "port" within a device model where a transport protocol is known has proven surprisingly controversial.  (e) avoids the potential for delays from revisiting that as well.

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

Getting away from actions on the range of error status codes is a good idea within the description, although this might not matter is (e) is chosen above.

Eric

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