[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-mud-acceptable-urls-11: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-mud-acceptable-urls-11

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Henk Birkholz for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 3.1

About the 2nd paragraph, the conflation of unsecure protocols (telnet) with a
no-credential use case is confusing. The issue discussed here is not telnet vs.
SSH but poor credentials. Suggest removing telnet/http protocols in the example.

The 4th paragraph is important but I fail to see the link with this section
"adding capabilities".

## Section 3.3

ALso unsure whether this section should be in this I-D.

## Section 4

References to the protocol for MUD sources are probably welcome.

## Section 4.1

`That it, the signing authority is pinned. ` should this be "that is" ? Also, I
am not sure whether all readers will understand what is meant by "pinned".

## Section 5

What is the meaning of the "proposed mechanism" in a standard track document?
Let's be more assertive and remove "proposed".

Is there a common definition of "lowest Certification Authority (CA)" ? If so,
a normative reference is welcome.

"SHOULD" is used twice, when can an implementation deviate from the "SHOULD" ?
I.e., why not a "MUST".

## Section 5.1

Where is "Base-URI" defined in this (or in another document) defined ? To be
honest, I was about to ballot a blocking DISCUSS on this point.

s/it contains the same series of segments/it contains the same serie of
segments/ ?

In `if a device ever suggests a URL that was previously used` how can a device
downgrade to a previous firmware ?

## Section 5.3.1

Is this just an example ? If so, let's be clear in the section title.

Last paragraph, should it be a "MUST" in `The manufacturer must continue to
serve`.

## Section 5.3.2

Why can an implementation deviate from the `SHOULD NOT` ?

## Section 6

Should this section use more normative uppercase verbs ?

## Section 7

Is there any change wrt to RFC 8520 privacy considerations ?

# NITS (non-blocking / cosmetic)

I find the use of "!" in an IETF document rather unusual, but this is a matter
of taste.

## Section 5.1

s/series of segment/series of segments/ ?