Responding to Spencer, Ben, and Alexy (in order).
On 16.04.18 21:09, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-opsawg-mud-20: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a Yes who's watching Discussions with other ADs, but that's still a Yes. > Thanks for doing this work. > > I do have some questions and comments. > > I don't think this requires any changes to the current document, but I note > that > > 3.15. direction-initiated > > When applied this matches packets when the flow was initiated in the > corresponding direction. [RFC6092] specifies IPv6 guidance best > practices. While that document is scoped specifically to IPv6, its > contents are applicable for IPv4 as well. When this flag is set, and > the system has no reason to believe a flow has been initiated it MUST > drop the packet. This node may be implemented in its simplest form > by looking at naked SYN bits, but may also be implemented through > more stateful mechanisms. > > it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2 > over QUIC, and I'm a bit suspicious of "may also be implemented through more > stateful mechanisms" in 2018. Do the right thing, of course. I proposed a clarification: direction initiated is a TCP element. > > Does > > 3.5. is-supported > > This boolean is an indication from the manufacturer to the network > administrator as to whether or not the Thing is supported. In this > context a Thing is said to not be supported if the manufacturer > intends never to issue an update to the Thing or never update the MUD > file. A MUD controller MAY still periodically check for updates. > > ever mean anything except "is-updated"? Mostly that what it means, but the implication is that there's no support, and enterprise administrators in particular might want to know that (usually they do- because those devices represent a particular risk). > "Supported" covers a lot of ground … > > If a manufacturer sells off one product line (so, flobbidy.example.com covered > multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be > maintained by a manufacturer that isn't flobbidy.example.com), is there a good > plan for what comes next? I'm not sure what happens to is-supported, for > instance. The intent is that the entity providing the MUD file (probably the manufacturer) will not be issuing software/firmware updates or MUD file updates. But your point is more about device lifecycle, and that's a more interesting question than just "is-supported". Steve Rich and Thorsten Dahm have begun to delve in that direction. There are at least a few possibilities, such as the use of redirects, or even domain names that are used for particular classes of devices, or even common repos. More work needed. > > I'm sensitive to Eliot's "walk before trying to run" comment on another ballot > thread, but I'm thinking that > > 3.11. model > > This string matches the entire MUD URL, thus covering the model that > is unique within the context of the authority. 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. > > might usefully result in a BCP about naming models, after the community has > some experience with MUD. So, that's not intended to affect the current draft > text, only the working group that produced it ;-) > > And, double ;-) ;-) but I wrote that before I saw this text in Section 14: > > A caution about some of the classes: admission of a Thing into the > "manufacturer" and "same-manufacturer" class may have impact on > access of other Things. Put another way, the admission may grow the > access-list on switches connected to other Things, depending on how > access is managed. Some care should be given on managing that > access-list growth. Alternative methods such as additional network > segmentation can be used to keep that growth within reason. > > So, when people know enough to describe best practices, I hope they do. > Thanks, Spencer. We're just getting going. Now to Ben: > §1.6, 2nd paragraph: Why is the SHOULD not a MUST? Because at this stage there is only one encoding and no source of confusion as to what is returned, and the people implementing this stuff are getting their feet wet. If they're using a service that simply doesn't include the right Accept: header, and the right thing can still happen, let's let that happen. > > §1.8, 4th paragraph: "The web server is typically run by or on behalf of the > manufacturer. > Its domain name is that of the authority found in the MUD URL. " > > These URLS are likely to be hardcoded, correct? This seems to point to > operational considerations, especially around Thing lifecycle and ownership. Indeed. It's captured in Security Considerations, but we can place a forward pointer there. > > Editorial/Nits: > > Abstract: I'm not sure the use of the term "Things" will be obvious to a > reader > of the abstract in isolation from the rest of the document. (Abstracts should > be able to stand alone.) EKR beat you to it. Change proposed. > > §1.1 : first paragraph: The idea that a Thing might have highly restricted > communication patterns seems core to the document. It would be helpful to > mention that earlier in §1. I think EKR beat you to this one as well ;-). Change proposed. > §1.3, definition of "Manufacturer": The definition says that "Manufacturer" > may > not necessarily be the entity that constructed the Thing. But that's the plain > English meaning of the word "manufacturer". If you don't want it to mean that, > please consider choosing a different term. ( for example, "authority") This one's harder to change, and authority has its own ambiguities. > > §1.4: "... we assume that a device has so few > capabilities that it will implement the least necessary capabilities > to function properly." > > That's a bit circular. Perhaps one of the two instances of "capabilities" > should have been "requirements"? How about: > In seeking a general > solution, however, we assume that a device will implement > functionality necessary to fulfill its limited purpose. > > §1.8 4th paragraph: The 2nd (and last) sentence is a comma splice, and > otherwise difficult to parse. That is a mouthful. Propose: > The web server is typically run by or on behalf of the manufacturer. > Its domain name is that of the authority found in the MUD URL. For > legacy cases where Things cannot emit a URL, if the switch is able to > determine the appropriate URL, it may proxy it. In the trivial case > it may hardcode MUD-URL on a switch port or a map from some > available identifier such as an L2 address or certificate hash to a > MUD-URL. > > §1.9, list item 7: are we talking about transient disconnect or permanent > removal? Could be either. The only difference between the two is that at some point someone has to CRUD the thing out of a database somewhere. > > §2: "A MUD file consists of a YANG model ..." > A model instance, right? That is, not the model itself? Indeed. > > §3.8, 2nd sentence: Consider reformulating this as a construction of MUST. I think that's fair, and propose to change it to the following: > Note that MUD extensions MUST NOT be used in a MUD file without > the extensions being declared. Implementations MUST ignore any node > in this file that they do not understand. > > §4: The idea of a "default" in bullet 2 seems in tension with the idea of > "Anything not explicitly permitted is forbidden" in bullet 1. Maybe so, but the intent here is that a great many devices are going to be making use of DNS and NTP, and that not listing them in a MUD file is more likely to lead to mistakes, rather than accidentally listing them. > > §14: Please define the concept of "east-west infection". > Propose "lateral infection" with a parenthetical definition. On to Alexey: > 16.4. MIME Media-type Registration for MUD files > > The following media-type is defined for transfer of MUD file: > > o Type name: application > o Subtype name: mud+json > o Required parameters: n/a > o Optional parameters: n/a > o Encoding considerations: 8bit; application/mud+json values > are represented as a JSON object; UTF-8 encoding SHOULD be > employed. > > I am tempted to say "MUST be UTF-8 encoded". In this day and age I think that sounds correct. I personally have no objections. > > o Security considerations: See Security Considerations > of this document. > o Interoperability considerations: n/a > o Published specification: this document > > Nit: IANA Media Type registration templates need to have fully qualified > references. Use "[RFCXXXX]" instead of "this document" here, so that when the > RFC is published, the registration template can be posted to IANA website and > will have correct reference. Ok > > o Applications that use this media type: MUD controllers as > specified by this document. > > As above. Ok > > o Fragment identifier considerations: n/a > o Additional information: > > Magic number(s): n/a > File extension(s): n/a > Macintosh file type code(s): n/a > > o Person & email address to contact for further information: > Eliot Lear <l...@cisco.com>, Ralph Droms <rdr...@cisco.com> > > I think Ralph's address is wrong in 2 places. Corrected. > > o Intended usage: COMMON > o Restrictions on usage: none > o Author: > Eliot Lear <l...@cisco.com> > Ralph Droms <rdr...@cisco.com> > o Change controller: IESG > o Provisional registration? (standards tree only): No. > > UTF-8 needs to be a Normative reference (RFC 3629). > Ok. Thanks, all. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
