Re: [dispatch] More verbose notes from Dispatch 93

[Steve Lhomme <[e-mail]>]

On Wed, Jul 22, 2015 at 4:41 PM, A. Jean Mahoney <[e-mail]> wrote:
> Hi all,
>
> And here are rougher, more verbose notes from this morning's session.
>
> Jean
>
>
> -----------------------------------------------------------------
> Dispatch 93
> 2015-07-22
> 09:00-11:30 Congress Hall III
>
>
> 09:00-09:10 (10m) Status and agenda bash
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-3.pdf
> Presenters: Mary Barnes, Cullen Jennings
>
> Note Taker: Jean Mahoney
> Jabber Relay: Ted Hardy
>
> Slides presented - change to agenda, ICE WG presented first.
>
> Proposed ICE WG ______________________________________________________
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-4.pdf
> Presenter: Pal-Erick Martinsen
>
> Cullen: comments?
>
> Flemming: As MMUSIC chair - this has a lot of advantages, but we need to
> clarify that there is both core ICE and ICE SDP work.
>
> Ben: Marc had sent out some proposed charter text, but not to dispatch. On
> the SDP question, we have WG like payload, they do SDP in their own group.
> ICE would handle ICE-specific SDP, unless complex. Handle this on a case by
> case basis.
>
> Cullen showed the proposed charter.
>
> Roland: probably need more text regarding interacting with other WGs, to
> discuss on the ICE mailing list.
>
> Alissa: send the charter to dispatch. ACTION. We've had hallway
> conversations. Any opposed?  Need to update MMUSIC charter also.
>
> No opposition or comments.
>
> Summary: Send to the proposed charter text to list
>
> FFV1 and Matroska __________________________________________________
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-6.pdf
> Presenter:  Tessa Fallon, Emmanuel
> References:
> - FFV1 Video Specification: https://mediaarea.net/temp/ffv1.html
> - Github: http://matroska.org/technical/specs/index.html
>
> slide 1: Title
>
> slide 2: PREFORMA Project
>
> Tessa: wanting legitimacy from SDO to encourage uptake
>
> slide 3: FFV1 and Matroska
>
> slide 4: FFV1: Current Work
>
> slide 5: Matroska: Current Work
>
> slide 6: Objectives
>
> slide 7: History of development
>
> slide 8: Why FFV1 and Matroska
>
> slide 9: Why IETF
>
> slide 10: Charter
>
> Not sent to the ml yet.
>
> Ben: to the room - we should talk about whether this is interesting work for
> IETF, not charter text.
>
> slide 11: Charter
>
> slide 12: Charter
>
> slide 13: Charter
>
> slide 14: Deliverables
>
> slide 15: Questions for Discussion
>
> Mary: several people on ml voiced interest.
>
> RjS: What is it about this that is internet-centric? Look at OPUS. The codec
> group in OPUS was focused on internet realtime apps. That will inform if
> IETF is a good venue.
>
> Jerome:  Matroska used with VP8 and VP9, used with YouTube (WebM). Not
> completely internet based but maybe later. We want transparency, open source
> and openness. We would like to go through IETF.
>
> Alissa: Are these a package deal?
>
> Tessa: No. Looking for feedback on what IETF wants to do - both or either.
>
> Roni: this looks like storage. Why IETF?
>
> Tessa: I think Jerome's answer covered that.
>
> Roni: Will it be used to transfer over the Internet?
>
> Tessa: the specs for these are proprietary, the goal is to be open source.
>
> Jerome Martinez: Matroska is used over the internet. Matroska can transfer
> Opus. We use MP4 and 264, but want something more open. It is for storage -
> main purpose, but may be used as transport. FFV1 is good candidate for
> video.
>
> robux4 (Steve Lhome), from Jabber: Matroska is currently supported in

For the record it's Lhomme. I first misspelled it on the chat.

