ALLDISPATCH Hybrid Meeting @IETF-121

• Monday 4 Nov 2024
• Room: The Auditorium (level 3)
• 15:30-17:00 Local
  Log into the IETF datatracker to access:
• MeetEcho
• Notes
• Zulip

---

Status and Agenda Bash - Chairs and ADs (10 min)

Standards Processes

IETF Working Group Guidelines and Procedures
https://datatracker.ietf.org/doc/draft-rsalz-2418bis/
The Internet Standards Process
https://datatracker.ietf.org/doc/draft-rsalz-2026bis/
Presenter: Rich Salz (onsite)

First - 2026bis - proposal from Rich is AD-Sponsor.
Second - 2418bis - lots is outdated.

Murray:

• there's been loud resistance to AD-Sponsored from some people; would
  expect with a charter.

Mirja:

• want to just update, or changes as well? If more than getting up to
  date, need a working group.

Sean Turner:

• thank you; will volunteer to review.

Roman (Gen-AD):

• Was waiting for community to provide feedback.
• As an individual; re-opening even for an editorial change, need
  community disucssion. Not excited to AD sponsor.
• Propose: focused working group.
• Rich: will community participate BEFORE WGLC?
• Roman: would hope there would be participation to help you and
  editorial team through process.
• Good time if there's anyone else who would like to participate more?
  Now is good time.

David Schinazi:

• Had draft last time about milestones. If we do a working group for
  things like this that are tightly focused; could do that in the
  working group as well. Get charter slightly bigger to do things like
  that? Though hard to find boundary.
• Too big for AD sponsored.

Jim (wg chair): think we've got the answer.

The IETF Chair May Delegate

https://datatracker.ietf.org/doc/draft-eggert-ietf-chair-may-delegate/
Presenter: Lars Eggert (onsite)

• When I was Chair, discovered lots to do - want to make sure future
  Chairs have more ability to delegate.
• most of the work is hard to delegate!
• no way to handle temporary incapacity.

Ted Hardie:

• Propose WG - sorry Lars. Publish as AD sponsored doesn't work, has
  bigger implications. E.g. IAB - currently has liaison plus chair, so
  maybe don't need two.
• Think these are interesting and important questions, but need a WG
  to sort out. Interaction with other WG, make other a little less
  clean, but put this in charter for that WG.
• Lars: thank you, dammit, I agree. Close enough we can probably make
  a charter that brings this in charter as well, unless we find
  something else today.

Mike StJohns:

• recollect this being discussed in nomcom review 10-12 years ago.
• some interactions with NOMCOM with what you're talking about. Do we
  also want to sweep this in? Dammit.
• IAB also has process for temporary replacement -> just elect one.
  Don't think that's a problem.
• Agree WG dispatch.

Mirja:

• Need to separate the two things. Fallback - don't need interim
  chair, just be not stalled. That's a good change that can be small.
• Delegation question, needs more discussion. There's benefit to
  having these roles in a single person.
• Think it's important that IETF chair is an IAB member, even though
  there's a liaison so it's not a problem.
• Lars: agree sucession/standin part can be solved separately. Agree
  same person; but scaling problem. In a good week you can do all the
  roles, but not all weeks are good.
• Could have made self appealable by deciding not to show up and vote;
• Dispatch q: could do fallback. Not sure we have a problem on first
  part.

David S:

• Delegation enthuisiast. Think it's a real problem, we should have a
  WG, sensing formation of SUPERPOISED or so.
• WG with explicitly listed changes decided at chartering.

Francesca:

• Robert sparks (on jabber): prefer we don't lump together. This has a
  good chance of finishing first.

Roman:

• Would not AD sponsor, conflict of interest
• Lars: willing to start WG?
• Roman: yes.
• Lars: could always recuse yourself from balloting.

High Assurance DIDs with DNS

https://datatracker.ietf.org/doc/draft-carter-high-assurance-dids-with-dns/

Presenter(s): Jesse Carter and Tim Bouma (remote; not registered)
[sec]

• There's already some related drafts in Independent and DNSOP.

Martin Thomson:

• suggest that the work go to W3C not here.
• Questions related to DIDs that suggest W3C is the right place. Use
  of IETF stuff is just "using this" - while interaction with
  resolution methods is better there.

Richard Barnes:

• +1 to Martin

ekr:

• Don't think IETF should take this on; we get in trouble with other
  SDOs by doing stuff in their zone.

Jim:

• anyone want to propose IETF? Nobody.

Jesse: asking to reserve IANA namespace.

Martin: believe existing procedures allow for work from outside to
register things.

ALFA 2.0 - the Abbreviated Language for Authorization

https://datatracker.ietf.org/doc/draft-brossard-alfa-authz/
Presenter: David Brossard (not registered)
[sec]

Presented by Theo Dimitrakos

• Am relatively new to IETF.
• Suggest new WG or part of OAuth?

PHB:

• like the work - why IETF rather than OASIS? Would prefer to do in
  OASIS.
• Theo: personal view - IETF will stear into efficient and
  lightweight. OASIS may lead it into complexity that would not be fit
  for purposes in my opinion.

Jim: chat suggestions for BoF.

Theo: most important thing is progress with community engaged.

• different implementations suggest some maturity, but community
  engagement.

Aaron Parecki (OAuth):

• already have a completely packed agenda for 3 sessions this week,
  don't think we can handle additional drafts that are this large in
  scope.

Jim: BoF might also answer here or oasis.

Paul Wouters (security AD):

• Think it's worth doing a BOF in security area, see where it goes
  from there. If there is a BOF, in security area.

Theo: would also like to highlight that because of obligation
statements, other people may be interested.

Jim: we cross over areas a lot here.

Identifying and Authenticating Home Servers: Requirements and Solution Analysis

https://datatracker.ietf.org/doc/html/draft-rbw-home-servers-00
Presenter: Mohamed Boucadair (onsite)
[sec]

Dan Wing presenting.

• work came out of ADD - but is beyond scope for that.
• propose a BOF

Cullen Jennings:

• Think it's an important problem we should have solved long ago.
  Support a BOF. Hard to convince people to charter work until we
  dicuss whether it's solvable.

Ben Schwartz:

• support non-WG-forming BOF. At a fuzzy stage of working out what the
  problem is.
• Is about configuring client platform, which is quite different from
  configuring rounter.

Eric Resorla:

• all in agreement on technical solution, which is nobody knows what
  to do.
• There's been lots of thinking on this, but zero uptake on existing
  document.
• Don't think a BOF should be done.
• Would like to see a document which describes it.
• Maybe send to IRTF.

Glenn Deen (ADD co-chair):

• has been boucing around in ADD for a while.
• Think BOF is the right approach - bring together minds and ideas.
• Problem keeps coming up in things we want to do.
• Support BOF

PHB:

• think a BOF would be a good idea. Eventually going into IRTF would
  be a good idea.
• Glad everyone is saying it's impossible to solve because I have
  running code.
• Issue isn't "having a solution"; it's "meets constraints others want
  to put around it"

Paul Wouters (as individual):

• Unlike old homenet working group; will also get pushback against
  people who have monthly billing for access to devices on your
  network.
• in camp with EKR - need to do research first.

Eric Vyncke (responsible AD for ADD):

• Support WG forming BOF - think requirements are well know, solution
  isn't.

Jim: seems consensus is BOF - split between WG forming and non.

• can't dispatch to IRTF but can talk to them about it.

Update IDMEFv1

https://datatracker.ietf.org/doc/draft-lehmann-idmefv2/
https://datatracker.ietf.org/doc/draft-lehmann-idmefv2-https-transport/

Presenter: Gilles Lehmann (remote)
[sec]

Arnaud Taddie:

• surprised no mention of OCSF (open security schema framework) - a
  lot of duplication of that work.
• Gilles: learning about this now; will have to check.

Paul Wouters (Sec AD):

• Wanted to be last!
• When you approached us first, looked at who's using V1 version,
  can't find anyone using it.
• Am a little worried that without v1 being used, don't want to spend
  resources at IETF.
• Propose AD sponsored; but before committing would want to see if
  people will use it.
• Previous comment, alternatives available already.
• So much competition in the field.

ekr:

• didn't realise would open AD sponsored.
• Don't think we should take something this big and sponsor as AD
  sponsored. Even for informational requires consensus.
• Expect me to object to it when it comes up for consensus.
• EKR: even though v1 is existing IETF work, doesn't change my
  opinion.

Jim: think that covers it.

Two secevent drafts

Multi-Push-Based Security Event Token (SET) Delivery Using HTTP
https://datatracker.ietf.org/doc/draft-deshpande-secevent-http-multi-push/

Push And Pull Based Security Event Token (SET) Delivery
https://datatracker.ietf.org/doc/draft-tulshibagwale-saag-pushpull-delivery/

Presenters: Aaron Parecki (onsite)
[sec]

MNot:

• feel compelled to remind people we have an HTTP directorate.
• Aaron: relevant to dispatch question?
• Mark: see issues here, need to be worked through, please engage
  early.
• See issues with proposal.

Josh Cohen:

