Subject: [dispatch] More verbose notes from Dispatch 93

From: "A. Jean Mahoney" <[email-masked]>
Date: Wed, 22 Jul 2015 16:41:36 +0200

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 
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.

[email-masked], 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.

---

From: Steve Lhomme <[email-masked]>
Date: Sat, 25 Jul 2015 08:47:38 +0200

On Wed, Jul 22, 2015 at 4:41 PM, A. Jean Mahoney <[email-masked]> wrote:
> 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.
>
> 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
>
> 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.
>
> completely internet based but maybe later. We want transparency, open source
> and openness. We would like to go through IETF.
>
> 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.
>

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
>
> 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)
>
> Ben, as individual: You've come here because of our openness and open spec.
> But you can put it out somewhere yourself.
>
> Ben: You don't need the IETF for publishing. We might be able to help with
> technical work. Does it need technical help?
>
> 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?
>
> 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
> 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.
>
> 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
>
> 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.
>
> Richard: I'm not seeing folks interested in netvc in this room. They should
> be asked.
>
> 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?
>
> 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.
>
> thing. But geoJSON can describe where lots of things are or city areas, and
> those have different privacy considerations.
>
> 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.
>
> [email-masked], from Jabber: why doesn't the url of the lis tell you
> the source of the location data anyway?
>
> Alissa: If you want this used out of the emergency content, you don't get
> the pass anymore on the privacy.
>
> Alissa: Ask the authors to take the feedback here under advisement. And rev
> a draft ACTION.
>
>
>
> Adam: this was an off the cuff solution, probably something better than this
> if we do this work.
>
> slide 4: Example
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Barry: Maybe we can tweak charter wording, get specific wording changes in
> right now.
>
> Randy: We'll recharter.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
Steve Lhomme
Matroska association Chairman

---

From: Michael Niedermayer <[email-masked]>
Date: Sat, 25 Jul 2015 12:53:12 +0200

On Wed, Jul 22, 2015 at 04:41:36PM +0200, A. Jean Mahoney wrote:
[...]
> 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.
> 
> 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.
> 
> 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.

As the original author of FFV1. Same here indeed, ive participated
in getting the ffv1 spec into better shape over the previous
weeks/months and will continue to participate in standarization
efforts wherever they are going to happen

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato