Re: [Netconf] issues with processing onboarding information (zerotouch)

Martin Bjorklund <mbj@tail-f.com> Tue, 14 August 2018 10:10 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED181292F1 for <netconf@ietfa.amsl.com>; Tue, 14 Aug 2018 03:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSf2vg80Xxad for <netconf@ietfa.amsl.com>; Tue, 14 Aug 2018 03:10:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7AB127148 for <netconf@ietf.org>; Tue, 14 Aug 2018 03:10:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 834601AE0426; Tue, 14 Aug 2018 12:10:25 +0200 (CEST)
Date: Tue, 14 Aug 2018 12:10:24 +0200 (CEST)
Message-Id: <20180814.121024.510147117520021210.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <F192C17C-E9EE-4C42-AA7E-3059ACCE9A61@juniper.net>
References: <40EF0531-4112-4121-996F-32A030CC9670@juniper.net> <20180813.123601.53608699346435534.mbj@tail-f.com> <F192C17C-E9EE-4C42-AA7E-3059ACCE9A61@juniper.net>
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: <https://mailarchive.ietf.org/arch/msg/netconf/Ge1k-Ld-37Lw1xMG68lZKHpFW8I>
Subject: Re: [Netconf] issues with processing onboarding information (zerotouch)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2018 10:10:29 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> 
> > Do you mean that each script takes some kind of (conceptual) input
> > parameter that tells it to clean up the state produced by the previous
> > invocation?
> 
> Yes, exactly, it would be written as such, so implementations can choose
> how to do it.
> 
> 
> > Could we instead leave this to implementations?  In some environments
> > the server might be able to do the cleanup itself (which would be less
> > error prone).  In some other environments the scripts might not even
> > create any state.
> 
> Perhaps.  The text could just say "the device must, on error, exit the
> bootstrapping sequence leaving behind no state".

But even this might not be necessary in some environments.  I think
this whole notion of dealing with state associated with script
execution should be left to implementations to deal with.  It would be
ok if this document had some kind of Implementation Notes where things
like this could be discussed (w/o any 2119 language though).

> It would be good, I
> believe, to mention that some implementations may achieve this thru 
> infrastructure, whereas others may require scripts to 1) leave behind
> no state on error, and 2) provide a conceptual "clean up" parameter 
> for when an error occurs after a script had executed successfully.
> 
> What do you think?
>
> Kent


/martin