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

[Adam Roach <[e-mail]>]

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.

---------------------------------------------------------------------------

§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)

---------------------------------------------------------------------------

§1.7:

>  JSON is used as a serialization for compactness and readability,

Perhaps cite RFC 7159 here?

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

(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?

---------------------------------------------------------------------------

§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?

---------------------------------------------------------------------------

§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. My understanding so far is that the
Thing will provide a URL that points to the MUD file. Inside this MUD file is a
"mud-signature" that points to the signature discussed in this section. So, to
get to the MUD signature, the MUD controller has to first retrieve the MUD file.
But the text above says that it SHOULD retrieve the signature before it
retrieves the MUD file.

How?

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§16.4:

>   o Security considerations: See Security Considerations
>     of this document.

Ideally, this would also cite RFC 7159, section 12.