Thanks, those all work for me. Deb
On Tue, May 5, 2026 at 6:04 PM Mike Ounsworth <[email protected]> wrote: > @Deb Cooley <[email protected]> > > FYI the authors just published -04 a few minutes ago, which addresses all > the IESG comments received so far. > https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ > > > On Tue, 5 May 2026 at 17:00, Ganesh Mallaya <ganesh.mallaya= > [email protected]> wrote: > >> Hello Deb, >> >> Thank you for the note and the comments, all points noted, yes we will >> review and work through them along the IETF LC. >> >> Get Outlook for iOS <https://aka.ms/o0ukef> >> ------------------------------ >> *From:* Deb Cooley <[email protected]> >> *Sent:* Monday, May 4, 2026 04:22 >> *To:* [email protected] < >> [email protected]> >> *Cc:* <[email protected]> <[email protected]>; IETF ACME < >> [email protected]> >> *Subject:* AD comments on draft-ietf-acme-device-attest >> >> *CAUTION: *This email originated from outside of the organization. Do >> not click links or open attachments unless you can confirm the sender and >> know the content is safe. >> >> First-time / External Recipient Warning >> You have not previously corresponded with this sender. >> >> Thanks for the work to improve this draft! >> >> I have several pretty easy comments. I will put this draft into IETF >> Last Call, with the assumption that my comments will be worked >> before/together with IETF Last Call comments. >> >> Section 1, para 3: 'is to be' is an odd turn of phrase, how about 'will >> be'? >> >> Section 3.1, assigner value: Is this intended to be an IP address? If >> so, expect to get a comment similar to 'what about IPv6 addresses?' If it >> is intended to be an OID, then I would just say that, as is done in Section >> 4.1. >> >> Section 3.2, title: Add (CSR). Or within para 4, spell out CSR instead. >> >> Section 3.2 and 4.2, para 3 and 4: 'octet-for-octet', I'm curious to >> hear why any other sort of 'match' isn't correct or useful. And why merely >> saying that it 'MUST be a match' wouldn't work. >> >> Section 6.1, para 1: nit: remove '###External Account Binding'. >> >> Section 6.1.1, para 2: This wording isn't clear (I had to read it a >> bunch of times to understand). How about something like, 'Servers can rely >> on other authorization mechanisms,such as external account binding or >> pre-authorized accounts, to establish device identity instead of completing >> the device-attest-01 challenge.' >> >> Deb Cooley >> Sec AD >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
