[dispatch] More verbose notes from Dispatch 93
"A. Jean Mahoney" <mahoney@nostrum.com> Wed, 22 July 2015 14:41 UTC
Return-Path: <mahoney@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11351A87C2 for <dispatch@ietfa.amsl.com>; Wed, 22 Jul 2015 07:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lltwY-E4yglK for <dispatch@ietfa.amsl.com>; Wed, 22 Jul 2015 07:41:41 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92C91B2E02 for <dispatch@ietf.org>; Wed, 22 Jul 2015 07:41:39 -0700 (PDT)
Received: from dhcp-8c60.meeting.ietf.org (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6MEfb9T057551 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dispatch@ietf.org>; Wed, 22 Jul 2015 09:41:38 -0500 (CDT) (envelope-from mahoney@nostrum.com)
To: dispatch@ietf.org
From: "A. Jean Mahoney" <mahoney@nostrum.com>
Message-ID: <55AFABA0.20601@nostrum.com>
Date: Wed, 22 Jul 2015 16:41:36 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/AXQrkQ71xqerlwyaDUqX6Q-whZM>
Subject: [dispatch] More verbose notes from Dispatch 93
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 14:41:44 -0000
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. jon-ietf@jabber.org, 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] More verbose notes from Dispatch 93 A. Jean Mahoney
- Re: [dispatch] More verbose notes from Dispatch 93 Steve Lhomme
- Re: [dispatch] More verbose notes from Dispatch 93 Michael Niedermayer