Subject: Re: [OPSAWG] 🔔 WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03

From: Qin Wu <[email-masked]>
Date: Sat, 16 Jan 2021 11:30:35 +0000

Hi, authors of draft-richardson-opsawg-mud-acceptable-urls:
I have seen most of comments I raised earlier on have been addressed, e.g.,
1. provide recommendation to the implementers or developer on when they choose MUD URL updating and when they choose MUD file updating?
2.Clarify the difference between RFC8520 and draft-richardson-opsawg-mud-acceptable-urls on MUD file signing
3.Add summary text at the beginning of the section 2
Thanks for that, it improve clarity and readability. I support adoption of this work

One more comment is Does MUD URL updating require any new protocol exchange between end device and firmware server, how does end device detect MUL URL change?
Thanks!

-Qin
-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 Henk Birkholz
发送时间: 2021年1月5日 2:06
收件人: opsawg <[email-masked]>
主题: [OPSAWG] 🔔 WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03

Dear OPSAWG members,

this starts a call for Working Group Adoption on
https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-03
ending on Monday, January 25.

As a reminder, this I-D describes ways to update (if possible) MUD URIs as specified in RFC8520 Manufacturer Usage Description (MUD) in a secure and acceptable manner.

Please reply with your support and especially any substantive comments you may have.

For the OPSAWG co-chairs,

Henk

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Jan 2021 17:32:36 -0500

> I have seen most of comments I raised earlier on have been addressed,

Yes, I think that I have some comments in my queue that I need to address.

    > 1. provide recommendation to the implementers or developer on when they
    > choose MUD URL updating and when they choose MUD file updating?

draft-richardson-opsawg-mud-acceptable-urls has a table of contents:

   2.  Updating MUD URLs vs Updating MUD files . . . . . . . . . . .   3
     2.1.  Updating the MUD file in place  . . . . . . . . . . . . .   3
       2.1.1.  Adding capabilities . . . . . . . . . . . . . . . . .   3
       2.1.2.  Removing capabilities . . . . . . . . . . . . . . . .   4
       2.1.3.  Significant changes to protocols  . . . . . . . . . .   5
     2.2.  Motivation for updating MUD URLs  . . . . . . . . . . . .   5

The goal of section two is to motivate when to do each.
One thought I have is that we could turn that section into its own BCP
document, but I'm not convinced there is enough text there to justify its own
document.

So my second instinct is that this part of the document could also be more
explicitely a normative update to RFC8520, providing advice on when to update
the URL and when to update the file contents.

    > 2.Clarify the difference between RFC8520 and
    > draft-richardson-opsawg-mud-acceptable-urls on MUD file signing

There is no syntactic difference.  Is there something that suggests differently?

RFC8520 intentionally (I think) didn't say a lot about about who is
authorized to sign which file.
This document does not say how a MUD controller begins to trust a signer, but
it does say something about how a MUD controller continues to trust.

    > Thanks for that, it improve clarity and readability. I support adoption of this work

okay.

    > One more comment is Does MUD URL updating require any new protocol
    > exchange between end device and firmware server, how does end device
    > detect MUL URL change?

RFC8520 says nothing about firmware server/end-device protocol.
Neither does the SUIT WG at this point.
This is still a place where it would be good to find some commonalities among
various industry verticals.   So I don't think that there is any update to
a protocol that currently underspecified/not-standardized :-)

The end device would not detect a MUD URL change, but rather, having updated
it's firmware, the new firmware would simply have the new URL built in.
(That URL might be different than the one built-in to the IDevID, which would
not get updated during a firmware update)
That new URL would get expressed through LLDP and/or DHCP.
It would be up to the MUD controller to observe this change.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide