[email protected] wrote: > A new version of I-D, > draft-richardson-opsawg-securehomegateway-mud-02.txt has been > successfully submitted by Michael Richardson and posted to the IETF > repository.
URL: https://www.ietf.org/internet-drafts/draft-richardson-opsawg-securehomegateway-mud-02.txt Status: https://datatracker.ietf.org/doc/draft-richardson-opsawg-securehomegateway-mud/ Htmlized: https://tools.ietf.org/html/draft-richardson-opsawg-securehomegateway-mud-02 HTML: https://www.ietf.org/id/draft-richardson-opsawg-securehomegateway-mud-02.html After a few false starts over the last year, I've completed the bulk of the text. I have split this work off from the "smarkaklink" text that some of you may have seen as it is stand-alone. I have reached out for a few other MUD experts to ask if they will co-author. I hope to ask OPSAWG to process this document, if it has enough support. There are two items which I've said the document will deal with, but which it does not currently do: } A issue addressed by this document is the question of whether and } when the MUD file should be specific to a specific version of the device } firmware. This is just text. } The third issue is that an intermediary (ISP, or third-party security } service) may want to extend or amend a MUD file received from a manufacturer. } In order to maintain an audit trail of changes, a way to encode the previous } MUD URL and signature file (and status) is provided. (FOR DISCUSSION) This is new mechanism, which probably belongs in another document. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
