I think draft-tschofenig-uta-tls13-profile represents work that UTA should take on, and that it is a good starting point for the working group to use.
Review of version -01: Section 2: Please change to the RFC 8174 boilerplate and add a normative reference to RFC 8174. Section 3, last paragraph: a nit, but I would change this to active voice: NEW TLS/DTLS clients and servers implementing raw public keys and/or certificates MUST follow the guidance for mandatory-to-implement extensions described in Section 9.2 of [RFC8446]. END Section 4: The last sentence has a typo and doesn’t make sense. I think you mean this: NEW Hence, it is more important for a developer to find out from which situations the device can recover and which situations are hopeless. END (And you might consider whether the word “more” is actually useful.) For Sections 8, 9, 10, 13, and 14 (and the first paragraph of Section 3), we should consider whether this document should be stand-alone (consider a future when TLS 1.3 is ubiquitous and 1.2 fades away), and copy the text from 7925 rather than refer to it, even though that makes this document longer. One could do that along with adding a note that the RFC Editor will remove, which says that the text is verbatim from RFC 7925, to help reviewers. Section 9: Change “this document” to “that document”. Section 10: Nit… “any more” should be two words. Section 15: draft-ietf-http-replay is now RFC 8470, published in September. Another unnecessary passive voice to change to active: OLD It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests. NEW Origin servers SHOULD allow resources to explicitly configure whether early data is appropriate in requests. END You say, ‘This specification defines a new CoAP option "timestamp" ‘. Why is that defined in Appendix A, and not here in Section 15? -- Barry _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
