Subject: [OPSAWG] Mirja Kühlewind's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 18 Apr 2018 07:11:05 -0700

Mirja Kühlewind 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:
----------------------------------------------------------------------

Minor comments:

1) "is-supported" confused me a bit at the beginning. Maybe "is-maintained" could be a better name?

2) Why does the MUD file contain the MUD URL? Is this meant to be used as an identifier?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Apr 2018 11:45:11 +0200

Hi Mirja,

I suspect this may just be a tech-language issue, but I view the two as
synonymous.  The description does try to define the term.

> 2) Why does the MUD file contain the MUD URL? Is this meant to be used as an identifier?

Oh good question!  Without it, the MUD file itself is not
self-identifying.  This URL provides a means by which one could use
alternative resolution mechanisms.  A good example would be that a MUD
file and signature have been uploaded manually.  The file can inform MUD
manager as to what it is intended to be used for.

I propose to include 2nd and 3rd sentences.

> 3) Given this document talks quite often about possible future extensions, I'm
> also wondering if this should be Experimental. However, I assume the
> framework/architecture that is defined in this doc is not suppoed to change and
> as such PS might be good as well.

This isn't intended to be an experiment, but rather that we make
incremental progress on how we build out this capability.  Also
manufacturers really won't code up to an experiment.  This costs them
real COGS to do, and without them, we can't gain necessary experience.

>
> 4) I understand that the use of YANG is quite convinent for ACLs, however, I'm
> wondering if it is still the right choice if the MUD File would be used to
> describe more detailed behavior/traffic patterns. However, that should probably
> not be changed now, but might be another reason to go for experimental.
> Annother solution would be to further separate the architecture from the MUD
> file format (maybe into different doc?) and include a versioning mechanism in
> the MUD URL.

Welcome to my pain.  The reason we went with JSON + YANG is that the
basic capability an access list.  Other capabilities will follow, and
the perfect way to do that is by referring to another file.  This having
been said, we should leave room for the possibility that the format WILL
change over time, but I expect the timescales to be quite great.

Eliot