IETF119 - ALLDISPATCH Agenda

Monday (180 min)

Chairs update – Shuping Peng, Jim Fenton, Rifaat Shekh-Yusef, Daniel Kahn Gillmor, Martin Vigoureux (10 min)

• Shuping and Jim at the front - notewell and noteverywell presented.
• This is an experiment - a BOF - please give feedback about how it
  went.
• Please focus on the dispatch question!

Towards SSH3 - François Michel (Remote) (15 min)

https://datatracker.ietf.org/doc/draft-michel-ssh3/

• Question - does anyone want to help collaborate on the draft?
• Easy to implement!

Mike Bishop:

• Like the general direction
• Little cautious about trying to do something on top of HTTP and then
  reach down into quic.
• Maybe web transport is a better thing.
• Dispatch:
  • Squarely in IETF's remit
  • No existing WG
  • Have a BOF, see if interest

François Michel:

• (not called)

Mark Nottingham:

• Long time user of SSH
• Question what the utility of putting it on top of HTTP here.
  Remember that if you're running over HTTP, that's a hop-by-hop
  protocol.
• Advantages; almost entirely QUIC. And if you're downgraded to
  H2/TCP, then you don't get the advantages.
• Dispatch question: sounds great, but question need to go over HTTP.
• As a community, we have a knee-jerk "put over HTTP" for everything.

Tommy Pauly:

• People leaning towards a BOF, sounds great.
• Similar to MASQUE, doesn't fit in charter of MASQUE.
• Other things in HTTPBIS working group, CONNECT-TCP.
• Agree point about webtransport is interesting. Let's have a BOF.

David Schinazi:

• Putting stuff over HTTP enthusiast.
• Excited about this work. See reasons to put over HTTP. We run ssh
  over our load balancer internally with connect.
• Would be supportive of a BOF, large enough to need own working
  group.

Christopher Allen:

• share questions of "everything over HTTP".
• Waved out hands at ssh auth. Have a lot of questions about using a
  lot of keys for ssh developer usage in peer-to-peer things which are
  easy with SSH and hard with HTTPs.
• Want to be sure would be looking at larger problems of auth and key
  usage.

Eric Rescorla:

• Agree with people who think there should be a BoF.
• Are people who are deploying ssh at scale interested in this? IESG
  should determine this before a BOF.

Alex Chernyakhovsky:

• maintainer of MOSH, which does something like this.
• Very keen on this. Have lots of evidence that users would want this
  and deploy it, including Google internally.
• BOF is fine. MASQUE is fine, but would need a recharter.

Richard Barnes:

• I think BOF is the obvious answer.
• Hate that every time we dispatch things to a BOF, it takes another 3
  months. Encouraging the proponents to aim for a virtual BOF before
  IETF 120.

Martin Thomson:

• Question of "do transport OR transport and various authentication
  options" might turn into an attractive nuisance - should do some
  work in advance to tighten the scope.

Dispatch Summary: A BoF is suggested. An interesting work, fits into
IETF, but could start the work now with AD's help, please also review
similar work.

Transport Layer Security (TLS) Authentication with Verifiable Credential (VC) - Andrea Vesco (Remote) (15 min)

https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/

• (presentation froze about 1 minute in - then we lost audio on
  reconnect)
• (Christopher spoke while reconnect was happening)
• TLS WG? UTA WG? ??

Christopher Allen:

• this is the beginning of an important pile of work.
• Dispatch: BOF? Feels like BOF should have more of a charter. Maybe
  multiple BOFs?

(post presentation comments)

Hannes Tschofenig:

• For adding a new value to the registry, only need a specification.
  That should be done in an organisation that works on those
  credentials.
• Would do this in W3C.
• If someone does something similar with CWD or JWD (e.g. in spice)
  there might be a home there, but was not proposed or discussed
  there.

Eric Rescorla:

• don't need anything in TLS; just a specification needed to allocate
  a codepoint.
• Only one place in IETF that is empowered is TLS. I think the answer
  here is to do in TLS.
• Questions in chat about whether there are issues.

Richard Barnes:

• would like to dispatch this to the future.
• Place is in TLS; but not yet.
• VC space is too unsettled right now, multiply defined unsettled
  stuff. Wait for that to settle before applying some codepoints.
• If dispatch today - to TLS; but think we should hold off.

Wes Hardaker:

• Not quite sure where it should go, like the future idea.
• Multiple spaces working on this. As chair of DANCE group, there's
  work there.
• Would like to see why not following the work in existing spaces to
  get an evaluation.

Dispatch outcome: To TLS, if ready to come to IETF at all, maybe W3C.
More discussions are needed.

