Re: [Acme] I-D Action: draft-ietf-acme-dtnnodeid-12.txt

[Deb Cooley <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/acme
> >>
> >
> >
> > _______________________________________________
> > Acme mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
>