Authorized update to MUD URLs
draft-ietf-opsawg-mud-acceptable-urls-11

[Ballot discuss]
I don't have a ton of experience w/ mud, but I do have a fair bit of experience w/ PKI certs.  I think there is work to be done on this draft to tighten it up and make it clearer, hence my discuss. Where I could, I have made suggestions.  I agree with the other comments on this draft.



Shepherd writeup:  It would be nice to enumerate the manufacturers that have implemented this concept.  The link to 'https://mudmaker.org' causes my browser to throw big flashy warning signs.  When I click through them, it tells me to 'GO AWAY'.  fun...

Section 3.1 upgrade causes vulnerabilities:  One would think that this situation should be avoided at all costs.  There could be a way for the device to signal which version of F/W it is running, allowing the MUD file to be tailored.

Section 3.2:  The same applies for this section as well.  False positives can be just as dangerous (because they bury the real positives). 

Section 4:  Updating IDevID URLs can't be updated with a F/W update?  F/W updates are signed by the manufacturer's signing key, correct?

Section 4.2:  Just how hard would it be to specify the CA certificate paired with a subject name (subject alt name, or CN)?  Seems like this is more secure than your proposed methods.  Oddly enough, Section 5.1 proposes this.

Section 5, last para:  Instead of subject names, SKI should be used [RFC5280, section 4.2.1.2].  This can be easily checked in a certificate validate that is presented.

Section 5.2:  Can't this be used all the time?

Section 5.3.3:  Classically to change a 'root' one signs the new with the old and signs the old with the new.  If it is done this way, I suspect one could change whatever names, CAs one needs to change.

Section 7:  One might argue that the use of server authenticated TLS might mitigate a bunch of concerns.

Section 9.  This is confusing. Please seperate the before issues and the after issues into seperate sections (at least). There are many potential vulnerabilities listed earlier in the draft.  Please consolidate those here (possibly with draft section links to where the mitigation is suggested).

[Ballot discuss]
Shepherd writeup:  It would be nice to enumerate the manufacturers that have implemented this concept.  The link to 'https://mudmaker.org' causes my browser to throw big flashy warning signs.  When I click through them, it tells me to 'GO AWAY'.  fun...

Section 3.1 upgrade causes vulnerabilities:  One would think that this situation should be avoided at all costs.  There could be a way for the device to signal which version of F/W it is running, allowing the MUD file to be tailored.

Section 3.2:  The same applies for this section as well.  False positives can be just as dangerous (because they bury the real positives). 

Section 4:  Updating IDevID URLs can't be updated with a F/W update?  F/W updates are signed by the manufacturer's signing key, correct?

Section 4.2:  Just how hard would it be to specify the CA certificate paired with a subject name (subject alt name, or CN)?  Seems like this is more secure than your proposed methods.  Oddly enough, Section 5.1 proposes this.

Section 5, last para:  Instead of subject names, SKI should be used [RFC5280, section 4.2.1.2].  This can be easily checked in a certificate validate that is presented.

Section 5.2:  Can't this be used all the time?

Section 5.3.3:  Classically to change a 'root' one signs the new with the old and signs the old with the new.  If it is done this way, I suspect one could change whatever names, CAs one needs to change.

Section 7:  One might argue that the use of server authenticated TLS might mitigate a bunch of concerns.

Section 9.  This is confusing. Please seperate the before issues and the after issues into seperate sections (at least). There are many potential vulnerabilities listed earlier in the draft.  Please consolidate those here (possibly with draft section links to where the mitigation is suggested).

[Ballot comment]

Nits:
Section 1, para 6: change 'check the signatures, rejecting files whose signatures do not match' to '... whose signatures do not validate'.  Using language like 'match' leads to bad behavior, when the entity should be taking a positive action to validate the signature.

Section 9, last sentence:  jargon?  I'm not sure I know what this means, and English is my (only) language.

[Ballot comment]
I am supporting John's discuss on mitigation to "rollback attack". If the mitigation is well defined and understood then I would strongly recommend to put a reference to the mitigation.

[Ballot comment]
Thanks to Darrel Miller for his ARTART review.

