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:

• MeetEcho

• Notes

• Zulip

DISPATCH Meeting

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

draft-schanzen-r5n

Messages

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
      responses.

  • 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
    group".

  • 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

draft-thomy-json-ntv

Messages

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:

  • Christian Grothoff - This would also be a good fit for our work
    on Set Reconciliation (https://lsd.gnunet.org/lsd0003/).

• 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
      context.
    • Would love to understand how to get this to different
      protocols.

  • 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
      different
    • 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
      general.
    • 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

draft-toomim-httpbis-braid-http

Messages

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
      people.
    • 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
      people.
    • 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

draft-brotman-dkim-fbl

Messages

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
      draft.
    • 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

draft-yao-tsvwg-cco-problem-statement-and-usecases

draft-yao-tsvwg-cco-requirement-and-analysis

Messages

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