Re: [Netconf] a couple zerotouch-21 issues

Martin Bjorklund <> Wed, 09 May 2018 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 194491275FD for <>; Wed, 9 May 2018 03:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c1gT4Y9l6066 for <>; Wed, 9 May 2018 03:40:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FFCE1201F2 for <>; Wed, 9 May 2018 03:40:34 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id EE9BB1AE034F; Wed, 9 May 2018 12:40:31 +0200 (CEST)
Date: Wed, 09 May 2018 12:40:31 +0200
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Netconf] a couple zerotouch-21 issues
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 May 2018 10:40:36 -0000


Kent Watsen <> 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


> Any thoughts, especially with regards to issue #1?
> Kent // contributor
> _______________________________________________
> Netconf mailing list