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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 02 February 2021 01:54 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 0F0F63A1668 for <opsawg@ietfa.amsl.com>; Mon, 1 Feb 2021 17:54:14 -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 QVTEyVQBi6g3 for <opsawg@ietfa.amsl.com>; Mon, 1 Feb 2021 17:54:11 -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 92EAF3A1667 for <opsawg@ietf.org>; Mon, 1 Feb 2021 17:54:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CBB7638999; Mon, 1 Feb 2021 20:56:55 -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 5GMSKzD3FpVt; Mon, 1 Feb 2021 20:56:55 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 653D238994; Mon, 1 Feb 2021 20:56:55 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 509EA52; Mon, 1 Feb 2021 20:54:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>, 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: Mon, 01 Feb 2021 20:54:09 -0500
Message-ID: <30609.1612230849@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/t-gzpCKOIyiPmOIme0b4-oKon50>
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: Tue, 02 Feb 2021 01:54:14 -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.,
    > 1. provide recommendation to the implementers or developer on when they
    > choose MUD URL updating and when they choose MUD file updating?

I think that I've changed section 2 to address this, but perhaps I have not
gone far enough.

    > 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

I want all MUD files signed; RFC8520 was a bit more pragmatic.

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

RFC8520 says nothing about how the LLDP or DHCP servers communicate at all.
At present, this is up to the vendor to figure out.

Enterprise DHCP servers tend to be centralized, via DHCP relays, so having
the two (redundant) servers on each campus send updates to a MUD controller
via some scripting process, etc. seems reasonable.   Probably it will be up
to MUD controller vendors to figure how to plug into the DHCP servers that
are popular among their customers.

The LLDP data set is usually collected via SNMP today, and probably by
RESTCONF later on.  So that collection system needs to forward information.
The LLDP information already includes a great deal with information about the
port/chassis/etc. where the device is located, and that information is
clearly needed by the MUD controller to push policy out.

Getting a MUD controllers is likely a reason to invest in a state-of-the-art
SDN process in my opinion.

In the home... it is all on a single platform, so it's all inside the one box.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide