You want to do this now? After (or your ask was right before) the telechat?
If you want to do this, I'd like the working group to weigh in (for whatever definition of 'working group' is best - at least lamps, and likely others). Deb On Thu, May 8, 2025 at 12:11 PM Toerless Eckert <t...@cs.fau.de> wrote: > I think yes, but i think to justify the update header for rfc9148, > this CSRattr draft would need a short new section to justify it, e.g.: > > | 3.4 Update to RFC9148 > | > | The updates to EST in this document equally apply when using > | CoAP as a transport as described in RFC9148. This document therefore > | adds the following paragraph after the second paragraph > | of RFC9148, Section 1. > | > | EST over CoAP as specified in this document applies unchanged > | to RFC7030 updated by THISRFC. Hence, all references to RFC7030 in > | this document are assumed to indicate RFC7030 updated by THISRFC. > | > | THISRFC also becomes a new mandatory reference to RFC9148 > > Cheers > toerless > > On Thu, May 08, 2025 at 12:59:03PM +0100, Michael Richardson wrote: > > > > internet-dra...@ietf.org wrote: > > > Title: Clarification and enhancement of RFC7030 CSR Attributes > definition > > > > Oops, something I meant to mention but we kept getting dragged back into > the > > weeds, and maybe belonged in the Shepherd write up: > > > > RFC9148, EST-coaps: Enrollment over Secure Transport with the Secure > Constrained > > Application Protocol > > > > This document puts 7030 over COAPS, and uses /csrattrs (as /att). > > It doesn't change CSRATTRS in any way, and someone implementing RFC9148 > ought > > to be reading 7030, and updates to 7030. > > > > But, should this document explicitely update 9148 as well? > > > > -- > > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > > > > > > > > -- > --- > t...@cs.fau.de >
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