Like Eric, I also found the sudden writing style shift in Section 5.3.1 to be a bit jarring.  Some intro text or a more clear title might be better here.

[Ballot discuss]
Despite having reviewed a number of the recent MUD specs, I'm not sufficiently expert in the subject area to be confident all my concerns below are right, so naturally I'm open to correction. That being said, I do have several concerns about the document that I'd like to resolve (either with changes to the document, or a clue bat) before it moves forward. Thanks in advance.

### Section 5.1 -- AND or OR? It matters!

  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’s not explicit if the requirement is that either condition is fulfilled, or both. I assume the requirement is both, but please make this explicit. I think it would scan better if you got rid of the bullets and just made this a regular sentence, although I guess you’d have to get rid of the “but” clause in the first bullet (which would be an improvement in my book). But do it however you wish, as long as it’s unambiguous. An "and" between the bullets is the minimum fix (assuming I'm right of course).

### Section 5.1 -- what to do with those darn suspicions

                                                                    MUD
  managers SHOULD keep track of the list of MUD-URLs that they have
  successfully retrieved, and if a device ever suggests a URL that was
  previously used, then the MUD manager should suspect that is a
  rollback attack.
 
What, specifically, is the MUD manager supposed to do if it has this suspicion? I’m somehow picturing the manager giving the client a very stern look 🧐 but otherwise doing nothing, because the developer who implemented it wasn’t given any guidance by the specification.

### Section 5.1 -- any URL that was previously used is suspicious O RLY?

Further to the previous, as written it sounds to me as though this could describe a perfectly innocent situation. As in,

- Device A of type N with firmware version 1 is powered up and suggests URL foo
- MUD manager retrieves foo and adds it to its “successfully retrieved” list
- Now device A is upgraded to firmware version 2 and suggests URL bar
- MUD manager retrieves bar and adds it to its “successfully retrieved” list
- Now a new device B of type N with firmware version 1 is powered up and suggests URL foo
- MUD manager consults its list, finds foo was previously retrieved, and becomes suspicious, gives B the stink-eye

Perhaps you mean “previously used *by that device*” in which case you should say so (although I still hope you’ll clarify what the manager is supposed to do with its suspicion). Or, perhaps you mean something else entirely, in which case let’s discuss. (Even if it's "by that device" aren't there benign cases, such as a factory reset?)

This requirement also appears to fly in the face of Section 6, see below.

### Section 5.3.2 -- new requirement? OR restatement?

  Note, however, that a 301 Redirect that changed the hostname SHOULD
  NOT be accepted by MUD controllers.

Is this a restatement of a preexisting requirement (in which case a reference is called for) or a new requirement (in which case it seems lacking in detail)?

### Section 6 -- file update mechanisms WUT?

  The MUD file update mechanisms described in Section 3 requires that
  the MUD controller poll for updates.
 
I don’t see any such requirement enumerated in Section 3. In fact, Section 3 has no requirements whatsoever, it reads like a litany of complaints about what a bad idea MUD file in-place updating is, as a way of motivating why the methods of Sections 4 + 5 should be used instead.

Possibly this is just a combination of my lack of knowledge of the MUD document set, combined with less-than-precise wording of the quoted text. Would it be correct to re-word something like,

NEW:
  If MUD files are updated in place, as discussed in Section 3, the updates
  will not be detected unless the MUD controller polls to discover them.

I.e., write the sentence in terms of natural consequences, without using the r-word ("requires") and without implying that Section 3 describes a mechanism.

### Section 6 -- in-place updates vs. the suspicious nature of the controller

Furthermore, the “previously used ... suspect” language I’ve already commented on seems to preclude (or at least cast suspicion on?!?) in-place updates, that you're now telling me are just fine. I'm tempted to suggest you clear this up by removing the Section 5.1 text I quoted earlier, but since I don't have enough knowledge of the problem space, I don't know if that's right. What I do know is that *some* resolution of this contradiction appears called for.

[Ballot discuss]
Despite having reviewed a number of the recent MUD specs, I'm not sufficiently expert in the subject area to be confident all my concerns below are right, so naturally I'm open to correction. That being said, I do have several concerns about the document that I'd like to resolve (either with changes to the document, or a clue bat) before it moves forward. Thanks in advance for your patience and discussion.

### Section 5.1 -- AND or OR? It matters!

  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’s not explicit if the requirement is that either condition is fulfilled, or both. I assume the requirement is both, but please make this explicit. I think it would scan better if you got rid of the bullets and just made this a regular sentence, although I guess you’d have to get rid of the “but” clause in the first bullet (which would be an improvement in my book). But do it however you wish, as long as it’s unambiguous. An "and" between the bullets is the minimum fix (assuming I'm right of course).

### Section 5.1 -- what to do with those darn suspicions

                                                                    MUD
  managers SHOULD keep track of the list of MUD-URLs that they have
  successfully retrieved, and if a device ever suggests a URL that was
  previously used, then the MUD manager should suspect that is a
  rollback attack.
 
What, specifically, is the MUD manager supposed to do if it has this suspicion? I’m somehow picturing the manager giving the client a very stern look 🧐 but otherwise doing nothing, because the developer who implemented it wasn’t given any guidance by the specification.

### Section 5.1 -- any URL that was previously used is suspicious O RLY?

Further to the previous, as written it sounds to me as though this could describe a perfectly innocent situation. As in,

- Device A of type N with firmware version 1 is powered up and suggests URL foo
- MUD manager retrieves foo and adds it to its “successfully retrieved” list
- Now device A is upgraded to firmware version 2 and suggests URL bar
- MUD manager retrieves bar and adds it to its “successfully retrieved” list
- Now a new device B of type N with firmware version 1 is powered up and suggests URL foo
- MUD manager consults its list, finds foo was previously retrieved, and becomes suspicious, gives B the stink-eye

Perhaps you mean “previously used *by that device*” in which case you should say so (although I still hope you’ll clarify what the manager is supposed to do with its suspicion). Or, perhaps you mean something else entirely, in which case let’s discuss. (Even if it's "by that device" aren't there benign cases, such as a factory reset?)

This requirement also appears to fly in the face of Section 6, see below.

### Section 5.3.2 -- new requirement? OR restatement?

  Note, however, that a 301 Redirect that changed the hostname SHOULD
  NOT be accepted by MUD controllers.

Is this a restatement of a preexisting requirement (in which case a reference is called for) or a new requirement (in which case it seems lacking in detail)?

### Section 6 -- file update mechanisms WUT?

  The MUD file update mechanisms described in Section 3 requires that
  the MUD controller poll for updates.
 
I don’t see any such requirement enumerated in Section 3. In fact, Section 3 has no requirements whatsoever, it reads like a litany of complaints about what a bad idea MUD file in-place updating is, as a way of motivating why the methods of Sections 4 + 5 should be used instead.

Possibly this is just a combination of my lack of knowledge of the MUD document set, combined with less-than-precise wording of the quoted text. Would it be correct to re-word something like,

NEW:
  If MUD files are updated in place, as discussed in Section 3, the updates
  will not be detected unless the MUD controller polls to discover them.

I.e., write the sentence in terms of natural consequences, without using the r-word ("requires") and without implying that Section 3 describes a mechanism.

### Section 6 -- in-place updates vs. the suspicious nature of the controller

Furthermore, the “previously used ... suspect” language I’ve already commented on seems to preclude (or at least cast suspicion on?!?) in-place updates, that you're now telling me are just fine. I'm tempted to suggest you clear this up by removing the Section 5.1 text I quoted earlier, but since I don't have enough knowledge of the problem space, I don't know if that's right. What I do know is that *some* resolution of this contradiction appears called for.

[Ballot comment]
I agree with many things from the SecDir review from Christian Huitema:

https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-acceptable-urls-11-secdir-telechat-huitema-2024-04-02/

I think the concept of small vs big changes is problematic.

There is also the issue of any lower version being seen as a roll back attack.
If successfull, it would prevent an administrator to downgrade the MUD file
after finding that it is preventing proper functioning.


A device has a firmware version and a MUD file that belongs to that version.
It seems this draft says that the MUD file can be upgraded to firmware versions
it was not intended for. It seems the simple fix is to not do that.

Updating a MUD file to plug a security hole seems the wrong mechanism. Instead
of updating the MUD file, the firmware should be updated (and that firmware
should come with a new MUD file covering that firmware version)

So I am confused about the mechanim of the firmware handing a URL to the
MUD manager, who then picks up the MUD file from the manufacturor. In a way,
one could see this as a firmware that has a bit of external firmware hosted
elsewhere. And these two can get out of sync. To me that just seems like
broken firmware and building a protocol mechanism to resolve this seems
the wrong way to fix this.

Similarly, changing a MUD file location seems to be something that should
be addressed in a firmware update - including updating the location of
future firmware updates.

I don't see a way for this document to resolve my issues, so instead of
balloting DISCUSS, I am ABSTAINing.

[Ballot comment]
I am balloting on this document from a GEN area perspective.

** Section 3.1
  While there is an argument that old firmware was insecure and should
  be replaced, it is often the case that the upgrade process involves
  downtime, or can introduce risks due to needed evaluations not having
  been completed yet.  As an example: moving vehicles (cars, airplanes,
  etc.) should not perform upgrades while in motion!  It is probably
  undesirable to perform any upgrade to an airplane outside the service
  facility.  A vehicle owner may desire only to perform software
  upgrades when they are at their residence.  Should there be a
  problem, they could make alternate arrangements for transportation.
  This contrasts with an alternative situation where the vehicle is
  parked at, for instance, a remote cabin, and where an upgrade failure
  could cause a much greater inconvenience.

  The situation for upgrades of medical devices has even more
  considerations involving regulatory compliance.

I’m having trouble understanding the examples provide and the associated analysis. Editorial recommendation: cut all the text after the first sentence.  Otherwise:

-- What does vehicles, aircraft and medical devices have to do with MUD? Is there existing and planned penetration of MUD in those markets?

-- Per “While there is an argument that old firmware was insecure and should
  be replaced, it is often the case that the upgrade process involves
  downtime, or can introduce risks due to needed evaluations not having
  been completed yet. As an example, moving vehicles ...” 

Where does the suggestion that moving cyber-physical systems should upgrade their firmware in use come from?

-- What is the basis for the claim that the regulatory compliance of medical devices is more considerations than say of aircraft?

** Reference

  [falsemalware]
              "False malware alerts cost organizations $1.27M annually,
              report says", 18 January 2020,
              .

Pick a single URL.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-acceptable-urls-11

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Henk Birkholz for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)


## Section 3.1

About the 2nd paragraph, the conflation of unsecure protocols (telnet) with a no-credential use case is confusing. The issue discussed here is not telnet vs. SSH but poor credentials. Suggest removing telnet/http protocols in the example.

The 4th paragraph is important but I fail to see the link with this section "adding capabilities".

## Section 3.3

ALso unsure whether this section should be in this I-D.

## Section 4

References to the protocol for MUD sources are probably welcome.

## Section 4.1

`That it, the signing authority is pinned. ` should this be "that is" ? Also, I am not sure whether all readers will understand what is meant by "pinned".

## Section 5

What is the meaning of the "proposed mechanism" in a standard track document? Let's be more assertive and remove "proposed".

Is there a common definition of "lowest Certification Authority (CA)" ? If so, a normative reference is welcome.

"SHOULD" is used twice, when can an implementation deviate from the "SHOULD" ? I.e., why not a "MUST".

## Section 5.1

Where is "Base-URI" defined in this (or in another document) defined ? To be honest, I was about to ballot a blocking DISCUSS on this point.

s/it contains the same series of segments/it contains the same serie of segments/ ?

In `if a device ever suggests a URL that was previously used` how can a device downgrade to a previous firmware ?

## Section 5.3.1

Is this just an example ? If so, let's be clear in the section title.

Last paragraph, should it be a "MUST" in `The manufacturer must continue to serve`.

## Section 5.3.2

Why can an implementation deviate from the `SHOULD NOT` ?

## Section 6

Should this section use more normative uppercase verbs ?

## Section 7

Is there any change wrt to RFC 8520 privacy considerations ?


# NITS (non-blocking / cosmetic)

I find the use of "!" in an IETF document rather unusual, but this is a matter of taste.

## Section 5.1

s/series of segment/series of segments/ ?

[Ballot comment]
i am not a mud expert, however i found the document well written giving me some indication on the technical objective of MUD and the problem/solution space identified in this draft.

[observation about the abstract]
i am not convinced that the use of 'to declare' covers 100% the document intent.
To me "declare" formally means to make a clear, explicit, or authoritative statement or announcement.
The draft prescribe that under certain conditions the behaviors of a specific device, described in the
original MUD file will no longer apply and consequently provides mechanisms to access and process an
updated MUD file. This suggests the document not only announces a new MUD's validity but also
outlines the update process, indicating a scope beyond mere declaration.

[Ballot comment]
Thanks to Darrel Miller for the ARTART review.

Agree with Darrel's comments.

It would be good to choose "MUD manager" (5 instances) over "MUD controller" (24 instances) because RFC 8520 indicates that "MUD controller" is an outdated synonym.

Section 4 mentions confusion regarding QRCodes and URLs, given the URL reference is to RFC 3986, which depends on RFC 3490 for IDNA, you way wish to add a reference to https://datatracker.ietf.org/doc/html/rfc5890#section-4.4

Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Darrel Miller. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-mud-acceptable-urls-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-mud-acceptable-urls@ietf.org, henk.birkholz@ietf.contact, henk.birkholz@sit.fraunhofer.de, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Authorized update to MUD URLs) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Authorized
update to MUD URLs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document provides a way for an RFC8520 Manufacturer Usage
  Description (MUD) definitions to declare what are acceptable
  replacement MUD URLs for a device.



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4635/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represents strong support of a few individuals with credible
feedback cycles that were addressed over time - with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

