Re: [OPSAWG] đź”” WG adoption call on draft-richardson-opsawg-mud-acceptable-urls-03

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 16 January 2021 22:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA0E3A19F4 for <opsawg@ietfa.amsl.com>; Sat, 16 Jan 2021 14:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZugYRNL5RCCw for <opsawg@ietfa.amsl.com>; Sat, 16 Jan 2021 14:32:40 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519453A19F2 for <opsawg@ietf.org>; Sat, 16 Jan 2021 14:32:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 787D538A1E; Sat, 16 Jan 2021 17:34:23 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NCF26ukXXFYr; Sat, 16 Jan 2021 17:34:21 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C3EF38A1D; Sat, 16 Jan 2021 17:34:21 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 55E13BCA; Sat, 16 Jan 2021 17:32:36 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>
cc: opsawg <opsawg@ietf.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADCDB5C3@dggeml531-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAADCDB5C3@dggeml531-mbs.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sat, 16 Jan 2021 17:32:36 -0500
Message-ID: <10523.1610836356@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2iQ3mIP-lKY2f_hl2qTn8u-vmdI>
Subject: Re: [OPSAWG] =?utf-8?q?=F0=9F=94=94_WG_adoption_call_on_draft-richar?= =?utf-8?q?dson-opsawg-mud-acceptable-urls-03?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jan 2021 22:32:42 -0000

Qin Wu <bill.wu@huawei.com> wrote:
    > Hi, authors of draft-richardson-opsawg-mud-acceptable-urls:
    > I have seen most of comments I raised earlier on have been addressed,
    > e.g.,

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.

    > 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

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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide