Also a late review (sigh). All of mine are typos, so they should be easy to fix.
Section 1.4, Endpoint ID def: typo: I think you need a comma here: 'An endpoint can be a singleton or not [,] so an Endpoint ID can also...' Section 2, para 1, sentence 2: typo: 'an Bundle Endpoint' sb 'a Bundle Endpoint'. Section 2, para 4, last sentence: typo: 'via scheme-specific means [is] authorized'? Deb Cooley no hats.... On Mon, Jan 29, 2024 at 7:18 PM Stephen Farrell <[email protected]> wrote: > > Hiya, > > On 12/01/2024 12:00, Deb Cooley wrote: > > This is the beginning of a two week WGLC for this draft, which will end > on > > 26 Jan. > > > > Please review and comment. > > Sorry for the slightly late review. > > I previously reviewed -09 of this and think the changes since then, > (perhaps partly in response to that review), nicely capture the nature > of the experiment being done here, are well-stated in the draft and > are sufficient for publication of an experimental RFC. (As a nit, some > of those changes have enhanced visibility in the text version but not > in the HTML - I like the way the text version calls our those bits of > text myself fwiw, e.g. in the last para before 1.1.) > > I mostly reviewed the diff from -09 to -12 and haven't implemented > either a client or server for this but the nitty details look fairly > sane for an experimental RFC. > > If there were one thing I'd suggest adding, it'd be to describe a > DTN scenario where the multi-perspective thing was ineffective, from > the vantage point(s) of a CA. I think that might help people doing > experiments figure out some things to look out for, or might help > some CA decide to play-ball in an experiment if they don't have to > discover the problem themselves. (A known problem there is a DTN where > all traffic between the CA and DTN nodes has to go via one (set of) > agents all under the control of a potential attacker.) I don't think > such text is required for publication, but spelling it out in 3.5 or > the security considerations would be nicer I think. > > I see Rob has commented that he doesn't see how this draft can garner > IETF consensus. I don't get that objection(*) as ISTM the IETF can of > course reach consensus to enable experiments related to DTN security and > key management, which are both fairly tricky topics where improvements > will (I think) benefit from experimentation of this kind. (Or to put > it negatively, without experiments like this, we'll likely not see > improvements in DTN security and key management.) > > So, yes, I think this is ready to move along to IETF LC and to become > an experimental RFC. > > Cheers, > S. > > (*) WRT IETF consensus, we're not there yet since IETF LC hasn't > started, so it's puzzling to object that we can't get that when > WGLC is only now under way. > > > > > > > Deb C > > ACME WG Chair > > > > On Thu, Jan 11, 2024 at 4:26 PM <[email protected]> wrote: > > > >> Internet-Draft draft-ietf-acme-dtnnodeid-12.txt is now available. It is > a > >> work > >> item of the Automated Certificate Management Environment (ACME) WG of > the > >> IETF. > >> > >> Title: Automated Certificate Management Environment (ACME) > >> Delay-Tolerant Networking (DTN) Node ID Validation Extension > >> Author: Brian Sipos > >> Name: draft-ietf-acme-dtnnodeid-12.txt > >> Pages: 31 > >> Dates: 2024-01-11 > >> > >> Abstract: > >> > >> This document specifies an extension to the Automated Certificate > >> Management Environment (ACME) protocol which allows an ACME server > to > >> validate the Delay-Tolerant Networking (DTN) Node ID for an ACME > >> client. A DTN Node ID is an identifier used in the Bundle Protocol > >> (BP) to name a "singleton endpoint", one which is registered on a > >> single BP node. The DTN Node ID is encoded as a certificate Subject > >> Alternative Name (SAN) of type otherName with a name form of > >> BundleEID and as an ACME Identifier type "bundleEID". > >> > >> The IETF datatracker status page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > >> > >> There is also an HTML version available at: > >> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-12.html > >> > >> A diff from the previous version is available at: > >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-dtnnodeid-12 > >> > >> Internet-Drafts are also available by rsync at: > >> rsync.ietf.org::internet-drafts > >> > >> > >> _______________________________________________ > >> Acme mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/acme > >> > > > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
