Hello Gorry, Thank you for clearing the DISCUSS. The draft would now be ready to pass. We will have an editorial update end of this week with some wordsmithing as indicated by Michael. My understanding is that Mahesh will wait progressing the draft as part of the cluster until RFC8366bis is ready to ensure that potential cross dependencies can be easier handled.
Best regards Steffen > -----Original Message----- > From: Gorry Fairhurst via Datatracker <nore...@ietf.org> > Sent: Wednesday, May 21, 2025 8:20 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de; i...@kovatsch.net > Subject: Gorry Fairhurst's No Objection on draft-ietf-anima-brski-prm-22: > (with > COMMENT) > > Gorry Fairhurst has entered the following ballot position for > draft-ietf-anima-brski-prm-22: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to > https://www.ietf.org/ > %2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positions%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7Cc99c2802552 > 4431d142d08dd982f913c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638834052248722338%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=32d7UWpXuezQELNfykYihAT1KM6hU8sTyb97J2 > JtKFA%3D&reserved=0 > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.i/ > etf.org%2Fdoc%2Fdraft-ietf-anima-brski- > prm%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7Cc99c28025524431 > d142d08dd982f913c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8834052248744490%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=uZFlkCDjoNkYGLiEfUVE8y9KVnqYEF6Nj9ZqnUAqdig% > 3D&reserved=0 > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for preparing this document, and the update in rev-19/20, and the > additional text describing the relation to TLS 1.3. > > 1. There appears to be some slight format problem with the bullets I saw > listed > in my rendering: > "such as: * Avoid > logging personally identifiable information unless unavoidable. * > Anonymize or pseudonymize data where possible." (resolved). > > 2. I did not understand the list of three security considerations at the start > of section 12. At least, it would be very helpful to explain these in > sufficient detail to understand each, and also helpful to understand the > implications for users of each. Some words to clarify would be very helpful. > > 3. Please could you add text to explain "no transport layer security between > Registrar-Agent and pledge.." e.g., please explain: Is this something that > users ought to add to a design? how? why? is it a desirable property? Why? ... > or is this intended to be explained more in the next subsections? ... > Especially since 7.1 speaks of optional use of TLS. > > 4. Please update the text to clarify what is intended by: "Pledges MAY support > both initiator and responder mode." ... (resolved - made "may"). > > 5. Please consider updating the text: > "503 Service Unavailable: if a simple retry of the Registrar-Agent > request might lead to a successful response; this error response > SHOULD include the Retry-After response header field with an > appropriate value" > - Why is this not a MUST, if there is a reason, please explain the alternative > to the SHOULD and when this is a suitable response. > > _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
