Hi Med, Thanks for your detailed review and comments.
We believe that we have addressed your comments and suggestions in the new version of the draft: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/ Please, take a look and let us know if you have any further comments. Regards, Rifaat On Wed, Jul 30, 2025 at 9:40 AM Mohamed Boucadair via Datatracker < [email protected]> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-anima-brski-cloud-16: 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: > ---------------------------------------------------------------------- > > Hi Owen, Rifaat, and Michael, > > Thank you for the effort put into this specification. > > Also, thanks to Tim Wicinski for the DNSDIR review and to the authors for > engaging and proposing changes. > > # Overall > > The document is well-written with a clear applicability scope. The > description > is repetitive in some places (e.g., all the details about “SIP phones” is > repeated several times, redundant text in 1.2.1, etc.); some less words > would > be appropriate to help readers better focus on the core specification. > > Please find below more detailed comments. Major comments are marked with > (*). > > # Operationalizing the solution (*) > > The approach requires some coordination and provisioning that involve > several > entities. The document includes some useful discussion but those are really > scattered in the document. I suggest to group these matters under a new > “Operational Considerations” section. That section can include, e.g., > required > out of band configuration, discovery consideration, scalability discussion, > service stability requirements and migration considerations, current > Sections 5 > and 7 as subsections. > > # Inappropriate use of normative language (*) > > Several uses of the normative language in the document are not justified. > Also, > many of those are redundant with other statements in the document. For > example: > > (1) Introduction > This work is in support of [BRSKI], Section 2.7, which describes how > a Pledge MAY contact a well-known URI of a Cloud Registrar if a local > ^^ > Registrar cannot be discovered or if the Pledge's target use cases do > not include a local Registrar. > > … > This document updates [BRSKI] by clarifying operations that are left > out of scope in [BRSKI]. Two modes of operation are specified in > this document. The Cloud Registrar MAY redirect the Pledge to the^ > ^^^^ > owner's Registrar, or the Cloud Registrar MAY issue a voucher to the > ^^^ > Pledge that includes the domain of the owner's Enrollment over Secure > Transport [RFC7030] (EST) server. > > (2) Section 2 > It is also possible that the Cloud Registrar MAY redirect the Pledge > ^^^^ > to another Cloud Registrar operated by a VAR, with that VAR's Cloud > Registrar then redirecting the Pledge to the Owner Registrar. This > scenario is discussed further in Sections Section 7.2 and 8.3. > > (3) Section 3.1.1 > BRSKI defines how a Pledge MAY contact a well-known URI of a Cloud > > I suggest s/MAY/may at least in these excerpts and similar ones. > > # Internal inconsistency (*) > > CURRENT: > … and MUST > NOT send the CSR Attributes request to the Cloud Registrar, because > the Cloud Registrar does not have authority to issue a certificate > for the customer domain. (The Cloud Registrar is not a full EST > server) If a Pledge sends a CSR Attributes request to the Cloud > Registrar, then the Cloud Registrar MUST reply with 404 response > code. > > There is a conflict between the first MUST NOT and “if … sends”. > > # Compliancy with BCP 56 (*) > > There are several statements in the document that are not consistent with > this > reco: > > Applications using HTTP MUST NOT re-specify the semantics of HTTP > status codes, even if it is only by copying their definition. It is > NOT RECOMMENDED they require specific reason phrases to be used; the > reason phrase has no function in HTTP, is not guaranteed to be > preserved by implementations, and is not carried at all in the HTTP/2 > [HTTP/2] message format. > > Examples of such statements are > > Registrar, then the Cloud Registrar MUST reply with 404 response > code. > > Or > > 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 > > Or > > If the request is correct and the Registrar is able to handle it, but > unable to determine ownership at that time, then it MUST return a 401 > > and similar statements in the document. Please check and revise > accordingly. > Typically, s/MUST return/returns > > # Deviation vs. RFC8366bis (*) > > The document says: > > (Section 2.3) > [RFC8366bis] contains the two needed voucher extensions: "est-domain" > and "additional-configuration" which are needed when a client is > redirected to a local EST server. > > (Section 3.2.3) > The voucher MAY include the new "additional-configuration" field. > .. > The exact Pledge and Registrar behavior for handling and specifying > the "additional-configuration" field is outside the scope of this > document. > > ## However, there is no “additional-configuration” in > draft-ietf-anima-rfc8366bis. Do we meant “additional-configuration-url”? > If so, > please update accordingly > > ## BTW, s/extensions/parameters as “extensions” have a special meaning in > YANG. > > # Need for a concrete recommendation (*) > > CURRENT: > In order to avoid permanent bootstrap cycles, the Pledge MUST NOT > revisit a prior location. > > How this is actually implemented? How the behavior is controlled? Should > previous attempts be cached, time-outed? If so, what is the depth of cached > failures? > > # Incomplete behavior (*) > > Section 3.1.1 has the following > > CURRENT: > The Pledge SHOULD be provided with the entire URI of the Cloud > Registrar, including the protocol and path components, which are > typically "https://"; and "/.well-known/brski", respectively. > > But, what is supposed to do if incomplete URI is provided? > > # Please find below some additional minor comments > > ## Expand BRSKI in the title. > > ## Abstract > > ### Help the device > > CURRENT: > Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how > to onboard a device securely into an operator-maintained > infrastructure. It assumes that there is local network > infrastructure for the device to discover and help the device. > > I don’t parse what is meant by “help the device”. > > ## New device > > CURRENT: > This document defines how to contact a well-known Cloud Registrar, > and two ways in which the new device may be redirected towards the > operator-maintained infrastructure. > > The concept of “new” is not clear at this stage. Do we consider a device > new > when it contacts the registrar for the first time or do we also consider > cases > where a device first connect to a given network? > > ## Introduction > > ### Nits > > OLD: > Bootstrapping Remote Secure Key Infrastructures [BRSKI] BRSKI > ^^^^^^ > specifies automated and secure provisioning of nodes (which are > ^^^^^^^^^^ > called Pledges) with cryptographic keying material (trust anchors and > > NEW: > Bootstrapping Remote Secure Key Infrastructures [BRSKI] (BRSKI) > specifies automated and secure provisioning of nodes > (called Pledges) with cryptographic keying material (trust anchors and > > ### Phone, a bit outdates and does not reflect actual uses > > I suggest to use User Agent (UA), rather than “phone” in this part (and > similar > ones) > > OLD: > This kind of non-network onboarding is sometimes called "Application > Onboarding", as the purpose is typically to deploy a credential that > will be used by the device in its intended use. For instance, a SIP > [RFC3261] phone might have a client certificate to be used with a SIP > proxy. > > NEW: > This kind of non-network onboarding is sometimes called "Application > Onboarding", as the purpose is typically to deploy a credential that > will be used by the device in its intended use. For instance, a SIP > [RFC3261] user agent (UA) might have a client certificate to be used > with a > SIP proxy. > > ## Terminology > > The document says: > > This document uses the terms Pledge, Registrar, MASA, and Voucher > from [BRSKI] and [RFC8366bis]. > > But provides a copy/past of some other entries (e.g., Manufacturer). Any > reason > that entry is copy/pasted here rather than listing it similar to other > BRSKI > terms? > > ## Applicability > > This text is lost in the “target Use Cases”. I suggest to move this to a > dedicated subsection or to the introduction. > > CURRENT: > A network with an operator that is able to > provision these options would also be able to use BRSKI without > changes. Such a network has no need for the mechanisms described in > this document! > > ## Typical, really? > > CURRENT: > A typical example is a VoIP phone manufacturer provides telephones to > a local system integration company (a VAR). > > This may be “typical” in the past, but I don’t think this is “typical” > nowadays. > > ## Missing LDevID reference > > CURRENT: > When the employee plugs in the device and turns it on, > the device will be provisioned with a LDevID and configuration that > connections the phone with the Enterprises' VoIP PBX. > > Consider adding a pointer to 802.1AR? > > ## “cloud” in Section 1.2.2 > > OLD: > The voucher > issued by the cloud includes domain information for the owner's EST > service that the Pledge should use for certificate enrollment. > > NEW: > The voucher > issued by the Cloud Registrar includes domain information for the > owner's EST > service that the Pledge should use for certificate enrollment. > > ## Architecture > > ### Cloud Registrars > > The text seems to assume that there is one single Cloud Registrar instance, > while this shouldn’t. I suggest to make this change (and also through the > doc): > > OLD: > In both use cases, the Pledge connects to the Cloud Registrar during > bootstrap. > > NEW: > In both use cases, the Pledge connects to a Cloud Registrar during > bootstrap. > > ### Additional information > > CURRENT: > When > returning a voucher, additional bootstrapping information is embedded > in the voucher. > > Can we cite examples of additional information? > > Absent such example, not sure that sentence adds value. > > ### IP address and reachability > > CURRENT: > prior to connecting to the Cloud Registrar. The Pledge must have an > IP address so that it is able to make DNS queries, and be able to > send requests to the Cloud Registrar. > > The first “must” does not guarantee that DNS queries can be successfully > placed. > > For example, a device can only have a link local address, but that does not > help communicating more than one hop further. > > ### Internal setup > > CURRENT: > For many telephony applications, this is typically going to be a > wired connection. For wireless use cases, existing Wi-Fi onboarding > mechanisms such as [WPS] can be used. > > Do we really need to have this? > > ## Section 3.3.1 > > s/will a follow/will follow > > ## Section 4.2 > > * s/In step 3, the the Cloud Registrar/In step 3, the Cloud Registrar > * s/ authenticate/authenticate > > ## Section 7.1: nit > > OLD: > When the Pledge attempts to connect to any Cloud Registrar, an > incorrect connection will be detected because the Pledge will be > unable to verify the TLS connection to its Cloud Registrar via DNS-ID > check Section 6.3 of [RFC9525]. > > NEW: > When the Pledge attempts to connect to any Cloud Registrar, an > incorrect connection will be detected because the Pledge will be > unable to verify the TLS connection to its Cloud Registrar via DNS-ID > check (Section 6.3 of [RFC9525]). > > Cheers, > Med > > > >
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