• have skimmed the draft
• How much of this is about sending events back and forth vs the
  security payload? Is this another case of PUBSUB/events systems? Or
  is this really a security thing that's different?
• Aaron: security events are a particular type of payload. These
  drafts describe the delivery method for those events. NOT a general
  pubsub mechanism, specifically for security event tokens.
• Josh: OK but is the information encapsulated separable from the
  event delivery? Dispatch question depends on this.

Roman (security AD) who closed down secevents:

• I closed secevent because we had real difficulty closing final
  deliverable.
• Would like to hear about how dynamics have changed.

Deb Cooley:

• sent this to a bunch of working groups, proposed to HTTP groups who
  said no. Atul did that; chairs didn't think it fit.
• Have been a number of reviews on SAAG list. Possible that proponents
  have changed in last year, unsure if we can keep the momentum going.
• Jim: what's your opinion?
• Deb: if two drafts, re-open secevents. If one, maybe AD.

Jim: conclusion - reopen secevents, try to understand dynamics, involve
HTTP directorate.

A File Format to Aid in Consumer Privacy Enforcement, Research, and Tools

https://datatracker.ietf.org/doc/draft-colwell-privacy-txt/

Presenter: Louise Van der Peet (onsite)
[wit?]

• proposed - collaborators

MNot:

• was in W3C P3P working group. How is this different?
• Louise: P3P is about only privacy policies; privacy.txt is simpler
  and hopefully easier for websites to comply to. Related to working
  .txt standards.
• MNot - don't think ease of understanding was the problem.
• Dispatch: want to see more discussion before dispatching.

Ted Hardie:

• With no action, or to full BOF. Same reasons as Mark.
• The reason people use robots.txt is because there is a cooperative
  relationship - people want robots to access data in particular ways.
  Search engines want to access data without being blocked.
• Not convinced by what's in the document is that same cooperative
  thing is not there.
• People want legal stuff in place, don't necessarily want them easily
  parsed.
• Would require a different framing - not format; convince people
  there's enough commonality across jurisdictions.
• Extensibility problem is enormous. If you don't understand
  robots.txt, OK to not parse file. Not clear you can do that with
  legal things.
• Jim: plz focus on

PHB:

• Do you remember Michael Baum and eterms - used in international
  trade. Standard terms.
• Think it's possibly practical.
• P3P - things fail, but someonetimes propsed too early.
• Need to have discussions, maybe a BOF. Think about the pain point.
  For users, going to website and seeing "accept cookies". If you
  could remove that, would make it useful.

ekr:

• Banners exist to force people to click them. If easy to reject, they
  wouldn't work for the purpose.
• Dispatch: don't think a BOF will get us very far. Offer a mailing
  list to discuss this. Most critical thing, get sites and user agents
  to give level of interest.
• Might also be W3C topic.
• premature for BOF.

Nick Doty (co-chair privacy working group at W3C):

• appreciate you bringing work and not giving up.
• Useful to hear scepticism about this, but keen to hear ideas.
• Might be longer mailing list discussion before BOF.

Stephen Farrell:

• WG or BOF not right answer.
• Mailing list either here or W3C.
• There's experience here (at least in what to avoid)
• Maybe a thing we keep trying and keeps failing until it succeeds.

---

DKIM2 Why DKIM needs replacing, and what a replacement would look like

https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation/
Presenter: Pete Resnick (onsite)
[art]

No time to present.
Bron Gondwana gave a brief introduction.

Summary of dispatch outcome:

1. Standards Processes (Rich Salz)
   -> Charter a focused working group
2. The IETF Chair May Delegate (Lars Eggert)
   -> Charter a working group (possibly combined with #1 above)
3. High Assurance DIDs with DNS (Jesse Carter)
   -> Not appropriate for IETF, fits better with W3C
4. ALFA 2.0 - The Abbreviated Language for Authorization (Theo
   Dimitrakos)
   -> Hold a BOF
5. Identifying and Authenticating Home Servers: Requirements and
   Solution Analysis (Dan Wing)
   -> Hold a BOF; consider IRTF
6. Update IDMEFv1 (Gilles Lehmann)
   -> AD sponsor, but need to show significant demand first
7. Secevent drafts (Aaron Parecki)
   -> Reopen secevent WG and try to understand issues the WG had just
   before its closure. (This was announced erroneously at the end of
   the session)
8. A File Format to Aid in Consumer Privacy Enforcement, Research, and
   Tools (Louise Van der Peet)
   -> Create a non-WG mailing list for further discussion
9. DKIM2 (Bron Gondwana)
   -> No time for discussion; will be discussed in mailmaint WG this
   week