Strong Assertions of IoT Network Access Requirements
draft-ietf-suit-mud-10

I support Éric's discuss, and think we should discuss the oddness of a draft updating a draft without an Update: clause.

Thanks for this document.

I to am supporting Erik and Rob in their discusses, though I have no fundamental issues with the protocol per say.

Thanks for this document. I have just a couple of nit-level comments:

- "communication pattern are described" should be "patterns are" or "pattern is" depending on your intent (which I can't divine).

- Is "Serverdig" a typo, or...?

Comments from incoming ART AD, Orie Steele:

> Only the developer can attest the communication requirements of the device.

^ is this sentence using the word attestation in accordance with 9334 ?

> or as part of other interactions that involve the conveyance of Evidence to the operational network.

it might be preferable to repeat the RATS terms you are using, in terminology.

> Devices can be quarantined if they do not attest a known software/firmware version.

^ perhaps include the word evidence here?

> To accomplish the transport of the manifest Evidence is used, which needs to be available at the protocol of choice.

reads awk.

There is no normative definition of URL, but there should be probably.

Noting several normative references to drafts.

Thanks for addressing my comments.

Thank you for this document.

Also, thank you to Susan Hares for the OpsDir review, and for the followup discussions.

I'd like to support Robert and Eric's DISCUSS positions, especially the "This seems more like an ops thing than a security thing."

Thanks for working on this specification. No objection from transport protocol point of view.

I am supporting Eric's and Rob's discuss. I also found it a bit odd that we are already extending a yet to be specified specification, can't this wait?.

Besides, I have following comments which I believe would improve the readability of the document when addressed -

   # Elaborate SUIT at it's first occurrence in the document.
  
   # What is a MUD URL? yes, a reference to RFC 8520 would be necessary, otherwise, I would need to ask how do you encode the URL, and it's internationalization factors.

   # We would need to know about the "other MUD URL reporting mechanism" to actually understand the pros and cons. Where to we find them?