Monday 3 November 2025
09:30-11:30 Local
Room: Place du Canada
Presenter: Ziang Zhou (remote)
draft-shenzhihong-dacp
Desire to bring the work to an existing WG in ART.
Ted Hardie: URI and Port requests belong at IETF, but the rest uses
tools which already exist. Not convinced that the work belongs at the
IETF. Could progress protocol work elsewhere.
Martin Thompson: Have read the draft, not sure that the protocol work is
needed. Unsure what novel thing this does separate to HTTP. By my
understanding, most of the functions work fine in HTTP. Suggestion is to
not take on this work.
Charles Eckel: Asked whether the Apache Arrow project are interested in
bringing things to the IETF? Would be important to have people from that
community here.
Mike Bishop: (without AD hat) - Understand this is build on Apache
Arrow, not an IETF thing, on GRPC, which is also not an IETF thing. If
this was standardised at the IETF, would need to standardise the
building blocks first. Feel like this needs to happen outside the IETF,
or a lot of predicate work brought in.
DISPATCH OUTCOME: This work is not suitable for the IETF right now.
Presenter: Jim Mozley (onsite)
draft-mozley-aidiscovery
draft-mozleywilliams-dnsop-bandaid
Jonathan Rosenberg (JR): Wonder whether discovery should be on topic is
on agenda for a side meeting tomorrow already scheduled.
Phillip Hallam-Baker (PHB): Agree with everything except that BANDAID is
a registered trademark, so don't do it.
We've been doing AI at the IETF for a while. Only thing different is
nomenclature. Client/Server is used. All server means is "the party that
waits" and client is "the party that starts something".
Not seeing that you propose we do anything different other than tell
those who are pushing AI that we already have this covered.
Right now we have DANE/DANCE/DNS Service Discovery - three different
things that could in principle be one thing.
Chairs: Opinion on the Dispatch Question?
John Klensin: Want to point out one aspect with pushing it to DNS. You
get all DNS's non-technical issues with identification and who owns
name, responsibility.
There are privacy concerns which make things more complex. Unsure that
this application wants to inherit those concerns.
Roman Danyliw: (GEN AD) - When sending things to side meetings, remember
that they have no standing in the IETF. This meeting is the official
process.
Cullen Jennings: would be useful to get scope of requirements for scope
of discovery. Inside an enterprise vs across the internet.
Jonathan Rosenberg: propose a BOF from the side meeting. Suggest BOF.
DISPATCH OUTCOME: BOF
Presenter: Simon Josefsson
draft-josefsson-rfc4648bis
SKIPPED due to lack of slides
Presenter: Gianpaolo Scalone (onsite)
draft-scalone-cfr-source-privacy
Tommy Pauly: Agree ECH is not sufficient for privacy story: servers can
see IP. IAB has a statement on privacy partitions. Question "how is this
different from existing work?" Draft seems thin on details. Seems a
network hosted MASQUE proxy would do this, and there's ongoing work on
discoverying proxies. Reaction would be "engage with MASQUE or INTAREA"
Martin Thompson (MT): a bunch of people will talk about oblivious HTTP
after me. Think you're describing a NAT. Interesting that the IETF for a
long time rejected that notion. Already deployed in a lot of places.
Issue is, a lot of networks don't want to deploy NATs. Interested if
there are operators interested in running these, because you could do
this without the IETF. A lot of operators already do CGNAT.
Dennis Jackson: really matters what tech this will use. Need to settle
that first.
Andrew Campling: thing that the surveilence thread of CDNs is
interesting. Dispatch to a dedicated mailing list to scope itself
better, and a BOF later?
DISPATCH OUTCOME: Create a dedicated mailing list.
Presenter: Tim Geoghegan (onsite)
draft-google-cfrg-libzk
Eliot Lear (EL): Want to add urgency - I live in Switzerland, we had a
vote for electronic IDs last month. Passed 50.4%, so controversy but
moving forward. Governments aren't waiting, so would like to see it move
forward.
Tommy Pauly: (IAB chair hat) wanted to point out for scheduling that we
had a workshop (on age-based restrictions on content access) and are
planning on producing a workshop report (ideally by end of year). Also
the IAB open meeting on Thursday will cover this.
Mark Nottingham (MNOT): (co-chair of the workshop) Will produce a
report. It will take a little while because so much happened. It's a
meaty topic. Complex topic, a lot of moving parts and a lot of actors.
More than just defining some tech.
At the same time, creating a mailing list - this is a very emotive
topic. A list could be open slather for very unproductive discussion. A
little wary of saying "discuss age verification on this list".
Rohan Mahy: Two questions:
Andrew Campling: is this in scope for SPICE?
Deirdre Connolly (DC): this is another case where this is already
specced out, in the industry - needs a home to. Independent editor and
IRTF aren't right place. A working group for crypto engineering might be
the right place. If we had a crypto enginnering working group, that
would be the right home.
Alissa Cooper: could imagine a future where there's an IETF home; with
relationship with how CFRG works.
A working group feels like a natural fit, where we document things as
informational.
[FIRE ALARM WENT OFF]
Presenter: have a side meeting tomorrow too, at 4:30pm
Martin Thomson: question of whether compiler or circuit is in scope.
Circuits need to be standardised. Age Verification seems to be what
people are focused on, but don't think this is the reason you want to
use to motivate the work.
We have alternative zero-knowledge which is already progressing through
CFRG which are more efficient. Would like to see more questions
answered. Do we have use cases that are NOT the age verification thing?
As co-chair of the workshop, can confirm all the things MNOT said.
[INTERRUPT: fire handle was pulled accidentally.]
Richard Barnes: Martin's comments convinced me; we should focus towards
a working group. Don't need to wait.
Roberta Robert: Government is doing things. Need a way to stipulate the
best second case, best third case with what we already have. Propose
BOF.
Eric Rescorla: Think it's interesting work, much more complicated than
Signal. Mechanism is appropriate for CFRG. Need to find a way.
DISPATCH OUTCOME: Chairs will talk with ADs to determine proper action.
No immediate decision made.
Presenter: Stephen Farrell (onsite)
draft-farrell-tls-pqg
[FINALLY THE ALARMS STOPPED]
Mike Ounsworth: Mostly agree with Stephen. Don't need to rush to PQsig
everywhere. Will waste a lot of of energy. Should discuss where there's
urgency on signatures. Please give u a place to discuss.
Phillip Hallam-Baker: Each WG chooses a thing they like, then 10 years
later it's obsolete (e.g. SAML). We need a discussion. Whether OPS or
SEC, maybe somewhere else without vested interests arguing. Propose WG.
Eric Rescorla: Suggest send to /dev/null, it's a rathole that will get
us nowhere.
Rich Salz: Think we'll never get consensus. Please start a mailing list
to which I can deliberately not subscribe.
Flo D: Applaud this. If going somewhere, should go to PQUIP, mirrors
deployment guidance there. But agree with Rich and rkr that we'll never
agree. If anywhere, PQUIP.
Sean Turner: agree with /dev/null. Should let it go and see what
happens. Sean and Stephen don't agree.
Richard Barnes: Agree, do nothing.
Thom Wiggers: Disagree with the point that we shouldn't be talking about
signatures. Postponing discussion will cause a world of hurt down the
line. Need to be having discussions today.
Paul Wouters: (speaking only as self, not for both ADs). Think this is a
bad idea, we won't be able to agree. Speaking for last bullet point,
"over my dead body" for AD sponsored.
Britta Hale: For many use cases, authenticity for short time -
confidentiality for long time. Sometimes public data, but need
authenticity to be validated for a long time. Maybe a need for
discussions, but a draft is impossible. Agree with ekr.
Stephen (presenter): Trying NOT to address use cases.
Eliot Lear: (speaking as ISE) I won't entertain anything that looks like
a BCP. Saw a good writeup from ekr on his blog. Would be OK with a
"state of affairs" document.
Chair: Maybe a dedicated list for this discussion. Don't see
convergence.
Stephen: not sure that's a useful outcome. We have lists. Maybe having
AD direct discussion to a particular list.
Deb Cooley: (SEC AD) Push it to saag mailing list.
DISPATCH OUTCOME: Discuss on saag mailing list.
Presenter: Sarah de Haas (remote)
draft-laurie-tmif
Muhammad Usama Sardar: Don't see connection with SEAT working group. Not
sure what to standardize; is there a protocol here? Seems more
appropriate for RATS.
Dennis Jackson: RATS
Henk Berikholz: seems like RATS work. Suggest "present in RATS"
Kathleen Moriarty: I am a co-chair for RATS. Have a draft which would
take output from this too. Want to look at mix of local vs remote
attestation. Would be happy to help.
Eliot Lear: Q - meant for software system? vetted, both?
Muhammad: would like to see that it remains compatible with attested
TLS.
DISPATCH OUTCOME: to RATS
Presenter: Robert Moskowitz (onsite)
draft-moskowitz-tesla-update-gnss-sbas
Rich Salz: Not ready yet.
Stuart Card: This work came out of our drone (DRIP) working group. We're
friendly to it, but it's not in our charter. Very little IETF can do
when signal is jammed at physical layer, but you KNOW you're being
jammed.
Much more dangerous is spoofing, it can cause planes to fly into
mountains. Challenging for IETF to work with other groups; but this is
live and die.
Robert Moskowitz: There's a meeting next week for navigations systems
panel. Highly likely this document will be released next week.
Britta Hale: Urgent problem, but this TESLA variant: is this a proposal
to use what ICAO is doing?
Christopher Inacio: Do we have a process for other SDOs to request
updates to RFCs?
Deb Cooley: (SEC AD) - The previous draft was AD sponsored. Would be
willing to AD sponsor this work.
Ted Hardie: I'm not a security AD. Issue is change control. Concerned
that the change control for this would not allow the IETF to make
substantive changes. Before bringing it to the IETF, then they send us a
request for review (to DRIP or SAAG) - unless change control comes to
IETF.
Ted Hardie: Concerned about change control. If the answer the IETF came
to was "this does not achieve goal" then that would be a problem.
Éric Vyncke: There is no official liaison with ICAO, just liaison
statements (which are not the same thing).
DISPATCH OUTCOME: Create a dedicated mailing list, clarify change
control and IETF involvement.
None
DACP -> /dev/null
AI Discovery -> BOF
Base64 -> SKIPPED
Customer Relay -> New Mailing List
Longfellow -> Chairs and ADs to discuss
PQ Guidance -> SAAG mailing list
Transparency -> RATS
TESLA Update -> More discussion on mailing list, maybe AD sponsored