Hi Sheng, authors, I checked the new text vs the WGLC issues and confirm that these are resolved.
Because there's new text being added; I've reviewed this as well. Below my findings. I would prefer if the WG could fix this as part of the WGLC work. ** Section 3.2 I can't fully follow the logic in Section 3.2 - it's unclear. Below is a proposal for improvement. There needs to be reference to [BRSKI] defined codes, and a particular code defined for the "owner cannot be determined" case because just using any 4xx/5xx code for that at the whim of the registrar implementer doesn't make sense to me. (The party implementing the cloud registrar may be another party than the one making the pledge code - interoperability plays a role here.) PROPOSED NEW TEXT: The cloud registrar must determine pledge ownership. Prior to ownership determination, the registrar checks the request for correctness and if it is unwilling or unable to handle the request, it MUST return a suitable 4xx or 5xx error response to the pledge as defined by [BRSKI] and HTTP. For example, in case of an unknown pledge a 404 is returned, for a malformed request 400 is returned, or in case of server overload 503. If the request is correct and the registrar is able to handle it, but unable to determine ownership, then it MUST return a 401 Unauthorized response to the pledge. This signals to the Pledge that there is currently no known owner domain for it, but that retrying later might resolve this situation. If the cloud registrar successfully determines ownership, then it MUST take one of the following actions: * return a suitable 4xx or 5xx error response (as defined by [BRSKI] and HTTP) to the pledge if the request processing failed for any reason * redirect the pledge to an owner register via 307 response code * issue a voucher and return a 200 response code ** Section 3.3 It seems that a section is missing on the Pledge side handling an "error response". For example, it could be just a sentence saying the "usual" HTTP error handling defined by [BRSKI] and HTTP applies. And that for the case of 401 Unauthorized the Pledge MAY retry at a later time. ** Nits "They operator the Registrar or EST Server" "which is addresses in part in" Best regards Esko -----Original Message----- From: Anima <anima-boun...@ietf.org> On Behalf Of Sheng Jiang Sent: Friday, June 16, 2023 05:17 To: Brian E Carpenter <brian.e.carpen...@gmail.com>; Brian Carpenter <br...@cs.auckland.ac.nz>; Toerless Eckert <t...@cs.fau.de>; Esko Dijk <esko.d...@iotconsultancy.nl> Cc: anima-chairs <anima-cha...@ietf.org>; anima <anima@ietf.org> Subject: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward Hi, Brian, Esko & Toerless, The authors has submitted a new version draft-ietf-anima-brski-cloud-06. In principle, this draft has passed ANIMA WGLC with the condition that your editional comments are addressed. Could you check and confirm? After your confirmation, the document shepherd and WG chair would like to move it forward. Regards, -------------- Sheng Jiang _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
