Re: [OPSAWG] Adam Roach's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear <[e-mail]>]

Hi Adam,


On 19.04.18 07:36, Adam Roach wrote:
> Adam Roach 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 would like to thank everyone who worked on this document, and the authors in
> particular for clear, easy-to-read prose. The described mechanism seems quite useful.
>
> ---------------------------------------------------------------------------
>
> §1.3:
>
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>  document are to be interpreted as described in [RFC2119].
> This document also uses lowercase forms of these words. Consider using the
> boilerplate from RFC 8174.

I propose to include this change.
>
> ---------------------------------------------------------------------------
>
> §1.6:
>
>>  Section 5.3.2) containing "application/mud+json", an "Accept-
>>  Language" header ([RFC7231], Section 5.3.5), and a "User-Agent"
>>  header ([RFC7231], Section 5.5.3).
> s/header/header field/ (three times)

ACK
>
> ---------------------------------------------------------------------------
>
> §1.7:
>
>>  JSON is used as a serialization for compactness and readability,
> Perhaps cite RFC 7159 here?

Now 8259.

>
> ---------------------------------------------------------------------------
>
> §3.5:
>
>>  A MUD controller MAY still periodically check for updates.
> I'm surprised to see this as a "MAY" rather than a "SHOULD." For example, even
> an unsupported device may be the subject of a CERT security advisory, and the
> manufacturer would presumably (if possible) take whatever mitigating steps would
> make sense.

I think this is definitional.  The idea in the preceding text really is
that once the vendor sets this, they really have no intention of
updating even CERT-based issues.  This is another instance where
operational experience could provide us guidance between MAY and SHOULD.
>
> ---------------------------------------------------------------------------
>
> §8:
>
>>                    "ietf-acldns:src-dnsname": "test.com",
> The domain "test.com" is registered by an entity known as TESTCOM Inc. It's
> probably best to avoid its use in an example. I would propose "test.example.org"
> or something else reserved by RFC 6761.

Good catch!
>
> (This applies to three other locations in the document as well)
>
> ---------------------------------------------------------------------------
>
> §9:
>
>>   reserved = 1*( CHAR ) ; from [RFC5234]
> Is there a reason to restrict this to be only 7 bits?

It's mostly fear of the unknown.  We don't know how this stuff will be
carried.  But since the URL can be 8 bits wide, I suppose this issue
will have to be solved anyway, so.... OCTET then?

>
> ---------------------------------------------------------------------------
>
> §11:
>
>>  The LLDP vendor specific frame has the following format:
>>
>>  +--------+--------+----------+---------+--------------
>>  |TLV Type|  len   |   OUI    |subtype  | MUD URL
>>  |  =127  |        |= 00 00 5E|  = 1    |
>>  |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
>>  +--------+--------+----------+---------+--------------
> Should this final field be a MUD URL? Or should it be the (extensible)
> MUDstring defined in §9?

Leftover.  Good catch.  Changed to MUDString.
>
> ---------------------------------------------------------------------------
>
> §12.2:
>
>>  Prior to retrieving a MUD file the MUD controller SHOULD retrieve the
>>  MUD signature file by retrieving the value of "mud-signature" and
>>  validating the signature across the MUD file.
> I'm really confused about how this works. 

Propose changed to... "Prior to processing the rest of the MUD file..." 
Earlier versions of the draft had an implicit file for the signature. 
We changed that based on feedback from mnot, but this text didn't get
caught.


> ---------------------------------------------------------------------------
>
> §12.2:
>
> I'm surprised to see no discussion in here of duration of signature validity. I
> presume these will typically be cached by the MUD controller.

I think the choices here are limited, and in particular, if a device is
set to unsupported and the signature becomes invalid, you don't want to
just delete the policy.  The same thing occurs if you don't have
Internet connectivity and can't refresh easily.  Deleting the policy
would violate principle of least astonishment.  Should we say that?

>
> ---------------------------------------------------------------------------
>
> §16.4:
>
>>   o Security considerations: See Security Considerations
>>     of this document.
> Ideally, this would also cite [[RFC 8259]], section 12.
>
>
>

So edited in my copy.

Thanks!

Eliot