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

From: [email-masked]
Date: Fri, 11 Aug 2017 13:02:37 -0700

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/

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Aug 2017 13:10:58 -0700

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, [email-masked] wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Joe Clarke <[email-masked]>
Date: Mon, 14 Aug 2017 14:41:07 -0400

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
> 
> 
>> 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.
>> 
>> 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.
>> 
>> 
>> 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.
>> 
>> _______________________________________________ OPSAWG mailing
>> list [email-masked] 
> _______________________________________________ OPSAWG mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Aug 2017 21:07:15 +0100

Hi Joe,

Thanks for your thoughtful review.  Please now see below.

<individual-not-editor-or author>

> I chose a different word.

+1.  Nice catch.

> "Facebook" with "social network" or something a bit more generic.

Ok.

> state, "An other method" or "The second method".

Right.

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

> would be good to keep the use of URL as that is what you define in

Righto.  There are a handful of places where URI is still appropriate
(registrations, internationalization).
> think it's worth calling out here as well.

Good point.
> refer to your terminology here and say "MUD controllers parsing MUD
Right.

> should be explicit here in the text.

Made explicit.

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

> I think you mean "authors".
Corrected.

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

> lastUpdate instead of last-update, cacheValidity instead of
Oh nertz!  That's a mudmaker bug.  Fixed!

Thanks!

Eliot

---

From: Joe Clarke <[email-masked]>
Date: Mon, 14 Aug 2017 16:41:21 -0400

On 8/14/17 16:07, Eliot Lear wrote:
>> 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.

Yes, I agree.  Very good distinction.

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

Count me in.  I thought about this section for a little bit before
writing this, and I got really comfortable with the notation of the
timers and is-supported being the only mandatory elements.

>> 
>> 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.
> 
>> important is that such resolutions be consistent with ACLs
>> required by devices  to properly operate.

I like this text.  I would only add some element of time to this to
indicate that hosts may be resolved at different points in the packet
processing path, and attention should be paid to how this is done to
ensure any changes that may occur in resolution.

Ugh, that just made me think.  Maybe there should be a manufacturer
considerations blurb that says that different vendors may do
resolution differently, and if a manufacturer uses DNS with a
round-robin set of addresses, it may cause discrepancies in what ACLs
will allow (based on the controller/network device that does the
resolution).

I feel this kind of thing should be made more explicit to ensure that
The Right Thing gets done on the network.

Thanks for your attention, Eliot.  Like I said, I continue to enjoy
the readability of this document.

Joe

---

From: Joe Clarke <[email-masked]>
Date: Tue, 15 Aug 2017 08:58:04 -0400

> other directorate reviews.

Eliot, as co-chair, I have requested an early review for this draft
(and revision) from YANG Doc, IOTDIR, SECDIR, and GENART.  I have
given the reviews a two-week deadline (for August 29).

Joe