Hi Henk and thanks very much for your review. Please see below.
On 8/29/17 11:40 PM, Henk Birkholz wrote: > > > # 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. Ok, but a cautionary note: this draft intentionally focuses NOT on giving the Thing guidance but on giving the *network* guidance. That isn't to say that Things couldn't derive guidance from extensions to the model (we'll talk about that below), but at the moment, the pain point is protecting them. > > ### 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. On the first point, that is precisely the intent of the previous reorg, to demote, if you will, access control so that other mechanisms can be employed. I'll speak more to this below. On the second point, one reason for referencing information is so that the underlying information can change as needed without the need to change the URL itself. While it may be possible in some instances to update the URL, this will not always be the case. Consider that the URL may be inside a signed certificate that is burned into the device. This having been said, we leave open the possibility that the MUD controller may wish to modify the URI through "extras". See below for more details. > > ### 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. That is indeed the assumption. The initial consumers of this information are going to be switches and access control systems that generally speaking can easily parse JSON. Furthermore, at least as we get started, it's important for humans to be able to read and debug this stuff. > > 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)? If the extension augments the YANG module then, well, yes ;-) On the other hand, if the extension is a reference to something else, then the rules are up to that "something else". Let's take an example. Suppose there is an extension that points to some form of WoT/schema.org-based description. That description could be in the form of a URN, that a network might use to populate a CoAP resource directory, that other Things could then retrieve. The rules for the form of all of that would be well outside the scope of MUD, which would be a good thing, because I just referenced a bunch of stuff that you know a lot more about than I do ;-) All the encoding rules and semantics are left to you to define. At that point, a network management system would have to obey your semantics if the device wants want to play. If you like the above text, we could add something like it. > > > 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)? Yes, for reasons given above. > > ### 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. I wouldn't go that far. The point of externalizing the version # from JSON is so that the next version could return something else. Many of us have lived through ASN.1 BER/DER, SGML, HTML, XML, RDF (and numerous other forms of XML), JSON, CBOR, and YAML in all of its looseness. It would be presumptuous to believe that either JSON or CBOR are the be-all end-all, especially since we're discussing them here. Also, one could easily envision an entire conceptual reorganization in the next version, but let's hope that will be down the road a bit. Having written all of this, clearly the draft led you who are knowledgeable in this subject to somehow believe otherwise. If there is a textual change that clarify that, let's make it. > > 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. You've caught an important point, and we should review the text: OLD: > This string matches the entire MUD URL, thus covering the model that > is unique within the context of the authority. It may also include > product version information. Thus how this field is constructed is > entirely a local matter for the manufacturer. I propose the following to address your point: NEW: > > This string matches the entire MUD URL, thus covering the model that > is unique within the context of the authority. It is attended to > uniquely identify > a particular class of device. It may contain not only model > information, but > versioning information as well, and any other information that the > manufacturer > wishes to add. The intended use is for devices of this precise class > to match, to permit or > deny communication between one another. To make this point clearer, I also propose a change to the non-terminal in the ABNF to avoid confusion, as well as a modest change to the text that follows. > > ### 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? Here I can only but agree that "extra" is under-specified, and I believe an earlier reviewer mentioned this as well. Here is what I have in mind for text: NEW: > "extras" is intended for use by the MUD controller to provide > additional information such as posture about the Thing to the MUD file > server. This field MUST not be configured on the Thing itself by a > manufacturer - that is what "modelinfo" is for. It is left as future > work to define the full semantics of this field. > > ### 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). Keep in mind that the signature is intended to be consumed by a MUD controller. This having been said, I'll examine this and see if we can add guidance. > > ## 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."? I don't know about you, but I find XML as easy to parse as binary. I say, relative to XML because I certainly don't want to claim that JSON is EASIEST for humans to read. A natural language such as English or German is far easier. > > %s/Application\/pkcs7-signature/application\/pkcs7-signature/g > Very good. I hope this answer addresses your issues. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
