Hi Brian, Apologies for the late response.
On 3/31/17 6:40 AM, Brian Weis (bew) wrote: > 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]”. Fixed. > > (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. Removed for now. This might be something that we use an extension for. > > (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”. I normalized to "authority component" where appropriate, and added a brief definition. That component is a domain name, roughly speaking. > > (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 …”. Corrected. > > (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. Right. Re-sign. > > (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”? Yes. I don't actually have a registry for this, and maybe we need one. Regards, Eliot > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
