[OPSAWG] Barry Leiba's No Objection on draft-ietf-opsawg-sdi-10: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba 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:
----------------------------------------------------------------------

Just a nitty load of nits nitting about:

— Section 1 —

   Internet Exchange Points (IXP) or "carrier neutral

Nit: hyphenate “carrier-neutral”,

   vendor proprietary) protocols to perform initial device installs

Nit: hyphenate “vendor-proprietary” (or just drop “vendor”).

   use DHCP [RFC2131]to get an IP address

Nit: add a space after the citation.

   security related and/or proprietary information

Nit: hyphenate “security-related”.

   (or using an auto-
   install techniques which fetch an unencrypted config file

Nit: remove “an”.

   perform the initial configuration work; this costs, time and money.

Nit: remove the comma.

   configure the devices before shipping it;

Nit: “device” (or “them”).

   optimized for simplicity, both for the implementor and the operator;

Nit: make it “for both” (or repeat “for” before “the operator”).

   is it intended to solve all use-cases

Nit: do not hyphenate “use cases”.

   Solutions such as Secure Zero Touch Provisioning (SZTP)" [RFC8572],

Nit: there’s an unpaired quotation mark.

— Section 2 —

   the devices serial number, MAC address or similar.

Nit: Make it “device’s” (possessive).

   extends this (vendor specific) paradigm

Nit: hyphenate “vendor-specific”.

— Section 2.1 —

   When the device arrives at the POP, it gets installed in Operator_A'

   autoboot state, and begins the DHCP process.  Operator_A' DHCP server

Nit: “Operator_A’s” in both places.

— Section 3.1 —

   Each devices requires a public-private key keypair

Nit: “Each device”
Nit: you don’t need “key keypair”; I suggest “key pair”.

   (for example, extended key usage, extensions, etc.)

Nit: “for example” and “etc.” don’t go together; use one or the other.

— Section 4.3 —

   configurations fails, the device will either abort the auto-install
   process, or will repeat this process until it succeeds.

Nit: “configuration” (singular).
Nit: remove the second “will” (or make it “either will”).

— Section 5.2 —

   completely replace the initial device generated key

Nit: hyphenate “device-generated”.

   operators installed key.

Nit: “operator’s” (possessive).

— Section 5.3 —

   device management, whereby portions (or the entire) configuration

Nit: “portions of”

— Section 7 —

   third-party to copy and paste it over a serial terminal.

Nit: “them”, not “it” (the antecedent is plural).

   An attacker (e.g., a malicious datacenter employee) who has physical
   access to the device before it is connected to the network the
   attacker may be able to extract the device private key

Nit: remove “the attacker”.

   Even when using a secure bootstrapping mechanism, security conscious
   operators may wish to bootstrapping devices with a minimal / less
   sensitive config

Nit: hyphenate “security-conscious”.
Nit: “bootstrap” (no “ing”).
Nit: hyphenate “less-sensitive”.