Skip to main content

Manufacturer Usage Description Specification
RFC 8520

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc:, The IESG <>,,,, Joe Clarke <>,,
Subject: Protocol Action: 'Manufacturer Usage Description Specification' to Proposed Standard (draft-ietf-opsawg-mud-25.txt)

The IESG has approved the following document:
- 'Manufacturer Usage Description Specification'
  (draft-ietf-opsawg-mud-25.txt) as Proposed Standard

This document is the product of the Operations and Management Area Working

The IESG contact persons are Warren Kumari and Ignas Bagdonas.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

  This memo specifies a component-based architecture for manufacturer
  usage descriptions (MUD).  The goal of MUD is to provide a means for
  Things to signal to the network what sort of access and network
  functionality they require to properly function.  The initial focus
  is on access control.  Later work can delve into other aspects.

  This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
  LLDP TLV, a URL suffix specification, an X.509 certificate extension
  and a means to sign and verify the descriptions.

Working Group Summary

  There was excellent discussion and comments throughout.  The authors were quick to respond, and incorporate feedback as well as push back on items thought to be out of scope.  The discussions led to talks of subsequent work for future drafts.

Document Quality

  There are implementations in the works.  Eliot Lear has stood up a tool at that builds MUD files as a way to help vendors.  There were numerous expert reviews including multiple areas and YANG Doctors.  Those reviews led to some tighter security considerations, as well as more explicit mention that MUD files are to be taken under operational advisement as it is not wise to blindly apply others' configurations to your network.  The YANG Doctors review, in particular, led to a better structure to the MUD YANG module that will allow it to provide a data definition, as well as be implemented on controllers if need be.


  Who is the Document Shepherd? Who is the Responsible Area
  Joe Clarke is the document shepherd.
  Ignas Bagdonas is the responsible AD.

RFC Editor Note