Reviewer: Henk Birkholz Review result: Has Issues Hi, I am the assigned IoT-DIR reviewer for this document's early review. Please find my comments in kramdown below. Viele Grüße, Henk # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 ## Draft Summary This draft defines a canonical way to compose an URI that points to a specific resource called a MUD file. A MUD file is a text resource that contains imperative guidance in the form of YANG-based ACL policies represented in JSON. The imperative guidance is intended to be applied to things that can be identified by the segments of the MUD URI via a specific controller. The version of MUD is a component (segment) of the MUD URI and there are three examples in what to embed a MUD URI in (DHCP option, X.509 extension, and LLDP extension). ## Comments on General Topics This draft could be a significant step towards to self-descriptiveness of things. Constrained things might require imperative guidance or declarative guidance in order to be managed appropriately - which in includes aspects, such as isolation, clustering, service/capability discovery/exposure, and therefore security automation in general. In a lot of usage scenarios, it might not be feasible to store that guidance on the thing itself and MUD URI could be a solution to support a lot of vendor supplied information, such as reference integrity measurements, intended composition of composite devices, etc. ### Scope of Application On one hand, this drafts limits the potential usage of the MUD architecture to the use of one specific branch of YANG modules regarding ACL policies. There is no way to express other manufacture usage description "information-types" or "content-types" on a fundamental level and section 13 specifically states that "coupled with the fact that we have also chosen to leverage existing mechanisms, we are left with no ability to negotiate extensions and a limited desire for those extensions in any event." Creating augments for the metainfo container as it is also described in Section 13, on the other hand, allows for virtually any kind of information to be expressed and conveyed via a MUD file, but on a semantic level that seems to be a bit perplexing. This comment is not intended to question the feasibility of the technical approach - which is okay - but more taking into account the principle of least surprise. Hence, a strong proposal - in respect to the already included universal extension mechanism - to consider: * aligning ACL content and "other" content on the same semantic level in the YANG module, and * maybe indicating the corresponding semantics of the MUD file in the MUD URI itself. ### Intended & Allowed Representations/Formats The assumption is that neither the MUD controller nor the server serving the MUD files are constrained devices. The things that the imperative guidance is intended to address can be constrained devices. YANG modules are used to create the MUD files and the representation in the MUD files is JSON. In the scope of the extensibility feature highlighted, is it intended that every MUD file must contain content that relates to the structure of a YANG module (or are there other data models for data at rest planned for)? Is JSON intended to be the only allowed representation used for the representation of content in MUD files (a question in respect to the CBOR-based CoMI draft in the CORE WG)? ### Segment "mud-rev" There seems to be conflicting definitions about the semantic of the segment "mud-rev": Section "5. What does a MUD URL look like?" states that a "mud-rev signifies the version of the manufacturer usage description file" and "this memo specifies "v1" of that file". The passages quoted here seem to imply that mud-rev is about the instance of JSON that is the content of the MUD file. Section "13. Extensibility" though states "at a coarse grain, a protocol version is included in a MUD URL. This memo specifies MUD version 1. Any and all changes are entertained when this version is bumped.", which implies that mud-rev is intended to state the version of the MUD protocol and probably the respective YANG module(s). Probably, you want both? Most certainly, this has to be clarified. ### Segment "model" Every device typically is a composite. Similarly, the hardware device-model identifier is a potential composite of device-type, device-model & device-version (and probably even more). The text is very vague on this part, maybe deliberatively so because the authors do not want to prescribe how to compose the string that constitutes the model segment - but a bit more guidance on what this typically means and what could be caveats if you concatenate this potentially very complex identifier into a single string is strongly recommended. Also, model is supposed to include in a not further specified way an identifier of the "version" of the software next to the "version" of the hardware. Even in very small things, software components can be composites, too. Furthermore, a software version may run on more than one device-model or even device-type. While it might introduce complexity in respect to URI composition (one/two extra segments), separating the hardware composite-identifier from the software/firmware composite-identifier will be helpful and provide more clear semantics to both humans and machines. ### Query "extra" While this option is included in the composition guidance of a MUD URI, it is not included in the text anywhere. One guess of its purpose could be to provide subsets of the modules via xpath or subtree expressions. Is that the case? Additionally, including a variable in an immutable container, e.g. DevID, seems to negate the intend of it being a variable? Maybe this should be highlighted in the upcoming section that illustrates what the "extra" query option is for? ### Signing MUD files The given openssl example basically allows for every kind of certificate- or key-type. Is that intentional? While most individuals will be able to inflate "mancertfile" or "mankey" to manufacturer certificate and manufacturer key, respectively, I strongly recommend to provide more guidance here - especially in regard to command parameters and appropriate hash and cipher algorithms with a low footprint. Providing examples here will be beneficial (maybe ECDSA & EDDSA). ## Nits What does the expression "relative to XML" intends to convey in "JSON is used as a serialization for compactness and readability, relative to XML."? %s/Application\/pkcs7-signature/application\/pkcs7-signature/g _______________________________________________ IoT-DIR mailing list IoT-DIR@ietf.org https://www.ietf.org/mailman/listinfo/iot-dir