Hi Madison, Thanks for your hard work. I approve this version of the document.
Best regards Jeremy On 13/05/2025, 15:54, "Madison Church" <mchu...@staff.rfc-editor.org> wrote: WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Nancy and Henk, Thank you for your quick replies! We have noted your approvals on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9781). Once we receive approval from Jeremy, we will move this document forward in the publication process. Thanks! RFC Editor/mc > On May 13, 2025, at 8:51 AM, Henk Birkholz <henk.birkholz@ietf.contact> wrote: > > I'll second Nancy's approval. Thanks Carsten for swatting our nit. > > On 13.05.25 15:49, Nancy Cam-Winget (ncamwing) wrote: >> Hi, >> I am good with this version and approve moving it forward. Thank you all >> for pushing this through. >> Best, Nancy >> *From: *Madison Church <mchu...@staff.rfc-editor.org> >> *Date: *Tuesday, May 13, 2025 at 6:48 AM >> *To: *Carsten Bormann <c...@tzi.org>, Henk Birkholz >> <henk.birkholz@ietf.contact>, Nancy Cam-Winget (ncamwing) >> <ncamw...@cisco.com>, Jeremy O'Donoghue <jodon...@qti.qualcomm.com> >> *Cc: *RFC Editor <rfc-edi...@rfc-editor.org>, rats-...@ietf.org >> <rats-...@ietf.org>, rats-chairs <rats-cha...@ietf.org>, >> kathleen.moriarty.i...@gmail.com <kathleen.moriarty.i...@gmail.com>, Roman >> Danyliw <r...@cert.org>, auth48archive@rfc-editor.org >> <auth48archive@rfc-editor.org> >> *Subject: *Re: [auth48] AUTH48: RFC-to-be 9781 <draft-ietf-rats-uccs-12> for >> your review >> Hi Carsten, >> Thank you for your reply! We have made your requested updates and noted your >> approval on the AUTH48 status page (see >> https://www.rfc-editor.org/auth48/rfc9781) >> <https://www.rfc-editor.org/auth48/rfc9781)>. >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9781.txt >> <https://www.rfc-editor.org/authors/rfc9781.txt> >> https://www.rfc-editor.org/authors/rfc9781.pdf >> <https://www.rfc-editor.org/authors/rfc9781.pdf> >> https://www.rfc-editor.org/authors/rfc9781.html >> <https://www.rfc-editor.org/authors/rfc9781.html> >> https://www.rfc-editor.org/authors/rfc9781.xml >> <https://www.rfc-editor.org/authors/rfc9781.xml> >> The updated diffs have been posted here: >> https://www.rfc-editor.org/authors/rfc9781-diff.html >> <https://www.rfc-editor.org/authors/rfc9781-diff.html> >> https://www.rfc-editor.org/authors/rfc9781-rfcdiff.html >> <https://www.rfc-editor.org/authors/rfc9781-rfcdiff.html> (side by side) >> https://www.rfc-editor.org/authors/rfc9781-auth48diff.html >> <https://www.rfc-editor.org/authors/rfc9781-auth48diff.html> >> https://www.rfc-editor.org/authors/rfc9781-auth48rfcdiff.html >> <https://www.rfc-editor.org/authors/rfc9781-auth48rfcdiff.html> (side by >> side) >> Once we receive approvals from Henk, Nancy, and Jeremy, we will move this >> document forward in the publication process. >> Thanks! >> RFC Editor/mc >>> On May 10, 2025, at 2:42 PM, Carsten Bormann <c...@tzi.org> wrote: >>> On 2025-05-07, at 18:00, Madison Church <mchu...@staff.rfc-editor.org> >>> wrote: >>>> We will await approvals from each author prior to moving forward in the >>>> publication process. >>> I have two more: >>> (1) >>> (Section 4): >>> OLD: >>> When a UCCS emerges from the Secure Channel and into the receiver, the >>> security properties of the secure channel no longer protect the UCCS, which >>> now are subject to the same security properties as any other unprotected >>> data in the Verifier environment. If the receiver subsequently forwards >>> UCCS, they are treated as though >> they originated within the receiver. >>> NEW: >>> When a UCCS emerges from the Secure Channel and into the receiver, the >>> security properties of the secure channel no longer protect the UCCS, which >>> now is subject >>> _______________________________________________________________________^ >>> to the same security properties as any other unprotected data in the >>> Verifier environment. If the receiver subsequently forwards UCCS, they are >>> treated as though they originated within the receiver. >>> The “which" points to the (now singular) UCCS, not the security properties >>> (which aren’t subject to security properties!). Sorry for misleading with >>> my original suggestion. >>> (2) >>> I note that since the acronym “CWT” no longer is in the title, it probably >>> should be added to the keywords. >>> With these two changes, RFC-to-be 9781 is now ready for publication. >>> Grüße, Carsten
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
