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

Martin Bjorklund <mbj@tail-f.com> Tue, 14 August 2018 21:17 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 09B25130DCF for <netconf@ietfa.amsl.com>; Tue, 14 Aug 2018 14:17:25 -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 iOqAw5rZgSTB for <netconf@ietfa.amsl.com>; Tue, 14 Aug 2018 14:17:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 92046130DC1 for <netconf@ietf.org>; Tue, 14 Aug 2018 14:17:23 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id E82151AE0426; Tue, 14 Aug 2018 23:17:20 +0200 (CEST)
Date: Tue, 14 Aug 2018 23:17:20 +0200 (CEST)
Message-Id: <20180814.231720.2109244537493128545.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <BB160F25-771C-429E-A046-8096F2ADEB44@juniper.net>
References: <F192C17C-E9EE-4C42-AA7E-3059ACCE9A61@juniper.net> <20180814.121024.510147117520021210.mbj@tail-f.com> <BB160F25-771C-429E-A046-8096F2ADEB44@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/_cNNesAcC0KQmF3jTLHAlfiNUPQ>
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 21:17:25 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> 
> >> 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).
> 
> This particular point was raised both offline as well as from the SecDir.
> From SecDir:
> 
>   """
>   I think it's already clear what an error in paragraph 6 is. What I 
>   found unclear was what to do with errors in paragraphs 6 or 7. Yes, 
>   don't go on to the next step, but what about: In paragraph 6, should 
>   the device rollback any partial config update if there's an error? 
>   In paragraph 7, should the device rollback all config from paragraph
>   6 if there's an error?
>   """

But this is a bit different than having cleanup parameters to the
scripts.  This seems to ask for a clarification that the config must
be committed all-or-nothing.  I think that it would be good to make
this clarification.

Also, in your original email in this thread you had

 c) change how script errors are handled from being "device
    reset" to "the script MUST not leave behind any state".
    This removes a potentially expensive reset, by shifting
    the onus to the script writers to do the right error
    handling logic.  Seems dangerous, but I think that it's
    fair to assume that the script can be written this way.

Ok.  OTOH I don't think that the text "the device MUST reset
itself in such a way that wipes out any bad state the script may have
left behind." implies that the reset is expensive.


/martin




> Thus, I think we need at least the high-level statement.
> 
> 
> Kent // author
>