On Sat, Jun 19, 2021 at 6:24 PM Paul Hoffman <[email protected]> wrote:
> On Jun 18, 2021, at 7:43 PM, Eric Rescorla <[email protected]> wrote: > > > > > > > >> On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman <[email protected]> > wrote: > >> Greetings again. Based on the WG discussion of the last few weeks, we > can see that the folks with the fully-authenticated use case do not yet > agree on a signaling mechanism. Given that, we have just published a new > version of draft-pp-dprive-common-features that lists "SVCB on the client > side" as one discovery mechanism, and a new version of > draft-ietf-dprive-unauth-to-authoritative that points to that mechanism. > When the folks with the fully-authenticated use case do agree on a > signaling mechanism, that can be added to the -common-features draft. > >> > >> We would like the WG chairs to have a formal call for > draft-pp-dprive-common-features to be a WG document soon so we know how to > deal with it before the draft cutoff before the next IETF meeting. If the > WG wants it as a WG document, great; if not, we would pull back all those > features into draft-ietf-dprive-unauth-to-authoritative and the WG would > have to decide what to do for the eventual fully-authenticated draft. > >> > > I think (unsurprisingly) I am not in favor of this. Let's figure out > what we are trying to do and roughly the approach we want to follow. Until > then, adopting drafts is premature. > > The WG can work on the already-adopted unauthenticated use case, and the > fully-authenticated use case can catch up when there are authors interested > in keeping the discussion on their protocol moving. > I don't see any need to personalize this discussion. In any case, to the extent to which the WG is going to work solely on the unauthenticated version, it can do so in the existing draft. Having a draft which purports to contain "common features" between the authenticated and unauthenticated use cases is not helpful when basic questions remain. -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
