Éric Vyncke has entered the following ballot position for draft-ietf-anima-brski-cloud-17: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my previous blocking DISCUSS issue (I told you that it was trivial to fix). Alas, I have noticed that some of my original non-blocking COMMENTS below are not addressed in -17 (notably having references *only* to DHCPv4 rather than DHCPv6). ## COMMENTS (non-blocking) ### Missing privacy / operational considerations ? As the Cloud and Owner are different organisation, I was expected to read some privacy considerations: - the Cloud Registrar will see the addresses (i.e., location) and devices count per Owner - the Owner relies on the Cloud Registrar availability, i.e., it is a single point of failure (the draft discusses briefly about bankruptcy but this could be censorship as well) ### Nice use of SVG Thanks for using SVG graphics, so much more readable :-) ### Section 1.1 The OEM definition is not really the usual one, but this is OK I guess in this I-D even if the word 'created' looks weird in this context (why not 'manufactured'). Missing "owner", does it mean the guy buying the phone (or...) or the company operating it ? It is really an ambiguous and overloaded term. The word 'domain' is also under-specified as it can means several things. ### Section 1.2 s/target use cases/use cases/ ? More important, as we are in 2025, why using DHCPv4 and no DHCPv6 ? One author is even a RFC 8415 author... Please update the draft with DHCPv6 reference. It is informational use of DHCPv4 as an example, therefore this point is sadly not DISCUSS worthy. Add an informative reference to `LDevID`. ### Section 2 Please expand `MASA` and provide a reference. ### Section 2.1 Please add "Pledge operator" to the terminology as it is a little unclear. It is not enough to state `The Pledge must have an IP address so that it is able to make DNS queries` suggest "The Pledge must have an IP address and be capable to reach a recursive DNS server". ### Section 2.2 Suggest expanding `CSR` at first use. Should a reference be added to `IDevID` ? ### Section 3 I find the flow of steps then ventilate by use case somehow difficult to read. Probably too late to change but a flow by use case then steps would have been easier to read. ### Section 3.1.1 `which are typically` or "which MUST be" ? ## NITS (non-blocking / cosmetic) ### Section 3.1.2 s/link local IPv6 address/link-local IPv6 address/ ### Section 3.2 Add a reference to RFC 7231 for "Retry-After". ### Section 3.2.3 Like in section 1.2, we are still in 2025, so how does the proposed solution compare to DHCPv6 ? ### Section 3.3.1 Should there be a bound to the number of redirects ? ### Section 4.2 Is it a little unclear whether global/routable IP addresses are included in `It MAY also be a local address that includes an IP address literal including both IPv4 [RFC1918] and IPv6 Unique Local Addresses [RFC4193]. `. ### Section 8.1 Isn't it a little scary/unsafe if a pledge upgrades its firmware (potentially in a non secure way) and its trust anchors ? _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
