Hi Warren, See inline. > On 7. May 2020, at 21:27, Warren Kumari <warren@xxxxxxxxxx> wrote: > > On Tue, May 5, 2020 at 11:28 AM Mirja Kühlewind via Datatracker > <noreply@xxxxxxxx> 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@xxxxxxxx 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 > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
