# DISPATCH Hybrid Meeting @IETF-118 {#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][1] * [Notes][2] * [Zulip][3] ## DISPATCH Meeting {#dispatch-meeting} ### 9:30 Status and Agenda Bash - Chairs and ADs (10 min) {#930-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) {#940-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][4] [Messages][5] 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) {#1000-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][6] [Messages][7] Dispatch outcome: More discussion ### 10:20 Forming a general State Synchronization Working Group (20 min) {#1020-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][8] [Messages][9] Dispatch outcome: Narrow down the scope, a research group is preferred at least initially. ### 10:40 DKIM-FBL (20 min) {#1040-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][10] [Messages][11] 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 {#art-area-meeting} * * * ### 11:00 BoFs, updates and meetings of interest - ADs (10 min) {#1100-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) {#1110-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][12] [draft-yao-tsvwg-cco-requirement-and-analysis][13] [Messages][14] ### 11:20 Flextime & AOB (10 min) {#1120-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 [1]: https://meetings.conf.meetecho.com/ietf118/?session=31582 [2]: https://notes.ietf.org/notes-ietf-118-dispatch [3]: https://zulip.ietf.org/#narrow/stream/dispatch [4]: https://datatracker.ietf.org/doc/draft-schanzen-r5n/ [5]: https://mailarchive.ietf.org/arch/msg/dispatch/9fnTpIHD2xACUP3ehXIy9x08wNk/ [6]: https://datatracker.ietf.org/doc/draft-thomy-json-ntv [7]: https://mailarchive.ietf.org/arch/msg/art/dkm9xSrpRfbpgztcUeat8PLlo1w/ [8]: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http [9]: https://mailarchive.ietf.org/arch/msg/dispatch/wCrAiHwWvlK9netFi71nz3FF7Aw/ [10]: https://datatracker.ietf.org/doc/html/draft-brotman-dkim-fbl [11]: https://mailarchive.ietf.org/arch/msg/dispatch/4e3ywiHzysz5CnB8sL888h6o-hg/ [12]: https://datatracker.ietf.org/doc/html/draft-yao-tsvwg-cco-problem-statement-and-usecases [13]: https://datatracker.ietf.org/doc/html/draft-yao-tsvwg-cco-requirement-and-analysis [14]: https://mailarchive.ietf.org/arch/msg/dispatch/15Jikb-QuEdG7xfmC2XUI8Nl2do/