[OPSAWG] Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

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.

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"? "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.

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.