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

[Mirja Kuehlewind <[e-mail]>]

Hi Warren,

See inline.

> On 7. May 2020, at 21:27, Warren Kumari <[e-mail]> wrote:
> 
> On Tue, May 5, 2020 at 11:28 AM Mirja Kühlewind via Datatracker
> <[e-mail]> 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
>> [e-mail] 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
>