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

[Joe Clarke <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

===

Section 1.2:

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

===

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

===

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

===

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.

===

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.

===

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

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.

===

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.

===

Section 7:

Typo: replicated across IPv4 and IPv6 to allow MUD file autjors the
ability

I think you mean "authors".

===

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.

===

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.

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
> 

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWZHuvgAKCRBvaI+K/hTP
h2xLAKCrdGolZdv0x/47tywrINlsT4XcowCfUCBThZqwYuO/+ZmyDl4G641Q1xs=
=cVEQ
-----END PGP SIGNATURE-----