> Chrome, Firefox and MS Edge, for streaming video. Opus can also be stored in
> Matroska for streaming and unlike MP4, Matroska was designed for streaming
> on networks, even live streams
>
> Dave Rice, from Jabber: The preservation of the video of the internet is
> longterm a complex matter filled with codecs that the gain wide use and then
> gradually fall into obsolescence. The role of a lossless codec helps
> preserve internet video in some form that is long-lasting
>
> Mei??: I work on mpeg MP4. ... There's a lot of maintenance work I assume.
> Does the IETF take that? (something about why needing a lossless codec)
>
> Tessa: we didn't take it to SMPTE because it's paywalled.
>
> Dave Rice, from Jabber: SMPTE standards are behind paywalls and lack the
> features of IETF that are most appealing, such as the openness and
> transparency of the process
>
> Jerome: there's lossy formats on net. Maybe we want a lossless format in
> future. Want to discuss how to maintain with IETF.
>
> Ben, as individual: You've come here because of our openness and open spec.
> But you can put it out somewhere yourself.
>
> Mary: It's already out there.
>
> Ben: You don't need the IETF for publishing. We might be able to help with
> technical work. Does it need technical help?
>
> Tessa: Yes, the specs are public, but would benefit from the IETF review
> process - vetted and thoroughly reviewed. There's been a lot of work already
> done, they don't need to be developed. They exist. But they don't have
> authority, need to be thoroughly vetted. But if people aren't interested,
> that's good to know.
>
> Ben, as AD: if this comes into IETF as a standards effort, the IETF takes
> change control and may change things. Is that OK?
>
> Tessa: yes, that's understood.
>
> Dave Rice, from Jabber:  today we are well familiar with the role of FLAC
> lossless audio on the internet, there is a similar need for FFV1 for
> lossless video as well. Just as we have lossless documents, audio, and
> photos on the internet, there is a future for lossless video on the internet
> as well. For reference http://github.com/ffmpeg/ffv1 and
> https://github.com/mediaarea/ebml-specification
>
> Ted Hardy: Yes, IETF requires change control. The IETF is a nebulous thing,
> who ever turns up in this room is IETF. If your dev team doesn't want to
> participate in IETF, it will fail. You need to bring the community into the
> IETF also.
>
> Tessa: thanks, we're not going to just hand over the files and be done. We
> hope the development community and the IETF come together.
>
> Cullen, as individual: There's lots of needs for lossless video - medical
> images for instance. Long term storage - I see that a standardized version
> is valuable. I've reviewed these specs. The codecs are good, but the specs
> are not. Wouldn't be interoperable. XMPP came to the IETF mainly done and
> then evolved. We have container formats that we're standardizing - JSON is a
> good example. I don't see this as a huge leap for IETF.
>
> Steve Bozko: Personally, I think it's interesting and valuable. Concern - on
> Matroska - work will be ongoing, maybe never-ending maintenance. Unless it's
> limited to FFV1.
>
> Alissa: Does your dev community meet in person?
>
> Tessa: No. On the lists.
>
> Dave Rice: some in-person meetings at FOSDEM, but most is virtual
>
> robux4, from Jabber: As the original author of Matroska I'm already involved
> with the more formal specifications of EBML and Matroska that started a few
> months ago and will continue participating wherever it is going to happen.
>
> robux4, from Jabber: how each codec is defined in Matroska is outside of the
> main specs, it's a top layer and not all codec have to be defined formally
>
> Ben: what's the level of support in your community?
>
> Tessa: We have support from both communities.
>
> Ben: Will the community be active in the process?
>
> Tessa: based on the outcome on this meeting.
>
> Mary: There sounds like there's interest. We need people from IETF willing
> to contribute - who is willing to review and provide input? Raise hands.
>
> 2 people.
>
> Alissa: I'd like to clarify - who would review?
>
> Cullen: please raise hands
>
> 8-10 people
>
> robux4,from Jabber: Matroska actually stands on top of EBML which can be
> used for a lot of other storage, just like a binary XML.
>
> Dave Rice, from Jabber: discussions on working on FFV1 within the IETF
> context starting in discussion on listservs in 2012. Matroska has an RFC
> Draft from 2004 (unfortunately this work wasn't completed, but there is
> sincere support to move forward with this now)
>
> Richard: I'm not seeing folks interested in netvc in this room. They should
> be asked.
>
> Mary: Take it to the list. Sounds like there's interest.  ACTION.
>
>
>
> 09:45-10:15 (30m)
> GeoJSON____________________________________________________________
> Presentation:
> Presenter:  Sean Gillies
> Charter: https://github.com/geojson/draft-geojson/blob/master/charter.md
> Document:   draft-butler-geojson
>
> slide 1: Title
>
> slide 2: GeoJSON
>
> slide 3: Status
>
> slide 4: Proposed Charter
>
> slide 5: Refinements
>
> slide 6: Coordinate Precision
>
> slide 7: Undefined Elevation
>
> slide 8: Anti-Meridian
>
> slide 9: Timestamps
>
> slide 10: High Volume
>
> slide 11: Extensibility
>
> slide 12: Geopriv
>
> slide 13: Other Groups
>
> slide 14: Docs
>
> RjS: on Geopriv - who did the analysis? did it happen on list?
>
> Sean: On dispatch list. The original geoJSON creators are from the OGC and
> they are ignorant of geopriv.
>
> RjS: Depends on the context about whether they are location objects. PIDFs
> and PIDF-LOs take location and policy rules. On extensibility - adding
> policy rules would allow adding geopriv into this format.
>
> Alissa: I looked at this spec and I looked at geo URI. What you can do with
> geo URI, you have to have some other protocol to specify location. This
> seemed very similar, this says this is a point. If you want to say something
> lives at this point, then it's a geo URI object. Extending it could change
> things.
>
> Richard: I did a similar analysis. There's a distinction between location
> description and location object. The privacy applies to objects. This is a
> layer down, like the geo URI.
>
> RjS: We chose not to ask the geo URI to encode some of the location object,
> because not feasible, but I think you can do all sorts of encoding here.
> There's a interesting conversation here - would this carry a location
> object, or would a location object carry this?
>
> Mary: There had been interest in this at the previous meeting.
>
> Roger Marshall: I support the work, I think it's important.
>
> Alissa: Geopriv is closed. We are not opening it back up.
>
> Mary: we may charter a new WG for this.
>
> Roger: this seems like this can talk about layers, and multiple points and
> features.
>
> Sean: yes. It's about talking about ensembles of features. A collection that
> provides extra context. GeoJSON seems to be down stream of geopriv.
>
> Henning: We're talking about 3 different things in mapping. One is a map - a
> geographic area - can render in GeoJSOn
>
> Sean: yes
>
> Henning: We have developed constrained objects - for PSAPs, uncertainty area
> of an object. It could be a GIS layer, but it's not part of a GIS system.
> 3rd - a realtime description with geographic properties, generalization of a
> point. ...
>
> Sean: fair to say.
>
> Richard: This is a layer down from geopriv. It describes location of a
> thing. But geoJSON can describe where lots of things are or city areas, and
> those have different privacy considerations.
>
> Mary: who would sign up on ML, read docs, provide comments?
>
> A few hands ACTION: Post on dispatch and geopriv, which is still open.
>
> Lennox: I'm glad we don't have ask if this goes in Apps or RAI.
>
>
>
> 10:15-10:35 (20m) Location source
> parameter__________________________________________
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-0.pdf
> Presenter:  Andrew Hutton
> Document:   draft-winterbottom-dispatch-locparam-00
>
> slide 1: Title
>
> slide 2: General Principle
>
> slide 3: Issues
>
> slide 4: Who Wants It?
>
> Cullen, from floor: On the trusted domain, we defined a spec-t which is
> required. I've never seen a spec-T doc delivered ever. All privacy bets are
> off in an emergency call. I don't think the trust domain concept  has
> worked.
>
> Conrad: The trust domain works. We're requiring this to satisfy regulations.
>
> Mary: Would people like to work on this, or is this is specific to the
> M/493? This would have gone to the sipping or geopriv.
>
> Alissa: Or ecrit.
>
> Andy: The use case is.
>
> Cullen: would this be used in a situation that is not an emergency call?
>
> Andy: it could be used when it's defined.
>
> [e-mail], from Jabber: why doesn't the url of the lis tell you
> the source of the location data anyway?
>
> Andy: It could be a PIDF-LO. Not sure that's true.
>
> Alissa: If you want this used out of the emergency content, you don't get
> the pass anymore on the privacy.
>
> Andy: The only use case I'm aware of is emergency.
>
> Mary: Who has read the draft?
>
> Handful
>
> Mary: Could be used outside of emergency services.
>
> Andy: ...
>
> Ben: Let's worry about the use cases we have in mind first.
>
> Alissa: Ask the authors to take the feedback here under advisement. And rev
> a draft ACTION.
>
>
>
> 10:35-10:55 (20m) Via header field parm for received
> realm____________________________
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-1.pdf
> Presenter:  Christer Holmberg
> Document:   draft-holmberg-dispatch-received-realm-00
>
> slide 1: Title
>
> slide 2: Problem
>
> slide 3: Solution
>
> Adam: this was an off the cuff solution, probably something better than this
> if we do this work.
>
> slide 4: Example
>
> slide 5: Why Not Look at the Vias?
>
> Andrew allen: They may have been tokenized by an SBC.
>
> slide 6: Suggestion
>
> Christer: I think this should be AD sponsor.
>
> Cullen: why did it go to sipcore and come out.
>
> Adam, as chair: our charter is narrow, and this isn't a core change. We
> would need to recharter to take this on. I'm game to have this conversation.
>
> Ben: I would say this should be AD sponsor, but if it needs work from more
> than just the authors. Need to make sure the input on authentication.
>
> Adam: if we had one sec guy look at it.
>
> Cullen: RAI sec advisor to review. sipcore ML? ACTION:
>
> Adam: I'm ok with that.
>
> Ben: Just need a good shepherd.
>
> Adam: send me email Christer. ACTION.
>
> Discuss with security to see if can be AD sponsored first. ACTION:
>
> slide 7: The End
>
>
>
>
> 10:55-11:25 (30m) SLIM
> charter____________________________________________________
> Presentation:
> https://www.ietf.org/proceedings/93/slides/slides-93-dispatch-2.pdf
> Presenter:  Randell Gellens
> Charter:    https://datatracker.ietf.org/wg/slim/charter/
>
> slide 1: Title
>
> slide 2: Real-Time Language Negotiation
>
> slide 3: Proposal
>
> slide 4: (show proposed charter)
>
> Mary: Is Bernard ok with this? (Bernard not in the room)
>
> Randy: not at the lunch. He's on the email.
>
> Cullen: anyone share Bernard's concern?
>
> Henning: We had overlapping concerns. This covers mine. If there's routing
> work to be done, the chairs would allow discussion on it. It helps if we
> have rough notion of big picture.
>
> Randy: That's why it says "won't focus", not out of scope.
>
> Christer: My concern was about a new attribute, and the charter doesn't
> discuss it. If you say, "won't focus". Have to make the decision on whether
> it's used for routing or not, and it changes the mechanism. If we assume SIP
> entities don't understand this, but we have caller prefs.
>
> Barry: the chairs should allow enough discussion to move ahead properly to
> routing discussions. The charter text allows the chairs more flexibility.
> Propose text if we need to change it.
>
> Christer: I'm fine to discuss, if someone brings a solution that supports
> routing, can't sweep aside because the charter says we're not doing it.
>
> Ben: I don't think the charter says go away if you want to talk about
> routing. The only reason the chairs would say "Go away" is that they are not
> ready to talk about it yet.
>
> Paul Kyzivat, from Jabber: is there any doubt that, lacking anything else,
> the labeling *will* be used for routing?
>
> Henning: I'll submit draft that will be usable for common use cases based on
> my experience with caller prefs.
>
> Cullen: People thinking that routing will end up in this group.
>
> Barry: Maybe we can tweak charter wording, get specific wording changes in
> right now.
>
> Randy: We'll recharter.
>
> Ben: Just say won't focus on routing now, but later. Not sure we need to
> trigger a recharter.
>
> Barry: agree. ACTION. Discuss on the SLIM ML. ACTION.
>
> Mary: Anything else?
>
> Ted: QIC protocol bar bof this evening in Congress I.
>
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch



-- 
Steve Lhomme
Matroska association Chairman