Subject: [OPSAWG] AD review of draft-ietf-opsawg-sdi-07

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 17 Apr 2020 19:27:05 +0000

Hi,

Thank you for this work.  I found this document informative and both easy to read and understand.  I have a one question on this document and a few nits listed below.

My main question concerns this sentence in section 3.1: "[I-D.gutmann-scep] is one method which vendors may want to strongly consider."

It looks like the IESG comments associated with I-D.gutmann-scep suggests that this is being documented for historical reasons and probably is no longer recommended practice.  Hence, I was wondering whether it is appropriate to recommend or even reference it?

Nits:
Some inconsistency on how the device identifier is referred to.  Sometimes it is "unique identifier" sometimes "unique device identifier", perhaps try and unify on a single term?

Introduction:
   I prefer "and/or" to "and / or" that turns up twice.

Section 2.1:
"and Acme publishes it on their keyserver" => "and acme publishes the public key on their keyserver"?

Section 3.1:
  "may will" => "may"?

Section 3.2:
"Note that the certificate publication server MUST only accept certificates or keys from the vendor's manufacturing facilities." => This text, or very similar appears in both section 3.2 and 3.1.

Section 4.3,
  "contact" => "contacts",
  "It able," => "If able,"
  "If this fails" => It could potentially be more clear as to what "it" refers to here, although the diagram below does make it clear.
   In diagram "give up go home" => "give up, go home"

"keylenghts" => "key lengths"
"isn't" => "is not"?

Regards,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Apr 2020 15:40:13 -0400

Rob Wilton \(rwilton\) <rwilton=[email-masked]> wrote:
    > Thank you for this work.  I found this document informative and both
    > easy to read and understand.  I have a one question on this document
    > and a few nits listed below.

    > My main question concerns this sentence in section 3.1:
    > "[I-D.gutmann-scep] is one method which vendors may want to strongly
    > consider."

    > It looks like the IESG comments associated with I-D.gutmann-scep
    > suggests that this is being documented for historical reasons and
    > probably is no longer recommended practice.  Hence, I was wondering
    > whether it is appropriate to recommend or even reference it?

It did get published as an RFC a week or so ago.
It has been been used extensively in the industry for two decades.
I think it is reasonable to consider it.
(And I'm not a fan of it)

It's a protocol to consider, along with EST, and CMP, depending upon what you
otherwise use.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Apr 2020 13:36:15 -0400

On Fri, Apr 17, 2020 at 3:27 PM Rob Wilton (rwilton) <[email-masked]> wrote:
> My main question concerns this sentence in section 3.1: “[I-D.gutmann-scep] is one method which vendors may want to strongly consider.”

DONE
Oooh, I had intended to also recommend EST, but got sidetracked when
looking up the RFC number (7030) and then forgot what I was doing. I
don't know enough about CMP to recommend it...
I just added it, thanks!

> Some inconsistency on how the device identifier is referred to.  Sometimes it is “unique identifier” sometimes “unique device identifier”, perhaps try and unify on a single term?

DONE
Doh! Good catch - I settled on "unique device identifier" and updated
it everywhere that made sense.

>
>
>
> Introduction:
>
>    I prefer “and/or” to “and / or” that turns up twice.

DONE
Bah... I prefer the "and / or", but I'm definitely in the rough, so I
updated it, but while muttering all the time...

>
>
>
> Section 2.1:
>
> “and Acme publishes it on their keyserver” => “and acme publishes the public key on their keyserver”?

DONE
Oooh, good catch, done.

>   “may will” => “may”?

DONE
:-)

>
>
>
> Section 3.2:
>
> “Note that the certificate publication server MUST only accept certificates or keys from the vendor's manufacturing facilities.” => This text, or very similar appears in both section 3.2 and 3.1.
>

DONE.
Nice catch, done...

>   “contact” => “contacts”,

DONE

>   “It able,” => “If able,”

DONE
Nice.

>
>   “If this fails” => It could potentially be more clear as to what “it” refers to here, although the diagram below does make it clear.

DONE.
Fair nuff, fixed.
"If it cannot decrypt the file, or if parsing the configurations fails,
the device will either abort the auto-install process, or will repeat this
process until it succeeds."

>
>    In diagram “give up go home” => “give up, go home”

DONE.

>
>
>
> “keylenghts” => “key lengths”

DONE... stupid spacebar... :-P

> “isn’t” => “is not”?

Oh, all right...
DONE

Thank you, I've posted a new version (-08) with all these folded in...

Thank you!
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