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

Warren Kumari <warren@kumari.net> Thu, 07 May 2020 19:28 UTC

Return-Path: <warren@kumari.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 EE4573A0D52 for <tsv-art@ietfa.amsl.com>; Thu, 7 May 2020 12:28:14 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 siPuxtr43z5r for <tsv-art@ietfa.amsl.com>; Thu, 7 May 2020 12:28:12 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 92DC13A0D51 for <tsv-art@ietf.org>; Thu, 7 May 2020 12:28:08 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id w20so7637150ljj.0 for <tsv-art@ietf.org>; Thu, 07 May 2020 12:28:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BLoWXjI+aUpURVQ9A/mMNbG3B/ScWhYXCURDgDGByVU=; b=c8tTRg3bmNXsaQN4Kmcx7kpqT2bXm9oQBF7P0shNUguKxaEhZ1OiX0aBdkupsIa5SM ZjL2qeI57QjFCX6m+0Kd3T3PVIcNC86C8VYRvu81Zdvz6qnrSOxlD3pA5UeaTjuuJfvx XPzCtW5eML7D1qZ9d6nCUMExaH4EQvhe7vKniKncfE/1nz8ntP74sKZgum5B187guMwe iqJ4ybIxMNylaV4khSqR+1wZcAWbKFBOXZt6S6S8xFd0Mchs1j+KtMGvS7jRBXXNy/Dl m/hapAKiRpB4jDNUwhtfIgHXH0YdQFRMjmTsrzCjFyu2HUrmivZ7f+qf+4D4WJs6VPQn 5i0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BLoWXjI+aUpURVQ9A/mMNbG3B/ScWhYXCURDgDGByVU=; b=JAZEUNqYHUhqrNQCZztFPnTSP5+esTao9xBcSCZN6QDJZ9ROIYnxKibTTRgJgiHbut IPHdHPih/A5es4CTbOL6fqufQp9igB2LjszuT6dQLIeKy83OrVoZvHRpj9U75iZEJPKk VbizMM1Y+Lc1a3Ble4q7UCEn3hsRE1/TMir1C1SKOSLS0Z7BWKy+yz84901Chtr7bqr3 2FsrzJvB9c8OeKAwGPDHCKe4NpWhmn0VIDcD7H4rv1IIeviXYMPnLolWIEf2HEm4OkAt ywVEAmrpxxCvLPHNRa650lSzYXgZuj/i+ZHYmpkuAAL8Trl8UGIBbbMP6kU+rvV8Qj/p Olgw==
X-Gm-Message-State: AGi0PubyGZR0ORKP6or5t/dsv7rgRTrA6UqM4TJ8D9w2s9bzA1Appsc/ 5z8XcGgu4SVIZ8NvQCwwHBES7GPD2aDkkKnmpwIPmQ==
X-Google-Smtp-Source: APiQypIMUWujQI3h9BixUu6NUk3zYPubn+GFZCyn2MdAge8rp6Molno7s9q0YWpBV4AMQpF/fHLMcGjhurDxki9lrtE=
X-Received: by 2002:a2e:9048:: with SMTP id n8mr9569276ljg.122.1588879686606; Thu, 07 May 2020 12:28:06 -0700 (PDT)
MIME-Version: 1.0
References: <158869247940.11245.12621022136416122709@ietfa.amsl.com>
In-Reply-To: <158869247940.11245.12621022136416122709@ietfa.amsl.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 7 May 2020 15:27:30 -0400
Message-ID: <CAHw9_iK8-bTm6teZPjwdvHLNHeWJsY5BeuW9Ux1HcirP_L9znQ@mail.gmail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Cc: tsv-art@ietf.org, opsawg <opsawg@ietf.org>, draft-ietf-opsawg-sdi.all@ietf.org, last-call@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/HAkGYz-gu_Oki5VV3UpQk9nH_Nc>
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: Thu, 07 May 2020 19:28:21 -0000

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...


>
> 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...

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