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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Sat, 16 May 2020 22:48:00 -0700

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?

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.

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.

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.

And now, a lot of editorial suggestions:

Section 1:
* "... or using an auto install techniques which fetch ..." --
s/techniques/technique/, or remove "an" * "... or something similar, is an
unacceptable ..." -- remove the comma * "... vendor to pre-configure the
devices before shipping it ..." -- change either "devices" to "device", or "it"
or "them" * "... configuration, etc; but these ..." -- change to "...
configuration, etc.  However, these ..." * "... managing installed / deployed
devices ..." -- suggest just picking one

Section 2:
* "... newly installed / unconfigured ..." -- change to "... newly installed,
unconfigured ..." * "... 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 ..." * "This document describes a concept ..." -- this
paragraph feels like it belongs in Section 1

Section 2.1:
* "... Point of Presence (POP) / datacenter." -- maybe just replace all of this
with "facility"? * "... device configuration, fetches the certificate ..." --
s/,/ and/ * "... encrypted config ..." -- please use either "configuration"
(preferred) or "config", but not both * "... 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)

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.

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

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

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

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

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

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

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

Section 5.1:
* "chassis / backplane" -- another; see previous remarks
* TPM could use a reference (ISO/IEC 11889?)

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

Section 7:
* "... may wish to bootstrapping devices with ..." -- s/bootstrapping/bootstrap/
* "... minimal / less sensitive ..." -- pick one, or at least use "or"

Appendix B:
* s/csr/CSR/ (and probably expand it)
* "Demo / proof of concept" -- pick one
* "... from the command line, in production ..." -- start a new sentence
* Don't use "I'm".  Maybe change "I'm using S/MIME because ..." to "S/MIME is
used here because ..."

---

From: Warren Kumari <[email-masked]>
Date: Tue, 19 May 2020 15:35:44 -0400

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-sdi/

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

> Section 4.2.  One could easily change "SHOULD fetch" to "fetches" and do away

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

> 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

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

> s/techniques/technique/, or remove "an"

DONE

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

DONE

* "... vendor to pre-configure the
> 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!

> unconfigured ..."

Nice. DONE.

* "... obtain an IP address and address of a config server
> 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.

> 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' ..." --
> this ..." -- s/all this/all of this/ (and actually, this should be its own

DONE and DONE.

>    proceeds to install the new, decrypted, configuration.

Oooh, better. DONE, thanks.

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

DONE.

> * "... the vendors roles and ..." -- s/vendors/vendor's/

DONE.

> * Please expand "EST" on first use.

DONE.

> stand out to me as in need of making an editorial choice

DONE.

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

DONE.

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

DONE.

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

DONE.

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

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

Indeed. DONE.

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

DONE!

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

DONE.

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

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 May 2020 11:50:49 -0400

Murray Kucherawy via Datatracker <[email-masked]> wrote:
    > 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?

When I did the review of comments, there were a few comments/threads
in the archives which did not clearly have a followup action/commit/diff.
I am not sure if the WG decided that the comments were not relevant, or if
changes were made but not acknowledged.  I don't know if the commenters
are happy with the result, or still waiting for a response.

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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 20 May 2020 18:24:27 +0000

> On May 20, 2020, at 11:50, Michael Richardson <[email-masked]> wrote:
> 
> 

I think at times in the email exchanges, the authors might have been buried under other things.  That said, I don’t think they have outright ignored any comments at this point.  Either they’ve been addressed, discussed, or are going to be addressed.  I have the impression the authors are very keen on taking comments and improving the doc.

Joe

---

From: Colin Doyle <[email-masked]>
Date: Wed, 27 May 2020 19:23:38 +0000

I can confirm both the desire to improve the doc, as well as being buried under things.

C

___________________________________________
Colin Doyle
Juniper Networks | Senior Systems Engineer
C. 503.810.2129 | E. [email-masked]

On 5/20/20, 11:24 AM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    [External Email. Be cautious of content]

    Joe

Juniper Business Use Only