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

"Yangjie (Jay, IP Standard)" <jay.yang@huawei.com> Tue, 30 June 2020 09:42 UTC

Return-Path: <jay.yang@huawei.com>
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 6A5DD3A1141 for <opsawg@ietfa.amsl.com>; Tue, 30 Jun 2020 02:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 dWlKxNFx_66B for <opsawg@ietfa.amsl.com>; Tue, 30 Jun 2020 02:42:49 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F623A0CBA for <opsawg@ietf.org>; Tue, 30 Jun 2020 02:42:49 -0700 (PDT)
Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 746DFF44BDAF6DCF1ABE; Tue, 30 Jun 2020 10:42:47 +0100 (IST)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 10:42:46 +0100
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 17:42:44 +0800
Received: from nkgeml704-chm.china.huawei.com ([10.98.57.158]) by nkgeml704-chm.china.huawei.com ([10.98.57.158]) with mapi id 15.01.1913.007; Tue, 30 Jun 2020 17:42:44 +0800
From: "Yangjie (Jay, IP Standard)" <jay.yang@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: My comments about : draft-richardson-opsawg-mud-acceptable-urls-01
Thread-Index: AdZOEylPfZY7pxiPRuGhlcfswv7QQv//3woA//6LF5A=
Date: Tue, 30 Jun 2020 09:42:43 +0000
Message-ID: <7904a67ac8844ce29d394c2c1a152cc8@huawei.com>
References: <3921d68321f84d2b9d3e01f1448f272b@huawei.com> <8036.1593456448@localhost>
In-Reply-To: <8036.1593456448@localhost>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.151.29]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/gy9nyvSb8NLvgjczvC9CClWb3Yg>
Subject: [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: Tue, 30 Jun 2020 09:42:50 -0000

Thanks Michael. 

I get the point for introduction of ACL and DNS.

About acceptable URL rule, I don't understand how to do for the following:

For example, if the "root" mud-url is http://example.com/hello/there/file.json,
Then how to clarify acceptable any URL, if starts with the following will be OK?
a) http://example.com/hello/there/  , which mapping specific product
b) http://example.com/hello , which mapping product line, 
c) http://example.com , which mapping company
if exist, DNS solution may be complicated. I'am not certain about this.

So if partition Root URL with the fixed parts and variable parts initially, and storage fixed parts in certification, maybe more flexible.

And about these scenarios, I don't know if the acceptable url rule will be clarified later. 
Certainly, if WG give some feedback for acceptable url, it will better.


Best Regards,
Jay.


-----邮件原件-----
发件人: Michael Richardson [mailto:mcr+ietf@sandelman.ca] 
发送时间: 2020年6月30日 2:47
收件人: Yangjie (Jay, IP Standard) <jay.yang@huawei.com>
抄送: opsawg@ietf.org
主题: Re: My comments about : draft-richardson-opsawg-mud-acceptable-urls-01


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