Re: [OPSAWG] Murray Kucherawy's No Objection on draft-ietf-opsawg-sdi-10: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Sun, May 17, 2020 at 1:48 AM Murray Kucherawy via Datatracker
<[e-mail]> wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-opsawg-sdi-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Bigger points first:
>
> The shepherd writeup contains this remark, which made me squint a bit: "More
> security review was asked for by the WG at various [times], and it is not clear
> that this input will be taken into account."  Why's that?


Erk! Joe (chair) is checking with the shepherd (MCR) -- I think that
this was a miscommunication -- the WG asked for more security review,
and didn't really get very much feedback. I'm hoping that this was
just poorly worded in the writeup, otherwise there is an issue here...

>
> This Informational document cites BCP 14, and then has a solitary SHOULD in
> Section 4.2.  One could easily change "SHOULD fetch" to "fetches" and do away
> with all of that.

Oooh! Nice! Done! That was the only normative reference, and so I
managed to do away with that section as well.

>
> There are several places where the prose uses two words to mean roughly the
> same thing (e.g., "store / cache").  I found this awkward each time I hit it.
> Please, in each case, pick one.  Worst case, replace the slash with "or", but
> you'll probably find that redundant anyway.

Done. Thank you, this has significantly improved readability... Also,
it turns out that XML tags, ASCII art and URLs contain a LOT of
forward slashes, which makes grepping hard :-P

>
> There are several places where a list or example is introduced with a hyphen
> (e.g., "There are two options when implementing this - a vendor could...").
> Instead, it should be a new sentence, or at least a colon followed by a clause
> or maybe a bulleted list.

Wow, there were a lot of those. Thank you, done.

>
> And now, a lot of editorial suggestions:


Wow. Apologies for how poorly written this was, and thank you for all
of the editorial work -- I really appreciate your time and effort on
this...

>
> Section 1:
> * "... or using an auto install techniques which fetch ..." --
> s/techniques/technique/, or remove "an"

DONE

* "... or something similar, is an
> unacceptable ..." -- remove the comma

DONE

* "... vendor to pre-configure the
> devices before shipping it ..." -- change either "devices" to "device", or "it"
> or "them"

DONE.

* "... configuration, etc; but these ..." -- change to "...
> configuration, etc.  However, these ..."

DONE. Nice, thank you,

* "... managing installed / deployed
> devices ..." -- suggest just picking one

DONE!

>
> Section 2:
> * "... newly installed / unconfigured ..." -- change to "... newly installed,
> unconfigured ..."

Nice. DONE.

* "... obtain an IP address and address of a config server
> ..." change to "... obtain an IP address for itself and discover the address of
> a configuration server ..."

DONE. Much better, thanks!

* "This document describes a concept ..." -- this
> paragraph feels like it belongs in Section 1


Good point -- that works much better, thanks.

>
> Section 2.1:
> * "... Point of Presence (POP) / datacenter." -- maybe just replace all of this
> with "facility"?

DONE. Thanks.

* "... device configuration, fetches the certificate ..." --
> s/,/ and/

DONE. Thanks.

* "... encrypted config ..." -- please use either "configuration"
> (preferred) or "config", but not both

DONE
Thank you - I selected "configuration" (other than in ASCII art, where
it would not really fix, and I think is clear from context).

* "... installed in Operator_A' ..." --
> missing an "s" (two instances in the third paragraph) * "... (note that all
> this ..." -- s/all this/all of this/ (and actually, this should be its own
> sentence)

DONE and DONE.

>
> OLD:
>    The device attempts to load the
>    config file - if the config file is unparsable, (new functionality)
>    the device tries to use its private key to decrypt the file, and,
>    assuming it validates, installs the new configuration.
> NEW:
>    The device attempts to load the configuration file.  As an added
>    step, if the configuration file cannot be parsed, the device tries
>    to use its private key to decrypt the file and, assuming it validates,
>    proceeds to install the new, decrypted, configuration.

Oooh, better. DONE, thanks.

>
> * "(See Security Considerations)" -- section number, please


DONE.

>
> Section 3:
> * This section doesn't appear to me to describe a role other than "vendor".
> * "... the vendors roles and ..." -- s/vendors/vendor's/

DONE.

>
> Section 3.1:
> * Please expand "EST" on first use.

DONE.

>
> Section 3.2:
> * "... store / cache ... uptime / reachability ..." -- as above, these really
> stand out to me as in need of making an editorial choice

DONE.

>
> Section 4:
> * I don't see a role in here either other than "operator".

DONE.

>
> Section 4.1:
> * "(likely serial number)" -- suggest "(e.g., the serial number)"

DONE.

>
> Section 4.2:
> * "publication server, and download ..." -- remove the comma

DONE.

>
> Section 5.1:
> * "chassis / backplane" -- another; see previous remarks

DONE.

> * TPM could use a reference (ISO/IEC 11889?)
>

NOT DONE. I will need to find a non-payware reference (the ISO one is
a 198CHF PDF). I think that the RFC Ed already has a good ref for
this...

> Section 5.3:
> * "(e.g.: 'load replace <filename> encrypted))" -- unbalanced quoting and
> parentheses
>

Indeed. DONE.

> Section 7:
> * "... may wish to bootstrapping devices with ..." -- s/bootstrapping/bootstrap/

DONE!

> * "... minimal / less sensitive ..." -- pick one, or at least use "or"

DONE.

>
> Appendix B:
> * s/csr/CSR/ (and probably expand it)

DONE.

> * "Demo / proof of concept" -- pick one

DONE (Proof of Concept).


> * "... from the command line, in production ..." -- start a new sentence

DONE.

> * Don't use "I'm".  Maybe change "I'm using S/MIME because ..." to "S/MIME is
> used here because ..."

DONE.

Thank you VERY much - I'm embarrassed by the amount of editorial work
that this needed, and really appreciate your time...

Thank you again,
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