Minutes for DISPATCH at IETF-90
minutes-90-dispatch-3

IETF-90 DISPATCH minutes
========================

Tuesday, July 22, 2014, 16:40-18:40 (Ballroom)

Chairs: Mary Barnes, Cullen Jennings

Notetakers: Andrew Hutton and Michael Proctor

Jabber Scribe: Jonathan Lennox

Meetecho Recording:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF90_DISPATCH&chapter=chapter_0

Summary:
---------

WebPUSH: there was unanimous support for this work being pursued in the RAI
area (since a major use case is incoming voice call notification). Half the
room indicated they were willing to do work.

IOTL: to be progressed as AD sponsored (as usual an expert/RAI directorate
review is required).

=========================
Notes by Andrew Hutton:
=========================

WG MANAGEMENT IN THE RAI AREA  (AD's)
--------------------------------------

R.Sparks - We have been talking about closing these down for years what is
different these times.

J.Peterson - Problem is they are not causing eneough pain to worry about
closing these down.

A.Allen - Insipid has quite a bit of work to do to finish.

Cullen - We need to make space (Editors, Chairs, Etc.)

K.Drage - Insipid is not finished.....

J.Peterson - Urge you to consider what is causing is work.

Alissa - These are not been forced to close they are approach a natural end.

Mary - There are some wg's languishing but will not name names ......

Charles - XRBLOCK might be longer lived.

Alissa - There are options for xrblock.....

J.Peterson - I will need xrblock sometime in the future what is the problem
with keeping it going in a dormant state is it really causing pain?

WEB PUSH
--------

Ted - Goals Slides - Should be "Define App Server <-> Push Server Protocol" not
"Define App<-> Push Server Protocol".

A.Allen - Some previous standardization activity in OMA what is the issue with
these why have they not been deployed.

Speaker -

M.Thomson - The people who initiated the work in W3C where part of the OMA
initiative and looked at this but is not suitable.

Dan D - Very happy to see this work......

Ted - Why is this in RAI

Speaker - The time is small.

Cullen - This is probably in a grey area could be in multiple places there are
some real-time aspects.

Drage - Some apps using this might be in the RAI area but need to have a
discussion as to why this is in RAI area.

.....

Alissa - There is obviously some interest here and boundaries between areas are
not set in stone.

Mark Nottingham - .... Learn from websockets issues???????

Dan Druta - There is a lot of synergie with real-time apps.....

Ted - Privacy question, Currently queries are distinct and go to separate
services agregating them causes some privacy issues. Could be beneficial due to
have some control over different services. -----missed some stuff----

Ekr - One of major apps for this is incoming call notification why it is in RAI.

?? Definitately an interesting topic and thinks it is justified to be in
RAI.....

J.Peterson - People want it and it is useful and not so far from what RAI does.

J.Lennox - Do we think the expertise in RAI the right type compared to people
in other areas.

M.Thomson - Convinced that the RAI is the area to right place we have expertise
in going down previous rat holes.

J. Peterson - Would be astonished if there is more expertise in other areas.

HUMM - Who thinks we should be doing this work in the IETF. ***** Strong
consensus in favor did not hear any humms against.

Who is willing to show up in the WG and do work.  Lots of hands.

IOTL - Inter Operator Traffic Leg.
====

J.Peterson - We killed P-Header fields so cannot use a new P-Header.

Discussion on what backwards compatibility means in this context.......

Question: Should it be generic or 3GPP Specific? Question: WG delivery or AD
Sponsor?

Ted: If there was a mechanism for 3GPP to request this be a private use URI
parameter that is what should happen.

K.Drage: If this is 3GPP specific fine but still needs to be IANA registered.

M.Dolly: 3GPP Specific and AD Sponsored please

J.Peterson: A very low bar to review.

Cullen: Does not seem to be the energy for a WG

Cullen: Anyone object to getting a SIP Directorate review and AD Sponsor - No
objections and Alissa was ok with this.

=========================
Notes by Michael Proctor
=========================

Brief note concerning Francois' passing.

Always be closing - ADs
-----------------------
Richard presented his slides.

RjS: Some WGs have been hanging around for many years.  How
     can we actually mean to shut them down this time.
JonPeterson: Not much effort to leave WGs in a quiescent state.
AndrewAllen: insipid still has lots of work, doesn't it?
BenCambell: Protest! dart is probably the newest wg in rai!
Cullen: (floor) Everyone has a favourite wg, but we need to clear
     out old groups to make way for new wgs and chairs and
     document authors etc.  Need to trim the dead leaves, need
     to replace fluffy.
KeithDrage: If it has open milestones with drafts in progress,
     will they be able to complete?
Richard: Yes
ekr: I approve this message.
Richard: Like vipr, moved to AD-sponsored to keep the tempo up.
JonPeterson: Too many groups, but don't fret about it too much.
Alyssa: No unnatural endings - just urge to complete work
KeithDrage: Add dispatch to this list?  What about ecrit?
Mary: (floor) keep languid groups separate from recent quick groups
Charles?: xrblock: might be long-lived.  What's the plan?
Alyssa: couple of options - keep it open but dormant, or roll into
     one of the avt* groups.  Will work it out nearer the time.
JonPeterson: vipr draft delayed - is this a problem?
RichardShockey: the problem with vipr is it is a bad idea
Mary: Would like to get the vipr draft off the table

WebPush - Doug Turner
---------------------
Doug presented his slides.

TedHardie: Clarify App should be App Server on "Goals" slide
AndrewAllen: Previously standardisation before (mobile alliance?)
     Why hasn't this worked before?  Why these standards aren't adopted?
Doug: Driving force is wanting push notifications on the web, not
     just for native apps.  Need to define app server--push server protocol
     but accept device link will probably be proprietary for a while
MartinThomson: Previous standard attempts had large amounts of push-back
     for various reasons, such as authentication and others.
Dan@at&t: Pleased to see it coming to fruition - more modular approach
     allowing delivery mechanism to be separate.  Still need developer
     to engage with multiple delivery platforms.
TedHardie: On "Broadcast" slide, is this delivery is basically pub-sub?
Doug: Yes - the api between app-server and push-server may be optimised.
TedHardie: "Store and Forward" slide, why are we in rai?
Doug: Time is very small, 15s-1min. Able to prioritise less urgent msgs
      to reduce battery usage.
TedHardie: Still, why rai?  Not real-time.
Cullen: We might conclude "this is totally routing", but the storing part
      is to meet a real-time requirement to not do head-of-line blocking for
      more urgent messages. dispatch is probably a good place to start.
KeithDrage: Applications of this could be in rai, but why this should be
      in rai rather than in the area with http?
Doug: We asked for use-cases, and people said to bring it here first.
Alyssa: Think we can close this part of this subject.  Obviously there is
      interest here, so here is a good place to start.
MarkNottingham: Interesting topic. Reminds me of websockets.  But at
      previous job, we couldn't scale that out across the platform.  Be
      careful and ensure it is baked in from the start.
Dan?: Push service is a complex entity.  Synergy with real-time applications.
TedHardie: privacy question: device creates distinct queries for different
      information.  Now aggregating in a push service.  Could have different
      push-services to control aggregation in new and different ways.  But
      leaving message encryption to app layer? Just app server->push server?
Doug: Pushback from web devs and privacy: there are already libraries that
      do this.  Should do end-to-end encryption.
TedHardie: Offering too many choices for web dev.  Have a worked example at
least. ekr:  I agree with Ted. Major usecase is for incoming call
notification/sms
      which are clearly real-time, which is why it should be in rai.  Even
      email notification is expected to be fast now.
Xavier?: Interesting topic. Lots of interest in rai to help real-time comms.
JonPeterson: This doesn't seem too far from pub-sub stuff.
JonathanLennox: Not so much speed as defining reason.  Are people with e.g. SIP
      experience more likely to deliver rather than other areas?
MartinThomson: Convinced this is the right place.  We have done it wrong
      before, so we have the wisdom to identify ratholes.
JonPeterson: How many times to we need to coordinate with apps?
      We have skinned this cat in so many ways, we must have the experience
      by now.
Mary: hum on doing work in IETF now.
Fluffy: pretty strong consensus - basically unanimous

Fluffy: Who is willing to work on this?  Show of hands
Fluffy: lots of people prepared to actively work on this
Fluffy: Will discuss more on the list

IOTL - Christer Holmberg
------------------------
Mass exodus from room, before Christer mentions "IMS"
Christer presented his slides.

AndrewAllen: Loopback slide: This slide only shows signalling?
Christer: Yes.

JonPeterson: Do we still do P- headers?
Christer: Not suggesting using a p-header.
AndrewAllen: Not developing new p-headers.

RichardBarnes: briefly elaborate what you mean by backwardly compatible?
Christer: need to make sure legacy devices strip this indication
Mary: (floor) not defined behaviour to strip unknown headers
Christer: you strip topmost route header
KeithDrage: probably overstrict.  You only need to ensure it doesn't cause
     problems further down the line

TedHardie: equivalent to a bgp community with a shared understanding
     You want to define something only for use within a private community which
     shouldn't leak out.  Maybe register the private-use token and not define
     it in IETF
KeithDrage: Link to use-cases sent on the list.  You should have read it if you
     are interested.  Private-use is fine, but still needs to be
     IANA-registered.
MartinDolly: 3gpp-specific and AD-sponsored
AndrewAllen: What are the rules for uri-parameters?
Fluffy: You need an RFC
Fluffy: If we had a document describing this, who should read it?
     Who is going to read it? 5 people!
JonPeterson: The only review needed to ensure it doesn't change the
     behaviour of SIP.
Fluffy: OK to get SIP directorate to review it then AD sponsored?
     OK - no SIP directorate!
Fluffy: Anyone wanting to propose mini-WG?  Not seeing the energy in the room.
Alyssa: I think what you suggest is fine.

Fluffy: Thank you very much!