Happy Eyeballs Version 3 - Tommy Pauly (On site) (15 min)

https://datatracker.ietf.org/doc/draft-pauly-v6ops-happy-eyeballs-v3/

• from the chat: dispatch to multiple WG's, pick the one which accepts
  it first.
• v6ops? tsvwg? a new WG?

Nidhi Jaju speaking for second half of presentation:

• lots of other things have changed, hence need for V3 of happy
  eyeballs.

Bob Hinden:

• Support this work, think it's important - don't have a strong
  preference v6ops or tcp working group.

Lozenzo Colitti:

• should not go to v6ops. Came out of, but has other implications.
• Racing stuff that has security implications.
• Feel it belongs in a transport working group.
• Keep in mind: performance advantages of this protocol might be
  reacting to random packet loss.
• Transport folks most qualified to talk about this.

Jen Linkova:

• think this should definitely be done.
• Understand Lozenzo's concerns, but also see value in v6ops.
• Doesn't really matter which room the people sit in, but one thing we
  need to discuss - dual stack device with nat64 vs native v4?

Ted Hardie:

• Think dispatch question here is best answered by a new working
  group. There's overlap, but it's in different areas and different
  areas.
• Only way to solve - assign advisors from areas and encourage people
  to join.

Ralf Weber:

• from Akamai. Support work.
• Maybe new WG is a good idea.

Mike Bishop:

