Minutes IETF106: dispatch
minutes-106-dispatch-02

IETF 106 - DISPATCH WG / ART Area session
Sophia room - 10:00 Monday 18 Nov 2019

The chairs would like to express their gratitude to Pete Resnick and Steve
Donovan for taking excellent notes, and Jonathan Lennox for acting as Jabber
relay.

Dispatch Summary

The working group discussed two drafts:

- SIP Auto-Peer ( draft-kinamdar-dispatch-sip-auto-peer-01 )

The discussion was generally favorable towards progressing the work. Discussion
moved on to where the work should be done, and to suggest that we needed to
involve people who would actually implement and/or deploy it.

Conclusion: The ADs are leaning towards a mini-WG. The next step is to draft a
charter.

Real-Time Internet Peering Protocol (RIPP,
draft-rosenbergjennings-dispatch-ripp-03)

Discussion showed interest in the work, but a need to refine the scope. The
effort would probably be too large for a "mini" WG. We need to make sure there
is HTTP clue involved.

Conclusion: Organize a (possibly virtual) BoF. The proponents would like to
advance quickly. Cullen to organize a side-meeting Thursday morning.

ART Area Summary:

The chairs, ADs and BoF chairs plugged various BoFs and other meetings of
interest.

Bron Gondwana led discussion of various efforts to standardize use of push
services for IMAP, etc. There appears to be some interest in the work, but
there were also concerns that deployment may be constrained by the mobile OS
providers. Only a small number of people responded positively to the question
of who would participate in such work.

Justin Richer briefly described work on HTTP request signing. More detailed
discussion is to occur in secdispatch. However, there is some indication that
this is reasonable work for httpbis.

Detailed notes follow:
---------------------

DISPATCH WG

Agenda:
https://datatracker.ietf.org/meeting/106/materials/agenda-106-dispatch-03

Materials: https://datatracker.ietf.org/meeting/106/session/dispatch

Notetakers: Pete Resnick & Steve Donovan
Jabber Relay: Jonathan Lennox

Note Well was noted well.

Agenda bash. Note that the two Dispatch items have been switched in order.
No objections heard.

AD Comments:
Alexey Melnikov: Welcome Patrick as new DISPATCH co-chair. Chair rotation is to
be a regular thing. Thanks to Mary Barnes for her years of service. Barry
Leiba: Add thanks to Mary. Thanks to the 5 who accepted nominations for ART AD.
Please give your comments.

Richard Barnes: Nomcom is open for office hours 9-10 every morning this week.
Stop by.

SIP Auto Peer presentation
https://datatracker.ietf.org/meeting/106/materials/slides-106-dispatch-sip-auto-peer-00

Discussion:
    Suhas Nandakumar: This is something we've come across. We need to talk
    about what is needed, and there are places where manual intervention will
    be required, but this is worth doing. Patrick (from chair): Any more
    broadbased interest? Cullen Jennings: Are there any vendors in the room
    who've seen this problem? Gonzalo (Cisco) : We see this enough that it
    seems worth solving. Ben Campbell (from floor): How fixed will the
    capability set being offered be over time?
            - We don't expect changes unless there are radical changes to
            SIP/RTC.
    Ted Hardie: Does this belong better in OPS/Management? For instance, YANG
    stuff. They might have good input.
            - We're open to talking to them, but we haven't so far.
          Alexey Melnikov: ADs think that a mini WG might be a good idea. Might
          land in O&M, might be ART. Robert Sparks: Have you had any
          conversations with SIPConnect/SIPForum? Is this something they would
          be receptive to adding?
            - We see it as complementary
                    - Ben: You should talk to them.
          Chris Wendt: Is this too little too late? Yes, it makes our life
          hard, but it's not clear that there's motivation to standardize.
                        - We're hoping that down the line folks will see the
                        time/$ advantage.
          Mary Barnes: Given how we never could get folks to even agree on
          basic SIP device configuration, I'm not sure this will go anywhere
          either. Not that I don't think it's a good idea.

Ben: Anyone who thinks we *shouldn't* work on this? (Crickets). Summary:
Probably worth doing, but concerns that it might not be used. Need to
coordinate with folks who might use it. ADs think mini WG is good, ART or O&M.
Brian Rosen: that SIPCORE might be OK. Adam Roach: Could adjust SIPCORE
charter. Jon Peterson: Might want to use the MODERN. Robert Sparks: there's no
actual SIP there, just nouns about sip/rtp things Mary Barnes: And, I agree
with Jon P about MODERN.   If stuff works, there is no impetus for change.
Barry Leiba: Mary's point is well taken: Might be better to have a mini WG with
an OPS advisor to increase visibility. Cullen Jennings: Benoit's been doing
some review from a YANG point of view.

Conclusion: ADs leaning toward a mini WG. Drafting a charter would be next step.

Adam Roach: Put call out here and on SIP list to get interest. (8-10 folks put
hands up in this room.)

Real Time Internet Peering Protocol
https://datatracker.ietf.org/meeting/106/materials/slides-106-dispatch-ripp-01

Ted Hardie: Clarifying question: Are you concerned with cases where there's
processing after speech recognition, or speech recognition itself?
        - If speech recognition is local, less problem. If you're calling out
        to other service, that's when it counts. Ted: Thanks. Probably want to
        say in the document that it's both voice recognition *and* callout.

