Reviewer: Darrel Miller Review result: Ready with Nits I reviewed this document as part of the Art Area's Last Call Review. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. In general this document was clearly written and without any background in this area I was able to get a reasonable understanding of the problem being addressed and the proposed solution. There were a few nits that could be addressed to improve clarity. Section 1 The introduction uses the term network manager but then later seems to use the term MUD controller to mean the same thing. RFC8520 defines terminology for MUD manager and MUD controller but not network manager, so it is unclear if this is actually a different concept or just another name for the same thing. Section 3.4 > While many small tweaks to a MUD file can be done in place, the situation described above, > particularly when it comes to removing capabilities will suggest that changes to the MUD URL > are in order. This sentence could use some editing for clarity. It is not clear what is being referenced by "the situation described above". Is it referring to 3.1, 3.2 and 3.3 and if so, would it be better to say "the situations described above" ? Section 5 > Subsequent MUD files are considered valid if: > - they have the same initial Base-URI as the MUD-URL, but may have a different final part > - they are signed by an equivalent End Entity (same trusted CA and same Subject Name) as > the "root" MUD file. It wasn't immediately obvious to me if the following conditions were "and" or "or". Section 5.1.1 > Note that in order for MUD controllers to reload the old file, it MUST have been served > with an appropriate ETag, and appropriate Expires or Cache Control headers [RFC9111], Section 5.3. It is not clear why an Etag would be required for a MUD controller to reload the file. Would an Expires or Cache-Control with Max-Age not be sufficient? > The manufacturer must continue to serve the files from the old location for some time, > or to return an HTTP 301 (Moved Permanently) redirecting to the new location. It is not clear whether I could use a HTTP 301 to redirect https://example.com/household/products/mudfiles/toaster.json directly to https://example.com/mudfiles/toasters/model1945/mud.json or whether the 301 is also constrained by "have the same initial Base-URI as the MUD-URL". Section 6 > The use of ETag allows a MUD controller to more efficiently poll for changes in the file. It might be worth adding "by making conditional GET requests" for additional clarity. > A manufacturer should also serve MUD files with an HTTP Max-Age header as per Section 5.2.2.8 of [RFC7234]. Should this should be SHOULD? > MUD controllers MAY use a single HTTP(S)/1.1 connection to retrieve all resources at the same destination. This doesn't seem necessary. Is there any significance to whether one or more connections are used? Is this making some statement about the use of HTTP/2 or HTTP/3? Regards, Darrel -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
