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

[Warren Kumari <[e-mail]>]

On Wed, May 20, 2020 at 12:27 AM Barry Leiba via Datatracker
<[e-mail]> wrote:
>
> 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:

Yikes, apologies for the number of nits - I feel that I usually have
cleaner drafts than this, and apologize for the amount of editorial
issues you had to note...

I'm submitting a new version (-11) with the below (as well as Roman's
and Murray's comments) addressed....


>
> — Section 1 —
>
>    Internet Exchange Points (IXP) or "carrier neutral
>
> Nit: hyphenate “carrier-neutral”,

DONE. Thank you.

>
>    vendor proprietary) protocols to perform initial device installs
>
> Nit: hyphenate “vendor-proprietary” (or just drop “vendor”).

DONE. Thank you.
>
>    use DHCP [RFC2131]to get an IP address
>
> Nit: add a space after the citation.

DONE. Thank you.

>
>    security related and/or proprietary information
>
> Nit: hyphenate “security-related”.

DONE. Thank you.

>
>    (or using an auto-
>    install techniques which fetch an unencrypted config file
>
> Nit: remove “an”.

NOT DONE.
I changed this to be:
"Exposing these to a third party to load onto a new device (or using
an auto-install technique which fetches an unencrypted configuration
file via..."

I assume that this addresses your concern, please let me know if not...


>
>    perform the initial configuration work; this costs, time and money.
>
> Nit: remove the comma.
>

DONE. Thank you. Not sure where the comma came from, but removed :-)

>    configure the devices before shipping it;
>
> Nit: “device” (or “them”).

DONE. Thank you.

>
>    optimized for simplicity, both for the implementor and the operator;
>
> Nit: make it “for both” (or repeat “for” before “the operator”).

DONE. Thank you.

>
>    is it intended to solve all use-cases
>
> Nit: do not hyphenate “use cases”.

DONE, thanks!

>
>    Solutions such as Secure Zero Touch Provisioning (SZTP)" [RFC8572],
>
> Nit: there’s an unpaired quotation mark.

... not any more there isn't :-) DONE.
>
> — Section 2 —
>
>    the devices serial number, MAC address or similar.
>
> Nit: Make it “device’s” (possessive).
>

Done!

>    extends this (vendor specific) paradigm
>
> Nit: hyphenate “vendor-specific”.

DONE.

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

DONE. Thank you.

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

DONE and DONE. Thank you.

>
>    (for example, extended key usage, extensions, etc.)
>
> Nit: “for example” and “etc.” don’t go together; use one or the other.

Doh! DONE. Thank you.

>
> — 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”).

DONE and DONE. Thank you.

>
> — Section 5.2 —
>
>    completely replace the initial device generated key
>
> Nit: hyphenate “device-generated”.

DONE.

>
>    operators installed key.
>
> Nit: “operator’s” (possessive).

DONE. Thank you.

>
> — Section 5.3 —
>
>    device management, whereby portions (or the entire) configuration
>
> Nit: “portions of”
>

DONE.

> — Section 7 —
>
>    third-party to copy and paste it over a serial terminal.
>
> Nit: “them”, not “it” (the antecedent is plural).

Whoops. DONE. Thank you.

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

DONE. I wish it were always this easy :-)

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

DONE, DONE and DONE.


Thank you! These are addressed in commit 533160d
(https://github.com/wkumari/draft-wkumari-opsawg-sdi/commit/533160d8e294848f6ba0221f1983f11398ac2467
) and I'm cutting a new version 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