Strong Assertions of IoT Network Access Requirements
draft-ietf-suit-mud-08
Yes
Roman Danyliw
No Objection
Erik Kline
Francesca Palombini
Jim Guichard
No Record
Deb Cooley
Gunter Van de Velde
Mahesh Jethanandani
Orie Steele
Note: This ballot was opened for revision 07 and is now closed.
Roman Danyliw
Yes
Éric Vyncke
(was Discuss)
Yes
Comment
(2024-03-29)
Sent
Thank you, Roman and WG, for adding an Update: meta-data to the document + the explanations on the timeline for this 'cluster' of MUD I-Ds. Thanks also for your patience as the revised I-D was submitted when I was in pre-IETF holidays and I am only now back to work. -éric
Erik Kline
No Objection
Francesca Palombini
(was Discuss)
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Comment
(2024-01-31 for -07)
Sent
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...?
Murray Kucherawy
No Objection
Comment
(2024-01-31 for -07)
Sent
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.
Paul Wouters
No Objection
Comment
(2024-01-31 for -07)
Sent
I support Éric's discuss, and think we should discuss the oddness of a draft updating a draft without an Update: clause.
Warren Kumari
No Objection
Comment
(2024-01-30 for -07)
Not sent
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."
Zaheduzzaman Sarker
No Objection
Comment
(2024-01-31 for -07)
Sent
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?
Deb Cooley
No Record
Gunter Van de Velde
No Record
Mahesh Jethanandani
No Record
Orie Steele
No Record
Andrew Alston Former IESG member
No Objection
No Objection
(2024-02-01 for -07)
Not sent
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.
Robert Wilton Former IESG member
(was Discuss)
No Objection
No Objection
(2024-03-13)
Sent
Thanks for addressing my comments.