Skip to main content

Minutes IETF118: dispatch: Mon 08:30

Meeting Minutes Dispatch (dispatch) WG
Date and time 2023-11-06 08:30
Title Minutes IETF118: dispatch: Mon 08:30
State Active
Other versions markdown
Last updated 2023-11-06


DISPATCH Hybrid Meeting @IETF-118

Monday 6 Nov 2023

Room: Congress Hall 2

09:30-11:30 Local

Log into the IETF datatracker to access:


9:30 Status and Agenda Bash - Chairs and ADs (10 min)

  • Jim presented the Notewell and Note ReallyWell

    • Asked people to join with the meetecho client and lite client
      (from the agenda page)
    • Joint with ArtArea (showed agenda)
    • Asked for agenda bash (none)
    • Asked for volunteers to take notes (Bron)
    • Described mailing lists
  • Please focus on the dispatch questions, where next

    • Ben Campbell comment: include "BOF" as target

9:40 R5N Distributed Hash Table (20 min)

Presenter: Martin Schanzenbach/Christian Grothoff (On site)

  • Started 9:37
  • Martin presenting
  • Has been presented to dinrg, ...
  • Presentation done 9:48
  • Questions:

    • Cullen: think it's a substantial piece of work, would be
      interesting to have it available, think we need a working group
      • Author of "reload".
    • Murray (AD) followup - does the community (users, developers,
      etc) exist at IETF already?

      • A: we at gnunet use it (there's another draft)
      • Have contacts at IPFS, they may be interested too.
    • Harald Alvestrand: most deployments in the world are behind
      single NAT, sounds like it would have failure modes due to
      random walk - is it guaranteed to converge? Agree with Cullen is
      WG sized.

      • A: not guaranteed to converge, but usually does.

Jim: conclusion is WG?

  • Murray: what was conclusion when you took to routing?

    • A: this was a while ago.
  • Murray: could take to a BOF, but first would want to see more
    evidence of a likely community.

Finished 9:53



Dispatch outcome: Suggested to having a working group, AD wants to see
more evidence of community before forming one.

10:00 JSON NTV (20 min)

Presenter: Philippe Thomy (remote)

  • Some faffing about slide presentation
  • Started 9:55
  • Done 10:09
  • Questions:

    • Eliot Lear: comment and question - is the ground already well
      trodden? Should we be looking at OpenAPIs and JSON-Schema
      relationships? What's relationship between this and YANG?

      • A: not sure if understand the question.
    • Rohan Mahy: wanted to ask if posted on CBOR mailing list?

      • A: don't understand question?
      • A: yes, have asked CBOR working group, but don't have any
    • Carsten Bormann: asked about a CBOR to JSON conversion.

      • Usages of both JSON and CBOR would want to use JSON layer.
      • Inventing another format on the JSON side would not make our
        work much better.
      • Dispatch: don't think IETF should take on this work.
    • Jim: any more comments? Think feedback is "get more from CBOR

    • Cullen: don't think the CBOR group will love this. We don't need
      feedback - heard from the chair.

      • Don't know what that means for dispatch, but don't send to
        CBOR group.
    • Austin Wright: Author of JSON schema validation

      • Have you approached HTTP or JSON-schema to see if
        functionality you're looking for is in those specs?
      • A: Philippe - don't understand question.
      • Have you thought about approaching HTTP media or JSON Schema
        to see if functionality can be there.
  • Done: 10:17



Dispatch outcome: More discussion

10:20 Forming a general State Synchronization Working Group (20 min)

Presenter: Michael Toomim (On site)

  • Started: 10:18
  • from chat:

  • Finished: 10:

  • Questions:

    • Ted Hardie

      • Have you talked to usable formal methods research group?
      • A: no
      • If you want to create functions that work with HTTP.
      • Think current scope is too large to tackle in eithe WG or
        RG. Some in different protocols with different
    • Eliot Lear

      • Ted covered most of ground
      • Do you have disparate applications you want to cover.
      • Do you have two applications ready to go? (willing to work
        with you, test with you, to make sure it generalises)
      • A: we have web applications (chats, wikis) - not as much
        down-stack. It's potential possible future scope. Focus now
        is simple things (email, chat), start here.
      • Do offline mode, collaborative editing, etc.
      • Dispatch: neutral, sounds interesting, if choice between WG
        or RG, closer to WG.
    • Mark Nottingham

      • am somewhat enthusiastic about this work in HTTP
        specifically. Can go forward if get enough review.
      • concerned about overarching working group - top down efforts
        tend to fail, have to make a lot of compromises to paper
        over differences in technologies and use cases.
      • doing protocol by protocol and copying best practices is
        better. E.g. SASL which has had trouble getting adoption.
    • Daniel Gillmor

      • as a dispatch outcome, this might be two working groups.
      • in LAMPS, we had end-to-end email guidance.
      • something like this would be super useful in an IMAP
        context. Not convinced that one group would have the
      • Would love to understand how to get this to different
    • David Schinazi

      • said one word that scared me "generalised"
      • The IETF does not know how to solve generalised problems,
        because it's objectively hard.
      • Applying this to HTTP or to IMAP will look completely
      • Don't think it will be successful as a central working
        group, but taking it to individual groups and seeing if they
        want to use it will be more useful.
    • Austin Wright

      • HTTP is a wonderful general application of a protocol which
        can be used for many user applications.
      • Some of the shortcomings are niche things like "how do we do
        subscriptions and talk about data", RDF, JSON Schema, ...
      • Technologies already exist, already working groups exist for
        most of these problems. Just want to identify some best
        practices and unify technology for synchronisation.
      • Suggest a research group, and identify specific
        recommendations for technologies, bring to groups.
    • Harald Alvestrand

      • RFC3254 - wrote this 20 years ago.
      • Find this convincing - we should have a working group to
        define what you are working about.
      • Compare with MLS working group which has many documents on
        state synchronisation.
      • Dispatch question - this general thing it not baked enough
        to be anything like a working group.
    • Carsten Bormann

      • IRTF cannot do standards, but they can prepare standards.
        This has been done before.
      • Dispatch - research group, agree on experimental protocol,
        take to a working group.
    • Phillip Hallam-Baker

      • Also in research group camp.
      • I built one of these as well - everything in the MESH is
        represented as an append-only list, every list is a
        mergeable tree, encrpytion etc built in.
      • Pretty aware of the optimisations I've made which make my
        approach non-general, and I know the costs of making it more
      • Once you decide everything is a list and you'll never delete
        anything, you don't want gigabytes of data in that list.
        Sceptical of a general solution.
      • Just getting people to look at it is hard enough, getting
        people to use it is harder too.
      • Research group, take it from there.
      • A: believe a lot can be generalised.

A: thank you.
Jim: rough consensus appears to be something along the lines of a
research group? Don't want to create a protocol which is general but
nobody uses.

  • Done 10:48



Dispatch outcome: Narrow down the scope, a research group is preferred
at least initially.

10:40 DKIM-FBL (20 min)

Presenter: John Levine (On site)

  • Started 10:49
  • Existing experimental draft for put in header instead - detail to
    work out.
  • Done 10:53
  • Questions:

    • DKG:

      • Something reasonable to do, don't know if it should be a DNS
        record; don't see why not do in the DNS working group.
      • A: it's a regular text record (like DKIM) - draft specifies
        the format to send.
      • A: would be nice if we had a general email group
    • Murray:

      • Is Yahoo planning to do this?
      • A: haven't talked to Richard recently.
      • At M3AAWG last month there was a lot of enthusiasm.
      • seems that path of least resistance is
    • Barry Leiba

      • Chair of DMARC working group and IETF liaison for M3AAWG!
      • Suggest working group, email abuse thing brings out all the
        email people.
      • But maybe AD sponsoring will reduce number of crazy email
      • A: also got an "Expires" header draft.
      • From M3AAWG side, get a lot of interest, but not people
        coming over to IETF.
      • Would be very important for this to engage the M3AAWG
      • Maybe should pass around M3AAWG more and get agreement
        before bringing to IETF.
    • Eliot Lear:

      • Wonder if we could use the "feedback form" work.
      • Should address in charter.
  • Finished: 11:00



Dispatch outcome: Coordinate more closely with M3AAWG than perhaps form
a WG.

Summary of the Dispatch outcomes:

  1. Suggested to having a working group, AD wants to see more evidence
    of community before forming one.
  2. More discussions needed, CBOR is not the right place, try to get
    feedback from JSON Shema
  3. Narrow down the scope, if a working group to be formed, a research
    group is suggested.
  4. Coordinate more closely with M3AAWG than perhaps form a WG.

ART AREA Meeting

11:00 BoFs, updates and meetings of interest - ADs (10 min)

  • Francesca presenting.
  • also: vcon (didn't make the slides)

  • NOTE: ART is splitting:

    • Web-art to WIT
    • SEC-art to SEC
    • ART will keep rest
    • Timeline is by IETF119 (transition in Jan 2024)
  • Cullen: is IESG seeking feedback?

    • A: not any more, have already got feedback.
    • Murray: not on creation of area, but if you have feedback on
      what groups should move.
  • Mark Nottingham: have given feedback, won't do again - but should
    discuss how DISPATCH will be affected.

    • Francesca: have discussed in IESG, will be something.
  • Ted Hardie: also gave feedback

    • WIT and ART - not sure ART matches resulting group, should we go
      back to APPS?
    • Maybe worth making name more descriptive, but is a bikeshed.
    • Francesca: considered description still accurate.
  • Finished 11:09

11:10 Collective Communication Optimization: Use cases, Problems and Requirements (10 min)

Presenter: Kehan Yao (On site)

  • Q: Rohan Mahy

    • Can you say what IETF protocols you're already using? Show what
      you're trying to accomplish.
      • A: do you mean should be more related to ART area?
      • Q: trying to make sure I understand the problem that you're
        trying to solve. Didn't get enough information from your
      • Might be able to say what IETF protocols now are not solving
        your problem.
      • A: back to first slide
      • Problem space: currently network is point-to-point.
      • Q: be more specific about what processes, what protocols,
        what part of the network.
      • Work will span a lot of areas. Need APIs that are friendly
        to developers.
  • Side meeting will be held on Thursday at 14:30.

  • Finished 11:21




11:20 Flextime & AOB (10 min)

  • Murray: this week, Nomcom are doing interviews - if you have
    feedback for anyone who has accepted nomination, please give that!

  • finished 11:22