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+i...@sandelman.ca] 
发送时间: 2020年6月30日 2:47
收件人: Yangjie (Jay, IP Standard) <jay.y...@huawei.com>
抄送: opsawg@ietf.org
主题: Re: My comments about : draft-richardson-opsawg-mud-acceptable-urls-01


Yangjie (Jay, IP Standard) <jay.y...@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+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-



_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to