Subject: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-sdi-08

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 05 May 2020 08:27:59 -0700

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
[email-masked] 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.

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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 May 2020 11:40:28 -0400

Mirja Kühlewind via Datatracker <[email-masked]> wrote:
    > 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.

I wonder if we shouldn't reserve "example.com" in a few more languages so
that we can "Example.com" and пример.net, and Beispiel.org

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Warren Kumari <[email-masked]>
Date: Thu, 7 May 2020 15:23:37 -0400

> that we can "Example.com" and пример.net, and Beispiel.org

Due to the wonders of IDN, we can probably also abuse this into
"eXample.com", "exAmple.com", "EXample.com", "ExAmple.com", etc. As
"example" has 7 characters, I calculate we can have 127 variations of
this. We also now have ~1513 TLDs, so we can have 192151
variations....
Currently an RFC is "Each page must be limited to 58 lines followed by
a form feed" -- this means that if we published an RFC with only these
variations, and no other text, it would be 3,313 pages long (and more
like 87,000 with boilerplate :-)). This is 6.6 reams of paper, or a
stack ~35cm high (13.5" for
mericans...)

I encourage someone (not me!) to write this....

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 7 May 2020 15:27:30 -0400

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

> companies. I know it's boring but Vendor A and Operator B would probably work

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 8 May 2020 09:26:44 +0200

Hi Warren,

See inline.

> On 7. May 2020, at 21:27, Warren Kumari <[email-masked]> wrote:
> 
> 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).

> Operator_A and Vendor_B…

That works for me as well ;-) 

Mirja