Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt

[Eliot Lear <[e-mail]>]

Hi Joe,

Thanks for your thoughtful review.  Please now see below.

<individual-not-editor-or author>


On 8/14/17 7:41 PM, Joe Clarke wrote:
> Hello, Eliot and MUD authors.  I first want to chime in as a working
> group member and provide a review of this latest revision.  Please see
> below.
>
> Section 1:
>
> OLD:
>
> In this specification we specify each of these building blocks and
> how they are intended to be used together
>
> NEW:
>
> In this specification we describe each of these building blocks and
> how they are intended to be used together
>
> It's a nit, but specification and specify sound awkward together.  So
> I chose a different word.

+1.  Nice catch.

>
> ===
>
> Section 1.2:
>
> I love the readability of this in general, but maybe replace
> "Facebook" with "social network" or something a bit more generic.

Ok.

>
> ===
>
> Section 1.4:
>
> You state that the memo describes three ways to emit a MUD URL.  You
> ultimately list three, but this reads strangely:
>
> The other method defined is an X.509 constraint...
>
> This is the second method (the first being DHCP).  So maybe you should
> state, "An other method" or "The second method".

Right.

>
> ===
>
> Section 1.6:
>
> A MUD file is more than just a behavior.  It lists details about a
> Thing such as whether or not it's supported, details about it from a
> reference URL, etc.  Perhaps the definition of a MUD file should be
> "...JSON that describes a Thing and its required network behavior."

I would prefer to run with "suggested" than "required".  The analogy has
always been an indications label that comes with medicine.  You can go
off label if you want, Mme. Administrator, even if it isn't recommended.


>
> ===
>
> Section 1.7:
>
> You mix the use of URL and URI.  While a URL is a URI, I think it
> would be good to keep the use of URL as that is what you define in
> section 1.6.

Righto.  There are a handful of places where URI is still appropriate
(registrations, internationalization).
>
> ===
>
> Section 1.8:
>
> While you call out a reputation system check, would an important step
> here be to verify the overall veracity of the MUD file itself?  That
> is, verify the MUD files signature.  You talk about this below, but I
> think it's worth calling out here as well.

Good point.
>
> ===
>
> Section 2:
>
> You state that "Devices parsing MUD files..."  I think you should
> refer to your terminology here and say "MUD controllers parsing MUD
> files..."
>
Right.

> Additionally, you say that upon seeing "other" elements in the MUD
> file, the controller should cease processing.  What exactly happens,
> then, to the data already parsed?  Does that get applied, or must the
> controller reject the entire file?  IMHO, the controller should
> disregard a file that violates the spec.  But in any case, I think you
> should be explicit here in the text.

Made explicit.

>
> ===
>
> Section 6:
>
> Should the timers for last-update and cache-validity be mandatory?  As
> it stands now, nothing in metainfo is mandatory, and I think some
> things (like the timers) should be.  I also think is-supported is key.

That's a good question and I like the list that you identified.  I think
this requires some additional discussion, though, just to confirm model
structure.  I'll come back to you on this.


>
> ===
>
> Section 7:
>
> Typo: replicated across IPv4 and IPv6 to allow MUD file autjors the
> ability
>
> I think you mean "authors".
>
Corrected.

> ===
>
> Sections 7.1 and 7.2:
>
> I would imagine at some level these names would have to be resolved.
> Perhaps what you mean as to when they are resolved is left to the
> implementation?  That is to say, some vendors may resolve at the time
> of configuration whereas others may resolve more dynamically.

I think I want to say more than that.

What I'm thinking about is as follows:

> A number of    means may be used to resolve hosts.  What is
> important is that such resolutions be consistent with ACLs required by
> devices  to properly operate.

>
> ===
>
> Appendix B and Section 8:
>
> These are out of date with the current schema.  For example, you have
> lastUpdate instead of last-update, cacheValidity instead of
> cache-validity.
>
Oh nertz!  That's a mudmaker bug.  Fixed!

Thanks!

Eliot 

> Joe
>

> On 8/11/17 16:10, Eliot Lear wrote:
> > Hi everyone,
>
> > As promised, this update corrects all examples (we just didn't have
> > time to do that for the IETF) and adds a bit more wording around
> > the abstractions so as to give some guidance on how to translate
> > abstractions.  In addition, some guidance is given relating to how
> > to instantiate the ACL model, given the use of features.
>
> > Finally, the MUD file maker has been updated, and can now be
> > reached at mudmaker.org.
>
> > With this, I would ask that we start  the various YANG doctor and
> > other directorate reviews.
>
> > Eliot
>
>
> > On 8/11/17 1:02 PM, [e-mail] wrote:
> >> A New Internet-Draft is available from the on-line
> >> Internet-Drafts directories. This draft is a work item of the
> >> Operations and Management Area Working Group WG of the IETF.
> >>
> >> Title           : Manufacturer Usage Description Specification
> >> Authors         : Eliot Lear Ralph Droms Dan Romascanu Filename
> >> : draft-ietf-opsawg-mud-08.txt Pages           : 48 Date
> >> : 2017-08-11
> >>
> >> Abstract: This memo specifies a component-based architecture for
> >> manufacturer usage descriptions (MUD).  This includes two YANG
> >> modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix
> >> specification, an X.509 certificate extension and a means to sign
> >> and verify the descriptions.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-opsawg-mud-08
> >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-08
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-08
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________ OPSAWG mailing
> >> list [e-mail]
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
>
>
>
>
> > _______________________________________________ OPSAWG mailing
> > list [e-mail] https://www.ietf.org/mailman/listinfo/opsawg
>
>
>