Re: [Netconf] a couple zerotouch-21 issues

Mahesh Jethanandani <> Wed, 09 May 2018 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E990129C6B for <>; Wed, 9 May 2018 14:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1PQ6MDwjea_G for <>; Wed, 9 May 2018 14:37:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1601C129C51 for <>; Wed, 9 May 2018 14:37:06 -0700 (PDT)
Received: by with SMTP id q22-v6so49pff.11 for <>; Wed, 09 May 2018 14:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VcXDyniFSZOt/JWlixzQMHDjFB61RY5jk2c8G15Pkz0=; b=Kj/KRc3lmn+lFcLRaOrMMapyUf8+pvPj5o9nplidOZOt3qyalhcCqc8cGJn5D6HJe0 Wn/Slvgsmgq+/2ksg52IyBFzTdR/L8Uma77GoG2e81FPjWgN2Qc0hlmyrHcXWMbuUZev cyh+nygYmfUTQEBSsA8w6oXeZ/RIImTIgW4QNzvT6ncvcPfP1agErNiH+AD7VL8SEwIX JgQPKUv2cpYdL5fWH5DZK/95f1wu7mke4GIks32Y7OE4lpYkwgNarH4HfsL5OsNEY5SU BdysRCrBej8/uK+Q9rJv5FPqi92lvSm8VjEG+xw+e1hRD27NP69GzKLByw+xCEKKzrMP x5Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VcXDyniFSZOt/JWlixzQMHDjFB61RY5jk2c8G15Pkz0=; b=TBw01FjKg2QR3Pasr+lInNCMdFLeIwOtsW3zh/zXV1oB1XLSZzbKgwcR1SLzw3TAhg o+geSXrFIeO4QVCT8ytilTVhlMB/P4K43f4BRo0kb31p/oY8ksExayOrVDJrj+ZJxYvu Vkjm8sNX3bYU6N4kDq9Wurk1Dn6pp3p2sRcME2czp5j/Gg+hI6lozYe1vHJrCmMOZs6q jsRoXxAILoOjLMtniopSSVwaXuR19rSe4t+x2lXAE87lRAxOG/WAp5BrMXruXiBnRFBK qrc/yVB1cSOEygS75+qMqSU13kN9w/mQnc+ilP9tPdvY8PaWyYwjdYVjBcI56XU51b29 H3lw==
X-Gm-Message-State: ALQs6tDxB/tInJfoB2AvrR2vaF99AEPq+enn5WxkNF7vR6Ltjbed0rkf Id44UGxCoDQhrCGO9Cd1SVmVKk4j
X-Google-Smtp-Source: AB8JxZoZI6yl3gaLcIhXZWUICNltN9Bd71LRvvBjWNXKvhfSRwr3y7z0lmjiIE6bVUJORRVXF/QKng==
X-Received: by with SMTP id k16mr45025317pfb.19.1525901822568; Wed, 09 May 2018 14:37:02 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:6d75:66fb:492:d069? ([2601:647:4700:1280:6d75:66fb:492:d069]) by with ESMTPSA id k13sm64240635pfj.186.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 14:37:01 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Mahesh Jethanandani <>
In-Reply-To: <>
Date: Wed, 09 May 2018 14:37:00 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Kent Watsen <>
X-Mailer: Apple Mail (2.3445.6.18)
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 21:37:08 -0000

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

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.


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