IETF Logo Mail Archive

Re: [OPSAWG] My comments about : draft-richardson-opsawg-mud-acceptable-urls-01

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 29 June 2020 18:47 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 BFDFC3A09FF for <opsawg@ietfa.amsl.com>; Mon, 29 Jun 2020 11:47:34 -0700 (PDT)
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 jLwk-Je24tu4 for <opsawg@ietfa.amsl.com>; Mon, 29 Jun 2020 11:47:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9213A07A0 for <opsawg@ietf.org>; Mon, 29 Jun 2020 11:47:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 767A038997; Mon, 29 Jun 2020 14:44:43 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gc9fcq2gmE28; Mon, 29 Jun 2020 14:44:42 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C26138995; Mon, 29 Jun 2020 14:44:42 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 99ADA1CB; Mon, 29 Jun 2020 14:47:28 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Yangjie (Jay, IP Standard)" <jay.yang@huawei.com>
cc: "opsawg@ietf.org" <opsawg@ietf.org>
In-Reply-To: <3921d68321f84d2b9d3e01f1448f272b@huawei.com>
References: <3921d68321f84d2b9d3e01f1448f272b@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, 29 Jun 2020 14:47:28 -0400
Message-ID: <8036.1593456448@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ND3FctEaoyV3g8BZSMbTyPeKzxo>
Subject: Re: [OPSAWG] My comments about : draft-richardson-opsawg-mud-acceptable-urls-01
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: Mon, 29 Jun 2020 18:47:35 -0000

Yangjie (Jay, IP Standard) <jay.yang@huawei.com> wrote:
    > But perhaps in some scenarios, like mud server moved for follow-up
    > maintenance, this current acceptable URL will be changed.

If the MUD server needs to be moved, then the DNS can be updated to point
toward a replacement server.  And/or 301/302/307/.. redirects are usually
followed.
As long as the signature on the MUD file still validates, any location is okay.

So I don't think that this is a reasonable concern.

    > So Can we specify the fixed parts and variable in Root URL clearly in
    > the generation rule initially? I think this solution will be more
    > general.

I think this just makes it more complicated for the validator, which means
that it will have more bugs and take more words to explain properly.

    > Here, the fixed parts can be be the right of the last "/" in the root
    > URL, like your draft's description, also can be some invariable
    > attributes like manufacture and devices, which can be convert to some
    > parts of standard URL. And this fixed parts can be built-in initial
    > certification, used as the trust basis for the final valid URL.

Can you give me an example of what you mean?

    > The variable parts can be get from device storage, or from some file in
    > this device. I think, this MUD URL updating mechanism is more
    > flexible.

    > By the way, introduction on ACL and DNS in the beginning of this draft, may be no need.

Could be.
The WG could provide some feedback about how much introduction we need.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email