From nobody Wed Sep 2 05:21:09 2015 Return-Path: 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 DF26D1B39CB; Wed, 2 Sep 2015 05:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.663 X-Spam-Level: X-Spam-Status: No, score=0.663 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 4L_BD0m-LXuf; Wed, 2 Sep 2015 05:21:06 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 210231B32E2; Wed, 2 Sep 2015 05:21:06 -0700 (PDT) Received: from [IPv6:2602:61:753a:ca00:3875:3a56:d1fa:6aa] (unknown [IPv6:2602:61:753a:ca00:3875:3a56:d1fa:6aa]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 366FC203C5; Wed, 2 Sep 2015 14:21:04 +0200 (CEST) To: ice@ietf.org Followup-To: ice@ietf.org From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <55E6E9AE.7080400@acm.org> Date: Wed, 2 Sep 2015 06:21:02 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: DISPATCH list , "mmusic@ietf.org" Subject: [dispatch] New version of the proposed charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 12:21:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Please find below a new version of the proposed charter, trying to take in account all the comments so far. The discussions are taking place in the ice mailing-list, please do not cross-post. Thanks. - --------------------------------------------------------------------------------- Charter for Working Group Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. ICE was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including a multiplicity of IP addresses and ports in both the request and response messages of a connectivity establishment transaction. The IP addresses and ports provided by each side are paired and tested by peer-to-peer connectivity checks until one of these pair is selected to transport data. ICE follows the end to end principle where the clients themselves discovers, test and choose the network path to use. It makes no assumptions regarding network topology on the local or remote side. ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocol have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940). The goal of the ICE Working Group is to consolidate the various initiatives to update ICE to make it more suitable for the WebRTC environment but also to all the current usages of ICE. ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronised with the work in this working group. Synching with other network related working groups to make sure existing mechanisms like QoS, congestion control and other networking mechanisms still work would be essential if we want to improve how ICE works (MIF, TAPS, TSWG, HOMENET, etc...). From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be essential (RTCWEB, HIP, MMUSIC, P2PSIP). Milestones Jun 2016 Submit Dual-stack Fairness with ICE as Proposed Standard Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard Jan 2016 Submit Trickle ICE as Proposed Standard - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV5umuAAoJECnERZXWan7Ec9AQANIImmE2JC98QoBfq5MEGa01 w8gfLivIXT/Vx5BW3sGHQTv24dznMbwhMGKGwlizGYU0olgxGqc2VasogmvNrD5J 9PwMOHPzPxJe5rIVHMseiN8mk8DtPKVPmDoBZZt1T9ehP2yajYjRys9uFKwZiqhx +WJF6rxl/eRxmV6oF41m4VSs/UiN7inTMc8mnKvfi6TLdpInELiKHgnb6VxeW1N+ N6JU7TnG4MVYzUVTLPh5Di8BTCWVthOTqFEwJaGw8gcNA8ATDtx+XbTR2dAv3u0x WLzNep25LRcukn7UyPQaCZWaptIlqJJzzPit3w+oCuJlc5KTRv/SoODJuR1j4pS9 Lxj0ShAMwSCSfFg3MWIUP19+iE7QZcibh9WWHCY3LZWzOMD2uqLiIuH/OcJbwoIE c7kcd/m9oOxU0NWYNUYBIhFWbX5fg/bIeW+D3uQN9P9HDscs2XpWlwsL1M6ad2mC YtA0Mzd4E7PT18Q37eRcVcVeUBF+AF1gpqkUoBXKnZUTiUxIs8nORP9cLpywFaBz JhjganbYvvgDbPS6gnCSlQbMDlofpTWygfA8FT1FJ94wolv2pcPIH09ofDRYO8zM 5fqZuDkD9BFCKCuFzm/hxyeZTaHDB0pfe+wLN5Eccll06G7pOcMjR/8Q4SiR1l3Q LCNPefFKYJgT/SFpbL6k =3YsX -----END PGP SIGNATURE----- From nobody Thu Sep 3 04:15:23 2015 Return-Path: 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 184E41AC40B; Thu, 3 Sep 2015 04:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cI_IvhUTYTWr; Thu, 3 Sep 2015 04:15:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 378F01A212A; Thu, 3 Sep 2015 04:15:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> Date: Thu, 03 Sep 2015 04:15:19 -0700 Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, dret@berkeley.edu Subject: [dispatch] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 11:15:21 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-geojson-00-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- This seems like a fine thing to do, but I have one concern I'd like to chat about before we go ahead. I could buy the "no privacy issues here" argument except for the last sentence which says: "As the WG considers extensibility it will be careful not to preclude extensions that would allow GeoJSON objects to become location objects unless the group determines such extensibility would be harmful." Aside from being hard to parse, that seems to mean that some extensions could mean this format does become a RFC6280 Location object, which would then bring in the privacy and security issues, previously argued to be out of scope. I think that's a contradiction. As it happens, I also think that, despite folks best efforts, RFC6280 isn't an architecture that worked out that well, so I'd not suggest that this wG try emulate that with square brackets. Instead, I'd suggest that this WG be chartered to never take on work with does have security or privacy consequences (without a re-charter). That'd maybe mean a change in the last sentence such as: OLD: As the WG considers extensibility it will be careful not to preclude extensions that would allow GeoJSON objects to become location objects unless the group determines such extensibility would be harmful. NEW: In order to continue to validly avoid having to deal with the security and privacy issues that would arise, this WG will not define any extensions that would have the effect of making a geojson object an RFC6280 location object or location information as defined by RFC3693. Should such an extension be needed, re-chartering will be required. My propsed NEW text is very clunky so probably needs improving. From nobody Thu Sep 3 05:23:50 2015 Return-Path: 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 A49341A6F9A for ; Thu, 3 Sep 2015 05:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 AbDQliMiTHSV for ; Thu, 3 Sep 2015 05:23:43 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9521B31F1 for ; Thu, 3 Sep 2015 05:23:41 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BC5C02074D for ; Thu, 3 Sep 2015 08:23:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 03 Sep 2015 08:23:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=yQhP8sT1yI/VoDpoLqLhbzIKSiI=; b=CrEViw mUeqfqcwSNd59MyARfT1zeMC+x8uEYKslN0vFRXM3mVjlJBAEzs01NZcSs9upkiR AYWCMaked/DqGipSp1z7E+L/GCe+0O5rDKwcjvX2MZLo09uXpksfiXBfsiZqNCla LfJZdDoTE2nYBIQAhUK88z8vKmPmIS4z+dvMU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yQhP8sT1yI/VoDp oLqLhbzIKSiI=; b=V6RSpTgSfGOJLBf9H++IbXSho5rC0kM1rgEDHrzaSq8RrXT KBWCHOGnPkdEiH9jcu0W4xgOybfNeVjTOKW6hZyChBdw0USMbTPF8xah2S7zk8zx R0fNPz4oRiVyUNlSZOeVnrn+7Nf6bs1a/aqFNGlusgspIbyXnOV2yEH6I8ao= X-Sasl-enc: D7v90Xj1AQfmZC37Svi8Z1Vu9xeQ9602ae5Pz36RI0X7 1441283020 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id DBCE0C0028F; Thu, 3 Sep 2015 08:23:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> Date: Thu, 3 Sep 2015 05:23:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: geopriv@ietf.org, Erik Wilde , dispatch@ietf.org, IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 12:23:44 -0000 Hi Stephen, > On Sep 3, 2015, at 4:15 AM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > charter-ietf-geojson-00-01: Block >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-geojson/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 >=20 > This seems like a fine thing to do, but I have one=20 > concern I'd like to chat about before we go ahead. >=20 > I could buy the "no privacy issues here" argument except > for the last sentence which says: "As the WG considers > extensibility it will be careful not to preclude > extensions that would allow GeoJSON objects to become > location objects unless the group determines such > extensibility would be harmful." Aside from being hard to > parse, that seems to mean that some extensions could mean > this format does become a RFC6280 Location object, which > would then bring in the privacy and security issues, > previously argued to be out of scope. Maybe this is a verb tense problem, but I think the points of the entire = paragraph in question are:=20 1) the format the group intends to create is for representation of = things that are not location objects 2) even so, depending on how the format is specified, it may be possible = for them to get used in ways in which they become location objects, in = which case the privacy and security considerations kick in 3) in defining how to make the format extensible, the group does not = want to preclude (2) in the future, but=20 4) the group will not be defining specific extensions to achieve (2). Here is a re-phrase that tries to capture this better: The WG will be careful to craft its extensibility mechanism such that = extensions that would allow GeoJSON objects to become location objects = are not precluded, but will not be defining such extensions itself. = Should such an extension be needed, re-chartering will be required. Is that better? Alissa > I think that's a > contradiction. As it happens, I also think that, despite > folks best efforts, RFC6280 isn't an architecture that > worked out that well, so I'd not suggest that this wG try > emulate that with square brackets. Instead, I'd suggest > that this WG be chartered to never take on work with does > have security or privacy consequences (without a > re-charter).=20 >=20 > That'd maybe mean a change in the last sentence such as: >=20 > OLD: >=20 > As the WG considers extensibility it will be careful > not to preclude extensions that would allow GeoJSON > objects to become location objects unless the group > determines such extensibility would be harmful.=20 >=20 > NEW: >=20 > In order to continue to validly avoid having to deal > with the security and privacy issues that would arise, > this WG will not define any extensions that would have > the effect of making a geojson object an RFC6280 > location object or location information as defined by > RFC3693. Should such an extension be needed, > re-chartering will be required. >=20 > My propsed NEW text is very clunky so probably needs > improving. >=20 >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From nobody Thu Sep 3 05:31:47 2015 Return-Path: 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 508331AD0C3; Thu, 3 Sep 2015 05:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 8Cdh2gfvxcX3; Thu, 3 Sep 2015 05:31:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9B01B3CCF; Thu, 3 Sep 2015 05:28:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 332B3BE49; Thu, 3 Sep 2015 13:28:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlnK7iNkObfK; Thu, 3 Sep 2015 13:28:47 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9DF3BBE54; Thu, 3 Sep 2015 13:28:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441283327; bh=vjlWcFb378yG1Muloz9F96zzbOgLS8ez3eoB6oFmuLs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hy49P9MI4jDbxJbopeRJ968v7uJNJXskXDtmnpiiro6Ta89pNLrqezm9PaLA/fTff Z1jIOsvucb/Sw6vePpT8mZsaKmC6GlUgblrK1nuutFW4r3XtJZ8Jx1hr/lCoShhRNo MFLu0YAMI7xcN++PWSYTYKOS2B2T+5uEnJTzhFgQ= To: Alissa Cooper References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E83CFF.1040508@cs.tcd.ie> Date: Thu, 3 Sep 2015 13:28:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 12:31:45 -0000 Hiya, On 03/09/15 13:23, Alissa Cooper wrote: > Hi Stephen, > >> On Sep 3, 2015, at 4:15 AM, Stephen Farrell >> wrote: >> >> Stephen Farrell has entered the following ballot position for >> charter-ietf-geojson-00-01: Block >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found >> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >> >> >> >> ---------------------------------------------------------------------- >> >> BLOCK: >> ---------------------------------------------------------------------- >> >> >> >> This seems like a fine thing to do, but I have one >> concern I'd like to chat about before we go ahead. >> >> I could buy the "no privacy issues here" argument except for the >> last sentence which says: "As the WG considers extensibility it >> will be careful not to preclude extensions that would allow GeoJSON >> objects to become location objects unless the group determines >> such extensibility would be harmful." Aside from being hard to >> parse, that seems to mean that some extensions could mean this >> format does become a RFC6280 Location object, which would then >> bring in the privacy and security issues, previously argued to be >> out of scope. > > Maybe this is a verb tense problem, but I think the points of the > entire paragraph in question are: > > 1) the format the group intends to create is for representation of > things that are not location objects 2) even so, depending on how the > format is specified, it may be possible for them to get used in ways > in which they become location objects, in which case the privacy and > security considerations kick in 3) in defining how to make the format > extensible, the group does not want to preclude (2) in the future, > but 4) the group will not be defining specific extensions to achieve > (2). > > Here is a re-phrase that tries to capture this better: > > The WG will be careful to craft its extensibility mechanism such that > extensions that would allow GeoJSON objects to become location > objects are not precluded, but will not be defining such extensions > itself. Should such an extension be needed, re-chartering will be > required. > > Is that better? Yes. Definitely clearer. However, the "not precluded" is a bit troubling still. Let me try get to it this way - in the following timeline who/when would address the security/privacy issues and how'd we be confident that'd really happen? t1: This WG does it's planned stuff. t2: The foo-protocol uses geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't consider security/privacy as geojson doesn't create location objects t3: This WG defines how to annotate a location with an identity thus creating location objects Ta, S. > > Alissa > >> I think that's a contradiction. As it happens, I also think that, >> despite folks best efforts, RFC6280 isn't an architecture that >> worked out that well, so I'd not suggest that this wG try emulate >> that with square brackets. Instead, I'd suggest that this WG be >> chartered to never take on work with does have security or privacy >> consequences (without a re-charter). >> >> That'd maybe mean a change in the last sentence such as: >> >> OLD: >> >> As the WG considers extensibility it will be careful not to >> preclude extensions that would allow GeoJSON objects to become >> location objects unless the group determines such extensibility >> would be harmful. >> >> NEW: >> >> In order to continue to validly avoid having to deal with the >> security and privacy issues that would arise, this WG will not >> define any extensions that would have the effect of making a >> geojson object an RFC6280 location object or location information >> as defined by RFC3693. Should such an extension be needed, >> re-chartering will be required. >> >> My propsed NEW text is very clunky so probably needs improving. >> >> >> >> >> _______________________________________________ Geopriv mailing >> list Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > From nobody Thu Sep 3 05:48:54 2015 Return-Path: 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 7964F1B41FF; Thu, 3 Sep 2015 05:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Y8PBMchvBSgk; Thu, 3 Sep 2015 05:48:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FEC1B37BC; Thu, 3 Sep 2015 05:48:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903124848.27481.42289.idtracker@ietfa.amsl.com> Date: Thu, 03 Sep 2015 05:48:48 -0700 Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, dret@berkeley.edu Subject: [dispatch] Benoit Claise's No Objection on charter-ietf-geojson-00-01: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 12:48:49 -0000 Benoit Claise has entered the following ballot position for charter-ietf-geojson-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One readability improvement. So many RFC numbers I have to lookup, in this charter: 5870, 7464, 3693, 6280. Sorry I don't know them all by heart. A good convention is name + RFC, such as "JavaScript Object Notation (JSON) [RFC7159]" I guess it's a short-lived WG, right? Two deliverables and then closed, right? Would be worth mentioning IMO. In the milestones, that would be fine. From nobody Thu Sep 3 06:14:09 2015 Return-Path: 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 5F95A1B3DB2 for ; Thu, 3 Sep 2015 06:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 ob6BxIY-Fbpp for ; Thu, 3 Sep 2015 06:14:06 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86191B3A0D for ; Thu, 3 Sep 2015 06:14:05 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5ED5020425 for ; Thu, 3 Sep 2015 09:14:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 03 Sep 2015 09:14:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=flGfQVtNxdAzeH4ezdBTEH3oEhc=; b=Whjz1G eeWBVm6kwM1IjOMGXsSOLZ3iULD81yKED8G1+YTps+BnlgM0QUwbSM0PFPWXjA6l AppfWUFwk/Imc4TIFrDKpDWkvAdSQ/ilCN7GQewM9lS474HZSrV49peOVEdsgkzs MfpGs+xhAlQnW3XkspeHqxQmE/EbHs29RF6M8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=flGfQVtNxdAzeH4 ezdBTEH3oEhc=; b=m86UITeufYrhDxQosJjYrYHaOYovJ8jewzgJwAXSU1lGiM0 axBAJQO9n31AkOVUY2j0yyd9yZGh62XswkcZg6obzBKBRip5ouKt74WZ1LBa4amt 1WQ1hFtGsOKRSjHDZNBzTntTSGBotUNMcX9jP8NowFIwD6ww2zUrS3mHU92Y= X-Sasl-enc: EScDKc8l+Djj2vyce5xNRlJS6J25v1+67jFKG6FvavUu 1441286043 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 75B77C00287; Thu, 3 Sep 2015 09:14:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <55E83CFF.1040508@cs.tcd.ie> Date: Thu, 3 Sep 2015 06:14:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 13:14:08 -0000 > On Sep 3, 2015, at 5:28 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 03/09/15 13:23, Alissa Cooper wrote: >> Hi Stephen, >>=20 >>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell >>> wrote: >>>=20 >>> Stephen Farrell has entered the following ballot position for=20 >>> charter-ietf-geojson-00-01: Block >>>=20 >>> When responding, please keep the subject line intact and reply to >>> all email addresses included in the To and CC lines. (Feel free to >>> cut this introductory paragraph, however.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found >>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 > BLOCK: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 > This seems like a fine thing to do, but I have one >>> concern I'd like to chat about before we go ahead. >>>=20 >>> I could buy the "no privacy issues here" argument except for the >>> last sentence which says: "As the WG considers extensibility it >>> will be careful not to preclude extensions that would allow GeoJSON >>> objects to become location objects unless the group determines >>> such extensibility would be harmful." Aside from being hard to=20 >>> parse, that seems to mean that some extensions could mean this >>> format does become a RFC6280 Location object, which would then >>> bring in the privacy and security issues, previously argued to be >>> out of scope. >>=20 >> Maybe this is a verb tense problem, but I think the points of the >> entire paragraph in question are: >>=20 >> 1) the format the group intends to create is for representation of >> things that are not location objects 2) even so, depending on how the >> format is specified, it may be possible for them to get used in ways >> in which they become location objects, in which case the privacy and >> security considerations kick in 3) in defining how to make the format >> extensible, the group does not want to preclude (2) in the future, >> but 4) the group will not be defining specific extensions to achieve >> (2). >>=20 >> Here is a re-phrase that tries to capture this better: >>=20 >> The WG will be careful to craft its extensibility mechanism such that >> extensions that would allow GeoJSON objects to become location >> objects are not precluded, but will not be defining such extensions >> itself. Should such an extension be needed, re-chartering will be >> required. >>=20 >> Is that better? >=20 > Yes. Definitely clearer. >=20 > However, the "not precluded" is a bit troubling still. I think the thing is that you don=E2=80=99t want to specify this format = such that it could never describe the location of a person or a device, = because that would be an a priori limiting constraint on its utility. So = the point is to leave the door open via the extensibility mechanism, but = not design specific extensions to do this (unless there=E2=80=99s a = re-charter). >=20 > Let me try get to it this way - in the following timeline who/when > would address the security/privacy issues and how'd we be confident > that'd really happen? >=20 > t1: This WG does it's planned stuff. > t2: The foo-protocol uses geojson in a PDU (and the bar protocol etc.) > The foo-wg doesn't consider security/privacy as geojson doesn't > create location objects I think consideration for privacy/security could happen at t2 depending = on how the foo-protocol uses the geojson object. So in this case we = would rely on the remit of the foo-wg (this is the "When a GeoJSON = object is used in a context where it identifies the location of a Target = =E2=80=A6=E2=80=9D sentence). > t3: This WG defines how to annotate a location with an identity > thus creating location objects Then certainly at t3 the geojson WG would address privacy/security. And = this would be after re-charter. Alissa >=20 > Ta, > S. >=20 >=20 >=20 >>=20 >> Alissa >>=20 >>> I think that's a contradiction. As it happens, I also think that, >>> despite folks best efforts, RFC6280 isn't an architecture that=20 >>> worked out that well, so I'd not suggest that this wG try emulate >>> that with square brackets. Instead, I'd suggest that this WG be >>> chartered to never take on work with does have security or privacy >>> consequences (without a re-charter). >>>=20 >>> That'd maybe mean a change in the last sentence such as: >>>=20 >>> OLD: >>>=20 >>> As the WG considers extensibility it will be careful not to >>> preclude extensions that would allow GeoJSON objects to become >>> location objects unless the group determines such extensibility >>> would be harmful. >>>=20 >>> NEW: >>>=20 >>> In order to continue to validly avoid having to deal with the >>> security and privacy issues that would arise, this WG will not >>> define any extensions that would have the effect of making a >>> geojson object an RFC6280 location object or location information >>> as defined by RFC3693. Should such an extension be needed,=20 >>> re-chartering will be required. >>>=20 >>> My propsed NEW text is very clunky so probably needs improving. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ Geopriv mailing >>> list Geopriv@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/geopriv >>=20 From nobody Thu Sep 3 06:19:54 2015 Return-Path: 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 07AF21B4993; Thu, 3 Sep 2015 06:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 p8Zl5CaLaOa7; Thu, 3 Sep 2015 06:19:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209D31B46A0; Thu, 3 Sep 2015 06:19:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC94ABE77; Thu, 3 Sep 2015 14:19:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMRnX5Wreg1c; Thu, 3 Sep 2015 14:19:31 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8F98DBE4D; Thu, 3 Sep 2015 14:19:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441286371; bh=QVP/TqNQRHm1/6lHW2sW/uXjXuAMumae8/tsE+C51HQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4ohivpHcwaq/oIvW1Qd9sMSViPAtToFJgn5WMigluVI/xc9o5SOEc7c2RzWqHnAtr mHFLG8iUazr0ZEyyEmSQ1R8nQDcIzgrkZ5bDI71S5amQruQA6wa8xCS9G731RVCJ6I okdaOitcXG/92qitL0OIqsv7Krd3PLuo5vnPS6r8= To: Alissa Cooper References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E848E3.10403@cs.tcd.ie> Date: Thu, 3 Sep 2015 14:19:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 13:19:53 -0000 scroll on down... On 03/09/15 14:14, Alissa Cooper wrote: > >> On Sep 3, 2015, at 5:28 AM, Stephen Farrell >> wrote: >> >> >> Hiya, >> >> On 03/09/15 13:23, Alissa Cooper wrote: >>> Hi Stephen, >>> >>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell >>>> wrote: >>>> >>>> Stephen Farrell has entered the following ballot position for >>>> charter-ietf-geojson-00-01: Block >>>> >>>> When responding, please keep the subject line intact and reply >>>> to all email addresses included in the To and CC lines. (Feel >>>> free to cut this introductory paragraph, however.) >>>> >>>> >>>> >>>> The document, along with other ballot positions, can be found >>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> >> >>>> BLOCK: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> >>>> >> >>>> This seems like a fine thing to do, but I have one >>>> concern I'd like to chat about before we go ahead. >>>> >>>> I could buy the "no privacy issues here" argument except for >>>> the last sentence which says: "As the WG considers >>>> extensibility it will be careful not to preclude extensions >>>> that would allow GeoJSON objects to become location objects >>>> unless the group determines such extensibility would be >>>> harmful." Aside from being hard to parse, that seems to mean >>>> that some extensions could mean this format does become a >>>> RFC6280 Location object, which would then bring in the privacy >>>> and security issues, previously argued to be out of scope. >>> >>> Maybe this is a verb tense problem, but I think the points of >>> the entire paragraph in question are: >>> >>> 1) the format the group intends to create is for representation >>> of things that are not location objects 2) even so, depending on >>> how the format is specified, it may be possible for them to get >>> used in ways in which they become location objects, in which case >>> the privacy and security considerations kick in 3) in defining >>> how to make the format extensible, the group does not want to >>> preclude (2) in the future, but 4) the group will not be defining >>> specific extensions to achieve (2). >>> >>> Here is a re-phrase that tries to capture this better: >>> >>> The WG will be careful to craft its extensibility mechanism such >>> that extensions that would allow GeoJSON objects to become >>> location objects are not precluded, but will not be defining such >>> extensions itself. Should such an extension be needed, >>> re-chartering will be required. >>> >>> Is that better? >> >> Yes. Definitely clearer. >> >> However, the "not precluded" is a bit troubling still. > > I think the thing is that you don’t want to specify this format such > that it could never describe the location of a person or a device, > because that would be an a priori limiting constraint on its utility. > So the point is to leave the door open via the extensibility > mechanism, but not design specific extensions to do this (unless > there’s a re-charter). > >> >> Let me try get to it this way - in the following timeline who/when >> would address the security/privacy issues and how'd we be >> confident that'd really happen? >> >> t1: This WG does it's planned stuff. t2: The foo-protocol uses >> geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't >> consider security/privacy as geojson doesn't create location >> objects > > I think consideration for privacy/security could happen at t2 > depending on how the foo-protocol uses the geojson object. So in this > case we would rely on the remit of the foo-wg (this is the "When a > GeoJSON object is used in a context where it identifies the location > of a Target …” sentence). But at t2, the foo-wg doesn't know that a geojson object can e.g. include my photo or FB name or whatever so they can't take that into account. > >> t3: This WG defines how to annotate a location with an identity >> thus creating location objects > > Then certainly at t3 the geojson WG would address privacy/security. > And this would be after re-charter. Even if that re-charter says to consider the foo-protocol and the bar-protocol, it'd likely be too late to handle things well. On balance I think I'd argue that this charter would be better to just say "no security/privacy stuff needed" (as it currentlyu does) but to not get into extensibility and how that might affect privacy at all. Cheers, S. > > Alissa > >> >> Ta, S. >> >> >> >>> >>> Alissa >>> >>>> I think that's a contradiction. As it happens, I also think >>>> that, despite folks best efforts, RFC6280 isn't an architecture >>>> that worked out that well, so I'd not suggest that this wG try >>>> emulate that with square brackets. Instead, I'd suggest that >>>> this WG be chartered to never take on work with does have >>>> security or privacy consequences (without a re-charter). >>>> >>>> That'd maybe mean a change in the last sentence such as: >>>> >>>> OLD: >>>> >>>> As the WG considers extensibility it will be careful not to >>>> preclude extensions that would allow GeoJSON objects to become >>>> location objects unless the group determines such >>>> extensibility would be harmful. >>>> >>>> NEW: >>>> >>>> In order to continue to validly avoid having to deal with the >>>> security and privacy issues that would arise, this WG will not >>>> define any extensions that would have the effect of making a >>>> geojson object an RFC6280 location object or location >>>> information as defined by RFC3693. Should such an extension be >>>> needed, re-chartering will be required. >>>> >>>> My propsed NEW text is very clunky so probably needs >>>> improving. >>>> >>>> >>>> >>>> >>>> _______________________________________________ Geopriv >>>> mailing list Geopriv@ietf.org >>>> https://www.ietf.org/mailman/listinfo/geopriv >>> > From nobody Thu Sep 3 07:52:57 2015 Return-Path: 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 A31AD1B45E2; Thu, 3 Sep 2015 07:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 r0WlIJ_dcAJl; Thu, 3 Sep 2015 07:52:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FCE1A8BC0; Thu, 3 Sep 2015 07:52:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903145252.4721.11362.idtracker@ietfa.amsl.com> Date: Thu, 03 Sep 2015 07:52:52 -0700 Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, dret@berkeley.edu Subject: [dispatch] Stephen Farrell's No Objection on charter-ietf-geojson-00-01: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:52:54 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-geojson-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- please fix last sentence From nobody Thu Sep 3 07:58:20 2015 Return-Path: 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 A48C61B2DED for ; Thu, 3 Sep 2015 07:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 btyBeKstmifT for ; Thu, 3 Sep 2015 07:58:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAD41B4A43 for ; Thu, 3 Sep 2015 07:57:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CB6A723E72 for ; Thu, 3 Sep 2015 10:57:44 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 03 Sep 2015 10:57:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=bpgUz0jPb4JrCMv6oHEM9wwvGVE=; b=T8INSU jYa7R16SEcz0H85KdjUgOworSbYqOMFH4RM5Kidcn7Bgk4dQkuFdhULAhW91+mU6 famK3meurP+KQRMYQfSqRHB4RDvVwc5wY3I55Z05LmaM0TZnMZBY+a8dZMUV1c1E Tx+kZxjqDi9oLcxrxMS0oap+mBrSg3oG2CIOM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=bpgUz0jPb4JrCMv 6oHEM9wwvGVE=; b=pxy40wmOGtf40ZxJ1VF6uGb3239WkX+U5iWhRFlMHUSTIoz bw3yWnAXSXTsCdkL8YDyou1T43YnGLf+IyrpBZwxWB/+5+9XftlF/NpPUusr9bCM njfqZY66oGeCqyxaERbYa2oYXPgSOIa1YYLmEG7UvueExTn9bccYNqBVD7nw= X-Sasl-enc: MLJ3ZXb7KtNES/lqfr1xYJOWPtl5Wwn10I7FizAEZeAP 1441292264 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id E413FC00286; Thu, 3 Sep 2015 10:57:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <55E848E3.10403@cs.tcd.ie> Date: Thu, 3 Sep 2015 07:57:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:58:11 -0000 Suggestion below. > On Sep 3, 2015, at 6:19 AM, Stephen Farrell = wrote: >=20 >=20 > scroll on down... >=20 > On 03/09/15 14:14, Alissa Cooper wrote: >>=20 >>> On Sep 3, 2015, at 5:28 AM, Stephen Farrell >>> wrote: >>>=20 >>>=20 >>> Hiya, >>>=20 >>> On 03/09/15 13:23, Alissa Cooper wrote: >>>> Hi Stephen, >>>>=20 >>>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell=20 >>>>> wrote: >>>>>=20 >>>>> Stephen Farrell has entered the following ballot position for=20 >>>>> charter-ietf-geojson-00-01: Block >>>>>=20 >>>>> When responding, please keep the subject line intact and reply >>>>> to all email addresses included in the To and CC lines. (Feel >>>>> free to cut this introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found=20 >>>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>=20 >>>>>=20 > BLOCK: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>>>=20 > This seems like a fine thing to do, but I have one >>>>> concern I'd like to chat about before we go ahead. >>>>>=20 >>>>> I could buy the "no privacy issues here" argument except for >>>>> the last sentence which says: "As the WG considers >>>>> extensibility it will be careful not to preclude extensions >>>>> that would allow GeoJSON objects to become location objects >>>>> unless the group determines such extensibility would be >>>>> harmful." Aside from being hard to parse, that seems to mean >>>>> that some extensions could mean this format does become a >>>>> RFC6280 Location object, which would then bring in the privacy >>>>> and security issues, previously argued to be out of scope. >>>>=20 >>>> Maybe this is a verb tense problem, but I think the points of >>>> the entire paragraph in question are: >>>>=20 >>>> 1) the format the group intends to create is for representation >>>> of things that are not location objects 2) even so, depending on >>>> how the format is specified, it may be possible for them to get >>>> used in ways in which they become location objects, in which case >>>> the privacy and security considerations kick in 3) in defining >>>> how to make the format extensible, the group does not want to >>>> preclude (2) in the future, but 4) the group will not be defining >>>> specific extensions to achieve (2). >>>>=20 >>>> Here is a re-phrase that tries to capture this better: >>>>=20 >>>> The WG will be careful to craft its extensibility mechanism such >>>> that extensions that would allow GeoJSON objects to become >>>> location objects are not precluded, but will not be defining such >>>> extensions itself. Should such an extension be needed, >>>> re-chartering will be required. >>>>=20 >>>> Is that better? >>>=20 >>> Yes. Definitely clearer. >>>=20 >>> However, the "not precluded" is a bit troubling still. >>=20 >> I think the thing is that you don=E2=80=99t want to specify this = format such >> that it could never describe the location of a person or a device, >> because that would be an a priori limiting constraint on its utility. >> So the point is to leave the door open via the extensibility >> mechanism, but not design specific extensions to do this (unless >> there=E2=80=99s a re-charter). >>=20 >>>=20 >>> Let me try get to it this way - in the following timeline who/when=20= >>> would address the security/privacy issues and how'd we be >>> confident that'd really happen? >>>=20 >>> t1: This WG does it's planned stuff. t2: The foo-protocol uses >>> geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't >>> consider security/privacy as geojson doesn't create location >>> objects >>=20 >> I think consideration for privacy/security could happen at t2 >> depending on how the foo-protocol uses the geojson object. So in this >> case we would rely on the remit of the foo-wg (this is the "When a >> GeoJSON object is used in a context where it identifies the location >> of a Target =E2=80=A6=E2=80=9D sentence). >=20 > But at t2, the foo-wg doesn't know that a geojson object can e.g. > include my photo or FB name or whatever so they can't take that > into account. >=20 >>=20 >>> t3: This WG defines how to annotate a location with an identity=20 >>> thus creating location objects >>=20 >> Then certainly at t3 the geojson WG would address privacy/security. >> And this would be after re-charter. >=20 > Even if that re-charter says to consider the foo-protocol and > the bar-protocol, it'd likely be too late to handle things well. >=20 > On balance I think I'd argue that this charter would be better to > just say "no security/privacy stuff needed" (as it currentlyu does) > but to not get into extensibility and how that might affect privacy > at all. How about this? OLD As the WG considers extensibility it will be careful not to preclude extensions that would allow GeoJSON objects to become location = objects unless the group determines such extensibility would be harmful. NEW Should extensions that would allow GeoJSON objects to become location = objects be needed, re-chartering will be required. Alissa >=20 > Cheers, > S. >=20 >=20 >>=20 >> Alissa >>=20 >>>=20 >>> Ta, S. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Alissa >>>>=20 >>>>> I think that's a contradiction. As it happens, I also think >>>>> that, despite folks best efforts, RFC6280 isn't an architecture >>>>> that worked out that well, so I'd not suggest that this wG try >>>>> emulate that with square brackets. Instead, I'd suggest that >>>>> this WG be chartered to never take on work with does have >>>>> security or privacy consequences (without a re-charter). >>>>>=20 >>>>> That'd maybe mean a change in the last sentence such as: >>>>>=20 >>>>> OLD: >>>>>=20 >>>>> As the WG considers extensibility it will be careful not to=20 >>>>> preclude extensions that would allow GeoJSON objects to become=20 >>>>> location objects unless the group determines such >>>>> extensibility would be harmful. >>>>>=20 >>>>> NEW: >>>>>=20 >>>>> In order to continue to validly avoid having to deal with the=20 >>>>> security and privacy issues that would arise, this WG will not=20 >>>>> define any extensions that would have the effect of making a=20 >>>>> geojson object an RFC6280 location object or location >>>>> information as defined by RFC3693. Should such an extension be >>>>> needed, re-chartering will be required. >>>>>=20 >>>>> My propsed NEW text is very clunky so probably needs >>>>> improving. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ Geopriv >>>>> mailing list Geopriv@ietf.org=20 >>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>=20 >>=20 From nobody Thu Sep 3 08:00:31 2015 Return-Path: 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 78F7A1ACEE7; Thu, 3 Sep 2015 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 l0FxZXslqEBd; Thu, 3 Sep 2015 08:00:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A7D1B40CA; Thu, 3 Sep 2015 07:58:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B532EBE47; Thu, 3 Sep 2015 15:58:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BCH7Tj2IrkN; Thu, 3 Sep 2015 15:58:47 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 87324BE3F; Thu, 3 Sep 2015 15:58:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441292327; bh=i+H/d4ewV/YK+pfz/fm/HcircBFlf9o+MNTMMP/Xhhk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dhvOwdqIz1m2rF7qCxBXYg2HWEBXTr45XPAvj8SZL0bwNsd91vc2JRB7QcpgDdl2a 43kzIm/gInL9Oky232grfxFdca4WbO61VLB5hwivv7cFvvzP1N/yJUNLIWfagJ9+0u szzTrXlkHFHZjb8KxElF4aQdsyEM9/kOsdxl5ZbQ= To: Alissa Cooper References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E86027.9050903@cs.tcd.ie> Date: Thu, 3 Sep 2015 15:58:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:00:25 -0000 Better again. You could maybe add that's not expected to happen during the lifetime of this wg but that'd be fine. S On 03/09/15 15:57, Alissa Cooper wrote: > NEW Should extensions that would allow GeoJSON objects to become > location objects be needed, re-chartering will be required. From nobody Thu Sep 3 08:03:25 2015 Return-Path: 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 E58CC1B499B for ; Thu, 3 Sep 2015 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 5CscWChw7HvS for ; Thu, 3 Sep 2015 08:03:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7171B393D for ; Thu, 3 Sep 2015 08:02:55 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 07C8E24313 for ; Thu, 3 Sep 2015 11:02:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 03 Sep 2015 11:02:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=f5E7gSdKUOWk0ZxxLmGTj0CAe9k=; b=3qo2JZ PJMPwsxU1hbV+XHtB7K+MwxsMFe7sYIQvvbieWBOQwP+3bVfqpOejqjmL3qtyT5r Zu10Fi1UxuNx6rUcPM1zMMce56G5O4+2qLDbDT3ogHvoyWepB/cMxmldQvP3yi3H uXFW2f9HXDRsRpwqCGtgyMHdBxtZTifgmcCs4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=f5E7gSdKUOWk0Zx xLmGTj0CAe9k=; b=tysIjyF5pGocG2wMTN8D0PIAuZlo3nJ++oy2l1uoK35tUhg 4SokebwiDtm81qOt+c8xWyy9+OmjegiUJi1nBPhiYVV+EBFtApXqYP5vdFgoj7z5 LmoH2AwQ4iaDBrJr7bx67ih4EjkTJ7JJC0iykkISBeygVhz8SDnpr446DXTM= X-Sasl-enc: Hw0dEYv2CMUv4tg4wGqHPvQg/CjRI7ZSQHUZ1d+AhATZ 1441292574 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 323B1C0028A; Thu, 3 Sep 2015 11:02:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <55E86027.9050903@cs.tcd.ie> Date: Thu, 3 Sep 2015 08:02:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:03:08 -0000 Ok, one more try and we=E2=80=99re there I think: OLD As the WG considers extensibility it will be careful not to preclude extensions that would allow GeoJSON objects to become location = objects unless the group determines such extensibility would be harmful. NEW Extensions that would allow GeoJSON objects to become location objects = are not expected to be defined in the WG. Should that be needed, = re-chartering will be required. > On Sep 3, 2015, at 7:58 AM, Stephen Farrell = wrote: >=20 >=20 > Better again. You could maybe add that's not expected to happen > during the lifetime of this wg but that'd be fine. >=20 > S >=20 > On 03/09/15 15:57, Alissa Cooper wrote: >> NEW Should extensions that would allow GeoJSON objects to become >> location objects be needed, re-chartering will be required. From nobody Thu Sep 3 08:03:52 2015 Return-Path: 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 9A1531B49C6; Thu, 3 Sep 2015 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 OmE2-9m-c3uT; Thu, 3 Sep 2015 08:03:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F7A1B38C2; Thu, 3 Sep 2015 08:03:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93CE4BE47; Thu, 3 Sep 2015 16:03:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jGhs1sFbhX1; Thu, 3 Sep 2015 16:03:20 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E209BE59; Thu, 3 Sep 2015 16:03:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441292600; bh=cQ2Y6RIwKWBu3fMg+lPl2sTg3CXivYT8FZiuHb+jcyA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jWQpvSMttERsiMixLbCVTXdggcIfuypLL6mwB3Mte2UVo2EmIIJSmrk0MUZNCi05C HvloSU3xqyc04Gq9sYD49J8cHmIWsVHBQ1kiU1TpF+T156XnOsccAhLln0kWXACVVS Vl098JCrZh3mPDXdcOqgttQvJ1EAZaWEAn8h/Xf0= To: Alissa Cooper References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E86137.4090103@cs.tcd.ie> Date: Thu, 3 Sep 2015 16:03:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:03:38 -0000 Lovely. Thanks, S. On 03/09/15 16:02, Alissa Cooper wrote: > Ok, one more try and we’re there I think: > > OLD > As the WG considers extensibility it will be careful not to > preclude extensions that would allow GeoJSON objects to become location objects > unless the group determines such extensibility would be harmful. > > NEW > Extensions that would allow GeoJSON objects to become location objects are not expected to be defined in the WG. Should that be needed, re-chartering will be required. > >> On Sep 3, 2015, at 7:58 AM, Stephen Farrell wrote: >> >> >> Better again. You could maybe add that's not expected to happen >> during the lifetime of this wg but that'd be fine. >> >> S >> >> On 03/09/15 15:57, Alissa Cooper wrote: >>> NEW Should extensions that would allow GeoJSON objects to become >>> location objects be needed, re-chartering will be required. > From nobody Thu Sep 3 08:49:40 2015 Return-Path: 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 AE6A51B3BE3 for ; Thu, 3 Sep 2015 08:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 iooBABv1gmja for ; Thu, 3 Sep 2015 08:49:36 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AAC1B3D3E for ; Thu, 3 Sep 2015 08:49:27 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-09v.sys.comcast.net with comcast id Cfox1r0032Ka2Q501fpS5s; Thu, 03 Sep 2015 15:49:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id CfpS1r00D3Ge9ey01fpSP1; Thu, 03 Sep 2015 15:49:26 +0000 To: dispatch@ietf.org References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> From: Paul Kyzivat Message-ID: <55E86C05.7020103@alum.mit.edu> Date: Thu, 3 Sep 2015 11:49:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1441295366; bh=MR95TqD+GJvbRYbvYBypx3hWX3bo9kFGX95QKIZWZdE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bKsuBMwdrT5nrnMyjAvSx04gZozcWN87PWe7bXnEFp1AdrIC7lPSJUMfYeJQftocG KnIHAvZ0KsRmrvFXU8U3Rk21HtPj7n6oBC3dZLA9QuhRWNBfLm+bKxKBsolsTyGCsr JoNumMjlVq6iwsLMwQy9XkmJbqnRJOaDRmM48UrHzupP3f+ze+jG9/Rt0Ev+s7HPcP 4U726hYEEBgX5Vhe57VL2LgytTK9i9sA6v8ausfPrP+O9HJMPoPTBR6Mt5IJQ1AUTv NZxqv/alYnPnnUPZMCXo0GL9hnjVFHFBV0fBj9t9LHNjTWvUTXa+U9u0xiu8LSuUWd X7yaxnpfKOHyg== Archived-At: Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:49:38 -0000 I have been following this discussion, but haven't been able to make sense of it. :-( IIUC, the question is how to restrict GeoJSON so that it can't be used to represent Location Objects (loosely as defined in RF6280) because it doesn't have a way to include Privacy Rules. ISTM that this is an *impossible* goal. If you pass a representation of a geographic location where a target might be, then it may be possible for that location to be associated with a target contextually. This may be true without the knowledge of the sending application. (And possibly even without the knowledge of the receiving application.) The relationship may be inferred via complex data mining. For that matter, even the statement of the goal is problematic. In 6280 LO is defined as "location information together with Privacy Rules". I guess GeoJSON doesn't aspire to represent privacy rules, but I don't see how doing so would be a problem. Perhaps the goal should be to forbid a GeoJSON object from *containing* a representation of a *target* (as defined in 6280). This would not prevent a target from being associated with it contextually, but at least the users will not need to consider what might be *within* the GeoJSON object when analyzing whether there are privacy concerns. Thanks, Paul On 9/3/15 10:57 AM, Alissa Cooper wrote: > Suggestion below. > >> On Sep 3, 2015, at 6:19 AM, Stephen Farrell wrote: >> >> >> scroll on down... >> >> On 03/09/15 14:14, Alissa Cooper wrote: >>> >>>> On Sep 3, 2015, at 5:28 AM, Stephen Farrell >>>> wrote: >>>> >>>> >>>> Hiya, >>>> >>>> On 03/09/15 13:23, Alissa Cooper wrote: >>>>> Hi Stephen, >>>>> >>>>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell >>>>>> wrote: >>>>>> >>>>>> Stephen Farrell has entered the following ballot position for >>>>>> charter-ietf-geojson-00-01: Block >>>>>> >>>>>> When responding, please keep the subject line intact and reply >>>>>> to all email addresses included in the To and CC lines. (Feel >>>>>> free to cut this introductory paragraph, however.) >>>>>> >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found >>>>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>> >>>>>> >> BLOCK: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>>> >> This seems like a fine thing to do, but I have one >>>>>> concern I'd like to chat about before we go ahead. >>>>>> >>>>>> I could buy the "no privacy issues here" argument except for >>>>>> the last sentence which says: "As the WG considers >>>>>> extensibility it will be careful not to preclude extensions >>>>>> that would allow GeoJSON objects to become location objects >>>>>> unless the group determines such extensibility would be >>>>>> harmful." Aside from being hard to parse, that seems to mean >>>>>> that some extensions could mean this format does become a >>>>>> RFC6280 Location object, which would then bring in the privacy >>>>>> and security issues, previously argued to be out of scope. >>>>> >>>>> Maybe this is a verb tense problem, but I think the points of >>>>> the entire paragraph in question are: >>>>> >>>>> 1) the format the group intends to create is for representation >>>>> of things that are not location objects 2) even so, depending on >>>>> how the format is specified, it may be possible for them to get >>>>> used in ways in which they become location objects, in which case >>>>> the privacy and security considerations kick in 3) in defining >>>>> how to make the format extensible, the group does not want to >>>>> preclude (2) in the future, but 4) the group will not be defining >>>>> specific extensions to achieve (2). >>>>> >>>>> Here is a re-phrase that tries to capture this better: >>>>> >>>>> The WG will be careful to craft its extensibility mechanism such >>>>> that extensions that would allow GeoJSON objects to become >>>>> location objects are not precluded, but will not be defining such >>>>> extensions itself. Should such an extension be needed, >>>>> re-chartering will be required. >>>>> >>>>> Is that better? >>>> >>>> Yes. Definitely clearer. >>>> >>>> However, the "not precluded" is a bit troubling still. >>> >>> I think the thing is that you don’t want to specify this format such >>> that it could never describe the location of a person or a device, >>> because that would be an a priori limiting constraint on its utility. >>> So the point is to leave the door open via the extensibility >>> mechanism, but not design specific extensions to do this (unless >>> there’s a re-charter). >>> >>>> >>>> Let me try get to it this way - in the following timeline who/when >>>> would address the security/privacy issues and how'd we be >>>> confident that'd really happen? >>>> >>>> t1: This WG does it's planned stuff. t2: The foo-protocol uses >>>> geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't >>>> consider security/privacy as geojson doesn't create location >>>> objects >>> >>> I think consideration for privacy/security could happen at t2 >>> depending on how the foo-protocol uses the geojson object. So in this >>> case we would rely on the remit of the foo-wg (this is the "When a >>> GeoJSON object is used in a context where it identifies the location >>> of a Target …” sentence). >> >> But at t2, the foo-wg doesn't know that a geojson object can e.g. >> include my photo or FB name or whatever so they can't take that >> into account. >> >>> >>>> t3: This WG defines how to annotate a location with an identity >>>> thus creating location objects >>> >>> Then certainly at t3 the geojson WG would address privacy/security. >>> And this would be after re-charter. >> >> Even if that re-charter says to consider the foo-protocol and >> the bar-protocol, it'd likely be too late to handle things well. >> >> On balance I think I'd argue that this charter would be better to >> just say "no security/privacy stuff needed" (as it currentlyu does) >> but to not get into extensibility and how that might affect privacy >> at all. > > How about this? > > OLD > As the WG considers extensibility it will be careful not to > preclude extensions that would allow GeoJSON objects to become location objects > unless the group determines such extensibility would be harmful. > > NEW > Should extensions that would allow GeoJSON objects to become location objects be needed, re-chartering will be required. > > Alissa > >> >> Cheers, >> S. >> >> >>> >>> Alissa >>> >>>> >>>> Ta, S. >>>> >>>> >>>> >>>>> >>>>> Alissa >>>>> >>>>>> I think that's a contradiction. As it happens, I also think >>>>>> that, despite folks best efforts, RFC6280 isn't an architecture >>>>>> that worked out that well, so I'd not suggest that this wG try >>>>>> emulate that with square brackets. Instead, I'd suggest that >>>>>> this WG be chartered to never take on work with does have >>>>>> security or privacy consequences (without a re-charter). >>>>>> >>>>>> That'd maybe mean a change in the last sentence such as: >>>>>> >>>>>> OLD: >>>>>> >>>>>> As the WG considers extensibility it will be careful not to >>>>>> preclude extensions that would allow GeoJSON objects to become >>>>>> location objects unless the group determines such >>>>>> extensibility would be harmful. >>>>>> >>>>>> NEW: >>>>>> >>>>>> In order to continue to validly avoid having to deal with the >>>>>> security and privacy issues that would arise, this WG will not >>>>>> define any extensions that would have the effect of making a >>>>>> geojson object an RFC6280 location object or location >>>>>> information as defined by RFC3693. Should such an extension be >>>>>> needed, re-chartering will be required. >>>>>> >>>>>> My propsed NEW text is very clunky so probably needs >>>>>> improving. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ Geopriv >>>>>> mailing list Geopriv@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>> >>> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Sep 3 09:10:21 2015 Return-Path: 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 36CD41AD0C5; Thu, 3 Sep 2015 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_TVD_FUZZY_SECURITIES=0.01] autolearn=no 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 2ITW4p0Lt1-Y; Thu, 3 Sep 2015 08:56:22 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 52E521B4217; Thu, 3 Sep 2015 08:56:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 1440F9416D; Thu, 3 Sep 2015 11:56:21 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aElr7ZkI6lrF; Thu, 3 Sep 2015 11:56:20 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTPS id 3BD849416C; Thu, 3 Sep 2015 11:56:20 -0400 (EDT) Received: from mail2.standardsmail.org (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTPS id 2ED61EEB22B; Thu, 3 Sep 2015 11:56:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 1D134EEB225; Thu, 3 Sep 2015 11:56:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FP6L90vTj7sL; Thu, 3 Sep 2015 11:56:20 -0400 (EDT) Received: from OfficeHP (c-67-176-39-130.hsd1.co.comcast.net [67.176.39.130]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 724A1EEB203; Thu, 3 Sep 2015 11:56:19 -0400 (EDT) Message-ID: From: "Carl Reed" To: "Alissa Cooper" , "Stephen Farrell" References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> In-Reply-To: <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> Date: Thu, 3 Sep 2015 09:51:54 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 03 Sep 2015 09:10:20 -0700 Cc: geopriv@ietf.org, Scott Simmons , dispatch@ietf.org, Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:56:24 -0000 Sorry to jump in. I have now read the entire thread, reviewed the charter= ,=20 and reviewed a number of RFCs on this topic (starting with 4119). Been a=20 while! Before starting, I wish to state that I am not opposed to this WG=20 activity - GeoJSON is an important spec and one now being used in OGC=20 standards work as informational. I just have some concerns. In my mind, there is perhaps a more fundamental question: What is a Locat= ion=20 Object? Back with the LO activity first started, the focus was on extendi= ng=20 PIDF to include location content. From that perspective, privacy and=20 location are closely coupled. However, over time the use of the location=20 object became uncoupled from PIDF and as a result a number of other RFCs = now=20 speak to how to use a LO with SIP, RADIUS, and so on. Essentially, a LO c= an=20 also be viewed as a stand alone package of location content with addition= al=20 attributes such as uncertainty. When I worked on these RFC, I never viewe= d=20 LO as being tightly coupled with privacy but always viewed the LO as a da= ta=20 package that could be used with any number of other standards/specs or ev= en=20 as a standard alone payload. This is exactly what has happened. Don't get= me=20 wrong - the privacy implications associated with location are critical - = and=20 scary. Predictive analytics experiments have shown that future individual= =20 movement activity can be predicted with close to 95% accuracy by analyzin= g=20 past movement behavior (a joint Harvard/MIT study). Therefore, I would suggest that a GeoJSON encoded payload is a location=20 object. Consider that the PIDF-LO geodetic model is encoded using GML. Th= e=20 abstract model for geometry used in GML is ISO 19107: Spatial Schema (whi= ch=20 is now in revision). The GeoJSON geometry model is also based on ISO 1910= 7.=20 The main difference between the two (other than the LO requirement for=20 additional geometry types) is that GeoJSON encodes coordinates as=20 longitude/latitude. GML encodes coordinates as latitude-longitude. There = are=20 also differences in how other coordinate reference systems are handled.=20 While these differences are properly documented, I would strongly encoura= ge=20 the planned activity to consider: 1. Documenting the relationship (similarities and differences) between=20 GeoJSON and a LO. This would allow developers to choose the appropriate=20 implementation approach. 2. Have a section on threat analysis and security 3. Speak to how privacy issues could be addressed (back to item 1 also). Perhaps I am being overly sensitive but location and privacy (along with=20 provenance and uncertainty) are coming to the fore as major standards=20 issues. The OGC is working these standards related issues more and more.=20 Much of this is being driven by requirements to use location content=20 associated "citizens as scientists" activities, volunteered geographic=20 information, IoT, Smart Cities, and on and on. I know the GeoJSON authors do not wish to "overload" the GeoJSON spec. As= =20 such, I suspect many of my concerns could be easily addressed by referenc= ing=20 appropriate content from existing IETF RFCs. For example, the content of=20 7459 Uncertainty and Confidence is quite appropriate for a GeoJSON encodi= ng.=20 Also, 7459 was reviewed and commented on by OGC Members :-) Sorry for the long posting. Regards Carl Reed Geospatial Standards geek -----Original Message-----=20 From: Alissa Cooper Sent: Thursday, September 03, 2015 9:02 AM To: Stephen Farrell Cc: geopriv@ietf.org ; dispatch@ietf.org ; Erik Wilde ; IESG Subject: Re: [Geopriv] Stephen Farrell's Block on=20 charter-ietf-geojson-00-01: (with BLOCK) Ok, one more try and we=E2=80=99re there I think: OLD As the WG considers extensibility it will be careful not to preclude extensions that would allow GeoJSON objects to become location=20 objects unless the group determines such extensibility would be harmful. NEW Extensions that would allow GeoJSON objects to become location objects ar= e=20 not expected to be defined in the WG. Should that be needed, re-charterin= g=20 will be required. > On Sep 3, 2015, at 7:58 AM, Stephen Farrell = =20 > wrote: > > > Better again. You could maybe add that's not expected to happen > during the lifetime of this wg but that'd be fine. > > S > > On 03/09/15 15:57, Alissa Cooper wrote: >> NEW Should extensions that would allow GeoJSON objects to become >> location objects be needed, re-chartering will be required. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv=20 From nobody Thu Sep 3 09:30:33 2015 Return-Path: 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 E745B1A8AAD; Thu, 3 Sep 2015 09:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 FC3H7rSrp33C; Thu, 3 Sep 2015 09:15:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:681]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023B91B4118; Thu, 3 Sep 2015 09:14:58 -0700 (PDT) Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1838.namprd06.prod.outlook.com (10.162.133.16) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 3 Sep 2015 16:14:53 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) with mapi id 15.01.0256.013; Thu, 3 Sep 2015 16:14:53 +0000 From: Robin Wilton To: Stephen Farrell Thread-Topic: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) Thread-Index: AQHQ5kNjKgDEk3QDnEeIRF1iY9ipIJ4qu6KAgAAMpACAAAGIgIAAG28AgAAAToCAAAElgIAAAB+AgAAT7QA= Date: Thu, 3 Sep 2015 16:14:53 +0000 Message-ID: References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> <55E86137.4090103@cs.tcd.ie> In-Reply-To: <55E86137.4090103@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.174.34.240] x-microsoft-exchange-diagnostics: 1; SN1PR06MB1838; 5:0u2826gLj9qA0WGeqa9o34I+B6FxCts1eXtA1QJ3veUoYu0GnxXX9Hg3Km5ttjTOkdEvaLgMVocfc6D64LPrUtR2IrTsXaVHRjf2mlQK+b2wITwJA4oGi83uq6qOqUwHNQm51bcpu2oLkg1M+tGm4A==; 24:aqzgLyTEeB5cl0MJqkOEtPlFgV/1XKOAECYMG+fpCaatxjwIk8OUZdxF3iMA3zhLNhKineeDcpy1LkorWcKjaOPn+LCHZrFscmJP4gqPQUc=; 20:f/gttgbLNrxSIjlSCMPkPob/HRo+lP9B14URFuJMfcB1IiJWgVqol6dmsCNIK9I1uyTmmTYr48rG7AfASZyo2w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1838; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:SN1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1838; x-forefront-prvs: 0688BF9B46 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(252514010)(24454002)(377454003)(479174004)(189002)(164054003)(199003)(5001860100001)(66066001)(230783001)(5001830100001)(64706001)(16236675004)(101416001)(68736005)(15975445007)(99936001)(77096005)(102836002)(189998001)(36756003)(97736004)(81156007)(33656002)(4001540100001)(76176999)(40100003)(99286002)(19580405001)(19580395003)(5002640100001)(10400500002)(105586002)(106356001)(106116001)(86362001)(82746002)(62966003)(46102003)(5001960100002)(2950100001)(54356999)(110136002)(50986999)(87936001)(2900100001)(93886004)(5004730100002)(5007970100001)(92566002)(83716003)(77156002)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1838; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_FFC9DF87-E5EA-48A3-A86C-C490433FB122"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2015 16:14:53.0385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1838 Archived-At: X-Mailman-Approved-At: Thu, 03 Sep 2015 09:30:31 -0700 Cc: "geopriv@ietf.org geopriv@ietf.org" , "dispatch@ietf.org" , Erik Wilde , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 16:15:15 -0000 --Apple-Mail=_FFC9DF87-E5EA-48A3-A86C-C490433FB122 Content-Type: multipart/alternative; boundary="Apple-Mail=_1300D827-14A9-45C9-891D-785314F6CFCD" --Apple-Mail=_1300D827-14A9-45C9-891D-785314F6CFCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry, only just seen this thread - but I have read back through the = dialogue. I don=92t want to propose a change to the final suggested text, but I = would like to check an assumption (of mine) about privacy risk. In one of his replies, Stephen gave a timeline to illustrate how = something might be developed in compliance with the GeoJSON spec and = *not*, in itself, give rise to privacy concerns, but might subsequently = be extended/modified in such a way *did* give rise to privacy concerns. The assumption I wanted to check was this: I assume (having been through = a similar cycle in another standards development context) that this is = another instance of a recurring problem - namely, that if you design = specs to be =93composable=94, you have to deal with the possibility that = one apparently innocuous element could be combined with another element = in ways that make it more harmful. The question then is, what level of = (in this case privacy-related) warning/disclaimer should you put on the = element that, on its own, is harmless. As I say, I don=92t want to change the text proposed, just to check if = the problem, here, is of the species I=92ve described above. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 3 Sep 2015, at 16:03, Stephen Farrell = wrote: >=20 > Lovely. >=20 > Thanks, > S. >=20 > On 03/09/15 16:02, Alissa Cooper wrote: >> Ok, one more try and we=92re there I think: >>=20 >> OLD >> As the WG considers extensibility it will be careful not to >> preclude extensions that would allow GeoJSON objects to become = location objects >> unless the group determines such extensibility would be harmful. >>=20 >> NEW >> Extensions that would allow GeoJSON objects to become location = objects are not expected to be defined in the WG. Should that be needed, = re-chartering will be required. >>=20 >>> On Sep 3, 2015, at 7:58 AM, Stephen Farrell = wrote: >>>=20 >>>=20 >>> Better again. You could maybe add that's not expected to happen >>> during the lifetime of this wg but that'd be fine. >>>=20 >>> S >>>=20 >>> On 03/09/15 15:57, Alissa Cooper wrote: >>>> NEW Should extensions that would allow GeoJSON objects to become >>>> location objects be needed, re-chartering will be required. >>=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail=_1300D827-14A9-45C9-891D-785314F6CFCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Sorry, = only just seen this thread - but I have read back through the = dialogue. 

I don=92t want to propose a change to = the final suggested text, but I would like to check an assumption (of = mine) about privacy risk.

In one of his = replies, Stephen gave a timeline to illustrate how something might be = developed in compliance with the GeoJSON spec and *not*, in itself, give = rise to privacy concerns, but might subsequently be extended/modified in = such a way *did* give rise to privacy = concerns.

The assumption I wanted to check was = this: I assume (having been through a similar cycle in another standards = development context) that this is another instance of a recurring = problem - namely, that if you design specs to be =93composable=94, you = have to deal with the possibility that one apparently innocuous element = could be combined with another element in ways that make it more = harmful. The question then is, what level of (in this case = privacy-related) warning/disclaimer should you put on the element that, = on its own, is harmless.

As I say, I don=92t = want to change the text proposed, just to check if the problem, here, is = of the species I=92ve described = above.

Yrs.,
Robin 

Robin Wilton
Technical = Outreach Director - Identity and Privacy
Internet = Society

email: wilton@isoc.org
Phone: +44 705 = 005 2931
Twitter: @futureidentity

On 3 Sep 2015, at 16:03, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:


Lovely.

Thanks,
S.

On 03/09/15 16:02, = Alissa Cooper wrote:
Ok, one more try and = we=92re there I think:

OLD
As the WG considers extensibility = it will be careful not to
preclude extensions that would allow = GeoJSON objects to become location objects
unless the group = determines such extensibility would be harmful.

NEW
Extensions = that would allow GeoJSON objects to become location objects are not = expected to be defined in the WG. Should that be needed, re-chartering = will be required.

On Sep 3, 2015, at = 7:58 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:


Better again. You could maybe add that's not = expected to happen
during the lifetime of this wg but that'd be = fine.

S

On 03/09/15 15:57, Alissa Cooper = wrote:
NEW Should extensions that would = allow GeoJSON objects to become
location objects be needed, = re-chartering will be = required.


______________= _________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.= org/mailman/listinfo/geopriv

= = --Apple-Mail=_1300D827-14A9-45C9-891D-785314F6CFCD-- --Apple-Mail=_FFC9DF87-E5EA-48A3-A86C-C490433FB122 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlXocfMACgkQx1kEWLxmyT1suwCgjPo0l5VqdVkAn/ka3ukH2aMk zFMAnA6j8nYViBylPQ0ZwupzDbkyLJpl =mtH6 -----END PGP SIGNATURE----- --Apple-Mail=_FFC9DF87-E5EA-48A3-A86C-C490433FB122-- From nobody Thu Sep 3 10:34:03 2015 Return-Path: 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 D761F1B34F2 for ; Thu, 3 Sep 2015 10:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.132 X-Spam-Level: X-Spam-Status: No, score=-81.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL=20, USER_IN_WHITELIST=-100] autolearn=no 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 faIk70rvC95Y for ; Thu, 3 Sep 2015 10:34:00 -0700 (PDT) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFC61B4B55 for ; Thu, 3 Sep 2015 10:33:48 -0700 (PDT) Received: from [151.252.65.81] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 14456397 for dispatch@ietf.org; Thu, 03 Sep 2015 20:33:46 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Thu, 03 Sep 2015 22:33:15 +0500 MIME-Version: 1.0 Message-ID: <55E8845B.10457.14E9DDA9@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Antivirus: avast! (VPS 150901-0, 01.09.2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 17:34:02 -0000 Dear All, I want to discuss new ideas. This is a new version of my draft. I will insist on it. I'm sure this is not the final version - references need to check. I don't know if I need comparison with RFC 3891, or should I remove any reference to it. Some text is commented out of XML. ------- Forwarded message follows ------- From: internet-drafts@ietf.org To: "Anton Tveretin" , "Anton Tveretin" Subject: New Version Notification for draft-tveretin-dispatch-remote-01.txt Date sent: Tue, 01 Sep 2015 12:33:38 -0700 A new version of I-D, draft-tveretin-dispatch-remote-01.txt has been successfully submitted by Anton Tveretin and posted to the IETF repository. Name: draft-tveretin-dispatch-remote Revision: 01 Title: Remote Call Control and Call Pick-up in SIP Document date: 2015-09-01 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-01.txt Status: https://datatracker.ietf.org/doc/draft-tveretin-dispatch-remote/ Htmlized: https://tools.ietf.org/html/draft-tveretin-dispatch-remote-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-tveretin-dispatch-remote-01 Abstract: This memo defines a mechanism by which a SIP user agent could inspect calls at another user agent, and control a call, including picking up for itself. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------- End of forwarded message ------- From nobody Thu Sep 3 12:22:39 2015 Return-Path: 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 3F9DE1ACDD1 for ; Thu, 3 Sep 2015 12:22:38 -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 Ng7GY5wYeIek for ; Thu, 3 Sep 2015 12:22:37 -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 0C1001ACD1C for ; Thu, 3 Sep 2015 12:22:37 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t83JMYNO082286 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Sep 2015 14:22:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Paul Kyzivat , dispatch@ietf.org References: <55E8845B.10457.14E9DDA9@fas_vm.surguttel.ru> <55E88E2B.7030006@alum.mit.edu> From: Adam Roach Message-ID: <55E89DF9.9080707@nostrum.com> Date: Thu, 3 Sep 2015 14:22:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E88E2B.7030006@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 19:22:38 -0000 On 9/3/15 13:15, Paul Kyzivat wrote: > On 9/3/15 1:33 PM, Anton Tveretin wrote: >> Dear All, >> I want to discuss new ideas. This is a new version of my draft. I >> will insist on it. > > Insist on what? > >> I'm sure this is >> not the final version - references need to check. I don't know if I >> need comparison with RFC >> 3891, or should I remove any reference to it. Some text is commented >> out of XML. > > I would expect to see *much* more in the Security Considerations > section. This functionality could be used to do lots of bad things. > There should be a discussion of the threats and how they can be mitigated. The thing is, we've already gone through this exercise, including the security analysis to make sure it's safe to deploy. The comparison here isn't against just RFC 3891; it's against the entire call-control framework that we invested thousands of engineering hours in developing and publishing. Reading and really understanding the philosophy of RFC5850 will go a long way towards explaining how this kind of call control needs to work. In my opinion, the bullet list in section 1 of RFC5850 is some of the most important text ever written on the topic of SIP. /a From nobody Mon Sep 7 06:34:16 2015 Return-Path: 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 164501A8748 for ; Mon, 7 Sep 2015 06:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 4TfSeaETYJqg for ; Mon, 7 Sep 2015 06:34:10 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301E01A904B for ; Mon, 7 Sep 2015 06:34:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6FE51210DB for ; Mon, 7 Sep 2015 09:34:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 07 Sep 2015 09:34:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=KeDpLlFq7j9Q/Lt7mp91h8TBFLA=; b=woZISK JkK2y0tDAlvR48QQoVTtjtWACY43tWlZuaJtSJ6z29HrTBfO2/lttWg4skcuClOs iX0s/3l+Uz7psEHKQ1dT+HxEZ0kMoFA8j9hfdZWItdDPD4NZT58/byxm67GaRO+7 NWt+tLiii9aNTpRC3oaUYq2+XiAP3BO7PZK9w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=KeDpLlFq7j9Q/Lt 7mp91h8TBFLA=; b=a9Xyc7wxgFpp/FrLSdfel6SdPhd88HcFagrdOyrMebju0Ev zoDjWJRT6Z81VxaHURZ2AmsqDh7VAnc4wxTk84mGSz2GGtATykbVMOaPTS5Xdx4B S+KP3bYLkJZHzjZ3KJQfYNVFyy4D2sGJ+dnDbgdmOFsSZRWICK7y7+e9rmRk= X-Sasl-enc: nx3nDRK3KNbv5JuwiMcMTMKuThItHu9g4+wM3NrkFHTG 1441632847 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 4229CC00285; Mon, 7 Sep 2015 09:34:06 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: Alissa Cooper X-Priority: 3 In-Reply-To: Date: Mon, 7 Sep 2015 06:34:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <236228C1-7506-4009-AA78-62EEF3C3FF8F@cooperw.in> References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> To: Carl Reed X-Mailer: Apple Mail (2.2104) Archived-At: Cc: geopriv mailing list , dispatch@ietf.org, Erik Wilde , Scott Simmons , Stephen Farrell , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 13:34:12 -0000 Hi Carl, Thanks for this. I think the paragraph in the charter about whether = GeoJSON objects are LOs was focusing on the target identity aspect. That = is, the definitions of LO given in RFC 3693 and RFC 6280 both assume = that a location object describes the location of a target device. I = definitely appreciate that there are other implications of saying = something is or is not a LO, so perhaps the charter needs some = re-phrasing. The current thinking coming out of IETF 93 seemed to be that the GeoJSON = spec will define GeoJSON objects such that they represent geographic = features only and do not specify associations between geographic = features and particular devices. Of course, it will be fairly trivial = for developers to associate those objects with target identities of some = sort =E2=80=94 the whole point of specifying a json format is to make it = easier to use geo information in applications. And if the format is = built to be extensible, which generally would be a good thing, that = raises the question about the point at which we need to deal with the = associated privacy and security issues at the spec level should the = format be extended to associate a location with a target. To put it = another way, the base spec could be written (1) to preclude = extensibility of this sort, (2) to allow extensibility of this sort with = the expectation that when extensions are defined, the associated privacy = and security implications will be addressed, or (3) to allow = extensibility of this sort and explain how future extensions need to = address privacy and security. Personally I think (1) is unlikely given = the versatility of json. The text Stephen and I were debating was aimed = at (2). You seem to be suggesting (3). Does that seem like an accurate = assessment? Alissa > On Sep 3, 2015, at 8:51 AM, Carl Reed = wrote: >=20 > Sorry to jump in. I have now read the entire thread, reviewed the = charter, and reviewed a number of RFCs on this topic (starting with = 4119). Been a while! Before starting, I wish to state that I am not = opposed to this WG activity - GeoJSON is an important spec and one now = being used in OGC standards work as informational. I just have some = concerns. >=20 > In my mind, there is perhaps a more fundamental question: What is a = Location Object? Back with the LO activity first started, the focus was = on extending PIDF to include location content. =46rom that perspective, = privacy and location are closely coupled. However, over time the use of = the location object became uncoupled from PIDF and as a result a number = of other RFCs now speak to how to use a LO with SIP, RADIUS, and so on. = Essentially, a LO can also be viewed as a stand alone package of = location content with additional attributes such as uncertainty. When I = worked on these RFC, I never viewed LO as being tightly coupled with = privacy but always viewed the LO as a data package that could be used = with any number of other standards/specs or even as a standard alone = payload. This is exactly what has happened. Don't get me wrong - the = privacy implications associated with location are critical - and scary. = Predictive analytics experiments have shown that future individual = movement activity can be predicted with close to 95% accuracy by = analyzing past movement behavior (a joint Harvard/MIT study). >=20 > Therefore, I would suggest that a GeoJSON encoded payload is a = location object. Consider that the PIDF-LO geodetic model is encoded = using GML. The abstract model for geometry used in GML is ISO 19107: = Spatial Schema (which is now in revision). The GeoJSON geometry model is = also based on ISO 19107. The main difference between the two (other than = the LO requirement for additional geometry types) is that GeoJSON = encodes coordinates as longitude/latitude. GML encodes coordinates as = latitude-longitude. There are also differences in how other coordinate = reference systems are handled. While these differences are properly = documented, I would strongly encourage the planned activity to consider: >=20 > 1. Documenting the relationship (similarities and differences) between = GeoJSON and a LO. This would allow developers to choose the appropriate = implementation approach. > 2. Have a section on threat analysis and security > 3. Speak to how privacy issues could be addressed (back to item 1 = also). >=20 > Perhaps I am being overly sensitive but location and privacy (along = with provenance and uncertainty) are coming to the fore as major = standards issues. The OGC is working these standards related issues more = and more. Much of this is being driven by requirements to use location = content associated "citizens as scientists" activities, volunteered = geographic information, IoT, Smart Cities, and on and on. >=20 > I know the GeoJSON authors do not wish to "overload" the GeoJSON spec. = As such, I suspect many of my concerns could be easily addressed by = referencing appropriate content from existing IETF RFCs. For example, = the content of 7459 Uncertainty and Confidence is quite appropriate for = a GeoJSON encoding. Also, 7459 was reviewed and commented on by OGC = Members :-) >=20 > Sorry for the long posting. >=20 > Regards >=20 > Carl Reed > Geospatial Standards geek >=20 > -----Original Message----- From: Alissa Cooper > Sent: Thursday, September 03, 2015 9:02 AM > To: Stephen Farrell > Cc: geopriv@ietf.org ; dispatch@ietf.org ; Erik Wilde ; IESG > Subject: Re: [Geopriv] Stephen Farrell's Block on = charter-ietf-geojson-00-01: (with BLOCK) >=20 > Ok, one more try and we=E2=80=99re there I think: >=20 > OLD > As the WG considers extensibility it will be careful not to > preclude extensions that would allow GeoJSON objects to become = location objects > unless the group determines such extensibility would be harmful. >=20 > NEW > Extensions that would allow GeoJSON objects to become location objects = are not expected to be defined in the WG. Should that be needed, = re-chartering will be required. >=20 >> On Sep 3, 2015, at 7:58 AM, Stephen Farrell = wrote: >>=20 >>=20 >> Better again. You could maybe add that's not expected to happen >> during the lifetime of this wg but that'd be fine. >>=20 >> S >>=20 >> On 03/09/15 15:57, Alissa Cooper wrote: >>> NEW Should extensions that would allow GeoJSON objects to become >>> location objects be needed, re-chartering will be required. >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv=20 From nobody Tue Sep 8 07:49:52 2015 Return-Path: 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 B222F1B3ED2 for ; Tue, 8 Sep 2015 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 g0zuJUY6-LkG for ; Tue, 8 Sep 2015 07:49:47 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 6F8AC1B3E08 for ; Tue, 8 Sep 2015 07:49:47 -0700 (PDT) Received: by ioiz6 with SMTP id z6so120532383ioi.2 for ; Tue, 08 Sep 2015 07:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=eIBcivlwBk/LpraKKpC5FwqyExesE8NK9TxAu6GXXI0=; b=B/y3QP4Bq2SNQbRHkCF5TxXe/hYeBuRC8sjENsjXAJSV7hUoDNqARzizGChaAuDQDy Gb2/TyHtrNqxB9l5lD9yjZIhQuvnJ1wRZ7vE1TiQjNAWWQURExHDVKk4ygjcq1dHeR3p lNcjcINJ6eWB/R9nalkhnvasJjVQ+U0A1A1s65IT46gNbTUBGfJzPRXQldk6ZpjGT+Kh hODbzm/m0f7DxA29XED6Yj//eFs7fBPfPSwzyZQnmyt6VUr79D6XJbcNNpIAZmyYJ0w5 AMcgNXmXDbtnBCMVXkBwwvE7OWb5bfY89VvX2CwbeBaqOAOSCaDuSXL+BizPnUf23Iqt GkVg== X-Received: by 10.107.14.73 with SMTP id 70mr44060671ioo.11.1441723786520; Tue, 08 Sep 2015 07:49:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.19.164 with HTTP; Tue, 8 Sep 2015 07:49:07 -0700 (PDT) From: Tessa Fallon Date: Tue, 8 Sep 2015 10:49:07 -0400 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a113ff69c29205e051f3d7ae9 Archived-At: Subject: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 14:49:51 -0000 --001a113ff69c29205e051f3d7ae9 Content-Type: text/plain; charset=UTF-8 After presenting on FFV1 and Matroska at IETF 94 this past summer, we have incorporated feedback and input from IETF members to draft a new charter for a proposed working group that includes FFV1, Matroska, and FLAC. I look forward to discussing the proposed charter, which is included below. Best wishes, Tessa Fallon *_________________* *Proposed Name*: CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community. FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption. There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption. Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Existing specifications can be accessed here: Specifications: FFV1: https://mediaarea.net/temp/ffv1.html Matroska: http://matroska.org/technical/specs/index.html EBML: http://matroska-org.github.io/libebml/specs.html FLAC: https://xiph.org/flac/format.html Development Versions: FFV1: https://github.com/ffmpeg/ffv1 Matroska: https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml EBML: https://github.com/Matroska-Org/ebml-specification The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. *Deliverables:* - Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication - Standards Track specification for Matroska container format version 4 to IESG for publication - Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication - Standards Track specification for FFV1 video codec version 4 to IESG for publication - Standards Track specification for FLAC audio codec to IESG for publication --001a113ff69c29205e051f3d7ae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After presenting on FFV1 and Matroska at IETF 94 this past summer, = we have incorporated feedback and input from IETF members to draft a new ch= arter for a proposed working group that includes FFV1, Matroska, and FLAC.<= /div>

=
I l= ook forward to discussing the proposed charter, which is included below.

Best = wishes,

Tessa Fallon
_________________

Proposed Name: CELLAR: Codec Encoding for LossLess Archi= ving and Realtime transmission
=C2=A0
The preservation of audiovisual materials faces challenge= s from technological obsolescence, analog media deterioration, and the use = of proprietary formats that lack formal open standards. While obsolescence = and material degradation are widely addressed, the standardization of open,= transparent, self-descriptive, lossless formats remains an important missi= on to be undertaken by the open source community.
=C2=A0
FFV1 is a lossless video codec and Mat= roska is an extensible media container based on EBML (Extensible Binary Met= a Language), a binary XML format. There are open source implementations of = both formats, and an increasing interest in and support for use of FFV1 and= Matroska. However, there are concerns about the sustainability and credibi= lity of existing specifications for the long-term use of these formats. The= se existing specifications require broader review and formalization in orde= r to encourage widespread adoption.
=C2=A0
There is also a need for a lossless audio format to= complement the lossless video codec and container format. FLAC is a lossle= ss audio codec that has seen widespread adoption in a number of different a= pplications including=C2=A0archival applications. While there are open source im= plementations of the codec, no formal standards for either the codec itself= or its use in container formats currently exist. Review and formalization = of the FLAC codec standard and its use in Matroska container formats is nee= ded for wider adoption.
=C2=A0
Using existing work done by the development communities of Mat= roska, FFV1, and FLAC, the Working Group will formalize specifications for = these open and lossless formats. In order to provide authoritative, standar= dized specifications for users and developers, the Working Group will seek = consensus throughout the process of refining and formalizing these standard= s. Existing specifications can be accessed here:
=C2=A0
Specifications:
=C2=A0
Development Versions:
Matroska:=C2=A0https://github.com/Matroska-Org/foundation-source/blob/mas= ter/spectool/specdata.xml
=C2= =A0
The W= orking Group will seek consensus and refinements for specifications for bot= h FFV1 and Matroska in order to provide authoritative, standardized specifi= cations for users and developers. Backward compatibility with existing vers= ions 0-3 of the FFV1 and Matroska specifications will be an important goal,= while also reviewing and refining the current version 4 under active devel= opment. Although not encouraged, non-backwards-compatible changes to the in= put specifications will be acceptable if the Working Group determines that = the modifications are required to meet the group's technical objectives= , provided that the reasons for these changes are clearly documented.=C2=A0=
=C2=A0
Deliver= ables:
    Informational specification for Matroska containe= r format versions 1, 2 and 3 to IESG for publication
=
  • Standards Track specification for Matroska container format version 4 to= IESG for publication
  • Informational specification= for FFV1 video codec versions 0, 1 and 3 to IESG for publication
  • Standards Track specification for FFV1 video codec version = 4 to IESG for publication
  • Standards Track specific= ation for FLAC audio codec to IESG for publication
=C2=A0
=C2=A0
=
--001a113ff69c29205e051f3d7ae9-- From nobody Tue Sep 8 07:56:35 2015 Return-Path: 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 915B31AD291 for ; Tue, 8 Sep 2015 07:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wdbWl3HZNoEj for ; Tue, 8 Sep 2015 07:56:30 -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 94C131A88C4 for ; Tue, 8 Sep 2015 07:56:30 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t88EuM39020845 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Sep 2015 09:56:23 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Tessa Fallon , dispatch@ietf.org References: From: Adam Roach Message-ID: <55EEF716.8030103@nostrum.com> Date: Tue, 8 Sep 2015 09:56:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070904020101050507030005" Archived-At: Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 14:56:34 -0000 This is a multi-part message in MIME format. --------------070904020101050507030005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I support creation of a working group with this set of goals, for the reasons stated in the proposed charter's first paragraph. I have no suggestions for improvements. /a On 9/8/15 09:49, Tessa Fallon wrote: > After presenting on FFV1 and Matroska at IETF 94 this past summer, we > have incorporated feedback and input from IETF members to draft a new > charter for a proposed working group that includes FFV1, Matroska, and > FLAC. > > I look forward to discussing the proposed charter, which is included > below. > > Best wishes, > > Tessa Fallon > /_________________/ > / > / > /Proposed Name/: CELLAR: Codec Encoding for LossLess Archiving and > Realtime transmission > The preservation of audiovisual materials faces challenges from > technological obsolescence, analog media deterioration, and the use of > proprietary formats that lack formal open standards. While > obsolescence and material degradation are widely addressed, the > standardization of open, transparent, self-descriptive, lossless > formats remains an important mission to be undertaken by the open > source community. > FFV1 is a lossless video codec and Matroska is an extensible media > container based on EBML (Extensible Binary Meta Language), a binary > XML format. There are open source implementations of both formats, and > an increasing interest in and support for use of FFV1 and Matroska. > However, there are concerns about the sustainability and credibility > of existing specifications for the long-term use of these formats. > These existing specifications require broader review and formalization > in order to encourage widespread adoption. > There is also a need for a lossless audio format to complement the > lossless video codec and container format. FLAC is a lossless audio > codec that has seen widespread adoption in a number of different > applications includingarchival applications. While there are open > source implementations of the codec, no formal standards for either > the codec itself or its use in container formats currently exist. > Review and formalization of the FLAC codec standard and its use in > Matroska container formats is needed for wider adoption. > Using existing work done by the development communities of Matroska, > FFV1, and FLAC, the Working Group will formalize specifications for > these open and lossless formats. In order to provide authoritative, > standardized specifications for users and developers, the Working > Group will seek consensus throughout the process of refining and > formalizing these standards. Existing specifications can be accessed here: > Specifications: > FFV1: https://mediaarea.net/temp/ffv1.html > Matroska: http://matroska.org/technical/specs/index.html > EBML: http://matroska-org.github.io/libebml/specs.html > FLAC: https://xiph.org/flac/format.html > Development Versions: > FFV1: https://github.com/ffmpeg/ffv1 > Matroska: > https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml > EBML: https://github.com/Matroska-Org/ebml-specification > The Working Group will seek consensus and refinements for > specifications for both FFV1 and Matroska in order to provide > authoritative, standardized specifications for users and developers. > Backward compatibility with existing versions 0-3 of the FFV1 and > Matroska specifications will be an important goal, while also > reviewing and refining the current version 4 under active development. > Although not encouraged, non-backwards-compatible changes to the input > specifications will be acceptable if the Working Group determines that > the modifications are required to meet the group's technical > objectives, provided that the reasons for these changes are clearly > documented. > *Deliverables:* > > * Informational specification for Matroska container format versions > 1, 2 and 3 to IESG for publication > > * Standards Track specification for Matroska container format > version 4 to IESG for publication > > * Informational specification for FFV1 video codec versions 0, 1 and > 3 to IESG for publication > > * Standards Track specification for FFV1 video codec version 4 to > IESG for publication > > * Standards Track specification for FLAC audio codec to IESG for > publication > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------070904020101050507030005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I support creation of a working group with this set of goals, for the reasons stated in the proposed charter's first paragraph. I have no suggestions for improvements.

/a


On 9/8/15 09:49, Tessa Fallon wrote:
After presenting on FFV1 and Matroska at IETF 94 this past summer, we have incorporated feedback and input from IETF members to draft a new charter for a proposed working group that includes FFV1, Matroska, and FLAC.

I look forward to discussing the proposed charter, which is included below.

Best wishes,

Tessa Fallon
_________________

Proposed Name: CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission
 
The preservation of audiovisual materials faces challenges from technological obsolescence, analog media deterioration, and the use of proprietary formats that lack formal open standards. While obsolescence and material degradation are widely addressed, the standardization of open, transparent, self-descriptive, lossless formats remains an important mission to be undertaken by the open source community.
 
FFV1 is a lossless video codec and Matroska is an extensible media container based on EBML (Extensible Binary Meta Language), a binary XML format. There are open source implementations of both formats, and an increasing interest in and support for use of FFV1 and Matroska. However, there are concerns about the sustainability and credibility of existing specifications for the long-term use of these formats. These existing specifications require broader review and formalization in order to encourage widespread adoption.
 
There is also a need for a lossless audio format to complement the lossless video codec and container format. FLAC is a lossless audio codec that has seen widespread adoption in a number of different applications including archival applications. While there are open source implementations of the codec, no formal standards for either the codec itself or its use in container formats currently exist. Review and formalization of the FLAC codec standard and its use in Matroska container formats is needed for wider adoption.
 
Using existing work done by the development communities of Matroska, FFV1, and FLAC, the Working Group will formalize specifications for these open and lossless formats. In order to provide authoritative, standardized specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalizing these standards. Existing specifications can be accessed here:
 
Specifications:
 
Development Versions:
 
The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development. Although not encouraged, non-backwards-compatible changes to the input specifications will be acceptable if the Working Group determines that the modifications are required to meet the group's technical objectives, provided that the reasons for these changes are clearly documented. 
 
Deliverables:
  • Informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication
  • Standards Track specification for Matroska container format version 4 to IESG for publication
  • Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication
  • Standards Track specification for FFV1 video codec version 4 to IESG for publication
  • Standards Track specification for FLAC audio codec to IESG for publication
 
 



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------070904020101050507030005-- From nobody Tue Sep 8 08:25:23 2015 Return-Path: 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 BAF671B43E9 for ; Tue, 8 Sep 2015 08:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 KwBzoi51vu6i for ; Tue, 8 Sep 2015 08:25:19 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B3A1B3F29 for ; Tue, 8 Sep 2015 08:25:18 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 994AAC8F28 for ; Tue, 8 Sep 2015 15:25:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnpIKFDxfBdH for ; Tue, 8 Sep 2015 15:25:18 +0000 (UTC) Received: from [172.17.0.117] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 6BC34C8EC2 for ; Tue, 8 Sep 2015 15:25:18 +0000 (UTC) Message-ID: <55EEFDDD.5040804@xiph.org> Date: Tue, 08 Sep 2015 08:25:17 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: dispatch@ietf.org References: <55EEF716.8030103@nostrum.com> In-Reply-To: <55EEF716.8030103@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:25:21 -0000 Adam Roach wrote: > I support creation of a working group with this set of goals, for the > reasons stated in the proposed charter's first paragraph. I have no > suggestions for improvements. +1 From nobody Tue Sep 8 08:44:13 2015 Return-Path: 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 48A8C1B2EF3 for ; Tue, 8 Sep 2015 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 h9AIqW8aG_xb for ; Tue, 8 Sep 2015 08:44:10 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30FC1ACC8C for ; Tue, 8 Sep 2015 08:44:10 -0700 (PDT) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id D3C3DC5A51 for ; Tue, 8 Sep 2015 17:44:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 6ISjLNI4sI_6 for ; Tue, 8 Sep 2015 17:44:07 +0200 (CEST) X-Originating-IP: 84.114.129.144 Received: from localhost (chello084114129144.4.15.vie.surfer.at [84.114.129.144]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 70C8CC5A49 for ; Tue, 8 Sep 2015 17:44:07 +0200 (CEST) Date: Tue, 8 Sep 2015 17:43:59 +0200 From: Michael Niedermayer To: dispatch@ietf.org Message-ID: <20150908154359.GI4556@nb4> References: <55EEF716.8030103@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jJVMc5+FiwMz9o91" Content-Disposition: inline In-Reply-To: <55EEF716.8030103@nostrum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 15:44:12 -0000 --jJVMc5+FiwMz9o91 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 08, 2015 at 09:56:22AM -0500, Adam Roach wrote: > I support creation of a working group with this set of goals, for > the reasons stated in the proposed charter's first paragraph. I have > no suggestions for improvements. +1 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. --jJVMc5+FiwMz9o91 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlXvAj8ACgkQYR7HhwQLD6uGawCeMcBNa4RVqcVFowup9l7Tyt4+ 7jMAn3OzwGWGXkmZG9XOEGEpLjpuxTbz =X/nr -----END PGP SIGNATURE----- --jJVMc5+FiwMz9o91-- From nobody Wed Sep 9 10:55:46 2015 Return-Path: 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 383231B4101; Wed, 9 Sep 2015 10:55:40 -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 3CQvU3KQafqV; Wed, 9 Sep 2015 10:55:38 -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 D46931B40F5; Wed, 9 Sep 2015 10:55:25 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t89Ht2al082419 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2015 12:55:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Marc Petit-Huguenin" Date: Wed, 09 Sep 2015 12:55:02 -0500 Message-ID: In-Reply-To: <55E6E9AE.7080400@acm.org> References: <55E6E9AE.7080400@acm.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: DISPATCH list , mmusic@ietf.org, ice@ietf.org Subject: Re: [dispatch] [Ice] New version of the proposed charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 17:55:40 -0000 Comments inline: On 2 Sep 2015, at 7:21, Marc Petit-Huguenin wrote: > Please find below a new version of the proposed charter, trying to = > take in account all the comments so far. > > The discussions are taking place in the ice mailing-list, please do = > not cross-post. > > Thanks. > > - = > -----------------------------------------------------------------------= ---------- > > Charter for Working Group > > Interactive Connectivity Establishment was published as RFC 5245 in = > April 2010. Until recently the protocol had seen rather limited = > deployment. ICE was slow to achieve widespread adoption, as other = > mechanisms were already being used by the VoIP industry. This = > situation has changed drastically as ICE is mandatory to implement in = > WebRTC, a set of technologies developed at the IETF and W3C to = > standardize Real Time Communication on the Web. > > Interactive Connectivity Establishment (ICE) is at the same time a NAT = > traversal technique, a multihomed address selection technique, and a = > dual stack address selection technique that works by including a = > multiplicity of IP addresses and ports in both the request and = > response messages of a connectivity establishment transaction. The IP = > addresses and ports provided by each side are paired and tested by = > peer-to-peer connectivity checks until one of these pair is selected = > to transport data. ICE follows the end to end principle where the = > clients themselves discovers, test and choose the network path to use. = > It makes no assumptions regarding network topology on the local or = > remote side. > > ICE was originally defined for the Offer-Answer (RFC 3264) protocol = > used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP = > (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and = > other realtime media establishment protocol have used the protocol. = > ICE is also used by non-realtime media protocols, like HIP (RFC 5770) = > and RELOAD (RFC 6940). > > The goal of the ICE Working Group is to consolidate the various = > initiatives to update ICE to make it more suitable for the WebRTC = > environment but also to all the current usages of ICE. I'd like to see more specifics here. There are three milestones--the = charter text should describe the work items supported by those = milestones and expected output. If those milestones are assumed to be = based on existing drafts, please name them. We also need to be clear on how open or closed ended this is. Is the = goal to finish specific work and close? Or do you expect the wg to add new work items in the future as new ICE = requirements become apparent? (Note that a "standing" maintenance = working group may get more charter scrutiny than one intended to finish = and close.) > ICE is an application controlled protocol that leverages a set of = > network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and = > related protocol work done in the TRAM working group must be closely = > synchronised with the work in this working group. Synching with other = > network related working groups to make sure existing mechanisms like = > QoS, congestion control and other networking mechanisms still work = > would be essential if we want to improve how ICE works (MIF, TAPS, = > TSWG, HOMENET, etc...). From the application side, the users of ICE, = > there is a need to make sure what is specified is actually usable. = > Getting input from the application working groups will be essential = > (RTCWEB, HIP, MMUSIC, P2PSIP). > > Milestones > > Jun 2016 Submit Dual-stack Fairness with ICE as Proposed Standard > Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard > Jan 2016 Submit Trickle ICE as Proposed Standard > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Wed Sep 9 17:53:16 2015 Return-Path: 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 0CE931A00D4 for ; Wed, 9 Sep 2015 17:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 RNEhx-oLXZZU for ; Wed, 9 Sep 2015 17:53:13 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCD81A9177 for ; Wed, 9 Sep 2015 17:53:13 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 94F9F2021D for ; Wed, 9 Sep 2015 20:53:12 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 09 Sep 2015 20:53:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=QqO5NgNaeDtSq1FQENf+XjS+t6A=; b=t8v/rF fOlZYQl01fogvUuBfhAg3wHVpLA8n0pQzdvosOPklVzZ9of2OQT1CPxDdDqWn8dR t0iBuu/PA0QU7Sdy4EJp8JZ8vbuRSpyPfZjQO95BOXXrc4DtwHIqUuw61usSlzyG oOe59Eq11y8lOh+Rjfynnf0lhEBfhBU/4g3TM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=QqO5NgNaeDtSq1F QENf+XjS+t6A=; b=Sar5AI+5KVAJPHSg3h5ZL5so3FNAK4/SHYnXcqVD7+b2hR/ it6MMNjpi8R/DD1iihuIRNl6xEOrhuusWo1V2A0aRDyJq4mrzrwO9ET1pnHqS+jh KH6iLwT3oDX1kyfxq/3qBg46x5XsbTlpOnkIYpJizHqJG6bRJScw49IE3jwo= X-Sasl-enc: LvAF/a6SLUtgaKl7aCzpwaZjHz9zMFZZBcL48/eyUI3F 1441846392 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.171]) by mail.messagingengine.com (Postfix) with ESMTPA id F0B88680128; Wed, 9 Sep 2015 20:53:11 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <55E86C05.7020103@alum.mit.edu> Date: Wed, 9 Sep 2015 17:53:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86C05.7020103@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 00:53:16 -0000 Hi Paul, I don=E2=80=99t think the goal is to prevent anything necessarily. I = think the point is to express in the charter what the group plans to do, = what requirements flow from that, and the circumstances under which a = re-charter would be necessary. I agree with you that what we can limit = here is what the WG will work on, not what people will do with that = output. The point of discussing the relationship between a GeoJSON object and a = LO was to point out that a GeoJSON object itself does not specify the = location of a target, but rather just a location. Perhaps that point = could be made more clearly without talking about location objects at = all, if that is confusing? Alissa > On Sep 3, 2015, at 8:49 AM, Paul Kyzivat = wrote: >=20 > I have been following this discussion, but haven't been able to make = sense of it. :-( >=20 > IIUC, the question is how to restrict GeoJSON so that it can't be used = to represent Location Objects (loosely as defined in RF6280) because it = doesn't have a way to include Privacy Rules. ISTM that this is an = *impossible* goal. >=20 > If you pass a representation of a geographic location where a target = might be, then it may be possible for that location to be associated = with a target contextually. This may be true without the knowledge of = the sending application. (And possibly even without the knowledge of the = receiving application.) The relationship may be inferred via complex = data mining. >=20 > For that matter, even the statement of the goal is problematic. In = 6280 LO is defined as "location information together with Privacy = Rules". I guess GeoJSON doesn't aspire to represent privacy rules, but I = don't see how doing so would be a problem. >=20 > Perhaps the goal should be to forbid a GeoJSON object from = *containing* a representation of a *target* (as defined in 6280). This = would not prevent a target from being associated with it contextually, = but at least the users will not need to consider what might be *within* = the GeoJSON object when analyzing whether there are privacy concerns. >=20 > Thanks, > Paul >=20 > On 9/3/15 10:57 AM, Alissa Cooper wrote: >> Suggestion below. >>=20 >>> On Sep 3, 2015, at 6:19 AM, Stephen Farrell = wrote: >>>=20 >>>=20 >>> scroll on down... >>>=20 >>> On 03/09/15 14:14, Alissa Cooper wrote: >>>>=20 >>>>> On Sep 3, 2015, at 5:28 AM, Stephen Farrell >>>>> wrote: >>>>>=20 >>>>>=20 >>>>> Hiya, >>>>>=20 >>>>> On 03/09/15 13:23, Alissa Cooper wrote: >>>>>> Hi Stephen, >>>>>>=20 >>>>>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell >>>>>>> wrote: >>>>>>>=20 >>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>> charter-ietf-geojson-00-01: Block >>>>>>>=20 >>>>>>> When responding, please keep the subject line intact and reply >>>>>>> to all email addresses included in the To and CC lines. (Feel >>>>>>> free to cut this introductory paragraph, however.) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The document, along with other ballot positions, can be found >>>>>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>=20 >>> BLOCK: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>=20 >>> This seems like a fine thing to do, but I have one >>>>>>> concern I'd like to chat about before we go ahead. >>>>>>>=20 >>>>>>> I could buy the "no privacy issues here" argument except for >>>>>>> the last sentence which says: "As the WG considers >>>>>>> extensibility it will be careful not to preclude extensions >>>>>>> that would allow GeoJSON objects to become location objects >>>>>>> unless the group determines such extensibility would be >>>>>>> harmful." Aside from being hard to parse, that seems to mean >>>>>>> that some extensions could mean this format does become a >>>>>>> RFC6280 Location object, which would then bring in the privacy >>>>>>> and security issues, previously argued to be out of scope. >>>>>>=20 >>>>>> Maybe this is a verb tense problem, but I think the points of >>>>>> the entire paragraph in question are: >>>>>>=20 >>>>>> 1) the format the group intends to create is for representation >>>>>> of things that are not location objects 2) even so, depending on >>>>>> how the format is specified, it may be possible for them to get >>>>>> used in ways in which they become location objects, in which case >>>>>> the privacy and security considerations kick in 3) in defining >>>>>> how to make the format extensible, the group does not want to >>>>>> preclude (2) in the future, but 4) the group will not be defining >>>>>> specific extensions to achieve (2). >>>>>>=20 >>>>>> Here is a re-phrase that tries to capture this better: >>>>>>=20 >>>>>> The WG will be careful to craft its extensibility mechanism such >>>>>> that extensions that would allow GeoJSON objects to become >>>>>> location objects are not precluded, but will not be defining such >>>>>> extensions itself. Should such an extension be needed, >>>>>> re-chartering will be required. >>>>>>=20 >>>>>> Is that better? >>>>>=20 >>>>> Yes. Definitely clearer. >>>>>=20 >>>>> However, the "not precluded" is a bit troubling still. >>>>=20 >>>> I think the thing is that you don=E2=80=99t want to specify this = format such >>>> that it could never describe the location of a person or a device, >>>> because that would be an a priori limiting constraint on its = utility. >>>> So the point is to leave the door open via the extensibility >>>> mechanism, but not design specific extensions to do this (unless >>>> there=E2=80=99s a re-charter). >>>>=20 >>>>>=20 >>>>> Let me try get to it this way - in the following timeline who/when >>>>> would address the security/privacy issues and how'd we be >>>>> confident that'd really happen? >>>>>=20 >>>>> t1: This WG does it's planned stuff. t2: The foo-protocol uses >>>>> geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't >>>>> consider security/privacy as geojson doesn't create location >>>>> objects >>>>=20 >>>> I think consideration for privacy/security could happen at t2 >>>> depending on how the foo-protocol uses the geojson object. So in = this >>>> case we would rely on the remit of the foo-wg (this is the "When a >>>> GeoJSON object is used in a context where it identifies the = location >>>> of a Target =E2=80=A6=E2=80=9D sentence). >>>=20 >>> But at t2, the foo-wg doesn't know that a geojson object can e.g. >>> include my photo or FB name or whatever so they can't take that >>> into account. >>>=20 >>>>=20 >>>>> t3: This WG defines how to annotate a location with an identity >>>>> thus creating location objects >>>>=20 >>>> Then certainly at t3 the geojson WG would address privacy/security. >>>> And this would be after re-charter. >>>=20 >>> Even if that re-charter says to consider the foo-protocol and >>> the bar-protocol, it'd likely be too late to handle things well. >>>=20 >>> On balance I think I'd argue that this charter would be better to >>> just say "no security/privacy stuff needed" (as it currentlyu does) >>> but to not get into extensibility and how that might affect privacy >>> at all. >>=20 >> How about this? >>=20 >> OLD >> As the WG considers extensibility it will be careful not to >> preclude extensions that would allow GeoJSON objects to become = location objects >> unless the group determines such extensibility would be harmful. >>=20 >> NEW >> Should extensions that would allow GeoJSON objects to become location = objects be needed, re-chartering will be required. >>=20 >> Alissa >>=20 >>>=20 >>> Cheers, >>> S. >>>=20 >>>=20 >>>>=20 >>>> Alissa >>>>=20 >>>>>=20 >>>>> Ta, S. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Alissa >>>>>>=20 >>>>>>> I think that's a contradiction. As it happens, I also think >>>>>>> that, despite folks best efforts, RFC6280 isn't an architecture >>>>>>> that worked out that well, so I'd not suggest that this wG try >>>>>>> emulate that with square brackets. Instead, I'd suggest that >>>>>>> this WG be chartered to never take on work with does have >>>>>>> security or privacy consequences (without a re-charter). >>>>>>>=20 >>>>>>> That'd maybe mean a change in the last sentence such as: >>>>>>>=20 >>>>>>> OLD: >>>>>>>=20 >>>>>>> As the WG considers extensibility it will be careful not to >>>>>>> preclude extensions that would allow GeoJSON objects to become >>>>>>> location objects unless the group determines such >>>>>>> extensibility would be harmful. >>>>>>>=20 >>>>>>> NEW: >>>>>>>=20 >>>>>>> In order to continue to validly avoid having to deal with the >>>>>>> security and privacy issues that would arise, this WG will not >>>>>>> define any extensions that would have the effect of making a >>>>>>> geojson object an RFC6280 location object or location >>>>>>> information as defined by RFC3693. Should such an extension be >>>>>>> needed, re-chartering will be required. >>>>>>>=20 >>>>>>> My propsed NEW text is very clunky so probably needs >>>>>>> improving. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ Geopriv >>>>>>> mailing list Geopriv@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Sep 10 08:09:46 2015 Return-Path: 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 CAA711B69D9 for ; Thu, 10 Sep 2015 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 X-IvyX5nhSag for ; Thu, 10 Sep 2015 08:09:42 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D82B1B498D for ; Thu, 10 Sep 2015 08:09:42 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with comcast id FT9h1r0082D5gil01T9hrU; Thu, 10 Sep 2015 15:09:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id FT9g1r00X3Ge9ey01T9hEA; Thu, 10 Sep 2015 15:09:41 +0000 To: Alissa Cooper References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86C05.7020103@alum.mit.edu> From: Paul Kyzivat Message-ID: <55F19D34.2000106@alum.mit.edu> Date: Thu, 10 Sep 2015 11:09:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1441897781; bh=9dODzq1IJzyW5WnPTJva1v5gBerY6UMMnwy0o8osyb0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=IT5b9HP41wYvW31DIbbwM255vVZcFhD68rRna6FvtK2OWLOoCNpflVVbcDySQY1Xz eeOoDnNmAPDMutjawvN9G+B1K2t4IAjhrHfevGK0oOyMpyrd6SMOOEFYvMK6QmZw4b RsuVmUNdQAglFYTuBZ0Jbv5A3OVrXJtVtxgYk7o6SvrCDc8OETzP8+DXOfkKIBBWpf 3MC/CQpLmsR+brUGQ7xOPI4TYXNje7tKclA6+PgzQt6oDWyh1BhYM7ncyZ91Z7/kXe VCYz2Ylai8tPEG2hl95HrC65wHUJi8+gyusNySbPZ2GHh4mo34YIAcxZquRG0xCq1L I7cTxpooMg5VQ== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 15:09:44 -0000 Alissa, On 9/9/15 8:53 PM, Alissa Cooper wrote: > Hi Paul, > > I don’t think the goal is to prevent anything necessarily. I think the point is to express in the charter what the group plans to do, what requirements flow from that, and the circumstances under which a re-charter would be necessary. I agree with you that what we can limit here is what the WG will work on, not what people will do with that output. OK > The point of discussing the relationship between a GeoJSON object and a LO was to point out that a GeoJSON object itself does not specify the location of a target, but rather just a location. Perhaps that point could be made more clearly without talking about location objects at all, if that is confusing? Yes. I found the ref to LO to add confusion about what the point was. I think just saying that a GeoJSON object is not intended to contain identification of a target would do the trick. Thanks, Paul > Alissa > > >> On Sep 3, 2015, at 8:49 AM, Paul Kyzivat wrote: >> >> I have been following this discussion, but haven't been able to make sense of it. :-( >> >> IIUC, the question is how to restrict GeoJSON so that it can't be used to represent Location Objects (loosely as defined in RF6280) because it doesn't have a way to include Privacy Rules. ISTM that this is an *impossible* goal. >> >> If you pass a representation of a geographic location where a target might be, then it may be possible for that location to be associated with a target contextually. This may be true without the knowledge of the sending application. (And possibly even without the knowledge of the receiving application.) The relationship may be inferred via complex data mining. >> >> For that matter, even the statement of the goal is problematic. In 6280 LO is defined as "location information together with Privacy Rules". I guess GeoJSON doesn't aspire to represent privacy rules, but I don't see how doing so would be a problem. >> >> Perhaps the goal should be to forbid a GeoJSON object from *containing* a representation of a *target* (as defined in 6280). This would not prevent a target from being associated with it contextually, but at least the users will not need to consider what might be *within* the GeoJSON object when analyzing whether there are privacy concerns. >> >> Thanks, >> Paul >> >> On 9/3/15 10:57 AM, Alissa Cooper wrote: >>> Suggestion below. >>> >>>> On Sep 3, 2015, at 6:19 AM, Stephen Farrell wrote: >>>> >>>> >>>> scroll on down... >>>> >>>> On 03/09/15 14:14, Alissa Cooper wrote: >>>>> >>>>>> On Sep 3, 2015, at 5:28 AM, Stephen Farrell >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hiya, >>>>>> >>>>>> On 03/09/15 13:23, Alissa Cooper wrote: >>>>>>> Hi Stephen, >>>>>>> >>>>>>>> On Sep 3, 2015, at 4:15 AM, Stephen Farrell >>>>>>>> wrote: >>>>>>>> >>>>>>>> Stephen Farrell has entered the following ballot position for >>>>>>>> charter-ietf-geojson-00-01: Block >>>>>>>> >>>>>>>> When responding, please keep the subject line intact and reply >>>>>>>> to all email addresses included in the To and CC lines. (Feel >>>>>>>> free to cut this introductory paragraph, however.) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The document, along with other ballot positions, can be found >>>>>>>> here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>> BLOCK: >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>> This seems like a fine thing to do, but I have one >>>>>>>> concern I'd like to chat about before we go ahead. >>>>>>>> >>>>>>>> I could buy the "no privacy issues here" argument except for >>>>>>>> the last sentence which says: "As the WG considers >>>>>>>> extensibility it will be careful not to preclude extensions >>>>>>>> that would allow GeoJSON objects to become location objects >>>>>>>> unless the group determines such extensibility would be >>>>>>>> harmful." Aside from being hard to parse, that seems to mean >>>>>>>> that some extensions could mean this format does become a >>>>>>>> RFC6280 Location object, which would then bring in the privacy >>>>>>>> and security issues, previously argued to be out of scope. >>>>>>> >>>>>>> Maybe this is a verb tense problem, but I think the points of >>>>>>> the entire paragraph in question are: >>>>>>> >>>>>>> 1) the format the group intends to create is for representation >>>>>>> of things that are not location objects 2) even so, depending on >>>>>>> how the format is specified, it may be possible for them to get >>>>>>> used in ways in which they become location objects, in which case >>>>>>> the privacy and security considerations kick in 3) in defining >>>>>>> how to make the format extensible, the group does not want to >>>>>>> preclude (2) in the future, but 4) the group will not be defining >>>>>>> specific extensions to achieve (2). >>>>>>> >>>>>>> Here is a re-phrase that tries to capture this better: >>>>>>> >>>>>>> The WG will be careful to craft its extensibility mechanism such >>>>>>> that extensions that would allow GeoJSON objects to become >>>>>>> location objects are not precluded, but will not be defining such >>>>>>> extensions itself. Should such an extension be needed, >>>>>>> re-chartering will be required. >>>>>>> >>>>>>> Is that better? >>>>>> >>>>>> Yes. Definitely clearer. >>>>>> >>>>>> However, the "not precluded" is a bit troubling still. >>>>> >>>>> I think the thing is that you don’t want to specify this format such >>>>> that it could never describe the location of a person or a device, >>>>> because that would be an a priori limiting constraint on its utility. >>>>> So the point is to leave the door open via the extensibility >>>>> mechanism, but not design specific extensions to do this (unless >>>>> there’s a re-charter). >>>>> >>>>>> >>>>>> Let me try get to it this way - in the following timeline who/when >>>>>> would address the security/privacy issues and how'd we be >>>>>> confident that'd really happen? >>>>>> >>>>>> t1: This WG does it's planned stuff. t2: The foo-protocol uses >>>>>> geojson in a PDU (and the bar protocol etc.) The foo-wg doesn't >>>>>> consider security/privacy as geojson doesn't create location >>>>>> objects >>>>> >>>>> I think consideration for privacy/security could happen at t2 >>>>> depending on how the foo-protocol uses the geojson object. So in this >>>>> case we would rely on the remit of the foo-wg (this is the "When a >>>>> GeoJSON object is used in a context where it identifies the location >>>>> of a Target …” sentence). >>>> >>>> But at t2, the foo-wg doesn't know that a geojson object can e.g. >>>> include my photo or FB name or whatever so they can't take that >>>> into account. >>>> >>>>> >>>>>> t3: This WG defines how to annotate a location with an identity >>>>>> thus creating location objects >>>>> >>>>> Then certainly at t3 the geojson WG would address privacy/security. >>>>> And this would be after re-charter. >>>> >>>> Even if that re-charter says to consider the foo-protocol and >>>> the bar-protocol, it'd likely be too late to handle things well. >>>> >>>> On balance I think I'd argue that this charter would be better to >>>> just say "no security/privacy stuff needed" (as it currentlyu does) >>>> but to not get into extensibility and how that might affect privacy >>>> at all. >>> >>> How about this? >>> >>> OLD >>> As the WG considers extensibility it will be careful not to >>> preclude extensions that would allow GeoJSON objects to become location objects >>> unless the group determines such extensibility would be harmful. >>> >>> NEW >>> Should extensions that would allow GeoJSON objects to become location objects be needed, re-chartering will be required. >>> >>> Alissa >>> >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>>> >>>>> Alissa >>>>> >>>>>> >>>>>> Ta, S. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Alissa >>>>>>> >>>>>>>> I think that's a contradiction. As it happens, I also think >>>>>>>> that, despite folks best efforts, RFC6280 isn't an architecture >>>>>>>> that worked out that well, so I'd not suggest that this wG try >>>>>>>> emulate that with square brackets. Instead, I'd suggest that >>>>>>>> this WG be chartered to never take on work with does have >>>>>>>> security or privacy consequences (without a re-charter). >>>>>>>> >>>>>>>> That'd maybe mean a change in the last sentence such as: >>>>>>>> >>>>>>>> OLD: >>>>>>>> >>>>>>>> As the WG considers extensibility it will be careful not to >>>>>>>> preclude extensions that would allow GeoJSON objects to become >>>>>>>> location objects unless the group determines such >>>>>>>> extensibility would be harmful. >>>>>>>> >>>>>>>> NEW: >>>>>>>> >>>>>>>> In order to continue to validly avoid having to deal with the >>>>>>>> security and privacy issues that would arise, this WG will not >>>>>>>> define any extensions that would have the effect of making a >>>>>>>> geojson object an RFC6280 location object or location >>>>>>>> information as defined by RFC3693. Should such an extension be >>>>>>>> needed, re-chartering will be required. >>>>>>>> >>>>>>>> My propsed NEW text is very clunky so probably needs >>>>>>>> improving. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ Geopriv >>>>>>>> mailing list Geopriv@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv >>>>>>> >>>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From nobody Thu Sep 10 16:14:08 2015 Return-Path: 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 DAF3A1B2CB9 for ; Thu, 10 Sep 2015 16:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 4PojF0NFKbvy for ; Thu, 10 Sep 2015 16:14:04 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C381A6F6E for ; Thu, 10 Sep 2015 16:14:03 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3E62B2062A for ; Thu, 10 Sep 2015 19:14:03 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 10 Sep 2015 19:14:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=yn8FMxx23PT3IhGs73QD9U1+XT0 =; b=FF1qYbzKaJmtIFb8AteXjwFlpsnaDL+T2gf4KUD/b0sM7SBMqFNoQpNTC+t hi4/mDidtvJ8vpOHysyjcqjdSDbtdNJ33pEl2FS3ThFLpRh/xrMP8x/IAE8GSlcC 4/OklHAN1TNOjix9GnPVZN+AHYcagUyygviXvOX3z/5rTkXw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=yn 8FMxx23PT3IhGs73QD9U1+XT0=; b=pAelHsdOqMLQXE/p0mkhDIWE5hOkBQYdHX 7H5aqC5M19pS2m1DWgTfFRlnq9UW1F1YpbIoeBeZh3d3I9BV958PJXLXpZXCjMos jMB5OEzIxPqBbl7EvjrPldAc5DyHa0JOgTa+O5vcz+4WCaQXzasU02cFkM2b9gCt vE5dwYLes= X-Sasl-enc: H7tAt0CfpigNLIBgGYV/LSgrwg1MH6jmDrcetr69UBhJ 1441926842 Received: from dhcp-171-68-21-63.cisco.com (dhcp-171-68-21-63.cisco.com [171.68.21.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 2BE71680154; Thu, 10 Sep 2015 19:14:02 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_DE9233BC-80DC-4B45-9712-DFB1E5897D74" Date: Thu, 10 Sep 2015 16:14:01 -0700 Message-Id: To: dispatch@ietf.org, geopriv mailing list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Erik Wilde , Carl Reed , Stephen Farrell Subject: [dispatch] Updated geojson charter text X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 23:14:06 -0000 --Apple-Mail=_DE9233BC-80DC-4B45-9712-DFB1E5897D74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve made an update to the geojson charter text in response to = the list discussion with Paul, Carl, and Stephen. I have removed the = text about location objects since that seemed to confuse people and was = superfluous given the point being made about target identity. I also = changed the last sentence per my exchange with Stephen, but inserted a = note about the extensibility of the format to try to capture Robert=E2=80=99= s earlier comments. The changes to the paragraph are below and the full = charter is at >. Please shout = if you think this charter is not ready for external review. Thanks, Alissa OLD GeoJSON objects represent geographic features only and do not specify associations between geographic features and particular devices, users, = or facilities. Any association with a particular device, user, or facility = requires another protocol. As such, a GeoJSON object does not fit the "Location Information" definition according to Section 5.2 of RFC 3693, because = there is not necessarily a "Device" involved. Because there is also no way to = specify the identity of a "Target" within the confines of a GeoJSON object, it also = does not fit the specification of a "Location Object" (Section 5.2 of RFC 3693, = Section 3.2 of RFC 6280). When a GeoJSON object is used in a context where it = identifies the location of a Target, it becomes subject to the architectural, = security, and privacy considerations in RFC 6280. The application of those = considerations is specific to protocols that make use of GeoJSON objects and is out of = scope for the GeoJSON WG. As the WG considers extensibility it will be careful not = to preclude extensions that would allow GeoJSON objects to become location = objects unless the group determines such extensibility would be harmful.=20 NEW GeoJSON objects represent geographic features only and do not specify associations between geographic features and particular devices, users, = or facilities. Any association with a particular device, user, or facility = requires another protocol. When a GeoJSON object is used in a context where it = identifies the location of a device, user, or facility, it becomes subject to the architectural, security, and privacy considerations in RFC 6280. The = application of those considerations is specific to protocols that make use of = GeoJSON objects and is out of scope for the GeoJSON WG. Although the WG is = chartered to improve the extensibility of the format, extensions that would allow = GeoJSON objects to specify associations between geographic features and = particular devices, users, or facilities are not expected to be defined in the WG. = Should that be needed, re-chartering will be required. --Apple-Mail=_DE9233BC-80DC-4B45-9712-DFB1E5897D74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve made an update to the geojson charter text in = response to the list discussion with Paul, Carl, and Stephen. I have = removed the text about location objects since that seemed to confuse = people and was superfluous given the point being made about target = identity. I also changed the last sentence per my exchange with Stephen, = but inserted a note about the extensibility of the format to try to = capture Robert=E2=80=99s earlier comments. The changes to the paragraph = are below and the full charter is at <http://datatracker.ietf.org/doc/charter-ietf-geojson/>. = Please shout if you think this charter is not ready for external = review.

Thanks,
Alissa

OLD
GeoJSON objects =
represent geographic features only and do not specify
associations between geographic features and particular devices, users, =
or
facilities. Any association with a particular device, user, or facility =
requires
another protocol. As such, a GeoJSON object does not fit the "Location
Information" definition according to Section 5.2 of RFC 3693, because =
there is
not necessarily a "Device" involved. Because there is also no way to =
specify the
identity of a "Target" within the confines of a GeoJSON object, it also =
does not
fit the specification of a "Location Object" (Section 5.2 of RFC 3693, =
Section
3.2 of RFC 6280). When a GeoJSON object is used in a context where it =
identifies
the location of a Target, it becomes subject to the architectural, =
security, and
privacy considerations in RFC 6280. The application of those =
considerations is
specific to protocols that make use of GeoJSON objects and is out of =
scope for
the GeoJSON WG. As the WG considers extensibility it will be careful not =
to
preclude extensions that would allow GeoJSON objects to become location =
objects
unless the group determines such extensibility would be harmful. =


NEW
GeoJSON objects =
represent geographic features only and do not specify
associations between geographic features and particular devices, users, =
or
facilities. Any association with a particular device, user, or facility =
requires
another protocol. When a GeoJSON object is used in a context where it =
identifies
the location of a device, user, or facility, it becomes subject to the
architectural, security, and privacy considerations in RFC 6280. The =
application
of those considerations is specific to protocols that make use of =
GeoJSON
objects and is out of scope for the GeoJSON WG. Although the WG is =
chartered to
improve the extensibility of the format, extensions that would allow =
GeoJSON
objects to specify associations between geographic features and =
particular
devices, users, or facilities are not expected to be defined in the WG. =
Should
that be needed, re-chartering will be required.


= --Apple-Mail=_DE9233BC-80DC-4B45-9712-DFB1E5897D74-- From nobody Thu Sep 10 17:01:34 2015 Return-Path: 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 EA4341B4045 for ; Thu, 10 Sep 2015 17:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 29bc2RbM9EhM for ; Thu, 10 Sep 2015 17:01:31 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE7B1B3E32 for ; Thu, 10 Sep 2015 17:01:31 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-07v.sys.comcast.net with comcast id Fc1U1r0052Ka2Q501c1WvQ; Fri, 11 Sep 2015 00:01:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id Fc1U1r0013Ge9ey01c1Ufa; Fri, 11 Sep 2015 00:01:30 +0000 To: Alissa Cooper , dispatch@ietf.org, geopriv mailing list References: From: Paul Kyzivat Message-ID: <55F219D6.2090208@alum.mit.edu> Date: Thu, 10 Sep 2015 20:01:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1441929690; bh=nYboB3nUKCUS0m4eZWnM4SHbnvYiAb2MMFYD+ZDG4Uo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=S4hBN6ZdAtpnohXm4/r0K043W/22xCkOaXxJudJrl2lwW3jCXxvAbIlHahqvlf4s9 cwwQEF9yXoaRhh2wig0JUyjSsG1b8cTI0/oAm/Q6T4ZRiWkkzB1x7lLK2/qSWqpS2p Zma4EqY5QL5YXBCXE3MLNirMh3ym2HdlPkZM/NSVxNhRfag5m9njBYqUE3VGsDjHnu 4EvBuaaFhDJEP7yKK05yVlT2+KmQHj4SLPUb13D9cZxUzZcvdJJo6vDM7cIEcdvL8L Hk6c6lEeLPMLTFb/4H/aWxSouiWsgixnHn81AXgyHTEJuWlc/091ZAuTkTP1Mvpc2w F+A2VLTnPSG6g== Archived-At: Cc: Stephen Farrell , Carl Reed , Erik Wilde Subject: Re: [dispatch] Updated geojson charter text X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 00:01:33 -0000 WFM. Thanks, Paul On 9/10/15 7:14 PM, Alissa Cooper wrote: > I’ve made an update to the geojson charter text in response to the list > discussion with Paul, Carl, and Stephen. I have removed the text about > location objects since that seemed to confuse people and was superfluous > given the point being made about target identity. I also changed the > last sentence per my exchange with Stephen, but inserted a note about > the extensibility of the format to try to capture Robert’s earlier > comments. The changes to the paragraph are below and the full charter is > at . Please shout > if you think this charter is not ready for external review. > > Thanks, > Alissa > > OLD > > GeoJSON objects represent geographic features only and do not specify > associations between geographic features and particular devices, users, or > facilities. Any association with a particular device, user, or facility requires > another protocol. As such, a GeoJSON object does not fit the "Location > Information" definition according to Section 5.2 of RFC 3693, because there is > not necessarily a "Device" involved. Because there is also no way to specify the > identity of a "Target" within the confines of a GeoJSON object, it also does not > fit the specification of a "Location Object" (Section 5.2 of RFC 3693, Section > 3.2 of RFC 6280). When a GeoJSON object is used in a context where it identifies > the location of a Target, it becomes subject to the architectural, security, and > privacy considerations in RFC 6280. The application of those considerations is > specific to protocols that make use of GeoJSON objects and is out of scope for > the GeoJSON WG. As the WG considers extensibility it will be careful not to > preclude extensions that would allow GeoJSON objects to become location objects > unless the group determines such extensibility would be harmful. > > > > NEW > > GeoJSON objects represent geographic features only and do not specify > associations between geographic features and particular devices, users, or > facilities. Any association with a particular device, user, or facility requires > another protocol. When a GeoJSON object is used in a context where it identifies > the location of a device, user, or facility, it becomes subject to the > architectural, security, and privacy considerations in RFC 6280. The application > of those considerations is specific to protocols that make use of GeoJSON > objects and is out of scope for the GeoJSON WG. Although the WG is chartered to > improve the extensibility of the format, extensions that would allow GeoJSON > objects to specify associations between geographic features and particular > devices, users, or facilities are not expected to be defined in the WG. Should > that be needed, re-chartering will be required. > > > From nobody Thu Sep 10 23:43:11 2015 Return-Path: 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 00E301B3DE8 for ; Thu, 10 Sep 2015 23:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 YVFQd9hB2Qvy for ; Thu, 10 Sep 2015 23:43:08 -0700 (PDT) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) (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 72A341B3DE1 for ; Thu, 10 Sep 2015 23:43:08 -0700 (PDT) Received: by vkgd64 with SMTP id d64so21683344vkg.0 for ; Thu, 10 Sep 2015 23:43:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yBx1uudBbcHz4WmMFbU01ABZ48OS6fEnjS+8A5kQNWw=; b=JOHEsSfIAkODKVW2mEQX33ZZxWcg8XI11XVMuF7oaqprzVv3YYBpEP9TAS0Wy/ce7l 9h7hBx9cFFcwIyeE7/OOh/3IpqIDQUQVa8Q0irWc+ZOt1MLCFp7NlK5HKIf5MyvEYDWQ dyMSe9dhUHOl8+nzb87fND2v93ykzh9utGjdEecY1phDTX2tHkWoWcY1LCBQN+0LiymK 4JtfXuzItUrtUYkSHC1CJTZwLFtWCWSrGlIO9OUn/2neCR2HAW5KxEuUZ1P05/PxsG6e BfiPUyUPAkxVRsQWiyqeCYWE25GOaBPevdV3oBr5HgoVJuceaXe+koLV4uG7o5s4SPrT qaiA== X-Gm-Message-State: ALoCoQk809+L0Wd/dUB1JnPh96TKS/VtJozMJZcU6+gL4OGomh+w5+NGMtEyiz3/NH+Q7moSCsKP MIME-Version: 1.0 X-Received: by 10.31.178.149 with SMTP id b143mr3345237vkf.109.1441953787342; Thu, 10 Sep 2015 23:43:07 -0700 (PDT) Received: by 10.31.41.193 with HTTP; Thu, 10 Sep 2015 23:43:07 -0700 (PDT) In-Reply-To: <20150908154359.GI4556@nb4> References: <55EEF716.8030103@nostrum.com> <20150908154359.GI4556@nb4> Date: Fri, 11 Sep 2015 08:43:07 +0200 Message-ID: From: Steve Lhomme To: Michael Niedermayer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 06:43:10 -0000 Same here, I support the creation of this working group. On Tue, Sep 8, 2015 at 5:43 PM, Michael Niedermayer wrote: > On Tue, Sep 08, 2015 at 09:56:22AM -0500, Adam Roach wrote: >> I support creation of a working group with this set of goals, for >> the reasons stated in the proposed charter's first paragraph. I have >> no suggestions for improvements. > > +1 > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Steve Lhomme Matroska association Chairman From nobody Fri Sep 11 02:53:15 2015 Return-Path: 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 24F331A0369; Fri, 11 Sep 2015 02:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 ByrhiHmtHpSh; Fri, 11 Sep 2015 02:53:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7971B2DB2; Fri, 11 Sep 2015 02:53:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 081FBBE2F; Fri, 11 Sep 2015 10:53:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdLD3yLKCu4V; Fri, 11 Sep 2015 10:53:07 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.20.219]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D194CBDF9; Fri, 11 Sep 2015 10:53:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441965187; bh=jASrq7JlB9hUKQKcv0KSOlCZ1048gzm6SQBWt2A2EKg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=oNeNOQyf3wgGT6c6fe8ce0tLkVmNLfAB70QCrUxvaG/pmb4+l8dpP6UNRjUsLkeSG fIKVTmziw87p+ql0wVkOK5/GaEkKUyAgrX6Y2MV9zjOvgs8yA9vEH83ZhM+tpvqqwm jsO+A+MlsROpTZ6LYAGVp7hmMJk5jYjdQG9Pi4ac= To: Paul Kyzivat , Alissa Cooper , dispatch@ietf.org, geopriv mailing list References: <55F219D6.2090208@alum.mit.edu> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55F2A480.6080508@cs.tcd.ie> Date: Fri, 11 Sep 2015 10:53:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F219D6.2090208@alum.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Carl Reed , Erik Wilde Subject: Re: [dispatch] Updated geojson charter text X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 09:53:13 -0000 Looks good, S. On 11/09/15 01:01, Paul Kyzivat wrote: > WFM. > > Thanks, > Paul > > On 9/10/15 7:14 PM, Alissa Cooper wrote: >> I’ve made an update to the geojson charter text in response to the list >> discussion with Paul, Carl, and Stephen. I have removed the text about >> location objects since that seemed to confuse people and was superfluous >> given the point being made about target identity. I also changed the >> last sentence per my exchange with Stephen, but inserted a note about >> the extensibility of the format to try to capture Robert’s earlier >> comments. The changes to the paragraph are below and the full charter is >> at . Please shout >> if you think this charter is not ready for external review. >> >> Thanks, >> Alissa >> >> OLD >> >> GeoJSON objects represent geographic features only and do not specify >> associations between geographic features and particular devices, >> users, or >> facilities. Any association with a particular device, user, or >> facility requires >> another protocol. As such, a GeoJSON object does not fit the "Location >> Information" definition according to Section 5.2 of RFC 3693, because >> there is >> not necessarily a "Device" involved. Because there is also no way to >> specify the >> identity of a "Target" within the confines of a GeoJSON object, it >> also does not >> fit the specification of a "Location Object" (Section 5.2 of RFC 3693, >> Section >> 3.2 of RFC 6280). When a GeoJSON object is used in a context where it >> identifies >> the location of a Target, it becomes subject to the architectural, >> security, and >> privacy considerations in RFC 6280. The application of those >> considerations is >> specific to protocols that make use of GeoJSON objects and is out of >> scope for >> the GeoJSON WG. As the WG considers extensibility it will be careful >> not to >> preclude extensions that would allow GeoJSON objects to become >> location objects >> unless the group determines such extensibility would be harmful. >> >> >> >> NEW >> >> GeoJSON objects represent geographic features only and do not specify >> associations between geographic features and particular devices, >> users, or >> facilities. Any association with a particular device, user, or >> facility requires >> another protocol. When a GeoJSON object is used in a context where it >> identifies >> the location of a device, user, or facility, it becomes subject to the >> architectural, security, and privacy considerations in RFC 6280. The >> application >> of those considerations is specific to protocols that make use of GeoJSON >> objects and is out of scope for the GeoJSON WG. Although the WG is >> chartered to >> improve the extensibility of the format, extensions that would allow >> GeoJSON >> objects to specify associations between geographic features and >> particular >> devices, users, or facilities are not expected to be defined in the >> WG. Should >> that be needed, re-chartering will be required. >> >> >> > From nobody Fri Sep 11 05:07:42 2015 Return-Path: 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 D971B1B4A1B for ; Fri, 11 Sep 2015 05:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 O4sLXC2z0Isg for ; Fri, 11 Sep 2015 05:07:37 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 398F41B4A15 for ; Fri, 11 Sep 2015 05:07:37 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so61624104wic.1 for ; Fri, 11 Sep 2015 05:07:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7H5A9dull24kBlPdBGYFGXcbLeQL9RCjzNJb35DB3AE=; b=Lon7LcbZc66+Ux/hYHeqkah9a1eZFbrCEPagC9Bxbc9SXMBcIu18+2ZJWPzezbmbRz orxibNxSbFaRtTxzbb02qk7kxOO+QpC9hDuhChZwSYkpkpPoZwWwi1ukIXoDecFZlfw4 NFXTvYwwm7MHsfO7MHJQLUVJyiAdJF8uq9KUkkIYVJhGoBBN7lpPPyNIu5KIxTpYzpW0 mgkbnJJtU1rye/nlUOCskI3bULtI3ZkdJZFlJCD2satcVYuF7/um7aeA95OETCErePEq TtsWoLzWH4KFh0YLKIRkTsYGFv0zmK0jVnLoojVvofAzx/rf+EoIBP6SB2u1dBsmcoIV 9U1g== X-Gm-Message-State: ALoCoQkBZ/gPGGBuJVvWxLoz7fmTsfnK82VSKVdTb3kKxdRi0fYDl4+BfJQJeXmSoIFU0L1TEsru X-Received: by 10.180.73.244 with SMTP id o20mr3943559wiv.31.1441973255848; Fri, 11 Sep 2015 05:07:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.79.200 with HTTP; Fri, 11 Sep 2015 05:06:56 -0700 (PDT) In-Reply-To: References: <55EEF716.8030103@nostrum.com> <20150908154359.GI4556@nb4> From: Eric Rescorla Date: Fri, 11 Sep 2015 05:06:56 -0700 Message-ID: To: Steve Lhomme Content-Type: multipart/alternative; boundary=f46d0435c06ab0dbb2051f778f10 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 12:07:40 -0000 --f46d0435c06ab0dbb2051f778f10 Content-Type: text/plain; charset=UTF-8 I support the creation of this wg On Thu, Sep 10, 2015 at 11:43 PM, Steve Lhomme wrote: > Same here, I support the creation of this working group. > > On Tue, Sep 8, 2015 at 5:43 PM, Michael Niedermayer > wrote: > > On Tue, Sep 08, 2015 at 09:56:22AM -0500, Adam Roach wrote: > >> I support creation of a working group with this set of goals, for > >> the reasons stated in the proposed charter's first paragraph. I have > >> no suggestions for improvements. > > > > +1 > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > It is what and why we do it that matters, not just one of them. > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d0435c06ab0dbb2051f778f10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the creation of this wg

On Thu, Sep 10, 2015 at 11:43 PM, St= eve Lhomme <slhomme@matroska.org> wrote:
Same here, I support the creation of this working group.<= br>

On Tue, Sep 8, 2015 at 5:43 PM, Michael Niedermayer
<michael@niedermayer.cc> wrote:
> On Tue, Sep 08, 2015 at 09:56:22AM -0500, Adam Roach wrote:
>> I support creation of a working group with this set of goals, for<= br> >> the reasons stated in the proposed charter's first paragraph. = I have
>> no suggestions for improvements.
>
> +1
>
> [...]
>
> --
> Michael=C2=A0 =C2=A0 =C2=A0GnuPG fingerprint: 9FF2128B147EF6730BADF133= 611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> ________________________________= _______________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>



--
Steve Lhomme
Matroska association Chairman

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--f46d0435c06ab0dbb2051f778f10-- From nobody Fri Sep 11 09:02:29 2015 Return-Path: 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 A636B1B5006; Fri, 11 Sep 2015 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 OJUDRSE7kUxh; Fri, 11 Sep 2015 09:02:20 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 1B2541B5007; Fri, 11 Sep 2015 09:02:20 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so69882234wic.0; Fri, 11 Sep 2015 09:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xX6XxnA2rhxH1Jg6yeKqzJRv0vK8qI3GVXFBpAi+1pc=; b=Sc51sMNjz5zxAIV92Puw7mrdWtRB1NqLNWuy5Ud5FpeIElj++3IwS9qC/RuJdG0lLn IVKsREioO462zm6F4HuKF2jQ/FydHAIKEFqKpyfhq8P8wEVOhv+LqqQofq1qht8mjJjh teEMmVDaoHuAUfgnsmV+60tlzG7nykxlBeUyJ24kw1U+8CVJDzx/sCercf71LGNcU32J Nn7/pQFtT9hU6qDFjOnP8BQ/WTz//NlA0sqSWuGpNPVEf+G074ew43NX7MVsEes9MMfC ecKC7oyVHsDxUFgBVewTCYb5xL+55YFjXSAnbzn/2m5BqaqSlaxvjRYB1D0m4yCWGNHm 4jcg== MIME-Version: 1.0 X-Received: by 10.180.92.138 with SMTP id cm10mr17923023wib.33.1441987338576; Fri, 11 Sep 2015 09:02:18 -0700 (PDT) Received: by 10.27.22.7 with HTTP; Fri, 11 Sep 2015 09:02:18 -0700 (PDT) In-Reply-To: <55F2A480.6080508@cs.tcd.ie> References: <55F219D6.2090208@alum.mit.edu> <55F2A480.6080508@cs.tcd.ie> Date: Fri, 11 Sep 2015 10:02:18 -0600 Message-ID: From: Sean Gillies To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d043be24e1629e1051f7ad738 Archived-At: Cc: geopriv mailing list , DISPATCH list , Erik Wilde , Carl Reed Subject: Re: [dispatch] Updated geojson charter text X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 16:02:27 -0000 --f46d043be24e1629e1051f7ad738 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thumbs up from me. Thanks, Alissa. On Fri, Sep 11, 2015 at 3:53 AM, Stephen Farrell wrote: > > Looks good, > S. > > On 11/09/15 01:01, Paul Kyzivat wrote: > > WFM. > > > > Thanks, > > Paul > > > > On 9/10/15 7:14 PM, Alissa Cooper wrote: > >> I=E2=80=99ve made an update to the geojson charter text in response to= the list > >> discussion with Paul, Carl, and Stephen. I have removed the text about > >> location objects since that seemed to confuse people and was superfluo= us > >> given the point being made about target identity. I also changed the > >> last sentence per my exchange with Stephen, but inserted a note about > >> the extensibility of the format to try to capture Robert=E2=80=99s ear= lier > >> comments. The changes to the paragraph are below and the full charter = is > >> at . Please > shout > >> if you think this charter is not ready for external review. > >> > >> Thanks, > >> Alissa > >> > >> OLD > >> > >> GeoJSON objects represent geographic features only and do not specify > >> associations between geographic features and particular devices, > >> users, or > >> facilities. Any association with a particular device, user, or > >> facility requires > >> another protocol. As such, a GeoJSON object does not fit the "Location > >> Information" definition according to Section 5.2 of RFC 3693, because > >> there is > >> not necessarily a "Device" involved. Because there is also no way to > >> specify the > >> identity of a "Target" within the confines of a GeoJSON object, it > >> also does not > >> fit the specification of a "Location Object" (Section 5.2 of RFC 3693, > >> Section > >> 3.2 of RFC 6280). When a GeoJSON object is used in a context where it > >> identifies > >> the location of a Target, it becomes subject to the architectural, > >> security, and > >> privacy considerations in RFC 6280. The application of those > >> considerations is > >> specific to protocols that make use of GeoJSON objects and is out of > >> scope for > >> the GeoJSON WG. As the WG considers extensibility it will be careful > >> not to > >> preclude extensions that would allow GeoJSON objects to become > >> location objects > >> unless the group determines such extensibility would be harmful. > >> > >> > >> > >> NEW > >> > >> GeoJSON objects represent geographic features only and do not specify > >> associations between geographic features and particular devices, > >> users, or > >> facilities. Any association with a particular device, user, or > >> facility requires > >> another protocol. When a GeoJSON object is used in a context where it > >> identifies > >> the location of a device, user, or facility, it becomes subject to the > >> architectural, security, and privacy considerations in RFC 6280. The > >> application > >> of those considerations is specific to protocols that make use of > GeoJSON > >> objects and is out of scope for the GeoJSON WG. Although the WG is > >> chartered to > >> improve the extensibility of the format, extensions that would allow > >> GeoJSON > >> objects to specify associations between geographic features and > >> particular > >> devices, users, or facilities are not expected to be defined in the > >> WG. Should > >> that be needed, re-chartering will be required. > >> > >> > >> > > > --=20 Sean Gillies --f46d043be24e1629e1051f7ad738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thumbs up from me. Thanks, Alissa.

On Fri, Sep 11, 2015 at 3:53 AM= , Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:=

Looks good,
S.

On 11/09/15 01:01, Paul Kyzivat wrote:
> WFM.
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0Paul
>
> On 9/10/15 7:14 PM, Alissa Cooper wrote:
>> I=E2=80=99ve made an update to the geojson charter text in respons= e to the list
>> discussion with Paul, Carl, and Stephen. I have removed the text a= bout
>> location objects since that seemed to confuse people and was super= fluous
>> given the point being made about target identity. I also changed t= he
>> last sentence per my exchange with Stephen, but inserted a note ab= out
>> the extensibility of the format to try to capture Robert=E2=80=99s= earlier
>> comments. The changes to the paragraph are below and the full char= ter is
>> at <http://datatracker.ietf.org/doc= /charter-ietf-geojson/>. Please shout
>> if you think this charter is not ready for external review.
>>
>> Thanks,
>> Alissa
>>
>> OLD
>>
>> GeoJSON objects represent geographic features only and do not spec= ify
>> associations between geographic features and particular devices, >> users, or
>> facilities. Any association with a particular device, user, or
>> facility requires
>> another protocol. As such, a GeoJSON object does not fit the "= ;Location
>> Information" definition according to Section 5.2 of RFC 3693,= because
>> there is
>> not necessarily a "Device" involved. Because there is al= so no way to
>> specify the
>> identity of a "Target" within the confines of a GeoJSON = object, it
>> also does not
>> fit the specification of a "Location Object" (Section 5.= 2 of RFC 3693,
>> Section
>> 3.2 of RFC 6280). When a GeoJSON object is used in a context where= it
>> identifies
>> the location of a Target, it becomes subject to the architectural,=
>> security, and
>> privacy considerations in RFC 6280. The application of those
>> considerations is
>> specific to protocols that make use of GeoJSON objects and is out = of
>> scope for
>> the GeoJSON WG. As the WG considers extensibility it will be caref= ul
>> not to
>> preclude extensions that would allow GeoJSON objects to become
>> location objects
>> unless the group determines such extensibility would be harmful. >>
>>
>>
>> NEW
>>
>> GeoJSON objects represent geographic features only and do not spec= ify
>> associations between geographic features and particular devices, >> users, or
>> facilities. Any association with a particular device, user, or
>> facility requires
>> another protocol. When a GeoJSON object is used in a context where= it
>> identifies
>> the location of a device, user, or facility, it becomes subject to= the
>> architectural, security, and privacy considerations in RFC 6280. T= he
>> application
>> of those considerations is specific to protocols that make use of = GeoJSON
>> objects and is out of scope for the GeoJSON WG. Although the WG is=
>> chartered to
>> improve the extensibility of the format, extensions that would all= ow
>> GeoJSON
>> objects to specify associations between geographic features and >> particular
>> devices, users, or facilities are not expected to be defined in th= e
>> WG. Should
>> that be needed, re-chartering will be required.
>>
>>
>>
>



--
Sean Gillies
--f46d043be24e1629e1051f7ad738-- From nobody Fri Sep 11 10:12:01 2015 Return-Path: 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 440051B2FCD; Fri, 11 Sep 2015 10:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.659 X-Spam-Level: X-Spam-Status: No, score=0.659 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 yX4lpyxbdNQo; Fri, 11 Sep 2015 10:11:57 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id E18591ACEDF; Fri, 11 Sep 2015 10:11:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 3C52794050; Fri, 11 Sep 2015 13:11:56 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEBJUUTutCPE; Fri, 11 Sep 2015 13:11:55 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTPS id 44C5C94034; Fri, 11 Sep 2015 13:11:55 -0400 (EDT) Received: from mail2.standardsmail.org (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTPS id 37513104987B; Fri, 11 Sep 2015 13:11:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 2520F104987A; Fri, 11 Sep 2015 13:11:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3NEq5nHFb_I5; Fri, 11 Sep 2015 13:11:55 -0400 (EDT) Received: from OfficeHP (c-67-176-39-130.hsd1.co.comcast.net [67.176.39.130]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 6D4641049879; Fri, 11 Sep 2015 13:11:54 -0400 (EDT) Message-ID: <974D0EDDEA4A4E83B1F2C7D60CFEB960@OfficeHP> From: "Carl Reed" To: "Alissa Cooper" References: <20150903111519.12341.48799.idtracker@ietfa.amsl.com> <55E83CFF.1040508@cs.tcd.ie> <99B958BA-B141-43D0-A7FB-26ABFDFD274A@cooperw.in> <55E848E3.10403@cs.tcd.ie> <88EE4F71-A95D-478B-B38C-B76D12D8873F@cooperw.in> <55E86027.9050903@cs.tcd.ie> <118F4B72-CD5A-4870-9E6D-D348CD6D2CCC@cooperw.in> <236228C1-7506-4009-AA78-62EEF3C3FF8F@cooperw.in> In-Reply-To: <236228C1-7506-4009-AA78-62EEF3C3FF8F@cooperw.in> Date: Fri, 11 Sep 2015 11:11:23 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: geopriv mailing list , dispatch@ietf.org, Erik Wilde , Scott Simmons , Stephen Farrell , IESG Subject: Re: [dispatch] [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 17:11:59 -0000 Alissa - Yes, thanks. Much appreciate the detailed response. Regards Carl -----Original Message-----=20 From: Alissa Cooper Sent: Monday, September 07, 2015 7:34 AM To: Carl Reed Cc: Stephen Farrell ; geopriv mailing list ; dispatch@ietf.org ; Erik Wil= de=20 ; IESG ; Scott Simmons ; Sean Gillies Subject: Re: [Geopriv] Stephen Farrell's Block on=20 charter-ietf-geojson-00-01: (with BLOCK) Hi Carl, Thanks for this. I think the paragraph in the charter about whether GeoJS= ON=20 objects are LOs was focusing on the target identity aspect. That is, the=20 definitions of LO given in RFC 3693 and RFC 6280 both assume that a locat= ion=20 object describes the location of a target device. I definitely appreciate= =20 that there are other implications of saying something is or is not a LO, = so=20 perhaps the charter needs some re-phrasing. The current thinking coming out of IETF 93 seemed to be that the GeoJSON=20 spec will define GeoJSON objects such that they represent geographic=20 features only and do not specify associations between geographic features= =20 and particular devices. Of course, it will be fairly trivial for develope= rs=20 to associate those objects with target identities of some sort =E2=80=94 = the whole=20 point of specifying a json format is to make it easier to use geo=20 information in applications. And if the format is built to be extensible,= =20 which generally would be a good thing, that raises the question about the= =20 point at which we need to deal with the associated privacy and security=20 issues at the spec level should the format be extended to associate a=20 location with a target. To put it another way, the base spec could be=20 written (1) to preclude extensibility of this sort, (2) to allow=20 extensibility of this sort with the expectation that when extensions are=20 defined, the associated privacy and security implications will be address= ed,=20 or (3) to allow extensibility of this sort and explain how future extensi= ons=20 need to address privacy and security. Personally I think (1) is unlikely=20 given the versatility of json. The text Stephen and I were debating was=20 aimed at (2). You seem to be suggesting (3). Does that seem like an accur= ate=20 assessment? Alissa > On Sep 3, 2015, at 8:51 AM, Carl Reed wrote: > > Sorry to jump in. I have now read the entire thread, reviewed the chart= er,=20 > and reviewed a number of RFCs on this topic (starting with 4119). Been = a=20 > while! Before starting, I wish to state that I am not opposed to this W= G=20 > activity - GeoJSON is an important spec and one now being used in OGC=20 > standards work as informational. I just have some concerns. > > In my mind, there is perhaps a more fundamental question: What is a=20 > Location Object? Back with the LO activity first started, the focus was= on=20 > extending PIDF to include location content. From that perspective, priv= acy=20 > and location are closely coupled. However, over time the use of the=20 > location object became uncoupled from PIDF and as a result a number of=20 > other RFCs now speak to how to use a LO with SIP, RADIUS, and so on.=20 > Essentially, a LO can also be viewed as a stand alone package of locati= on=20 > content with additional attributes such as uncertainty. When I worked o= n=20 > these RFC, I never viewed LO as being tightly coupled with privacy but=20 > always viewed the LO as a data package that could be used with any numb= er=20 > of other standards/specs or even as a standard alone payload. This is=20 > exactly what has happened. Don't get me wrong - the privacy implication= s=20 > associated with location are critical - and scary. Predictive analytics= =20 > experiments have shown that future individual movement activity can be=20 > predicted with close to 95% accuracy by analyzing past movement behavio= r=20 > (a joint Harvard/MIT study). > > Therefore, I would suggest that a GeoJSON encoded payload is a location= =20 > object. Consider that the PIDF-LO geodetic model is encoded using GML. = The=20 > abstract model for geometry used in GML is ISO 19107: Spatial Schema=20 > (which is now in revision). The GeoJSON geometry model is also based on= =20 > ISO 19107. The main difference between the two (other than the LO=20 > requirement for additional geometry types) is that GeoJSON encodes=20 > coordinates as longitude/latitude. GML encodes coordinates as=20 > latitude-longitude. There are also differences in how other coordinate=20 > reference systems are handled. While these differences are properly=20 > documented, I would strongly encourage the planned activity to consider= : > > 1. Documenting the relationship (similarities and differences) between=20 > GeoJSON and a LO. This would allow developers to choose the appropriate= =20 > implementation approach. > 2. Have a section on threat analysis and security > 3. Speak to how privacy issues could be addressed (back to item 1 also)= . > > Perhaps I am being overly sensitive but location and privacy (along wit= h=20 > provenance and uncertainty) are coming to the fore as major standards=20 > issues. The OGC is working these standards related issues more and more= .=20 > Much of this is being driven by requirements to use location content=20 > associated "citizens as scientists" activities, volunteered geographic=20 > information, IoT, Smart Cities, and on and on. > > I know the GeoJSON authors do not wish to "overload" the GeoJSON spec. = As=20 > such, I suspect many of my concerns could be easily addressed by=20 > referencing appropriate content from existing IETF RFCs. For example, t= he=20 > content of 7459 Uncertainty and Confidence is quite appropriate for a=20 > GeoJSON encoding. Also, 7459 was reviewed and commented on by OGC Membe= rs=20 > :-) > > Sorry for the long posting. > > Regards > > Carl Reed > Geospatial Standards geek > > -----Original Message----- From: Alissa Cooper > Sent: Thursday, September 03, 2015 9:02 AM > To: Stephen Farrell > Cc: geopriv@ietf.org ; dispatch@ietf.org ; Erik Wilde ; IESG > Subject: Re: [Geopriv] Stephen Farrell's Block on=20 > charter-ietf-geojson-00-01: (with BLOCK) > > Ok, one more try and we=E2=80=99re there I think: > > OLD > As the WG considers extensibility it will be careful not to > preclude extensions that would allow GeoJSON objects to become location= =20 > objects > unless the group determines such extensibility would be harmful. > > NEW > Extensions that would allow GeoJSON objects to become location objects = are=20 > not expected to be defined in the WG. Should that be needed, re-charter= ing=20 > will be required. > >> On Sep 3, 2015, at 7:58 AM, Stephen Farrell =20 >> wrote: >> >> >> Better again. You could maybe add that's not expected to happen >> during the lifetime of this wg but that'd be fine. >> >> S >> >> On 03/09/15 15:57, Alissa Cooper wrote: >>> NEW Should extensions that would allow GeoJSON objects to become >>> location objects be needed, re-chartering will be required. > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From nobody Sun Sep 13 05:25:46 2015 Return-Path: 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 2E49F1B2B79; Sun, 13 Sep 2015 05:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 1RIlnRy_Uevd; Sun, 13 Sep 2015 05:25:41 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 2B0C41ACD74; Sun, 13 Sep 2015 05:25:41 -0700 (PDT) Received: by vkfp126 with SMTP id p126so45464114vkf.3; Sun, 13 Sep 2015 05:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=E/ZcmViDYmU8SXG3SniDmwZpC65faUnxmgqhJRKwuHs=; b=abeLvxkvos0ObZZ++PkJoeLkVL2bd1yZM3hr3MAO80aV9Ifc4ttKlX+hwL+Jw8c+4B wtDd5t9m72ZRmSpw7zARKKHbRV+V+HYD9lWbKmOLyIeItLzkE/e51E0fEAUUqz1a5mr2 SsA5nAm2bpIfSoMulKQ1mK2ZKN1nXfCKk4cFd4fDuBf8/vgnTv8xN9Arh6htHK2GvqeT THEoa60QT/P9ZJkcwa1stNNd619J4/yQv37bKj/No9/JjCbnXZH1gsrAKcRtmQxzn7H8 f+VmIkSVU3mICgKIhPPAsQqBgyBdFiScI5bNIwq5Ns6u4huWoZFLWvfZCw3JdCQXwNXN Gwiw== MIME-Version: 1.0 X-Received: by 10.31.49.140 with SMTP id x134mr7894120vkx.10.1442147140198; Sun, 13 Sep 2015 05:25:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Sun, 13 Sep 2015 05:25:40 -0700 (PDT) Date: Sun, 13 Sep 2015 08:25:40 -0400 X-Google-Sender-Auth: DunfNyO-yKLMwxGp7CbnCoZpdlU Message-ID: From: Barry Leiba To: Apps Discuss , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dispatch] Nominations needed for IESG, IAB, and IAOC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 12:25:43 -0000 The Nominating Committee (NomCom) has put out calls for nominations (see below) for the IESG, IAB, and IAOC positions it's tasked with filling. Alissa Cooper and Barry Leiba are the two ART ADs whose terms end and whose positions need to be filled. Both are planning to stand for another term. Even if you think the current ADs are doing a good job, we encourage you to make nominations if you know of folks who are willing to serve or if you're willing to serve yourself. All three of us are available to chat about the AD role or to put you in touch with other current or former ADs, IAB members, or IAOC members if you're thinking about standing for one of the open positions. The NomCom will also need your input to its deliberations, so when the time comes and they call for comments, please provide your feedback. Ben, Barry, and Alissa Links: Nominations: https://datatracker.ietf.org/nomcom/2015/nominate/ Desired expertise for ADs: https://datatracker.ietf.org/nomcom/2015/requirements/ Call for nominations (copied below): http://www.ietf.org/mail-archive/web/ietf-announce/current/msg14498.html --------------------------------------------- From: NomCom Chair 2015 To: "IETF Announcement List" Subject: NomCom 2015: Call for nominations Date: Wed, 26 Aug 2015 03:13:13 -0700 Cc: ietf@ietf.org Reply-To: ietf@ietf.org, nomcom15@ietf.org The 2015-16 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2015. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2015/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2015 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2015/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom15@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! NomCom 2015-16 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This is a new thing this year, and it defaults to =C3=A2=E2=82= =AC=C5=93no=C3=A2=E2=82=AC - we won=C3=A2=E2=82=AC=E2=84=A2t tell. After the nomination cycle, we will e= valuate the result of this and recommend whether the next Nomcom should do something different. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 8, 2015. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. We have set the questionnaire submission deadline for October 15, 2015. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAB: * Mary Barnes * Joe Hildebrand * Ted Hardie * Erik Nordmark * Brian Trammell * Mark Blanchet IESG: - Alissa Cooper, ART - Barry Leiba, ART - Brian Haberman, Internet (*) - Benoit Claise, O&M - Alia Atlas, Routing - Kathleen Moriarty, Security - Martin Stiemerling, Transport (*) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2015/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2015/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom15@ietf.org. Thank you for your help in identifying qualified nominees! Harald Alvestrand Nomcom Chair 2015-16 nomcom-chair-2015@ietf.org, hta+nomcom@alvestrand.no --------------------------------------------- From nobody Mon Sep 14 10:05:01 2015 Return-Path: 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 581EE1B611A; Mon, 14 Sep 2015 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QpMkeBiAH7Gt; Mon, 14 Sep 2015 09:03:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE491B5B2B; Mon, 14 Sep 2015 09:03:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914160324.1733.69159.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 09:03:24 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 14 Sep 2015 10:05:00 -0700 Subject: [dispatch] State changed: charter-ietf-geojson-00-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:03:26 -0000 State changed to External review. URL: https://datatracker.ietf.org/doc/charter-ietf-geojson/ From nobody Mon Sep 14 10:05:03 2015 Return-Path: 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 1EEAE1AD05E; Mon, 14 Sep 2015 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rEuUpdiFPJrt; Mon, 14 Sep 2015 09:41:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 107C61ACF19; Mon, 14 Sep 2015 09:41:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914164134.24876.5052.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 09:41:34 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 14 Sep 2015 10:05:01 -0700 Subject: [dispatch] Telechat update notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:41:35 -0000 Telechat date has been changed to 2015-10-01 from 2015-09-03 ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-geojson/ From nobody Wed Sep 16 04:55:18 2015 Return-Path: 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 0E5BA1A9121; Wed, 16 Sep 2015 04:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3bt0O5ftAuqO; Wed, 16 Sep 2015 04:55:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA071A86EF; Wed, 16 Sep 2015 04:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6820; q=dns/txt; s=iport; t=1442404503; x=1443614103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XEDOrwJwEOYpOuaOAzzzUwUjLQdMrIcwbgR7jTjtLQE=; b=hORSVyxeh2NTnmGkGPwZ1AZQIUS3VytjTVxGbN7uO5b1osU6Lhy6J5S5 KcegPSNBkAWY2vba+Eib9oJqkP9MJuWQAwLprWx9tp2a6nh1sc5i4c8EJ ayZm6BeCwE2+n0IJ7hhUzP30MY9/p5w/W584s5AkqS5RivlSSjQz7g2P6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DyAQAiWPlV/5tdJa1dgyNUaQa9IQENgW8KhXkCHIEiOBQBAQEBAQEBgQqEIwEBAQMBAQEBIBE6CwULAgEIGAICERUCAgIlCxUQAgQOBYgmCA21DpRDAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EihVGCD4JugkGBaQoHAR4zBwqCXy+BFAWHM4VHiGQBhQ+Hc4FNRoNvjFaIOB8BAUKEAXEBiGEJFyOBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,539,1437436800"; d="scan'208";a="32567999" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 16 Sep 2015 11:55:01 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8GBt19c028029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Sep 2015 11:55:01 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Sep 2015 06:55:01 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-rcd-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 16 Sep 2015 06:55:01 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 06:55:00 -0500 From: "Pal Martinsen (palmarti)" To: Ben Campbell Thread-Topic: [Ice] New version of the proposed charter Thread-Index: AQHQ6yjBV4+Ne8yrWUiJaSVKPdY+JZ4/aoaA Date: Wed, 16 Sep 2015 11:55:00 +0000 Message-ID: <5AF903D1-3E91-453B-8BAE-8465A04F2E68@cisco.com> References: <55E6E9AE.7080400@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.28] Content-Type: text/plain; charset="utf-8" Content-ID: <31C20B0BD0E7F74E945AAFCDD80AF9EE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: DISPATCH list , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [dispatch] [Ice] New version of the proposed charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 11:55:17 -0000 DQo+IE9uIDA5IFNlcCAyMDE1LCBhdCAxOTo1NSwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5j b20+IHdyb3RlOg0KPiANCj4gQ29tbWVudHMgaW5saW5lOg0KPiANCj4gT24gMiBTZXAgMjAxNSwg YXQgNzoyMSwgTWFyYyBQZXRpdC1IdWd1ZW5pbiB3cm90ZToNCj4gDQo+PiBQbGVhc2UgZmluZCBi ZWxvdyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyLCB0cnlpbmcgdG8gdGFr ZSBpbiBhY2NvdW50IGFsbCB0aGUgY29tbWVudHMgc28gZmFyLg0KPj4gDQo+PiBUaGUgZGlzY3Vz c2lvbnMgYXJlIHRha2luZyBwbGFjZSBpbiB0aGUgaWNlIG1haWxpbmctbGlzdCwgcGxlYXNlIGRv IG5vdCBjcm9zcy1wb3N0Lg0KPj4gDQo+PiBUaGFua3MuDQo+PiANCj4+IC0gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+PiANCj4+IENoYXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXANCj4+IA0KPj4g SW50ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgd2FzIHB1Ymxpc2hlZCBhcyBS RkMgNTI0NSBpbiBBcHJpbCAyMDEwLiBVbnRpbCByZWNlbnRseSB0aGUgcHJvdG9jb2wgaGFkIHNl ZW4gcmF0aGVyIGxpbWl0ZWQgZGVwbG95bWVudC4gSUNFIHdhcyBzbG93IHRvIGFjaGlldmUgd2lk ZXNwcmVhZCBhZG9wdGlvbiwgYXMgb3RoZXIgbWVjaGFuaXNtcyB3ZXJlIGFscmVhZHkgYmVpbmcg dXNlZCBieSB0aGUgVm9JUCBpbmR1c3RyeS4gVGhpcyBzaXR1YXRpb24gaGFzIGNoYW5nZWQgZHJh c3RpY2FsbHkgYXMgSUNFIGlzIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgaW4gV2ViUlRDLCBhIHNl dCBvZiB0ZWNobm9sb2dpZXMgZGV2ZWxvcGVkIGF0IHRoZSBJRVRGIGFuZCBXM0MgdG8gc3RhbmRh cmRpemUgUmVhbCBUaW1lIENvbW11bmljYXRpb24gb24gdGhlIFdlYi4NCj4+IA0KPj4gSW50ZXJh Y3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSkgaXMgYXQgdGhlIHNhbWUgdGlt ZSBhIE5BVCB0cmF2ZXJzYWwgdGVjaG5pcXVlLCBhIG11bHRpaG9tZWQgYWRkcmVzcyBzZWxlY3Rp b24gdGVjaG5pcXVlLCBhbmQgYSBkdWFsIHN0YWNrIGFkZHJlc3Mgc2VsZWN0aW9uIHRlY2huaXF1 ZSB0aGF0IHdvcmtzIGJ5IGluY2x1ZGluZyBhIG11bHRpcGxpY2l0eSBvZiBJUCBhZGRyZXNzZXMg YW5kIHBvcnRzIGluIGJvdGggdGhlIHJlcXVlc3QgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIG9mIGEg Y29ubmVjdGl2aXR5IGVzdGFibGlzaG1lbnQgdHJhbnNhY3Rpb24uIFRoZSBJUCBhZGRyZXNzZXMg YW5kIHBvcnRzIHByb3ZpZGVkIGJ5IGVhY2ggc2lkZSBhcmUgcGFpcmVkIGFuZCB0ZXN0ZWQgYnkg cGVlci10by1wZWVyIGNvbm5lY3Rpdml0eSBjaGVja3MgdW50aWwgb25lIG9mIHRoZXNlIHBhaXIg aXMgc2VsZWN0ZWQgdG8gdHJhbnNwb3J0IGRhdGEuIElDRSBmb2xsb3dzIHRoZSBlbmQgdG8gZW5k IHByaW5jaXBsZSB3aGVyZSB0aGUgY2xpZW50cyB0aGVtc2VsdmVzIGRpc2NvdmVycywgdGVzdCBh bmQgY2hvb3NlIHRoZSBuZXR3b3JrIHBhdGggdG8gdXNlLiBJdCBtYWtlcyBubyBhc3N1bXB0aW9u cyByZWdhcmRpbmcgbmV0d29yayB0b3BvbG9neSBvbiB0aGUgbG9jYWwgb3IgcmVtb3RlIHNpZGUu DQo+PiANCj4+IElDRSB3YXMgb3JpZ2luYWxseSBkZWZpbmVkIGZvciB0aGUgT2ZmZXItQW5zd2Vy IChSRkMgMzI2NCkgcHJvdG9jb2wgdXNlZCBieSBTSVAgKFJGQyAzMjYxKS4gTGF0ZXIgWE1QUCAo WEVQLTAxNzYpLCBSVFNQIChkcmFmdC1pZXRmLW1tdXNpYy1ydHNwLW5hdCksIFJUQ1dlYiAoZHJh ZnQtaWV0Zi1ydGN3ZWItanNlcCkgYW5kIG90aGVyIHJlYWx0aW1lIG1lZGlhIGVzdGFibGlzaG1l bnQgcHJvdG9jb2wgaGF2ZSB1c2VkIHRoZSBwcm90b2NvbC4gSUNFIGlzIGFsc28gdXNlZCBieSBu b24tcmVhbHRpbWUgbWVkaWEgcHJvdG9jb2xzLCBsaWtlIEhJUCAoUkZDIDU3NzApIGFuZCBSRUxP QUQgKFJGQyA2OTQwKS4NCj4+IA0KPj4gVGhlIGdvYWwgb2YgdGhlIElDRSBXb3JraW5nIEdyb3Vw IGlzIHRvIGNvbnNvbGlkYXRlIHRoZSB2YXJpb3VzIGluaXRpYXRpdmVzIHRvIHVwZGF0ZSBJQ0Ug dG8gbWFrZSBpdCBtb3JlIHN1aXRhYmxlIGZvciB0aGUgV2ViUlRDIGVudmlyb25tZW50IGJ1dCBh bHNvIHRvIGFsbCB0aGUgY3VycmVudCB1c2FnZXMgb2YgSUNFLg0KPiANCj4gSSdkIGxpa2UgdG8g c2VlIG1vcmUgc3BlY2lmaWNzIGhlcmUuIFRoZXJlIGFyZSB0aHJlZSBtaWxlc3RvbmVzLS10aGUg Y2hhcnRlciB0ZXh0IHNob3VsZCBkZXNjcmliZSB0aGUgd29yayBpdGVtcyBzdXBwb3J0ZWQgYnkg dGhvc2UgbWlsZXN0b25lcyBhbmQgZXhwZWN0ZWQgb3V0cHV0LiBJZiB0aG9zZSBtaWxlc3RvbmVz IGFyZSBhc3N1bWVkIHRvIGJlIGJhc2VkIG9uIGV4aXN0aW5nIGRyYWZ0cywgcGxlYXNlIG5hbWUg dGhlbS4NCj4gDQpPay4gV2lsbCBhZGQgc29tZSBtb3JlIGRlc2NyaXB0aW9uIG9mIGFjdGl2ZSB3 b3JrLiBUaGlzIHdpbGwgYmUgYmFzZWQgb24gYWRvcHRlZCBJQ0Ugd29yayBpbiBNTVVTSUMuDQoN CldpbGwgYWxzbyB0cnkgdG8gYWRkIHNvbWUgZGVzY3JpcHRpb24gb2Ygd2hhdCBJIHRoaW5rIHRo ZSBncm91cCBpcyB3b3JraW5nIG9uIGJhc2VkIG9uIGludGVyZXN0IGluIG5vbiBhZG9wdGVkIGRy YWZ0cy4gVGhpcyB3aWxsIGJlIHN1YmplY3QgdG8gbXkgaW50ZXJwcmV0YXRpb24gc28gc29tZSBi YXNoaW5nIG11c3QgYmUgZG9uZS4NCg0KDQo+IFdlIGFsc28gbmVlZCB0byBiZSBjbGVhciBvbiBo b3cgb3BlbiBvciBjbG9zZWQgZW5kZWQgdGhpcyBpcy4gSXMgdGhlIGdvYWwgdG8gZmluaXNoIHNw ZWNpZmljIHdvcmsgYW5kIGNsb3NlPw0KPiBPciBkbyB5b3UgZXhwZWN0IHRoZSB3ZyB0byBhZGQg bmV3IHdvcmsgaXRlbXMgaW4gdGhlIGZ1dHVyZSBhcyBuZXcgSUNFIHJlcXVpcmVtZW50cyBiZWNv bWUgYXBwYXJlbnQ/IChOb3RlIHRoYXQgYSDigJxzdGFuZGluZyIgbWFpbnRlbmFuY2Ugd29ya2lu ZyBncm91cCBtYXkgZ2V0IG1vcmUgY2hhcnRlciBzY3J1dGlueSB0aGFuIG9uZSBpbnRlbmRlZCB0 byBmaW5pc2ggYW5kIGNsb3NlLikNCj4gDQoNCk15IHBlcnNvbmFsIHByZWZlcmVuY2Ugb24gdGhp cyB3aWxsIGJlIHRvIGFjY2VwdCB3b3JrIHRoYXQgcHJvcG9zZXMgc21hbGwgY2hhbmdlcyB0byBp bXByb3ZlIElDRSBpbiBzdWJ0bGUgd2F5cy4gQW5kIG15IGd1dCBmZWVsaW5nIGlzIHRoYXQgd2Ug YXJlIHN0YXJ0aW5nIHRvIHNlZSB0aGUgZW5kIG9mIHRoaXMgd29yayB3aXRoIHRoZSBwYXNzaXZl LWFncmVzc2l2ZSwgY29udGludW91cyBub21pbmF0aW9uIGFuZCBzaGF2ZWQgSUNFIGluaXRpYXRp dmVzLiBJIHdvdWxkIGV4cGVjdCB0aG9zZSBpZGVhcyB3aWxsIGJlIHRyaWNrbGluZyBpbiBmb3Ig YW5vdGhlciB5ZWFyIG9yIHR3by4gQnV0IG9uY2UgdGhhdCBpcyBmaW5pc2hlZCBJIHRoaW5rIGl0 IHdvdWxkIGJlIHN1aXRhYmxlIHRvIGNsYWltIHZpY3RvcnkgYW5kIGNsb3NlIHRoZSBXRy4gDQoN ClVwZGF0ZWQgY2hhcnRlciB3aWxsIGJlIHNlbnQgb3V0IHNob3J0bHkuDQoNCi4tLg0KUMOlbC1F cmlrDQoNCj4gDQo+PiBJQ0UgaXMgYW4gYXBwbGljYXRpb24gY29udHJvbGxlZCBwcm90b2NvbCB0 aGF0IGxldmVyYWdlcyBhIHNldCBvZiBuZXR3b3JrIGRlZmluZWQgcHJvdG9jb2xzLiBUaGUgU1RV TiAoUkZDIDUzODkpLCBUVVJOIChSRkMgNTc2NikgYW5kIHJlbGF0ZWQgcHJvdG9jb2wgd29yayBk b25lIGluIHRoZSBUUkFNIHdvcmtpbmcgZ3JvdXAgbXVzdCBiZSBjbG9zZWx5IHN5bmNocm9uaXNl ZCB3aXRoIHRoZSB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC4gU3luY2hpbmcgd2l0aCBvdGhl ciBuZXR3b3JrIHJlbGF0ZWQgd29ya2luZyBncm91cHMgdG8gbWFrZSBzdXJlIGV4aXN0aW5nIG1l Y2hhbmlzbXMgbGlrZSBRb1MsIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgb3RoZXIgbmV0d29ya2lu ZyBtZWNoYW5pc21zIHN0aWxsIHdvcmsgd291bGQgYmUgZXNzZW50aWFsIGlmIHdlIHdhbnQgdG8g aW1wcm92ZSBob3cgSUNFIHdvcmtzIChNSUYsIFRBUFMsIFRTV0csIEhPTUVORVQsIGV0Yy4uLiku IEZyb20gdGhlIGFwcGxpY2F0aW9uIHNpZGUsIHRoZSB1c2VycyBvZiBJQ0UsIHRoZXJlIGlzIGEg bmVlZCB0byBtYWtlIHN1cmUgd2hhdCBpcyBzcGVjaWZpZWQgaXMgYWN0dWFsbHkgdXNhYmxlLiBH ZXR0aW5nIGlucHV0IGZyb20gdGhlIGFwcGxpY2F0aW9uIHdvcmtpbmcgZ3JvdXBzIHdpbGwgYmUg ZXNzZW50aWFsIChSVENXRUIsIEhJUCwgTU1VU0lDLCBQMlBTSVApLg0KPj4gDQo+PiBNaWxlc3Rv bmVzDQo+PiANCj4+IEp1biAyMDE2IFN1Ym1pdCBEdWFsLXN0YWNrIEZhaXJuZXNzIHdpdGggSUNF IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiBBcHIgMjAxNiBTdWJtaXQgYSByZXZpc2lvbiBvZiBJ Q0UgKFJGQyA1MjQ1KSBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gSmFuIDIwMTYgU3VibWl0IFRy aWNrbGUgSUNFIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiANCj4+IC0gLS0NCj4+IE1hcmMgUGV0 aXQtSHVndWVuaW4NCj4+IEVtYWlsOiBtYXJjQHBldGl0LWh1Z3VlbmluLm9yZw0KPj4gQmxvZzog aHR0cDovL2Jsb2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcNCj4+IFByb2ZpbGU6IGh0dHA6Ly93 d3cubGlua2VkaW4uY29tL2luL3BldGl0aHVnDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJY2UgbWFpbGluZyBsaXN0DQo+PiBJY2VA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJ Y2UgbWFpbGluZyBsaXN0DQo+IEljZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQo= From nobody Sun Sep 20 23:50:14 2015 Return-Path: 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 796401A1A79 for ; Sun, 20 Sep 2015 23:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Zi380sq9DrY2 for ; Sun, 20 Sep 2015 23:50:11 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 F38851A1A77 for ; Sun, 20 Sep 2015 23:50:10 -0700 (PDT) Received: by iofh134 with SMTP id h134so110186268iof.0 for ; Sun, 20 Sep 2015 23:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=IPFPvI4V1CoO6ClwqTaipE9E9MW5kk+pGReCMG0jI1k=; b=iJN4M+ze7kT+rHB7a9Xiw/94glo7Xl4GYsgYfFD6M9IpIgLjVf102Bj9JsGGo5vzEO z0/GLT24nVar1p4NrtfC5XBYtggGqcf2IPm0mxaJqSJQToG/COGkHx+T5grwGcpdrCZA gN6QQb6q/DsQH7mtarOdUHbWp/5k7xE9VVRE2sPYroBGmhMscGkp0zELzv0B100gqLic ghrWL4kLjLd+t6do4qSXAwumiIwNboqbih1P7ybm44hLppqYfYO4gzEU+ze76DtVkUul pVLSaxBVzL+uWWavo7hKg/nsNLmAi75mQj9uZr/V5PKIcccFZcqWbI1QsDdDX/Pz73gv SfJw== MIME-Version: 1.0 X-Received: by 10.107.40.12 with SMTP id o12mr24658634ioo.84.1442818210361; Sun, 20 Sep 2015 23:50:10 -0700 (PDT) Received: by 10.79.32.86 with HTTP; Sun, 20 Sep 2015 23:50:10 -0700 (PDT) Date: Mon, 21 Sep 2015 01:50:10 -0500 Message-ID: From: Alan Johnston To: DISPATCH Content-Type: multipart/alternative; boundary=001a1141d150e77c2b05203c4aa4 Archived-At: Cc: dispatch-chairs@tools.ietf.org, draft-johnston-dispatch-osrtp@tools.ietf.org Subject: [dispatch] Plan to Submit a Proposal for Opportunistic SRTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 06:50:12 -0000 --001a1141d150e77c2b05203c4aa4 Content-Type: text/plain; charset=UTF-8 All, This is a notification of our plan to submit a proposal for Opportunistic SRTP (OSRTP) to be considered by DISPATCH. Background is available in our draft: https://tools.ietf.org/html/draft-johnston-dispatch-osrtp OSRTP is an implementation of Opportunistic Security (OS), as defined in RFC 7435, and has a number of deployments and implementations. The SIP Forum is interested in having OSRTP in a future version of the SIPconnect SIP trunking recommendation. Thanks, - Alan - --001a1141d150e77c2b05203c4aa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

This is a notification of our plan= to submit a proposal for Opportunistic SRTP (OSRTP) to be considered by DI= SPATCH.=C2=A0 Background is available in our draft:

=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-johnston-dispatch-osrtp<= /a>

--001a1141d150e77c2b05203c4aa4-- From nobody Tue Sep 22 09:02:46 2015 Return-Path: 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 57F711B2A13 for ; Tue, 22 Sep 2015 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.432 X-Spam-Level: X-Spam-Status: No, score=-98.432 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 6W_QKsf7eO_6 for ; Tue, 22 Sep 2015 09:02:44 -0700 (PDT) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id 070171B2B49 for ; Tue, 22 Sep 2015 09:02:34 -0700 (PDT) Received: from [151.252.67.221] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 15159198 for dispatch@ietf.org; Tue, 22 Sep 2015 19:02:32 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Tue, 22 Sep 2015 21:02:00 +0500 MIME-Version: 1.0 Message-ID: <56017B78.8732.31D9DCBE@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Antivirus: avast! (VPS 150922-0, 22.09.2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [dispatch] Plan to Submit a Proposal for Opportunistic SRTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 16:02:45 -0000 I fully support the idea. But this I-D seems to be a little more than a reference to draft-kaplan-mmusic-best-effort-srtp-01... From nobody Wed Sep 23 05:22:40 2015 Return-Path: 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 984381B29CB for ; Wed, 23 Sep 2015 05:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 xfWZ13Jw9y8S for ; Wed, 23 Sep 2015 05:22:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828EB1B29C7 for ; Wed, 23 Sep 2015 05:22:36 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id E16143743DB for ; Wed, 23 Sep 2015 14:22:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C890038405A for ; Wed, 23 Sep 2015 14:22:34 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 14:22:34 +0200 From: To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-mohali-dispatch-cause-for-service-number-04.txt Thread-Index: AQHQ9XRpFpqcup0Oq02n+5VUz3hZ7J5KCSIQ Date: Wed, 23 Sep 2015 12:22:33 +0000 Message-ID: <21633_1443010954_5602998A_21633_1899_1_8B970F90C584EA4E97D5BAAC9172DBB815761529@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20150922202227.2715.1259.idtracker@ietfa.amsl.com> In-Reply-To: <20150922202227.2715.1259.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.133616 Archived-At: Subject: [dispatch] TR: New Version Notification for draft-mohali-dispatch-cause-for-service-number-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 12:22:38 -0000 RllJDQpJIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQtbW9oYWxpLWRp c3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlciB0byBhZGQgYSBkZWZpbml0aW9uIG9mIHRo ZSB0ZXJtICJzZXJ2aWNlIGFjY2VzcyBudW1iZXIiIHVzZWQgaW4gdGhlIGRyYWZ0Lg0KDQpCZXN0 IHJlZ2FyZHMsDQpNYXJpYW5uZQ0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpFbnZvecOpwqA6IG1hcmRpIDIyIHNlcHRlbWJyZSAyMDE1IDIyOjIyDQrDgMKgOiBNT0hB TEkgTWFyaWFubmUgSU1UL09MTjsgTU9IQUxJIE1hcmlhbm5lIElNVC9PTE4NCk9iamV0wqA6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZv ci1zZXJ2aWNlLW51bWJlci0wNC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci0wNC50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyaWFubmUgTW9oYWxpIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVz ZS1mb3Itc2VydmljZS1udW1iZXINClJldmlzaW9uOgkwNA0KVGl0bGU6CQlTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgKFNJUCkgQ2F1c2UgVVJJIHBhcmFtZXRlciBmb3IgU2VydmljZSBOdW1i ZXIgdHJhbnNsYXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTUtMDktMjINCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1z ZXJ2aWNlLW51bWJlci0wNC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1tb2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVt YmVyLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t b2hhbGktZGlzcGF0Y2gtY2F1c2UtZm9yLXNlcnZpY2UtbnVtYmVyLTA0DQpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1vaGFsaS1kaXNwYXRj aC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDQNCg0KQWJzdHJhY3Q6DQogICBbUkZDNDQ1OF0g ZGVmaW5lcyBhICJjYXVzZSIgVVJJIHBhcmFtZXRlciBhcyBoYXZpbmcgcHJlZGVmaW5lZCB2YWx1 ZXMNCiAgIGZvciBSZWRpcmVjdGluZyByZWFzb25zIGFzIGEgbWFwcGluZyBmcm9tIElUVS1UIFEu NzMyLjItNSBSZWRpcmVjdGluZw0KICAgUmVhc29ucy4gIFRoZSAiY2F1c2UiIFVSSSBwYXJhbWV0 ZXIgaXMgdG8gYmUgdXNlZCBpbiBTSVAgb3IgU0lQcyBVUkkuDQogICBJbiBwYXJ0aWN1bGFyLCBp dCBtYXkgYXBwZWFyIGluIHRoZSBSZXF1ZXN0LVVSSSBvZiBhIFNJUCByZXF1ZXN0Lg0KICAgVGhp cyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcgcHJlZGVmaW5lZCB2YWx1ZSBmb3IgdGhlICJj YXVzZSIgVVJJDQogICBwYXJhbWV0ZXIgZm9yIGNhc2VzIHdoZW4gdGhlIHJldGFyZ2V0aW5nIGlz IGR1ZSB0byBzcGVjaWZpYyBzZXJ2aWNlDQogICBhY3Rpb24gbGVhZGluZyB0byBhIGNhbGxlZCBz ZXJ2aWNlIGFjY2VzcyBudW1iZXIgdHJhbnNsYXRpb24uDQogICBUaGlzIGRvY3VtZW50IHVwZGF0 ZXMgW1JGQzQ0NThdLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LgpUaGFuayB5b3UuCgo= From nobody Fri Sep 25 11:54:36 2015 Return-Path: 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 8A0F51A87D0 for ; Fri, 25 Sep 2015 11:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 2OU9AXHh1LxB for ; Fri, 25 Sep 2015 11:54:32 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 B92011A87CA for ; Fri, 25 Sep 2015 11:54:27 -0700 (PDT) Received: by ioiz6 with SMTP id z6so120038987ioi.2 for ; Fri, 25 Sep 2015 11:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sOmCO1R6dV4Q2YtG8vbckC1lg5EkIltRoRJbj/HEtsU=; b=o+0t14ZcY93wvl4sZWPKbNuDExXut3GAecDVmiKTfBbhij8qi5DLAPOYnwFLWzt5v+ W8dYdLkSjkJ1hLKXeKYe9hmiJV3A/1QJc8+iRHmqvZe17FgunK/sXCOtBNIqCTKbhnba b4WWWQfnC/PZ7wNUCQsJjGG/w2iKaYeQZFOvA8+mP6EID4xSTZ5zTITI0em6WWchXiKY xm7nthppbVHH81c/st2uDpAdOpfepB3+s0CkNJPXwEpQAPGdtw4/5ROZ9d5VWF6Hh7OR IX3XkTJyaC1FaAclFlQ8Zvw+aLPZnfcrfonm9ElXUCHbSjUN+NU1aFoGdAPUUPNwt0nj SDOQ== MIME-Version: 1.0 X-Received: by 10.107.40.12 with SMTP id o12mr8043064ioo.84.1443207267011; Fri, 25 Sep 2015 11:54:27 -0700 (PDT) Received: by 10.79.32.86 with HTTP; Fri, 25 Sep 2015 11:54:26 -0700 (PDT) Date: Fri, 25 Sep 2015 13:54:26 -0500 Message-ID: From: Alan Johnston To: DISPATCH Content-Type: multipart/alternative; boundary=001a1141d1507cd092052096e0ef Archived-At: Subject: [dispatch] Charter Proposal for OSRTP Working Group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 18:54:34 -0000 --001a1141d1507cd092052096e0ef Content-Type: text/plain; charset=UTF-8 All, Here is proposed text for an OSRTP Working Group which we would request to be dispatched. We are not sure that we really need to form a working group in order to publish what is effectively already industry best practices, but this text is for discussion of the topic and the determination of the path forward in here in dispatch. Comments most welcome! - Alan - - - - - - - - - Charter for Opportunistic Security for RTP Working Group (OSRTP) Real-time voice and video communication using RTP is widely used over the Internet today, and much of it is negotiated using SIP and SDP offer/answer. Secure media transport negotiated using SIP and SDP with the secure profile of RTP, SRTP, is unfortunately not widely deployed today for voice and video communication. One reason for this is the difficulty in negotiating the use of SRTP. SDP offer/answer was not originally designed to negotiate profiles of RTP, and extensions such as SDP Capability Negotiation, RFC 5939, have not achieved enough deployment to be useful for negotiating secure media. Without extensions, a caller needs to decide in advance that secure media is used, but if chosen in advance and the called party does not support it, the session will fail. This presents a serious barrier to incremental deployment of secure media. Opportunistic Security (OS), defined in RFC 7435, is an approach to security that defines a third mode for security between "cleartext" and "comprehensive protection" that allows encryption and authentication to be used if supported but will not result in failures if it is not supported. An opportunistic approach for secure media would allow SRTP to be used if the called party support the opportunistic approach, but will fall back to RTP if the called party does not. This will allow SRTP to be incrementally introduced in voice and video communication networks during the transition from no encryption to always-on encryption. WG Objectives This WG will work on a solution for Opportunistic SRTP (OSRTP) that does not require SDP Capability Negotiation, but instead will be based on currently deployed techniques in many voice and video systems that use SDP offers that do not specify a secure profile, but instead use AVP and the presence of SRTP keying SDP attributes in the SDP offer and answer to negotiate secure media. The approach will be general enough to work with a variety of SRTP key agreement protocols including, but not limited to SDP Security Descriptions, DTLS-SRTP, and ZRTP. It is important to note that OSRTP makes no changes, and has no effect on media sessions in which the offer contains a secure profile of RTP, such as SAVP. Also, approaches that always require secure media, such as RTCWEB, will never utilize OSRTP. As allowed by Opportunistic Security, some authentication requirements of SRTP key agreement approaches will be relaxed. However, confidentiality requirements will not be relaxed. The working group will perform the following work: 1. Define the goals and requirements of an Opportunistic Security approach for RTP 2. Define a specification for OSRTP. Non Goals This work will not define any new extensions to SIP or SDP, but it may make changes in some offer/answer procedures or authentication requirements of key agreement protocols. No changes to SRTP or RTP will be made. Collaboration The working group may coordinate with SIPCORE, MMUSIC, and AVTCORE as needed. Input to the WG https://tools.ietf.org/html/draft-johnston-dispatch-osrtp (a starting point for the goals and requirements and protocol) https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-00 (for historical reasons and background) --001a1141d1507cd092052096e0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Here is proposed text for an OSRTP= Working Group which we would request to be dispatched.=C2=A0 We are not su= re that we really need to form a working group in order to publish what is = effectively already industry best practices, but this text is for discussio= n of the topic and the determination of the path forward in here in dispatc= h.

Comments most welcome!

- Alan -

=C2=A0- - = - - - - - -

Charter=C2=A0for Opportunistic= Security for RTP Working Group (OSRTP)
<= br>
Real-time voice and video communication using RTP is widely u= sed over the Internet today, and much of it is negotiated using SIP and SDP= offer/answer.=C2=A0 Secure media transport negotiated using SIP and SDP wi= th the secure profile of RTP, SRTP, is unfortunately not widely deployed to= day for voice and video communication.=C2=A0 One reason for this is the dif= ficulty in negotiating the use of SRTP.=C2=A0 SDP offer/answer was not orig= inally designed to negotiate profiles of RTP, and extensions such as SDP Ca= pability Negotiation, RFC 5939, have not achieved enough deployment to be u= seful for negotiating secure media. =C2=A0= Without extensions, a caller needs to decide in advance that secure media i= s used, but if chosen in advance and the called party does not support it, = the session will fail.=C2=A0=C2=A0This presents a serious barrier to= incremental deployment of secure media. =C2=A0

Op= portunistic Security (OS), defined in RFC 7435, is an approach to security = that defines a third mode for security between "cleartext" and &q= uot;comprehensive protection" that allows encryption and authenticatio= n to be used if supported but will not result in failures if it is not supp= orted.=C2=A0 An opportunistic approach for secure media would allow SRTP to= be used if the called party support the opportunistic approach, but will f= all back to RTP if the called party does not.=C2=A0 This will allow SRTP to= be incrementally introduced in voice and video communication networks duri= ng the transition from no encryption to always-on encryption.
WG Objectives

This WG will work on a s= olution for Opportunistic SRTP (OSRTP) that does no= t require SDP Capability Negotiation, but instead will be based on currentl= y deployed techniques in many voice and video systems that use SDP offers t= hat do not specify a secure profile, but instead use AVP and the presence o= f SRTP keying SDP attributes in the SDP offer and answer to negotiate secur= e media. The approach will be general enough to work with a variety of SRTP= key agreement protocols including, but not limited to SDP Security Descrip= tions, DTLS-SRTP, and ZRTP.

It is important to not= e that=C2=A0OSRTP=C2=A0makes no changes, and has no= effect on media sessions in which the offer contains a secure profile of R= TP, such as SAVP. Also, approaches that always require secure media, such a= s RTCWEB, will never utilize=C2=A0OSRTP.
=
As allowed by Opportunistic Security, some authentication re= quirements of SRTP key agreement approaches will be relaxed.=C2=A0 However,= confidentiality requirements will not be relaxed.

The working group will perform the following work:

1. Define the goals and requirements of an Opportunistic Security approac= h for RTP
2. Define a specification for=C2=A0OSR= TP.

Non Goals

--001a1141d1507cd092052096e0ef-- From nobody Fri Sep 25 15:46:33 2015 Return-Path: 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 147211A909E for ; Fri, 25 Sep 2015 15:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rVdpYySdOvr2 for ; Fri, 25 Sep 2015 15:46:32 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 F264D1A909D for ; Fri, 25 Sep 2015 15:46:31 -0700 (PDT) Received: by ykdg206 with SMTP id g206so127054314ykd.1 for ; Fri, 25 Sep 2015 15:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zuFmzDgLXznqnB2H5YV4s1uYLuKXMZ3VG+fnJLaR4fI=; b=jfri/Bk/g6qR3BUDJotqJ0svKQl96/4IltaEXXU9K10m5aDODwAbh9CmmojtTU/MLd OUJctgOudJZZD/Vns8VEA2uJB/22BBfHJDKe0rgbMsbjRsYEFw+1jxijuiwSFA0dr9qN 6Ci3UB5yyXkx4brsA7Lgt04jsqlyu1qxRZ4K6T7SzDrxUN01FhXweTBc8CYTpWfZvq0U 814VIF/eVNao5T5Yipuv0TJveiKxraC7elIV84Fl4asD21y9lFT6+vZB71ekMER9DBb0 TUDfGS2mGI2enhU0Mmu45qZ6j82+JpB/EJNNSkEtbtxMQRTsO799686US0yWvfnTOfO7 cX0g== MIME-Version: 1.0 X-Received: by 10.170.194.22 with SMTP id l22mr6633381yke.63.1443221191377; Fri, 25 Sep 2015 15:46:31 -0700 (PDT) Received: by 10.37.25.4 with HTTP; Fri, 25 Sep 2015 15:46:31 -0700 (PDT) Date: Fri, 25 Sep 2015 17:46:31 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a11391e2c71c6d905209a1ec7 Archived-At: Subject: [dispatch] Test X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 22:46:33 -0000 --001a11391e2c71c6d905209a1ec7 Content-Type: text/plain; charset=UTF-8 --001a11391e2c71c6d905209a1ec7 Content-Type: text/html; charset=UTF-8

--001a11391e2c71c6d905209a1ec7-- From nobody Mon Sep 28 09:05:02 2015 Return-Path: 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 E16971ACDBF; Mon, 28 Sep 2015 09:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 huT96eBE-ikv; Mon, 28 Sep 2015 09:04:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD27D1ACDBC; Mon, 28 Sep 2015 09:04:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150928160442.22217.78258.idtracker@ietfa.amsl.com> Date: Mon, 28 Sep 2015 09:04:42 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] State changed: charter-ietf-geojson-00-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 16:04:46 -0000 State changed to IESG review. URL: https://datatracker.ietf.org/doc/charter-ietf-geojson/ From nobody Wed Sep 30 00:41:33 2015 Return-Path: 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 DEC471A8AF0; Wed, 30 Sep 2015 00:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Sk5hVkdoHd4X; Wed, 30 Sep 2015 00:41:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF871A87CE; Wed, 30 Sep 2015 00:41:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150930074129.11798.56396.idtracker@ietfa.amsl.com> Date: Wed, 30 Sep 2015 00:41:29 -0700 Archived-At: Cc: geopriv@ietf.org, dispatch@ietf.org, dret@berkeley.edu Subject: [dispatch] Benoit Claise's No Objection on charter-ietf-geojson-00-02: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 07:41:31 -0000 Benoit Claise has entered the following ballot position for charter-ietf-geojson-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-geojson/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Very consistent feedback with my previous review: One readability improvement. So many RFC numbers I have to lookup, in this charter: 5870, 7464, 3693, 6280. Sorry I don't know them all by heart. A good convention is name + RFC, such as "JavaScript Object Notation (JSON) [RFC7159]" I guess it's a short-lived WG, right? Two deliverables and then closed, right? Would be worth mentioning IMO. In the milestones, that would be fine. From nobody Wed Sep 30 07:31:07 2015 Return-Path: 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 64AEF1A8784; Wed, 30 Sep 2015 07:31:06 -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 56_YWPIVxlRK; Wed, 30 Sep 2015 07:31:04 -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 3AF481A8789; Wed, 30 Sep 2015 07:31:04 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8UEUx17062426 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Sep 2015 09:30:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: SIPCORE , "DISPATCH list" Date: Wed, 30 Sep 2015 09:31:00 -0500 Message-ID: <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> In-Reply-To: <56031836.3080407@nostrum.com> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: Cullen Jennings Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:31:06 -0000 (+sipcore, dispatch) (as individual) I just realized this discussion did not include the sipcore or dispatch lists, and probably should. Recap: Christer proposed an errata (4474) to RFC 7315. It proposes the following change: > Section 5.4 says: > > extension-access-info = gen-value > > It should say: > > extension-access-info = generic-param The generic-param construction allows the NAME = VALUE syntax as in the TS 24.229 extension Jean mentioned below. Keeping in mind the RFC in question was for 3GPP: Is anyone aware of implementations of 7315 that would be broken by this? From Jean's example, it looks like 3GPP had already assumed generic-param. Ben. On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: > FWIW - TS 24.229, which defines the values for access-info, considers > extension-access-info to be a generic-param, and not a gen-value as > specified RFC7315. 3GPP has defined one extension so far (7.2A.4): > > > daylight-saving-time = "daylight-saving-time" EQUAL quoted-string > > TS 124 229 - V12.9.0 - Digital cellular telecommunications system > (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; > IP multimedia call control protocol based on Session Initiation > Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP > TS 24.229 version 12.9.0 Release 12) The daylight-saving-time is an > instance of generic-param from the current extension-access-info > component of the P- Access-Network-Info header field defined in RFC > 7315 [52]. > > > Jean > > > > On 9/23/15 3:47 PM, Cullen Jennings wrote: >> I can see that it might have been better if it had been done this way >> Christer is proposing but I don't see how you can change it now. This >> change would break existing parsers that checked this. That does not >> seem like an errata level thing to me. >> >> >>> On Sep 21, 2015, at 10:30 AM, Ben Campbell wrote: >>> >>> sipcore and dispatch chairs: >>> >>> Do you have any concerns about accepting Christer's errata? (I note >>> RFC 7315 was an orphaned sipping draft progressed as AD sponsored.) >>> >>> Ben. >>> >>> Forwarded message: >>> >>>> From: Christer Holmberg >>>> To: Ben Campbell >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>> Date: Mon, 21 Sep 2015 10:26:26 +0000 >>>> >>>> Any news on this? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of >>>> Christer Holmberg >>>> Sent: 14. syyskuuta 2015 23:24 >>>> To: Ben Campbell >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>> >>>> Hi Ben, >>>> >>>> I am pretty sure generic-param was the original intention. The >>>> majority of all existing value follow the generic-param syntax, and >>>> I can't think of any reason why new values would not follow the >>>> same syntax. That is how it works for other header fields too. >>>> >>>> I think this is due to a mistake, where someone thought that >>>> extension-access-info represents the actual parameter name, and >>>> therefor only a value (gen-value) is needed. But, >>>> extension-access-info represents the whole rule (name AND value), >>>> why generic-param is needed :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> Sent from my Windows Phone >>>> ________________________________ >>>> From: Ben Campbell >>>> Sent: ‎14/‎09/‎2015 21:31 >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>> Hi Christer, >>>> >>>> Is it your understanding that the use of generic-param was the >>>> actual >>>> intention at the time 7315 was published? Or was gen-value the >>>> original >>>> intention, but we now think that it should have been generic-param? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: >>>> >>>>> FYI, >>>>> >>>>> I've now submitted the errata. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>> Sent: 14. syyskuuta 2015 14:21 >>>>> To: r.jesske@telekom.de; >>>>> drage@alcatel-lucent.com; >>>>> Christer Holmberg; >>>>> iesg@ietf.org >>>>> Cc: Christer Holmberg; >>>>> rfc-editor@rfc-editor.org >>>>> Subject: [Technical Errata Reported] RFC7315 (4474) >>>>> >>>>> The following errata report has been submitted for RFC7315, >>>>> "Private >>>>> Header (P-Header) Extensions to the Session Initiation Protocol >>>>> (SIP) >>>>> for the 3GPP". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4474 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Christer Holmberg >>>>> > >>>>> >>>>> Section: 5.4 >>>>> >>>>> Original Text >>>>> ------------- >>>>> extension-access-info = gen-value >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> extension-access-info = generic-param >>>>> >>>>> Notes >>>>> ----- >>>>> Most of the pre-defined access-info values are following the >>>>> generic-param syntax. New access-info values (extensions) should >>>>> also >>>>> be allowed to follow the generic-param syntax, in order to allow >>>>> both >>>>> for a name and value of the extension. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, >>>>> please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. >>>>> When a decision is reached, the verifying party (IESG) can log in >>>>> to >>>>> change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14) >>>>> -------------------------------------- >>>>> Title : Private Header (P-Header) Extensions to the >>>>> Session Initiation Protocol (SIP) for the 3GPP >>>>> Publication Date : July 2014 >>>>> Author(s) : R. Jesske, K. Drage, C. Holmberg >>>>> Category : INFORMATIONAL >>>>> Source : IETF - NON WORKING GROUP >>>>> Area : N/A >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 30 08:13:07 2015 Return-Path: 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 0D5771B5E82; Wed, 30 Sep 2015 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 K2bxHEoGT00b; Wed, 30 Sep 2015 08:12:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA921B5E72; Wed, 30 Sep 2015 08:12:56 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-ac-560bfbf67f23 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.65.05274.6FBFB065; Wed, 30 Sep 2015 17:12:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 17:12:54 +0200 From: Christer Holmberg To: Ben Campbell , SIPCORE , DISPATCH list Thread-Topic: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu14AKWWCwgA5pe2uAAAkewA== Date: Wed, 30 Sep 2015 15:12:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> In-Reply-To: <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje7339xhBv+/clnM7zzNbrF00gJW iw/rfzBafP2xic2BxWPJkp9MHpfPf2T0mLXzCUsAcxSXTUpqTmZZapG+XQJXxouWP0wFz0Ir Vly5xN7AeCa4i5GTQ0LARKLjxzQmCFtM4sK99WxdjFwcQgJHGSUW7+xignCWMEpsutzM2MXI wcEmYCHR/U8bpEFEIFliZvdUZhCbWUBZorv1DCtIibCAj8THfSIQJb4Sx5o2MYOERQTCJF6f dwUJswioSmy49oMNxOYFKnn2op0dYlMbk8SnH/9YQBKcAvYSH+7cAytiBLrt+6k1TBCrxCVu PZkPdbOAxJI955khbFGJl4//sULYShKNS56AncMsoCmxfpc+RKuixJTuh+wQewUlTs58wjKB UWwWkqmzEDpmIemYhaRjASPLKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAuDq45bfqDsbL bxwPMQpwMCrx8Co4cYcJsSaWFVfmHmKU5mBREudtZnoQKiSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFR/MhvySC5UPWf7/86nkmq8p0ycUP2ii3zN2WePLp0Ue/rL5pTUxNfav87N0fJcI6a W0KxfPgZtoqCWV2L3KY/Kp3+QumMwJY4hUIOqx9Pvqk9maWuxLqgS3HH8apbyfe+GPGkLk1S +674wOPrv3Vxbw9a+qUWaE3blCsxN23hDcm5xR5C2brvlFiKMxINtZiLihMB7Zat/owCAAA= Archived-At: Cc: Cullen Jennings Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 15:13:01 -0000 SGksDQoNCj4oK3NpcGNvcmUsIGRpc3BhdGNoKQ0KPihhcyBpbmRpdmlkdWFsKQ0KPg0KPkkganVz dCByZWFsaXplZCB0aGlzIGRpc2N1c3Npb24gZGlkIG5vdCBpbmNsdWRlIHRoZSBzaXBjb3JlIG9y IGRpc3BhdGNoIGxpc3RzLCBhbmQgcHJvYmFibHkgc2hvdWxkLg0KPg0KPlJlY2FwOiBDaHJpc3Rl ciBwcm9wb3NlZCBhbiBlcnJhdGEgKDQ0NzQpIHRvIFJGQyA3MzE1LiBJdCBwcm9wb3NlcyB0aGUg Zm9sbG93aW5nIGNoYW5nZToNCj4NCj4+IFNlY3Rpb24gNS40IHNheXM6DQo+Pg0KPj4gZXh0ZW5z aW9uLWFjY2Vzcy1pbmZvICA9IGdlbi12YWx1ZQ0KPj4NCj4+IEl0IHNob3VsZCBzYXk6DQo+Pg0K Pj4gZXh0ZW5zaW9uLWFjY2Vzcy1pbmZvICA9IGdlbmVyaWMtcGFyYW0NCj4NCj4gVGhlIGdlbmVy aWMtcGFyYW0gY29uc3RydWN0aW9uIGFsbG93cyB0aGUgTkFNRSA9IFZBTFVFIHN5bnRheCBhcyBp biB0aGUgVFMgMjQuMjI5IGV4dGVuc2lvbiBKZWFuIG1lbnRpb25lZCBiZWxvdy4NCj4NCj4gS2Vl cGluZyBpbiBtaW5kIHRoZSBSRkMgaW4gcXVlc3Rpb24gd2FzIGZvciAzR1BQOiBJcyBhbnlvbmUg YXdhcmUgb2YgaW1wbGVtZW50YXRpb25zIG9mIDczMTUgdGhhdCB3b3VsZCBiZSBicm9rZW4NCj4g YnkgdGhpcz8gRnJvbSBKZWFuJ3MgZXhhbXBsZSwgaXQgbG9va3MgbGlrZSAzR1BQIGhhZCBhbHJl YWR5IGFzc3VtZWQgZ2VuZXJpYy1wYXJhbS4NCg0KQ29ycmVjdC4NCg0KQWxzbywgY29tcGFyaW5n IFJGQyAzNDU1IGFuZCBSRkMgNzMxNSwgKmFsbCBidXQgb25lKiBvZiB0aGUgbmV3IGFjY2Vzcy1p bmZvIHBhcmFtZXRlciB2YWx1ZXMgdGhhdCB3ZXJlIGFkZGVkIGluIFJGQyA3MzE1IGZvbGxvdyB0 aGUgZ2VuZXJpYy1wYXJhbSBzeW50YXguICBTbywgaXQgc2VlbXMgbGlrZSB3ZSBpbiBJRVRGIGFs c28gYXNzdW1lZCBnZW5lcmljLXBhcmFtIHdoZW4gd2UgZGlkIFJGQyA3MzE1IChhbmQvb3Igd2Ug d2VyZSBub3QgY29uY2VybmVkIGFib3V0IHBhcnNlciBpc3N1ZXMpLCBidXQgbm9ib2R5IG5vdGlj ZWQgdGhlIEFCTkYgaXNzdWUuDQoNCkFuZCwgYXMgSSBzYWlkIGVhcmxpZXIsIEkgYW0gcHJldHR5 IHN1cmUgdGhpcyBoZWFkZXIgaXMgbW9zdGx5IChvbmx5PykgdXNlZCBpbiAzR1BQIGVudmlyb25t ZW50cywgYW5kIG5vYm9keSBpbiAzR1BQIG9iamVjdGVkIHRvIHRoZSBjaGFuZ2UgSSBhbSBub3cg c3VnZ2VzdGluZy4gSXQgd2FzIGRpc2N1c3NlZCBpbiAzR1BQLCBhbmQgdGhlIG91dGNvbWUgd2Fz IHRvIGZpbGUgdGhlIGVycmF0YS4NCg0KRmluYWxseSwgYXMgSmVhbiBpbmRpY2F0ZWQsIDNHUFAg aGFzIGRlZmluZWQgYSBuZXcgdmFsdWUsIGRheWxpZ2h0LXNhdmluZy10aW1lLCB3aGljaCBhbHNv IHVzZXMgdGhlIGdlbmVyaWMtcGFyYW0gc3ludGF4Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCk9uIDIzIFNlcCAyMDE1LCBhdCAxNjoyMywgQS4gSmVhbiBNYWhvbmV5IHdyb3RlOg0KDQo+ IEZXSVcgLSBUUyAyNC4yMjksIHdoaWNoIGRlZmluZXMgdGhlIHZhbHVlcyBmb3IgYWNjZXNzLWlu Zm8sIGNvbnNpZGVycyANCj4gZXh0ZW5zaW9uLWFjY2Vzcy1pbmZvIHRvIGJlIGEgZ2VuZXJpYy1w YXJhbSwgYW5kIG5vdCBhIGdlbi12YWx1ZSBhcyANCj4gc3BlY2lmaWVkIFJGQzczMTUuIDNHUFAg aGFzIGRlZmluZWQgb25lIGV4dGVuc2lvbiBzbyBmYXIgKDcuMkEuNCk6DQo+DQo+DQo+IGRheWxp Z2h0LXNhdmluZy10aW1lID0gImRheWxpZ2h0LXNhdmluZy10aW1lIiBFUVVBTCBxdW90ZWQtc3Ry aW5nDQo+DQo+IFRTIDEyNCAyMjkgLSBWMTIuOS4wIC0gRGlnaXRhbCBjZWxsdWxhciB0ZWxlY29t bXVuaWNhdGlvbnMgc3lzdGVtIA0KPiAoUGhhc2UgMispOyBVbml2ZXJzYWwgTW9iaWxlIFRlbGVj b21tdW5pY2F0aW9ucyBTeXN0ZW0gKFVNVFMpOyBMVEU7IElQIA0KPiBtdWx0aW1lZGlhIGNhbGwg Y29udHJvbCBwcm90b2NvbCBiYXNlZCBvbiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgDQo+ IChTSVApIGFuZCBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApOyBTdGFnZSAzICgz R1BQIFRTIDI0LjIyOSANCj4gdmVyc2lvbiAxMi45LjAgUmVsZWFzZSAxMikgVGhlIGRheWxpZ2h0 LXNhdmluZy10aW1lIGlzIGFuIGluc3RhbmNlIG9mIA0KPiBnZW5lcmljLXBhcmFtIGZyb20gdGhl IGN1cnJlbnQgZXh0ZW5zaW9uLWFjY2Vzcy1pbmZvIGNvbXBvbmVudCBvZiB0aGUgDQo+IFAtIEFj Y2Vzcy1OZXR3b3JrLUluZm8gaGVhZGVyIGZpZWxkIGRlZmluZWQgaW4gUkZDDQo+IDczMTUgWzUy XS4NCj4NCj4NCj4gSmVhbg0KPg0KPg0KPg0KPiBPbiA5LzIzLzE1IDM6NDcgUE0sIEN1bGxlbiBK ZW5uaW5ncyB3cm90ZToNCj4+IEkgY2FuIHNlZSB0aGF0IGl0IG1pZ2h0IGhhdmUgYmVlbiBiZXR0 ZXIgaWYgaXQgaGFkIGJlZW4gZG9uZSB0aGlzIHdheSANCj4+IENocmlzdGVyIGlzIHByb3Bvc2lu ZyBidXQgSSBkb24ndCBzZWUgaG93IHlvdSBjYW4gY2hhbmdlIGl0IG5vdy4gVGhpcyANCj4+IGNo YW5nZSB3b3VsZCBicmVhayBleGlzdGluZyBwYXJzZXJzIHRoYXQgY2hlY2tlZCB0aGlzLiBUaGF0 IGRvZXMgbm90IA0KPj4gc2VlbSBsaWtlIGFuIGVycmF0YSBsZXZlbCB0aGluZyB0byBtZS4NCj4+ DQo+Pg0KPj4+IE9uIFNlcCAyMSwgMjAxNSwgYXQgMTA6MzAgQU0sIEJlbiBDYW1wYmVsbCA8YmVu QG5vc3RydW0uY29tPiB3cm90ZToNCj4+Pg0KPj4+IHNpcGNvcmUgYW5kIGRpc3BhdGNoIGNoYWly czoNCj4+Pg0KPj4+IERvIHlvdSBoYXZlIGFueSBjb25jZXJucyBhYm91dCBhY2NlcHRpbmcgQ2hy aXN0ZXIncyBlcnJhdGE/IChJIG5vdGUgDQo+Pj4gUkZDIDczMTUgd2FzIGFuIG9ycGhhbmVkIHNp cHBpbmcgZHJhZnQgcHJvZ3Jlc3NlZCBhcyBBRCBzcG9uc29yZWQuKQ0KPj4+DQo+Pj4gQmVuLg0K Pj4+DQo+Pj4gRm9yd2FyZGVkIG1lc3NhZ2U6DQo+Pj4NCj4+Pj4gRnJvbTogQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4gVG86IEJlbiBDYW1w YmVsbCA8YmVuQG5vc3RydW0uY29tPg0KPj4+PiBDYzogc2lwY29yZUBpZXRmLm9yZyA8c2lwY29y ZUBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBbVGVjaG5pY2FsIEVycmF0 YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCkNCj4+Pj4gRGF0ZTogTW9uLCAyMSBTZXAgMjAxNSAx MDoyNjoyNiArMDAwMA0KPj4+Pg0KPj4+PiBBbnkgbmV3cyBvbiB0aGlzPw0KPj4+Pg0KPj4+PiBS ZWdhcmRzLA0KPj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+PiBGcm9tOiBzaXBjb3JlIFtt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+Pj4+IENocmlz dGVyIEhvbG1iZXJnDQo+Pj4+IFNlbnQ6IDE0LiBzeXlza3V1dGEgMjAxNSAyMzoyNA0KPj4+PiBU bzogQmVuIENhbXBiZWxsDQo+Pj4+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6 IFJlOiBbc2lwY29yZV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUgKDQ0NzQp DQo+Pj4+DQo+Pj4+IEhpIEJlbiwNCj4+Pj4NCj4+Pj4gSSBhbSBwcmV0dHkgc3VyZSBnZW5lcmlj LXBhcmFtIHdhcyB0aGUgb3JpZ2luYWwgaW50ZW50aW9uLiBUaGUgDQo+Pj4+IG1ham9yaXR5IG9m IGFsbCBleGlzdGluZyB2YWx1ZSBmb2xsb3cgdGhlIGdlbmVyaWMtcGFyYW0gc3ludGF4LCBhbmQg DQo+Pj4+IEkgY2FuJ3QgdGhpbmsgb2YgYW55IHJlYXNvbiB3aHkgbmV3IHZhbHVlcyB3b3VsZCBu b3QgZm9sbG93IHRoZSANCj4+Pj4gc2FtZSBzeW50YXguIFRoYXQgaXMgaG93IGl0IHdvcmtzIGZv ciBvdGhlciBoZWFkZXIgZmllbGRzIHRvby4NCj4+Pj4NCj4+Pj4gSSB0aGluayB0aGlzIGlzIGR1 ZSB0byBhIG1pc3Rha2UsIHdoZXJlIHNvbWVvbmUgdGhvdWdodCB0aGF0IA0KPj4+PiBleHRlbnNp b24tYWNjZXNzLWluZm8gIHJlcHJlc2VudHMgdGhlIGFjdHVhbCBwYXJhbWV0ZXIgbmFtZSwgYW5k IA0KPj4+PiB0aGVyZWZvciBvbmx5IGEgdmFsdWUgKGdlbi12YWx1ZSkgaXMgbmVlZGVkLiBCdXQs IA0KPj4+PiBleHRlbnNpb24tYWNjZXNzLWluZm8gcmVwcmVzZW50cyB0aGUgd2hvbGUgcnVsZSAo bmFtZSBBTkQgdmFsdWUpLCANCj4+Pj4gd2h5IGdlbmVyaWMtcGFyYW0gaXMgbmVlZGVkIDopDQo+ Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IENocmlzdGVyDQo+Pj4+DQo+Pj4+IFNlbnQg ZnJvbSBteSBXaW5kb3dzIFBob25lDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+IEZyb206IEJlbiBDYW1wYmVsbDxtYWlsdG86YmVuQG5vc3RydW0uY29tPg0KPj4+ PiBTZW50OiDigI4xNC/igI4wOS/igI4yMDE1IDIxOjMxDQo+Pj4+IFRvOiBDaHJpc3RlciBIb2xt YmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+PiBDYzogc2lw Y29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6 IFtzaXBjb3JlXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCkgDQo+ Pj4+IEhpIENocmlzdGVyLA0KPj4+Pg0KPj4+PiBJcyBpdCB5b3VyIHVuZGVyc3RhbmRpbmcgdGhh dCB0aGUgdXNlIG9mIGdlbmVyaWMtcGFyYW0gd2FzIHRoZSANCj4+Pj4gYWN0dWFsIGludGVudGlv biBhdCB0aGUgdGltZSA3MzE1IHdhcyBwdWJsaXNoZWQ/IE9yIHdhcyBnZW4tdmFsdWUgDQo+Pj4+ IHRoZSBvcmlnaW5hbCBpbnRlbnRpb24sIGJ1dCB3ZSBub3cgdGhpbmsgdGhhdCBpdCBzaG91bGQg aGF2ZSBiZWVuIA0KPj4+PiBnZW5lcmljLXBhcmFtPw0KPj4+Pg0KPj4+PiBUaGFua3MhDQo+Pj4+ DQo+Pj4+IEJlbi4NCj4+Pj4NCj4+Pj4gT24gMTQgU2VwIDIwMTUsIGF0IDY6MjIsIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPj4+Pg0KPj4+Pj4gRllJLA0KPj4+Pj4NCj4+Pj4+IEkndmUgbm93 IHN1Ym1pdHRlZCB0aGUgZXJyYXRhLg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+ Pj4gQ2hyaXN0ZXINCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4gRnJvbTogUkZDIEVycmF0YSBTeXN0ZW0gW21haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iu b3JnXQ0KPj4+Pj4gU2VudDogMTQuIHN5eXNrdXV0YSAyMDE1IDE0OjIxDQo+Pj4+PiBUbzogci5q ZXNza2VAdGVsZWtvbS5kZTxtYWlsdG86ci5qZXNza2VAdGVsZWtvbS5kZT47DQo+Pj4+PiBkcmFn ZUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT47DQo+ Pj4+PiBDaHJpc3RlciBIb2xtYmVyZzsNCj4+Pj4+IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dA aWV0Zi5vcmc+DQo+Pj4+PiBDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7DQo+Pj4+PiByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KPj4+Pj4g U3ViamVjdDogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUgKDQ0NzQpDQo+Pj4+ Pg0KPj4+Pj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBm b3IgUkZDNzMxNSwgDQo+Pj4+PiAiUHJpdmF0ZSBIZWFkZXIgKFAtSGVhZGVyKSBFeHRlbnNpb25z IHRvIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gDQo+Pj4+PiBQcm90b2NvbA0KPj4+Pj4gKFNJUCkN Cj4+Pj4+IGZvciB0aGUgM0dQUCIuDQo+Pj4+Pg0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cg YW5kIGF0Og0KPj4+Pj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBo cD9yZmM9NzMxNSZlaWQ9NDQ3NA0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiBUeXBlOiBUZWNobmljYWwNCj4+Pj4+IFJlcG9ydGVkIGJ5 OiBDaHJpc3RlciBIb2xtYmVyZw0KPj4+Pj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uDQo+Pj4+PiBjb20+Pg0KPj4+Pj4N Cj4+Pj4+IFNlY3Rpb246IDUuNA0KPj4+Pj4NCj4+Pj4+IE9yaWdpbmFsIFRleHQNCj4+Pj4+IC0t LS0tLS0tLS0tLS0NCj4+Pj4+IGV4dGVuc2lvbi1hY2Nlc3MtaW5mbyAgPSBnZW4tdmFsdWUNCj4+ Pj4+DQo+Pj4+PiBDb3JyZWN0ZWQgVGV4dA0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IGV4 dGVuc2lvbi1hY2Nlc3MtaW5mbyAgPSBnZW5lcmljLXBhcmFtDQo+Pj4+Pg0KPj4+Pj4gTm90ZXMN Cj4+Pj4+IC0tLS0tDQo+Pj4+PiBNb3N0IG9mIHRoZSBwcmUtZGVmaW5lZCBhY2Nlc3MtaW5mbyB2 YWx1ZXMgYXJlIGZvbGxvd2luZyB0aGUgDQo+Pj4+PiBnZW5lcmljLXBhcmFtIHN5bnRheC4gTmV3 IGFjY2Vzcy1pbmZvIHZhbHVlcyAoZXh0ZW5zaW9ucykgc2hvdWxkIA0KPj4+Pj4gYWxzbyBiZSBh bGxvd2VkIHRvIGZvbGxvdyB0aGUgZ2VuZXJpYy1wYXJhbSBzeW50YXgsIGluIG9yZGVyIHRvIA0K Pj4+Pj4gYWxsb3cgYm90aCBmb3IgYSBuYW1lIGFuZCB2YWx1ZSBvZiB0aGUgZXh0ZW5zaW9uLg0K Pj4+Pj4NCj4+Pj4+IEluc3RydWN0aW9uczoNCj4+Pj4+IC0tLS0tLS0tLS0tLS0NCj4+Pj4+IFRo aXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5lY2Vzc2Fy eSwgDQo+Pj4+PiBwbGVhc2UgdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBz aG91bGQgYmUgdmVyaWZpZWQgb3IgDQo+Pj4+PiByZWplY3RlZC4NCj4+Pj4+IFdoZW4gYSBkZWNp c2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKSBjYW4gbG9nIGluIA0K Pj4+Pj4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNz YXJ5Lg0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+PiBSRkM3MzE1IChkcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMTQpDQo+Pj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gVGl0bGUgICAg ICAgICAgICAgICA6IFByaXZhdGUgSGVhZGVyIChQLUhlYWRlcikgRXh0ZW5zaW9ucyB0byB0aGUN Cj4+Pj4+IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBmb3IgdGhlIDNHUFANCj4+ Pj4+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBKdWx5IDIwMTQNCj4+Pj4+IEF1dGhvcihzKSAgICAg ICAgICAgOiBSLiBKZXNza2UsIEsuIERyYWdlLCBDLiBIb2xtYmVyZw0KPj4+Pj4gQ2F0ZWdvcnkg ICAgICAgICAgICA6IElORk9STUFUSU9OQUwNCj4+Pj4+IFNvdXJjZSAgICAgICAgICAgICAgOiBJ RVRGIC0gTk9OIFdPUktJTkcgR1JPVVANCj4+Pj4+IEFyZWEgICAgICAgICAgICAgICAgOiBOL0EN Cj4+Pj4+IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+Pj4+PiBWZXJpZnlpbmcgUGFydHkg ICAgIDogSUVTRw0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2lwY29y ZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0K Pj4+PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K