Re: [Tsv-art] Tsvart last call review of draft-ietf-opsawg-sdi-08

Mirja Kuehlewind <ietf@kuehlewind.net> Fri, 08 May 2020 07:26 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626DE3A0859; Fri, 8 May 2020 00:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 lHhKCS_RnzUh; Fri, 8 May 2020 00:26:50 -0700 (PDT)
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 A7D063A0853; Fri, 8 May 2020 00:26:49 -0700 (PDT)
Received: from p200300dee7007a008907a2ee8cfcaceb.dip0.t-ipconnect.de ([2003:de:e700:7a00:8907:a2ee:8cfc:aceb]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jWxPB-0008UP-6p; Fri, 08 May 2020 09:26:45 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CAHw9_iK8-bTm6teZPjwdvHLNHeWJsY5BeuW9Ux1HcirP_L9znQ@mail.gmail.com>
Date: Fri, 8 May 2020 09:26:44 +0200
Cc: tsv-art@ietf.org, opsawg <opsawg@ietf.org>, draft-ietf-opsawg-sdi.all@ietf.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C8B0FBE-EF02-4EDF-B4F4-6A9F1AA8AACF@kuehlewind.net>
References: <158869247940.11245.12621022136416122709@ietfa.amsl.com> <CAHw9_iK8-bTm6teZPjwdvHLNHeWJsY5BeuW9Ux1HcirP_L9znQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3445.104.14)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1588922810;414bc21a;
X-HE-SMSGID: 1jWxPB-0008UP-6p
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/CaFFLOWK1Hv7oljqBcShigCU_Eg>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-opsawg-sdi-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 07:26:53 -0000

Hi Warren,

See inline.

> On 7. May 2020, at 21:27, Warren Kumari <warren@kumari.net> wrote:
> 
> On Tue, May 5, 2020 at 11:28 AM Mirja Kühlewind via Datatracker
> <noreply@ietf.org> wrote:
>> 
>> Reviewer: Mirja Kühlewind
>> Review result: Ready
>> 
>> This document has been reviewed as part of the transport area review team's
>> ongoing effort to review key IETF documents. These comments were written
>> primarily for the transport area directors, but are copied to the document's
>> authors and WG to allow them to address any issues raised and also to the IETF
>> discussion list for information.
>> 
>> When done at the time of IETF Last Call, the authors should consider this
>> review as part of the last-call comments they receive. Please always CC
>> tsv-art@ietf.org if you reply to or forward this review.
>> 
>> This document specifies a process to encrypt an initial configuration file. The
>> process of fetching the config file is not altered and as such there are no new
>> transport related issue.
>> 
>> However, one quick question/comment regarding the following sentence in section
>> 4.3.: "if parsing the
>>   configurations fails, the device will either abort the auto-install
>>   process, or will repeat this process until it succeeds."
>> Is this supposed to indicate that the whole process, including fetching the
>> file should be repeated? If so, there needs to be guidance that one should not
>> immediately fetch again but wait for a period of maybe seconds (or minutes?)
>> and a limit for maximum number of retries must be implemented. Yes, this is not
>> necessarily part of the process that is altered in this document but if this
>> guidance is given it should be correct. If similar guidance is already provides
>> in other documents, a pointer to those docs might work as well.
> 
> Thank you! This solution does not need to be particularly agile -- the
> "initial" install of a device only happens once (or possibly a few
> times if the config is deleted / hard disks die, etc), and so I've
> recommended:
> "When retrying, care should be taken to not
> overwhelm the server hosting the encrypted configuration files. It is
> recommended
> that the device retry every 5 minutes for the first hour, and then
> every hour after
> that. As it is expected that devices may be installed well before the
> configuration file is ready, a maximum number of retrys is not specified."
> 
> I could see situations where a device gets installed and the engineers
> haven't finished writing the configs when the device is first turned
> on -- I don't want things to end up in a situation where devices try
> for a few days and then give up and require someone to poke them to
> restart this process.
> The "try every hour" is somewhat arbitrary, but even a tiny web server
> should be able to happily handle ~1000QPS, which means that it could
> support ~3.6M devices all stuck in an infinite retry loop…
> 
Thanks! I guess it could still be good to at least mention that there should be some termination condition (and that it should be in order of multiple days).

> 
>> 
>> Editorial comment:
>> I would recommend to use more generic company names than Sirius Cybernetics
>> Corp and Acme Network Widgets to avoid that these names can be mistaken as real
>> companies. I know it's boring but Vendor A and Operator B would probably work
>> just fine.
>> 
>> 
> 
> Sad panda, but you are right.... I replaced Sirrius and Acme with
> Operator_A and Vendor_B…

That works for me as well ;-) 

Mirja


> 
> Thank you again for your review, I'm publishing a new version with
> these addressed now.
> W
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
>