[Dance] Re: merging architecture document into client-auth

[Kaveh Ranjbar <[e-mail]>]

I'm in favour of this. The confusion you're pointing at is real, and
putting the context next to the mechanism, so a reader doesn't have to
reconstruct the intent, is the right fix.

Two things from the DNS-operator side, offered as help rather than
objection.

The part that actually answers the reviews is small: the actor definitions,
the when-and-how the server ends up doing a lookup, and the
device-versus-user distinction. That is the framing the ADs were missing,
and it belongs right next to the extension. The wider catalogue of examples
is good context, but it reads as breadth rather than as the thing that
makes the privacy posture legible, so I'd weight the introduction and the
forward references toward the former. I'm happy to take a pass at that
introduction text you flagged, so the folded-in section reads as one
argument.

The other is the privacy point, since it travels into the client-auth last
call with the merged text. I think it's answerable rather than fatal, but
only if the document says plainly when this applies and when it does not:
machine, device and service identities in an operator-controlled zone are
one case; names that resolve to natural persons in public DNS are another,
and the enumeration and correlation exposure there is what needs a clear
applicability line and a pointer to name-scoping and minimisation. I've
written that kind of language before and would gladly draft a Privacy
Considerations section for the merged document along those lines.

If a concrete example helps anyone follow the flow, I can pull a live
DANE-EE name and we can dig the TLSA together.

Kaveh

On Thu, Jul 30, 2026 09:11 PM, Wes Hardaker <[e-mail]> wrote:

> Michael Richardson <[e-mail]> writes:
>
> Greetings all, please do weigh in on this if you have an opinion:
>
> > I did a PR merging the bulk of the architecture use cases into the
> > client-auth document, nearer the end of the document.
> > There are no doubt some wording changes and forward references needed in
> > client-auth's introduction text.
> >
> > Please see:
> >   https://github.com/ietf-wg-dance/draft-ietf-dance-client-auth/pull/13
> >
> > this would reduce work to a single document.
> >
> > My observation is that we got many review comments that were confused
> about
> > how/when this would be used, how it violated privacy assumptions of
> > end-users, etc.   Because the entire context of the work was not
> understood.
> >
> > --
> > Michael Richardson <[e-mail]>, Sandelman Software Works
>
>
> >  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
> *I*LIKE*BOATS*
>
> (and trains)
>
> --
> Wes Hardaker
> Google
>
> --
> Dance mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>