I support advancing this document, and have the following minor comments. (1) Section 1.3. LLDP should be referenced at first use. The wording at the beginning of Section 11 is nice: "IEEE802.1AB Link Layer Discovery Protocol (LLDP) [IEEE8021AB]”.
(2) Section 1.4. An interesting policy example is: Allow access to host controller.example.com<http://controller.example.com> with QoS AF11 I don’t see how QoS markings are defined in MUD. If not, then “ with QoS AF11” should be removed. Supporting QoS markings would be a good idea though. (3) Section 1.4 and beyond. The word “authority”, “authority component”, “authority section” are all used to mean the same thing, but without further explanation as to what this means. The inconsistency is confusing. But more importantly, it isn’t clear to the reader in those earlier sections that each “authority *" is a forward reference to the “authority element” in the URL definition (Section 5) It would clearer if these references said something like “authority element of the MUD URL”. (4) Section 1.6. Regarding this text: "In the case of IEEE 802.1X, the switch would tunnel the URI via a certificate ….”. The URI isn’t really “tunneled”. How about, "In the case of IEEE 802.1X, the switch would present a certificate containing the URI …”. (5) Section 3.2. For "it should not be necessary to resign a MUD file when a new one is released”, I believe you mean that the MUD file does not not need to be signed again (“re-sign”). Or do you really mean that the manufacturer will “resign” (e.g., “leave” or “stand down”) the MUD file by moving it to the archival location? If so, this needs to be clearer. (6) Section 3.12. This section mentions "standard classes”. There’s should be a reference to what those classes would be, or more text describing what is a “standard class”. Should there be an IANA registry of “standard classes”? Thanks, Brian On Mar 17, 2017, at 3:17 AM, Tianran Zhou <[email protected]<mailto:[email protected]>> wrote: Dear OPSAWG, This is a notice to start a two-week OPSAWG WG last call for the document: Manufacturer Usage Description Specification https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ Please read the above draft and send any issues, comments, or corrections to this mailing list. Please indicate your support or concerns by Friday March 31, 2017. Thanks, Chairs _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg -- Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
