Subject: [OPSAWG] WG adoption poll for draft-wkumari-opsawg-sdi-04

From: Tianran Zhou <[email-masked]>
Date: Tue, 18 Jun 2019 06:38:49 +0000

Hi WG,

This document was presented in Prague, and got good feedback. The authors have addressed all the comments.
https://datatracker.ietf.org/doc/draft-wkumari-opsawg-sdi/

The chairs think this informational draft is easy to be implemented, and got good support.

This email starts a two weeks poll for adoption. 
If you support adopting this document please say so, and please give an indication of why you think it is important. Also please say if you will be willing to review and help the draft.
If you do not support adopting this document as a starting point for work on this topic, please say why.
This poll will run until 2nd July.

Regards,
Tianran & Joe

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Jun 2019 17:08:16 -0400

Dear OpsAWG,

Here is a link to the slidedeck from IETF104 to refresh your memory -
https://datatracker.ietf.org/meeting/104/materials/slides-104-opsawg-draft-wkumari-opsawg-sdi-01.pdf
-- basically the entire document is summarized in 2 slides (slide 9,
10).
If you'd prefer video -- https://youtu.be/a479Zohc5yg?t=1266

The main design criteria for this was to be as simple as possible, to
make it trivial to implement and use. This is specifically designed to
just augment existing auto-install functionality; there are much more
ambitious and fully featured solutions (such as ANIMA and RFC 8572)
available for those who can / want to use them.

I'd really appreciate your review and comment; it's short (if you
ignore the ASCII art diagrams and example appendix and similar it is 7
or 8 pages, and much of that is background).
W

On Tue, Jun 18, 2019 at 2:39 AM Tianran Zhou <[email-masked]> wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
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: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 18 Jun 2019 21:19:46 +0000

I have reviewed the material and the draft (latest).  As an individual, I support adoption of this draft as a WG item.

Joe

> On Jun 18, 2019, at 17:08, Warren Kumari <[email-masked]> wrote:
> 
> Dear OpsAWG,
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2019 20:47:13 -0400

Warren Kumari <[email-masked]> wrote:
    > 10).  If you'd prefer video -- https://youtu.be/a479Zohc5yg?t=1266

    > available for those who can / want to use them.

Your claim that BRSKI is too complex is interesting, and I'd like to discuss
this with you over beer.  But, I appreciate you trying to do this.
Saving CO2 expended by silly airplane flights is appreciated.

We did consider a protocol such as you describe.
The limitation is that it does not necessarily enroll the new device into the
ISP's security domain, and we really wanted that.

The Config file provided could do that, and as you say, some staging
mechanism could also use ssh to do that as well.  But, that wouldn't really
be a standard, and we needed something more specific.

I think you need a bit more text to explain why the device should trust the
DHCP server; and also how the owner convinces the manufacturer to turn over
this key.  As written, it looks like if I get a good look at the label of a
BFR I have a good chance of getting the key, and I'm sure you intend
something more involved.

It's unclear to me if this key should be retained in the factory reset
situation or not; I think you offer both possibilities, but each version has
some security gotchas, and I think it needs to be explained.

I would like you to consider specifying a standard format for the encrypted
configuration.   CMS, PGP, JOSE, COSE... pick one or more.  That way, we can
have tools that can support a multiple of vendors equipment.

Failing such a choice, I don't see anything in this description which a
manufacturer can't unilaterally do today.  So maybe it's a BCP, and and it
can go into an RFP. I don't think it's Informational: BCP or STD.

    > or 8 pages, and much of that is background).  W

Adopt it.

ps: it would be nice if the initial DHCP request included a MUD URL, so that
    the infrastructure can know what the device is expected to do,
    particularly if that might involve calling home to get the latest
    firmware before operating.
    Should the device get any kind of Internet access from the DHCP server?

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