Re: [Netconf] Mirja Kühlewind's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 06 December 2018 17:25 UTC

Return-Path: <ietf@kuehlewind.net>
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 75037130E81; Thu, 6 Dec 2018 09:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 X7f86UzklBnc; Thu, 6 Dec 2018 09:24:57 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8BC128CF3; Thu, 6 Dec 2018 09:24:57 -0800 (PST)
Received: from [2001:67c:10ec:5785:8000::430] (helo=ict-networks-2001-067c-10ec-5785-8000-0000-0000-0430.fwd-v6.ethz.ch); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gUxOQ-0002db-A7; Thu, 06 Dec 2018 18:24:54 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <A2E1042D-7543-424A-8E4F-AC7AD6732A1F@juniper.net>
Date: Thu, 6 Dec 2018 18:24:52 +0100
Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, The IESG <iesg@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0364247-B75F-49F3-8DA9-24AD7F007CB2@kuehlewind.net>
References: <154360369395.27402.18143504350346119719.idtracker@ietfa.amsl.com> <B0AF8548-5434-4A25-8D61-D80F6CB57FF6@juniper.net> <9964AC41-9B1E-4348-94C8-C9CED80D9147@kuehlewind.net> <A2E1042D-7543-424A-8E4F-AC7AD6732A1F@juniper.net>
To: Kent Watsen <kwatsen@juniper.net>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1544117097;92c00fcb;
X-HE-SMSGID: 1gUxOQ-0002db-A7
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/jDSHP-t_wZWqfJbvbK_xqd4M960>
Subject: Re: [Netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-zerotouch-25=3A_=28with_COMMENT=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 06 Dec 2018 17:25:01 -0000

Hi Kent,

sorry I didn’t read this as a question. However, looking at this again, I actually think the text is pretty clear as it is and I must have overlooked this on my first read. So I guess no further action needed. Thanks for engaging!

Mirja



> Am 06.12.2018 um 17:40 schrieb Kent Watsen <kwatsen@juniper.net>et>:
> 
> 
> Hi Mirja,
> 
> I assume you're happy with the Github commit, but what about the [uncommitted] proposal to add something like ", thus ensuring all possible bootstrapping options are attempted before starting over." to the end of the text in Section 5.6 discussed below?
> 
> Kent
> 
> 
> 
> -----Original Message-----
> From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
> Date: Thursday, December 6, 2018 at 10:49 AM
> To: Kent Watsen <kwatsen@juniper.net>
> Cc: The IESG <iesg@ietf.org>rg>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>rg>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>rg>, NETCONF Working Group <netconf@ietf.org>
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)
> 
> Thanks! That helps!
> 
> 
>> Am 06.12.2018 um 02:40 schrieb Kent Watsen <kwatsen@juniper.net>et>:
>> 
>> Hi Mirja,
>> 
>> Thanks for your review!
>> Please see below for responses.
>> 
>> Kent // principle author
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>>> Thanks for this well-written doc.
>>> 
>>> One quick question which wasn't fully clear to me from the text
>>> in the doc: If onboarding fails at some point, is the device
>>> supposed to iterate over another bootstrapping source or stop
>>> completely?
>> 
>> The device is to never stop trying to bootstrap, even in case of
>> a failed attempt.  The hope is that that the device's failed
>> attempts will be noticed and rectified by an administrator of
>> the operator's orchestrator/NMS system.
>> 
>> Checking the text to ensure this intent is conveyed, we find in
>> Section 5.3:
>> 
>>  Otherwise, the device MUST attempt to process the onboarding
>>  information as described in Section 5.6.  In either case, success or
>>  failure, the device MUST exit the recursive algorithm, returning to
>>  the bootstrapping sequence described in Section 5.2, the only
>>  difference being in how it responds to the "Able to bootstrap from
>>  any source?" conditional described in the figure in the section.
>> 
>> So, in your case, it is a "failure" and thus the answer to the
>> conditional is "No".  However, to your point, the current s5.2 
>> text says "Loop and/or wait for manual provisioning", which 
>> isn't quite right.  I have fixed this in the Github commit 
>> link provided below.
>> 
>> Continuing checking the text, we also find in Section 5.6:
>> 
>>  If the device encounters an error at any step, it MUST stop
>>  processing the onboarding information and return to the bootstrapping
>>  sequence described in Section 5.2.  In the context of a recursive
>>  algorithm, the device MUST return to the enclosing loop, not back to
>>  the very beginning.
>> 
>> Which I think is pretty good as is, though it might help to tack
>> onto the end of the last sentence ", thus allowing the logic to
>> attempt all possible bootstrapping options before starting over."
>> Thoughts?
>> 
>> 
>> 
>>> One minor comment:
>>> Maybe spell out TPM and provide a reference.
>> 
>> Fixed all three instances of "TPM".
>> 
>> 
>> 
>> Here is the Github commit for the above changes, as well as a
>> minor/unrelated RFC4408-reference issue reported by Adam:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_zero-2Dtouch_commit_0e86ec25f0f83c49dc1ec37e2b9f20bdec874a6f&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=tdPa_tMXTHo9_nEeMuGHsRyflARVGiqV5uz_oxwxZcg&s=IUawZTPKc9rN7G2W3eQO0S-BxaBUz8M1jWwj1GaprCI&e=
>> 
>> Thoughts?
>> 
>> Kent
>> 
>> 
>> 
>> 
> 
>