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

Mirja Kuehlewind <> Fri, 08 May 2020 07:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 626DE3A0859; Fri, 8 May 2020 00:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lHhKCS_RnzUh; Fri, 8 May 2020 00:26:50 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id A7D063A0853; Fri, 8 May 2020 00:26:49 -0700 (PDT)
Received: from ([2003:de:e700:7a00:8907:a2ee:8cfc:aceb]); authenticated by 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 <>
In-Reply-To: <>
Date: Fri, 8 May 2020 09:26:44 +0200
Cc:, opsawg <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Warren Kumari <>
X-Mailer: Apple Mail (2.3445.104.14)
X-HE-SMSGID: 1jWxPB-0008UP-6p
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-opsawg-sdi-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:
> On Tue, May 5, 2020 at 11:28 AM Mirja Kühlewind via Datatracker
> <> 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
>> 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 ;-) 


> 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