Bernard Aboba:
Chris Wendt:
EKR: This sounds like a bit late to the game. If the plan is to use this to
replace things, there's going to be friction. Issue with media going through a
centralized point. Jonathan Lennox: Either design this with video from the
beginning or declare it out of scope. We tried doing one after the other
before, and it didn't work. Jon Peterson: Divide UNI and NNI. Brian Rosen: This
sounds like SIP 3.0. This is redesigning multimedia connections. Maybe that's
OK, but let's not sidestep into it (like we did with SIP). Mo Zanaty: Video in
scope adds significant complexity. EKR: Proposed path forward is BOF. Cullen:
yes, should be a working group. Ben: can dispatch to a working group. Cullen:
not a miny working group. Mark Nottingham: Suggestion: BCP56bis is in HTTPWG.
Advice on how to build things on top of HTTP. Please either follow that
document or comment on why it might need to change. Cullen: Agreed. We do need
some HTTP clue. Chris Wendt: Need to figure out what kinds of problems we're
trying to solve. Brian Rosen: The more you try to limit the scope, someone is
going to try to expand it. You could start with a limited scope, but admit that
you're the big replacement. Cullen: Yes, it seems inevitable to have a bigger
scope. Ben Campbell: Chairs believe scope needs to be big, likely cross area
impacts.  Talking about a BOF.  Cullen: need to find a way to move faster than
normal. Barry : Can do things like mailing lists now Pete: Can do a virtual
BOF. Robert: Cullen, right now you own the delay. EKR: The reason people want a
BOF is because there's not consensus on what needs to be done. Aaron : Can we
do something later this week. Cullen: I don't think we could have something
together in that time. Alissa Cooper: The 2 years to charter WebRTC is short in
comparison to the 8 years to get the documents done. Cullen: One solution would
be to keep it outside the IETF. Ted Hardie: Changing the interop strategy
(i.e., no need to do backwards compat) makes this a different time frame. Stick
to this. Ben: Looking at BOF, will there be side meetings.  Cullen: difficult
to corrdinate. Mo Zanaty: Could help the WEBtransport effort.

Conclusion: Will look to chartering a BOF (perhaps a virtual one soon). There
is definitely interest. Clearly note the need for speed. Perhaps will grab a
room on Thursday.

ART Area portion of meeting

Meetings of interest slide. (Note typo in Web Transport BoF item.)

Dave Lawrence on ABCD: Recent history on DNS security. Though DoH has specific
issues, ABCD is meant to be generic discussion of what kinds of problems should
be worked on in IETF. Bernard Aboba on WebTrans: Next step beyond websockets.
Proposals are on the table. Discussion of use cases. David S.: Also related to
W3C work; they're looking to leverage this. Patrik McManus on WPACK: Web
packaging work. Working group forming BoF. Justin Richer: TXAUTH happening this
afternoon. "Like OAuth, but hopefully less messy."

PUSH Drafts - Bron Gondwana
https://datatracker.ietf.org/meeting/106/materials/slides-106-dispatch-dispatch-push-00

Cullen Jennings: Doesn't everybody use Apple's or Google's? Bron: Yes, but no
way to communicate to them to tell them to push. Cullen: So doesn't this depend
on the two? Bron: You can put something in front of the services, and use the
services for those things you can. Cullen: Need to clarify the scope. Neil
Jenkins: Clarifying the scope: Need a standardized way to set up the channel
with the provider. Seth ?: Is this third party for twilio on my phone, or more
generally for mail/calendar/etc.? Bron: The latter. Sean Leonard: Good work to
pursue in the IETF. Why not EXTRA? Bron: Sure, why not. Alexey: This is beyond
the current charter. Barry: Right people in the room; could just re-charter.
Adam Roach: RFC 8599 does this for SIP. Worth looking at. Matt Miller: There
needs to be an existing relationship  between the service and the push service.
That complicates it, but it's necessary. The concern is about SPAM / too many
bogus requests. That's what makes the relationship with Apple/Google to make
this work. Chris Wendt: Apple has made it extremely restrictive. This is going
to be a Terms of Service issue, not a protocol problem. Neil Jenkins: The way
to make this work now needs to have the service component that interacts with
the service. In the future, you could get the services to support removing the
intermediary. Ben Campbell: Will these people work with the IETF? Bron: Yes, I
believe so. Question for who would be interested on working on this: Not much
(1? in room, 1 in Jabber)

HTTP Signing - Justin Richer
https://datatracker.ietf.org/meeting/106/materials/slides-106-dispatch-http-signing-00
(Will also be discussed in SECDISPATCH)

Cullen Jennings: How does it relate to WebPack? Ted Hardie: They're very
distinct. There was discussion whether they should be tied, but no. Justin:
They should at least talk to eachother in some instances. Mike Jones: What
pieces need to land? Justin: Not sure yet. Where to start is still open. That's
the reason it's at SECDISPATCH. Mike: These groups need to talk to eachother.
(Incompatibilities potential; would be bad.) Mark Nottingham: This is on the
radar in HTTP. We haven't moved on it because of what you've said. Need to
include HTTP community in this discussion. Might land in HTTP. Carsten Borman:
CoAP has dealt with this as well. John Bradley: Signing is easy, HTTP is hard.
Need to work with HTTPWG to make progress.

Conclusion: Further discussion at SECDISPATCH, but sounds like HTTP WG might be
a good choice.

AOB:

RIPP side meeting is on Thursday 8:30 am Sophia room.

End of meeting.