Subject: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05

From: Tianran Zhou <[email-masked]>
Date: Fri, 17 Mar 2017 08:17:37 +0000

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

---

From: Thorsten Dahm <[email-masked]>
Date: Tue, 28 Mar 2017 13:20:01 -0500

I support the document.

Regards,
Thorsten

On 17 March 2017 at 03:17, Tianran Zhou <[email-masked]> wrote:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Fri, 31 Mar 2017 04:40:39 +0000

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-masked]<mailto:[email-masked]>> wrote:

Dear OPSAWG,

Thanks,
Chairs

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>