Linda,
The way that Roman has described this is correct.
There are however subtleties to the distinctions between Node ID, Administrative Endpoint ID, and general Endpoint ID that are not explained in this document that deserve at least an expansion in the Terminology section and a paragraph in the ACME Identifier section (to delineate between what you can do with this mechanism and what you cannot). I intend on making an update soon with this change and one other behavioral change that came up in earlier review.
Thank you for the feedback,
Brian S.
On Thu, Jan 6, 2022 at 11:57 AM Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> wrote:
Roman,
Thank you very much for the explanation.
It now all makes sense.
Thank you.
Linda
-----Original Message-----
From: Roman Danyliw <rdd@xxxxxxxx>
Sent: Thursday, January 6, 2022 9:00 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: acme@xxxxxxxx; draft-ietf-acme-dtnnodeid.all@xxxxxxxx; last-call@xxxxxxxx; Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Subject: RE: Opsdir last call review of draft-ietf-acme-dtnnodeid-07
Hi Linda!
Thanks for the review.
> -----Original Message-----
> From: Linda Dunbar via Datatracker <noreply@xxxxxxxx>
> Sent: Monday, November 29, 2021 4:31 PM
> To: ops-dir@xxxxxxxx
> Cc: acme@xxxxxxxx; draft-ietf-acme-dtnnodeid.all@xxxxxxxx;
> last-call@xxxxxxxx; ldunbar@xxxxxxxxxxxxx
> Subject: Opsdir last call review of draft-ietf-acme-dtnnodeid-07
>
> Reviewer: Linda Dunbar
> Review result: Not Ready
>
> I have reviewed this document as part of the Ops area directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like
> any other last call comments.
>
> This document specifies an extension to ACME protocol which allows an
> ACME server to validate the Delay-Tolerant Networking Node ID for an ACME client.
>
> Issues:
I will let the authors correct me when I get it wrong. As background, this is work that was coordinated with the DTN WG but done in the ACME WG since it has the most expertise with ACME extensions.
> The document didn't describe how the Node ID described in this
> document is related to the Delay Tolerant Network. I see the mechanism
> can be equally used in any network. What are the specifics related to
> the "Delay Tolerant Network"?
The relationship to DTN is that this document describes how to get a certificate via ACME for a DTN Node ID, the unique addressing scheme defined by the DTN architecture. Specifically, this document allows the validation of a claim for a Node ID represented in the certificate as a Subject Alternative Name (SAN) of type otherName with a name form of BundleEID (defined by the DTN WG in Section 4.4.2.1 of draft-ietf-dtn-tcpclv4-28). BundleEID is a new PKIX OID defined specifically for DTN addresses. This new OID was not the original design but something that surfaced during AD review of this document and resulted in coordinated changes to both this document and draft-ietf-dtn-tcpclv4.
While DTN is designed to be a flexible overlay onto many different types of networks assuming a convergence layer is defined, it is my understanding that the addressing scheme for the bundles would still be a DTN Node ID. I'm not aware of any other protocol that is using the DTN addressing scheme so this ACME extensions strikes me as quite purpose built for DTN.
Regards,
Roman
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