• (didn't speak)

Pete Resnick:

• Short recharter for TAPS might be interesting.
• Transport people need to be involved.
• New working group? Single topic.
• Something that gets this done Quick.

Warren:

• ACCESS POINT ISSUE

Dispatch outcome: A new working group which might across areas is
suggested. The experts from different areas are needed, especially the
ones from Transport area. Not v6ops due to lack of expertise of
security. Recharter the TAPS could also be considered.

Wrong-Recipient URL for Handling Misdirected Emails - David Weekly (Remote) (15 min)

https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/

• Not speaking on behalf of employers.

Tobias Fiebig:

• not sure whether this draft is adding another version of MDRs.
• Can just send an MDR to the return path, and people required to
  handle that.
• Dispatch: not sure whether we have something.

John Levine:

• One click unsubscribe has been successful enough. Think we should do
  it.
• Assume MAILMAINT gets spun up, seems

Bron Gondwana:

• Agree to MAILMAINT, but also there's a more general need for
  "feedback about this email", don't just keep adding headers.

Christopher Allen:

• Like this, have it go to MAILMAINT; can we just send it to an area
  director?

Murray Kucherawy:

• Think the right way is to MAILMAINT, should spun up on 4/4.
• No interest in AD-sponsoring a draft when there's a WG coming.

Scort Fluhrer:

• Might be security implications, needs to be thought through, not AD
  sponsored, needs WG.

Dispatch outcome: To MAILMAINT for more discussion there.

Human Rights Privacy through Deterministic Hashed Based Elision - Shannon Appelcline (Remote) (15 min)

https://datatracker.ietf.org/doc/draft-appelcline-hashed-elision/

• Also; Christopher Allen present to assist with answering questions.

Paul Hoffman

• Chairs gave a list of possible dispatches; thing this goes to IRTF.
  Skimmed over two drafts, a lot of statements "this will cause that"
  which are far outside of protocol space.
• This is strongly research, belongs in IRTF.
• Interact with CRSG.

Tobias Fiebig:

• HRPC might be the most fitting place.

Eric Rescorla:

• You've asked a number of dispatch question.
• These are citing IRTF documents, the fact that they're not being
  widely used in IETF might be that.
• This is a technology that people might use? If nobody in IETF wants
  this, gets dispatched to /dev/null.
• Asking for demonstrated desire for people in IETF to want to use
  this tech.

Michael Prorock:

• Strongly concur with maybe IRTF - not sure exactly what was being
  proposed there - there were technical drafts that went to COSE and
  CBOR and got feedback.
• If there's follow on tech that someone at IETF wants to use, carry
  them in with maybe 1-2 slides, not 41.

David Schinazi:

• As IAB - kind of confused by this presentation, started off by
  talking about how abstract documents were insufficient, then
  proceeded to say "and we have a technical solution" - a leap that
  lost me there.
• If the goal is to move forward with this technology, don't see a
  need for it or a protocol that wants it.
• If the goal is "maybe we need a human rights document that does what
  we want" that should go to HRPC.
• Saying "these documents aren't doing anything"; we've done a fair
  bit since that was published.

Alissa Cooper:

• Agree with comments so far on dispatch question, don't see anything
  here ready to dispatch.
• As author of 6973 - was a conscious decision to make it advisory.
• Also been discussion about updating it - if you're interested in
  doing that, would be something to consider.
• Seems like authors are after something different, using that as the
  motivator doesn't really work.

Colin Perkins:

• IRTF chair.
• Always happy to discuss work in IRTF or particular working groups.
• As a process issue; this group can not dispatch things to the IRTF.

Andrew Campling:

• both those drafts are information RFCs from the IRTF. Maybe authors
  didn't understand purpose, but would be surprising if they were
  applied to all documents.
• Perhaps IRTF be the place, should the chair be minded to take that
  up.

Ted Hardie:

• Encourage you take this away and break into chunks of work; and ask
  again with those.

Dispatch outcome: Not in IETF maybe in IRTF. Break down work into more
specific pieces; and come back for more specific feedback here.

• Probably IRTF; if they want it (we can't send it there)

WebSocket Extension to disable masking - Dragana Damjanovic (On site) (15 min)

https://datatracker.ietf.org/doc/draft-damjanovic-websockets-nomasking/

• Pete Resnick from Chatbox: WEBTRANS?

Mark Nottingham:

• experience in operations is that proxies are often not upgraded.
• dispatch question: talk to ADs; maybe to HTTP? Not really in our
  charter.

Haoran Luo:

• first time attending, thank you
• organisations; keeping their site up

Eric Rescorla:

• maybe demonstrating this is now less of an issue?
• before moving to a security feature, verify no longer an issue.
• attacker controls the webserver, can do the cache poisoning
  themselves.

David Schinazi:

• MASQUEing enthusiast
• would like to see more motivation on this, why is masking bad?
• would recommend send this to Websocket maintenance group; which is
  currently called HTTPBIS. Charter seems by my reading to cover this.
• As webtransport chair, don't think we should have a separate
  maintenance group.
• Get ADs to make determination.

Alessandro Ghedini:

• there are middleboxes which try to actively inspect or inject on
  websocket.

Dispatch outcome: Needs to see more motivations and gap analysis to the
necessity of this work. Could go to HTTPbis to collect more feedback
first.

Extended YANG Data Model for DOTS - Linzhe Li (On site) (15 min)

https://datatracker.ietf.org/doc/draft-cui-dots-extended-yang/

Zhaotao Liu:

• About 20 years ago, academic community proposed "network capability"
  • signed form of router intent.
• Published a lot of work on using this to prevent DDoS attacks.
• Talked with Cloudflare, Akamai etc - they said "large providers
  should only care about large things". Happy to see people at IETF
  talking about how only watching large attacks is not enough to help
  downstream providers.
• Answer to dispatch: like this; IETF should do.

Peng Liu:

• Support work

Paul Hoffman:

• Believe this should be a BOF. DOTS concluded a year ago, had lots of
  documents, lots of interest, has all been deployed.
• Don't think we need a DOTS-bis.
• One-time BOF for this draft or this topic?
• Hopefully AD with result of BOF could AD sponsor or say "we need a
  WG"

Kent Watsen:

• Chair of Netmod working group
• Have a standing agreement to publish YANG that doesn't go into other
  groups, best if you have experts look at it.

Arnaud Taddei:

• Broadcom.
• Would go for a BOF as well.
• On the content; don't know that responses are normalised.

Dispatch outcome: To a BOF; maybe related topics not just this draft.
Get more feedback during this week.

Unicode Character Repertoire Subsets - Tim Bray (Remote) & Paul Hoffman (Onsite) (15 min)

https://datatracker.ietf.org/doc/draft-bray-unichars/

• Not representing anybody.
• Came from JSONpath work.

John Klensin:

• Biggest concern is that if we end up with a large number of
  different profiles, we end up confusing everybody and creating
  interoperability problems.
• Problematic character list - there's probably some problematic
  things in the "seen as OK" list.
• Can we start with Precis and see problems there?
• Advice for dispatch: want to hear from authors why we can't build on
  Precis.
• If we need to modify precis, maybe start that working group again?

Pete Resnick:

• recommendation: ditch this document. The reason precis exists is to
  read through the proposal, make a profile.
• We don't need a working group, precis gives advice.
• Implementers just use the profile.

• Response:

  • Precis profiles not widely used; other groups might do things
    without knowing? How do we get precis profiles to be better
    known?
  • This as an RFC will have some focus, precis profiles won't.

• Give precis profiles visiblity - point to it, announce widely.

Carsten Bormann:

• agree with Pete's dispatch verdict, but not for the same reason.
• A document like this should give advice, this gives really bad
  advice.
• Gives a good history; no longer contains incorrect statements by 7th
  or 8th revision, but it should be useful.
• The episode that Tim related to on jsonpath; where JSON accepts
  toxic waste - not unicode but parser will ingest and get a stomach
  ache.
• Term "problematic character" - every character is problematic. Have
  to understand your application, what characters it needs.
• Need a document which gives useful advice to people wanting to
  create new protocols.
• We should find some way to have such a document. Thought maybe I
  should write one. It's the next document in this meeting!

Harald Alvestrand:

• Unicode offers many opportunities to shoot yourself in the foot.
• This document; like the presentation better than the document!
  Document seems to say "as long as you're only handling codepoints
  and don't care what they mean, you can get away with following these
  rules".
• Once you try to assign meanings, you get into lots of other
  problems!
• with "if you want do more than move characters around, you need to
  look at more"

Orie Steele:

• Incoming ART AD.
• Wish this was a Precis profile?

Pete Resnick:

• It's like an IANA registration - it has a process; register a
  profile, no working group needed.

Dispatch outcome: A good draft/presentation to provide useful advice.
More prefer Precis although it is currently not popular. Suggestions on
work more on Precis to make it more visible. AD-sponsored draft is also
a option suggested by the ART AD Orie Steele.

Modern Network Unicode - Carsten Bormann (On site) (15 min)

https://datatracker.ietf.org/doc/draft-bormann-dispatch-modern-network-unicode/

(no queue)
Jim: what's your preference on dispatch?

Cullen Jennings:

• Not an expert in this space
• Seen a ton of energy expended on this
• Have had a ton of working groups spend time on this, and this is
  different.
• Need to deprecate past advice maybe!
• NOT AD sponsored, we need to be serious about this.
• Advice for new designs may change what previously published
  documents said about new designs.

John Klensin:

• Agree with Cullen about complicated part.
• Our general internationalisation work is in general disarray.
• Has been discussed at length with ADs.
• I think the solution is to look at existing work, talk more clearly
  in the draft about how it related to existing work. See if it can
  become part of the picture instead of another conflicting picture.
• Worried about having multiple specs which are not the same but
  overlap - give people too much choice about where to go and what to
  look at.
• Not opposed to this draft, needs to be part of a larger picture.

Ted Hardie:

• I believe you have two different things you're trying to do, answer
  might be different for those.
• Guide - doesn't need to be standards track, maybe better if can
  iterate more rapidly. Take it outside the RFC stream.
• What do you want to reference as a new spec that's not a precis
  profile. If people need a reference which is NOT a precis profile,
  maybe we need to fix precis.
• But if split into two pieces, the answer falls out naturally.

Harald Alvestrand:

• some of the same objections to this draft as with the other draft.
• Can get into more trouble than draft seems to indicate.
• Comparing to other drafts - they are frankly incompatible.
  Publishing both would be a disaster.
• If we want to specify "here's a sane set of unicode to use" we need
  to get one, we can't dispatch both.

Paul Hoffman:

• If going to be dispatched to "a mailing list" would be good to know
  which one.
• Jim: to ART.

Dispatch Outcome: This is complicated. A lot of existing work, be
careful about overlaps. More discussions go to the art mailing list.

A summary of the dispatch outcomes follows:

1. Towards SSH3
   To have a BoF is suggested. It is an interesting work, and fits into
   IETF, but could start the work now with AD's help rather than wait
   for next IETF. An interim meeting could be held in between. Please
   also review similar work.

2. Transport Layer Security (TLS) Authentication with Verifiable
   Credential (VC)
   To have more discussions with tls wg to determine if suitable for
   IETF. Otherwise this might be better suited for W3C.

3. Happy Eyeballs Version 3
   A new working group is suggested. The experts from different areas
   are needed, especially the ones from Transport and Security areas.
   Not v6ops due to lack of expertise of security. Re-charter the TAPS
   could also be considered.

4. Wrong-Recipient URL for Handling Misdirected Emails
   To MAILMAINT for more discussions.

5. Human Rights Privacy through Deterministic Hashed Based Elision
   This seems more appropriate for IRTF, even though we can’t dispatch
   work there. Break down work into more specific pieces; and then come
   back for more specific feedback here.

6. WebSocket Extension to disable masking
   Collect more feedback back from the httpbis wg. Work more on the
   motivations and gap analysis to show the necessity of this work.

7. Extended YANG Data Model for DOTS
   To have a BOF including related topics. Collect more feedback this
   week.

8. Unicode Character Repertoire Subsets
   To use PRECIS profiles, even though they’re not particularly popular
   now. Could also be documented as an ART AD-sponsored document.

9. Modern Network Unicode
   Discuss further on the art mailing list. There is a lot of existing
   work, so be careful about overlaps.