All feedback was quickly and adequately addressed.  An extensive set of final
review comments from Qin Wu was discussed on via the list and seems to be
implicitly concluded.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are implementations for RFC 8520 including starter tools, such as
https://mudmaker.org/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document does not include such contents.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not include such content.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not include such content.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not include such content.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The assembled OPS area topics do not apply.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track, which is the right track for this document as it is updating
RFC 8520 The DT attributes and tags are now appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors/editors have stated that they are not aware of any IPR other than
the one IPR disclosure that has been submitted by Huawei Ltd. under
https://datatracker.ietf.org/ipr/4635/.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The documents has three authors that have shown their willingness to be listed
and no additional contributors are listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some outdated references are now updated:
* draft-ietf-opsawg-mud-tls-11 -> draft-ietf-opsawg-mud-tls-12

Some references are still outdated or obsoleted:
* draft-richardson-mud-qrcode -> RFC 9238
* RFC 7232 obsoleted by RFC 9110
* RFC 7234 obsoleted by RFC 7234

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not include such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No status change is intended, but the publication will update RFC 8520.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The authors need to add an empty IANA cons section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus represents strong support of a few individuals with credible
feedback cycles that were addressed over time - with others being silent.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

All feedback was quickly and adequately addressed.  An extensive set of final
review comments from Qin Wu was discussed on via the list and seems to be
implicitly concluded.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are implementations for RFC 8520 including starter tools, such as
https://mudmaker.org/.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document does not include such contents.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not include such content.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document does not include such content.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not include such content.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The assembled OPS area topics do not apply.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track, which is the right track for this document as it is updating
RFC 8520 The DT attributes and tags are now appropriate.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors/editors have stated that they are not aware of any IPR other than
the one IPR disclosure that has been submitted by Huawei Ltd. under
https://datatracker.ietf.org/ipr/4635/.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The documents has three authors that have shown their willingness to be listed
and no additional contributors are listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Some outdated references are now updated:
* draft-ietf-opsawg-mud-tls-11 -> draft-ietf-opsawg-mud-tls-12

Some references are still outdated or obsoleted:
* draft-richardson-mud-qrcode -> RFC 9238
* RFC 7232 obsoleted by RFC 9110
* RFC 7234 obsoleted by RFC 7234

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not include such references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No status change is intended, but the publication will update RFC 8520.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The authors need to add an empty IANA cons section.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/