From nobody Tue Sep 1 07:42:17 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F601B44B1; Tue, 1 Sep 2015 07:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 KPCiveAcL_Eb; Tue, 1 Sep 2015 07:42:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7022F1B44A1; Tue, 1 Sep 2015 07:42:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 07:42:12 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 14:42:14 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ecrit-additional-data-34: Yes 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Edit: I asked a question below about what happens if you dereference a block, and find the URL points to something other than what you expected. On reflection, I should expand that to ask how dereferencing errors should be handled in general.] This draft was clearly lots of work; thanks for making it happen. However, I have a number of comments: The shepherd’s writeup indicates that no XML or media type reviews were required—but this document contains a lot of XML (examples and schema), and a number of media type registrations. Is that an error in the writeup, or have those reviews been skipped? This draft implicitly assumes that the emergency calls are signaled with SIP. I don't dispute that assumption, but I think it should it's worth a paragraph stating it explicitly. -- section 2, 2nd paragraph: Are there any considerations for services provided with no "company" or "service provider" behind them? For example, lets say an individual hosts some VoIP related services for her own use (e.g. a SIP registrar, maybe a stun/turn server,etc) Are those in scope? I'm guessing not, since they would be unlikely to be registered with NENA, but it would be worth saying that explicitly. -- 3: Is there a critical need for the bit about "certain private-use situations"? That seems like license for abuse, without more elaboration about "prexisting relationship" and "privacy issues addressed". -- 4, third paragraph from end: Can you elaborate on what you mean by "at the same time"? Does that mean for the same call? Occurring in some interval of time ? -- 4.1.4 Is a provider limited to one type? If the same provider provides services in multiple categories, would they create multiple instances? -- 4.1.5: Do you intend 24x7 support to be a prerequisite to be a data provider? -- 4.1.7, Description: "Although multiple elements may be contained in a structure only one element SHOULD be provided. If more than one appears, the first SHOULD be used." When might it be reasonable to violate either of these SHOULDs? If the receiver should only look at the first entry why are multiple entries allowed at all? Also, it seems like there are vcard fields that are not useful to this purpose and might still have privacy implications. Do we really need people to send everything? -- 4.2.1, How Used..., last sentence: The term "wireless "needs more precision if you're going to use it in a 2119 expression. With a Wi-Fi handset connected to a wired Internet service count as wireless? How about a cordless phone? -- Figure 5: -Can the list of wireless types change over time? -I don't understand the full definition of "temp". Are these terms defined somewhere? -Do you really want "POTS" vs "PSTN"? -Is VoIP intentionally limited to OTT services? -- 4.3.3: What if the device model designation is not a number? -- 5, list item 1: "The "purpose" parameter also indicates the kind of data (by its MIME subtype) that is available at the URI" What happens if the URL points to something other than the indicated thing? - list item 2, last sentence: I gathered this section was an overview, since you have detailed procedures later. Please consider moving 2119 language to that section. -- Section 5, last paragraph: "only blocks in the registry are permitted to be sent using the mechanisms specified in this document" Are implementations supposed to check the registry at run time? (Also, that language sounds like it should be normative.) -- 5.1, last paragraph: "More than one Call-Info header field with a purpose value starting with ’EmergencyCallData’ can be expected, but at least one MUST be provided. The device MUST provide one if it knows no service provider is in the path of the call." What's the scope of the first MUST? Emergency calls? Is it possible the device doesn't know whether there is a service provider in the path? Should this say it MUST insert unless it knows there is a service provider in tHe path? -- 8: It might be worth discussing the potential harm done by a malicious proxy modifying a data element, or a compromised data source return incorrect information when dereferencing a URL. The first paragraph REQUIRES verification of requester credentials, but does specify the form of those credentials. Subsequent text talks about client-certs and PKI verification. Are other forms of credentials allows? (HTTP-digest, application level logins, etc). If client-certs are required, please say that explicitly. - "PSAPs and responder agencies SHOULD deploy a PKI " When might they not? What if they don't? - "emergency services authorities could obtain a credential from the DNS entry of the domain" Can you elaborate on that or cite something? - paragraph starting with "Much of the information supplied by service providers and devices is private and confidential": Seems like that should go in the privacy considerations. (And probably also the intro.) -- section 10: Many of the registry policies require experts to access whether an organization might be "legitimate" or "relevant". Are these reasonable expectations on the DEs? (I don't know the answer.) Nits and Editorial Comments: -- 4.2.1, Description: Currently, the only valid entries are... Current as of when? I suggest "The initially valid entries are..." -- 4.2.1, How Used... : "... service provider does not know ..." Does not know...what? (That's part of a long, convoluted sentence. Please consider breaking it into simpler sentences.) "... it is known to be valuable." Known by whom? -- 4.3.1, Description: "It is possible to receive two Additional Data Associated with a Call data structures,..." (Occurs in several places.) The naming is confusing. It's easy to read "additional data associated with..." as it's plain English meaning, rather than as a name. I suggest doing something more distinctive than capital letters. Perhaps quotes, or even an abbreviation. -- 4.3.7: That seems odd for this to be a subsection of the device information function. -- section 5: It seems awkard to use a numbered list for elements that are close to a page long each. This forces each to be a single, overlong paragraph. Please consider subsections. -- section 5, list item 2: "circumstances about the provision of the location" I'm not sure I understand the meaning of "provision" in this context. - Sentence starting with: "When the access network provider" This sentence provides context information that would have been useful to have at the start of the section. -- 5.4, 2nd paragraph: I think people are going to be confused and look for "by-reference" in 3204 or 3459. It might be worth re-citing 5621. --10: Some sections reference tables from other sections, and some include the tables directly. It would be nice to be consistent, one way or the other. From nobody Tue Sep 1 10:01:17 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9AA1B5350 for ; Tue, 1 Sep 2015 10:01:14 -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 Ckj-Kopet1YV for ; Tue, 1 Sep 2015 10:01:12 -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 ADF6E1B51B9 for ; Tue, 1 Sep 2015 10:01:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0A6682071E for ; Tue, 1 Sep 2015 13:01:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 01 Sep 2015 13:01: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=TM3AqgLTVRHAq/T15Ovc5xexaqI=; b=hS4H6E jHR0sfDpK4Qd3kyxonBfw7j85QOlhHTwCTiV2LVMhTphCP1lKZ+c2QKEVSJKiGHE xjL4SRG0ch++eoNPaq6D2ZrBGgaYVINAeYpBLb3C9yuMha/aOtFix20JwiD/Ud61 vjQ2EHrY7zKFLm2ChXVcEewVVr/jyb+oeCJnc= 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=TM3AqgLTVRHAq/T 15Ovc5xexaqI=; b=I6pV0ufuS/TF8sJTkf/1n4aHnoSnw/hlXNG6qsOJ+Jf4bWy lb5nVcYWsiUFeSaGOPXO4LSnF3lgLXHCEYhZrkyDl/J/oL8xIYQfXXeK8EHVfrOg V53l1RquBan/u3eQh2f27aTeGEzouyDhLy999+MFihUkuo08K56PJqdKWzBA= X-Sasl-enc: dQbEtezBqnTlJxW2NvRuci05OcVL2j3QJCjOaGRnhf5r 1441126871 Received: from dhcp-171-68-20-136.cisco.com (dhcp-171-68-20-136.cisco.com [171.68.20.136]) by mail.messagingengine.com (Postfix) with ESMTPA id C29AAC0001F; Tue, 1 Sep 2015 13:01:10 -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: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> Date: Tue, 1 Sep 2015 10:01:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:01:14 -0000 Hi Ben, Thanks for your comments. One note below. > On Sep 1, 2015, at 7:42 AM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: Yes >=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 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > [Edit: I asked a question below about what happens if you dereference = a > block, and find the URL points to something other than what you = expected. > On reflection, I should expand that to ask how dereferencing errors > should be handled in general.]=20 >=20 > This draft was clearly lots of work; thanks for making it happen. > However, I have a number of comments: >=20 > The shepherd=E2=80=99s writeup indicates that no XML or media type = reviews were > required=E2=80=94but this document contains a lot of XML (examples and = schema), > and a number of media type registrations. Is that an error in the > writeup,=20 > or have those reviews been skipped? I asked about this in my AD review and I believe Marc did these after = submitting the write-up and the write-up did not then get updated. Marc = is on vacation this week so he may not be able to confirm until he gets = back. Alissa From nobody Tue Sep 1 10:04:45 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8351B3F94; Tue, 1 Sep 2015 10:04:41 -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=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 jTVdUxGE1ubi; Tue, 1 Sep 2015 10:04:40 -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 C10431ACECF; Tue, 1 Sep 2015 10:04:37 -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 t81H4NEx060536 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2015 12:04:34 -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: "Alissa Cooper" Date: Tue, 01 Sep 2015 12:04:23 -0500 Message-ID: <45A3349E-A6FC-4B86-B9B9-91608F51A1DC@nostrum.com> In-Reply-To: References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 17:04:41 -0000 On 1 Sep 2015, at 12:01, Alissa Cooper wrote: > Hi Ben, > > Thanks for your comments. One note below. > >> On Sep 1, 2015, at 7:42 AM, Ben Campbell wrote: >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-ecrit-additional-data-34: Yes >> >> 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.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> [Edit: I asked a question below about what happens if you dereference >> a >> block, and find the URL points to something other than what you >> expected. >> On reflection, I should expand that to ask how dereferencing errors >> should be handled in general.] >> >> This draft was clearly lots of work; thanks for making it happen. >> However, I have a number of comments: >> >> The shepherd’s writeup indicates that no XML or media type reviews >> were >> required—but this document contains a lot of XML (examples and >> schema), >> and a number of media type registrations. Is that an error in the >> writeup, >> or have those reviews been skipped? > > I asked about this in my AD review and I believe Marc did these after > submitting the write-up and the write-up did not then get updated. > Marc is on vacation this week so he may not be able to confirm until > he gets back. > On digging through old email, I see evidence that he did that for the XML parts. Do you know if there was a MIME media type review? I guess IANA will kick off a final review before registration? > Alissa From nobody Tue Sep 1 13:49:53 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897091B444E; Tue, 1 Sep 2015 13:49:49 -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 CKdOmhRvQ73h; Tue, 1 Sep 2015 13:49:48 -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 7AC211B4448; Tue, 1 Sep 2015 13:49:48 -0700 (PDT) Received: by vkbf67 with SMTP id f67so59039081vkb.0; Tue, 01 Sep 2015 13:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ublhjWy2fzxvjqx0gmotGX++GhuXtPmD/Y7cMhDFOLY=; b=xkYXVZjjGAbAiSBsiYbIaNsyNT3tvMeQR9CpHTths357E3nrzYXnE3kXYctmvyj6au WZ82pKPIcdpDZyJMUXP+S1v7VUkrcyKB1lN8x+BZnZNSTCyCIc7DkhzYVYLmm/xEWWtd T5zEowytHQcVmGBD3yuAgX6625+XQ8o+cxDEcNw4HNg1gT+ZnPBkok0oOUbtjxV2rETM ytiMCxSQs/EjRwCuDXf9Pm4aDV57pskcBkN54FSHu98lMixk/+VoEtl0jl0ehZakW4He T8q1mYFe1YUvrtjTjpHbdPJfaK/HbgP4B1JN9pzZ9CIpPeodIjmOxnzpTO/4pAIegOA1 t7Sg== MIME-Version: 1.0 X-Received: by 10.52.32.230 with SMTP id m6mr31296057vdi.80.1441140587613; Tue, 01 Sep 2015 13:49:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 1 Sep 2015 13:49:47 -0700 (PDT) In-Reply-To: <45A3349E-A6FC-4B86-B9B9-91608F51A1DC@nostrum.com> References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <45A3349E-A6FC-4B86-B9B9-91608F51A1DC@nostrum.com> Date: Tue, 1 Sep 2015 16:49:47 -0400 X-Google-Sender-Auth: eIp_rc01mgMUSzSiCbi4Z9Yyxp0 Message-ID: From: Barry Leiba To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 20:49:49 -0000 > On digging through old email, I see evidence that he did that for the XML > parts. Do you know if there was a MIME media type review? I guess IANA will > kick off a final review before registration? No, they won't. Media types in IETF Standards Track documents no longer need expert review. I've been reviewing this document today (will post my comments soon), and find the media type registrations to be mostly OK (I have to check on character encoding things). If I had questions, I'd ask someone to post to the media-types list for review there... which is recommended, but not required. I don't have questions, so I'm not going to push for that. Barry From nobody Tue Sep 1 13:57:46 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7141A03A9; Tue, 1 Sep 2015 13:57:41 -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=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 ZR23xKBqs286; Tue, 1 Sep 2015 13:57:40 -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 AFD291B459B; Tue, 1 Sep 2015 13:57:40 -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 t81KvQFD081321 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2015 15:57:36 -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: "Barry Leiba" Date: Tue, 01 Sep 2015 15:57:25 -0500 Message-ID: In-Reply-To: References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <45A3349E-A6FC-4B86-B9B9-91608F51A1DC@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 20:57:41 -0000 On 1 Sep 2015, at 15:49, Barry Leiba wrote: >> On digging through old email, I see evidence that he did that for the >> XML >> parts. Do you know if there was a MIME media type review? I guess >> IANA will >> kick off a final review before registration? > > No, they won't. Media types in IETF Standards Track documents no > longer need expert review. I've been reviewing this document today > (will post my comments soon), and find the media type registrations to > be mostly OK (I have to check on character encoding things). If I had > questions, I'd ask someone to post to the media-types list for review > there... which is recommended, but not required. I don't have > questions, so I'm not going to push for that. > Okay, I didn't realize we had changed that requirement. For the record, I didn't find anything in the media-type registrations that raised questions. Ben. From nobody Tue Sep 1 16:47:58 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3345D1B3041; Tue, 1 Sep 2015 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 Vhf2mc8rqXsR; Tue, 1 Sep 2015 16:47:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E33F01B2E4F; Tue, 1 Sep 2015 16:47:54 -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: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 16:47:54 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 23:47:57 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ecrit-additional-data-34: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I've two things I'd like to chat about. (Note: I'm not trying here to insist on my preferred outcome, but I would like to have the discussion or else be pointed at where the WG already did that.) (1) section 3: You say these MAY be used. I'm not sure that's a good option. I think the data minimisation recommendations argued for in RFC6973 and RFC7258 would argue to add a MUST NOT. For example, saying that these additional data MUST NOT be sent in any non-emergency call without explicit user permission on a per-call basis or something similar? I have to admit I'm nervous that defining all of these may mean that some UA somewhere starts sending some of them in other calls without asking. A restriction along those lines would also be more in line with webrtc too perhaps. But maybe this was discussed in the WG, having considered those privacy issues - was it? Either way, would adding such a "MUST NOT except if..." be a good plan? 4.3.4 is a good example of the kind of thing I'd not want easily emitted in a call. (2) I'd like to (perhaps briefly) argue that the registries here should require more than expert review. Extensibility in dealing with what will inevitably be highly privacy sensitive data structures that are vulnerable to misuse once registered seems to perhaps call for a more stringent registration regime. The document itself also argues (in 4.3.7) that adding new kinds of data here can be counter productive for emergency call handling, so being more conservative in what we add seems unusually correct here. I'd like to suggest we require standards track for extensions. The following very recent -00 draft [1] makes some related arguments (but of course has no standing in the IETF so is just offered as a way to avoid repeating some arguments, not as an appeal to authority.) [1] https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: the "or by reference" point is made twice in the abstract - intro: floor plans? HVAC status? really? Why not contact lists? proximity of friends? That (or inferring as much) seems to me to be going too far, if applied to all calls. I'd say just saying that this could be extended in future by other standards-track specifications is enough. (See also discuss points above) - intro: Wedding anniversary? That's surely not relevant to a PSAP. - figure 5: "prison" is out of context here, I'd suggest deleting it. If not, why not add hospital, power station and many other kinds of building? There may be some country specific issue or technical here, but labelling that with "prison" seems inappropriate to me. - 4.3.8: sorry I don't get the privacy argument, can you try explain it to me? (I didn't know it was possible to tempt an implementation, so the language there could be improved for sure:-) - section 5: good that this is HTTPS only. I think provisioning the PKI for such a thing is easily done these days and is rightly not optional. It might be useful to say that TLS here needs to follow BCP195. I agree with the earlier comment that you should be clear as to when mutually authenticated TLS is required. The secdir review [2] also raised similar issues and it'd be good to see responses to that too. (Yes, that review only arrived today so it's entirely reasonable to not have responded so far.) [2] https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html - section 8: the sizes of the various additional data items here could be characteristic and leak value information regardless of TLS or not-TLS - perhaps add a warning that these may enable relatively simple traffic analysis. And wouldn't it be nice if someone had done the analysis of this potential vulnerability? This is btw a real issue - recall that avatar icon image size was usable to identify 30+% of contacts in one social network even over TLS, but before the provider canonicalised the avatar image sizes. - Thanks for section 9. Good job. From nobody Tue Sep 1 18:09:19 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E8D1B2BFF for ; Tue, 1 Sep 2015 18:09:17 -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 UFlnu031sjOQ for ; Tue, 1 Sep 2015 18:09:16 -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 DA9B21B2BD6 for ; Tue, 1 Sep 2015 18:09:16 -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 t82194mD004478 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2015 20:09:15 -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: "Stephen Farrell" Date: Tue, 01 Sep 2015 20:09:04 -0500 Message-ID: <9239AA5B-97F3-4A7E-A921-1F2CD8F14CAC@nostrum.com> In-Reply-To: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 01:09:18 -0000 One comment-comment: On 1 Sep 2015, at 18:47, Stephen Farrell wrote: > - figure 5: "prison" is out of context here, I'd suggest > deleting it. If not, why not add hospital, power station > and many other kinds of building? There may be some > country specific issue or technical here, but labelling > that with "prison" seems inappropriate to me. Hopefully the authors have more specifics, but my understanding is, at least in the US, prison inmate phone systems get very special handling. I can't speak for other countries. From nobody Tue Sep 1 18:36:14 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FC61B3655; Tue, 1 Sep 2015 18:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 0-K2g20n6p77; Tue, 1 Sep 2015 18:36:09 -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 472371B3650; Tue, 1 Sep 2015 18:36:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67FFEBE54; Wed, 2 Sep 2015 02:36:07 +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 J62aW7vKtfAf; Wed, 2 Sep 2015 02:36:06 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.16.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1A4A1BE4D; Wed, 2 Sep 2015 02:36:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441157766; bh=pg7GwgifwebrgFXiTXYhnSUIIxGAUt6f276URqjO7pw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OQgLsLtiCYoXV77CKS8sHjQlv26EbGiUK8OrGnI1NkbiTEPVTvMN1mmO+eNbixQKb 9lB2iYD/TRx6hppPTVxTqM0SSnm4fS5Dvsu2vuurLLLLYDJK93SbkR3+JOjC5KHeHx ZzxOezDFwBTQoS7q13x7xAssL4UlKQY8R9z7cdPQ= To: Ben Campbell References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <9239AA5B-97F3-4A7E-A921-1F2CD8F14CAC@nostrum.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E65285.9010609@cs.tcd.ie> Date: Wed, 2 Sep 2015 02:36:05 +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: <9239AA5B-97F3-4A7E-A921-1F2CD8F14CAC@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 01:36:11 -0000 Hiya, On 02/09/15 02:09, Ben Campbell wrote: > > Hopefully the authors have more specifics, but my understanding is, at > least in the US, prison inmate phone systems get very special handling. > I can't speak for other countries. Sure. And many other countries have many other oddities no doubt. I'd not be surprised if emergency call from mobiles in pubs late in the evening were treated a bit differently for example in many places. So I guess I'm suggesting to isolate the technical aspects of that handling and put one or more descriptors for those into the table. Assigning very country specific meanings to generic terms is probably not a great plan. S. From nobody Tue Sep 1 22:00:05 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC431B4464; Tue, 1 Sep 2015 22:00:04 -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 R8kIvrsT7JR2; Tue, 1 Sep 2015 22:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 574AF1B4454; Tue, 1 Sep 2015 22:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 22:00:02 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 05:00:04 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ecrit-additional-data-34: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Two things are incorrect and need fixing: ---- In Section 4, you have "tel" and "TYPE", and "property" and "parameter" reversed in the explanation about the "main" parameter value. The sentence is also confusingly worded. Try this (and see also my comments on this bit, below): NEW This document adds a new parameter value called "main" to the "TYPE" parameter of the "tel" property. END ---- In Section 6, there are problems in the MIME structure in the examples (figures 16 and 17). 1. The XML content should be indented at least as much as the SIP headers, so you should either make sure that all XML lines are indented at least 6 characters, or you should make the SIP headers be indented only by 3. 2. There should not be a blank line between the Content-Type and Content-Length headers. 3. There should not be a blank line after each boundary line; the part headers should start immediately, as the first blank line ends the headers. 4. There should be a blank line between the Content-Disposition header and the XML content; that blank line ends the part headers and signals the start of the part body. 5. The intermediate boundary lines should not have the trailing "--"; that's reserved for the ending boundary. The intermediates should all be "--boundary1". 6. Figure 17 is missing the ending boundary, "--boundary1--", at the very end of the figure. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Throughout the document: The current term is "media type", not "MIME type". It would be good if you can change that throughout the document. -- Section 3 -- A tiny, tiny point: I don't think the MAY in the last sentence is really a 2119 key word, and suggest making it lower case. -- Section 4 -- In an xCard there is no way to specify a "main" telephone number. These numbers are useful to emergency responders who are called to a large enterprise. This document adds a new property value to the "tel" property of the TYPE parameter called "main". This doesn't explain sufficiently what you're after. I initially wondered why the PREF parameter didn't give you what you need (PREF=1, this is my main phone number). It was only when I read the registration in Section 10 that I understood. I'd suggest a value other than "main", but I can't think of one right away. At the least, please add more text here to explain what you mean by "main". I'll also note that none of the examples include the new "main" parameter value. Given that you're creating the value, it might be good to show it in use. -- Section 4.1.5 -- The Data Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format fully specified with country code. If a TEL URI is not available, it MAY be a generic SIP URI. 2119 key word problem @1: "you SHOULD do X, but you MAY do Y instead." MAY contradicts the SHOULD. It's not so bad here because your "if" restricts the MAY (Section 5.3 isn't that way; see below), but I'd prefer it if you'd change it to something like "If a TEL URI is not available, a generic SIP URI is acceptable." Or perhaps "A generic SIP URI is acceptable only if a TEL URI is not available," which is a little stronger. -- Section 4.4.2 -- If more than one property is provided, a parameter from the vCard Property Value registry MUST be specified on each . Do you really want that MUST, rather than a SHOULD? Are you really saying that if there are multiple phone numbers but I don't know their TYPE values, it's better to pick one and send only that one than it is to send you all of them just in case? -- Section 5.1 -- The data may also be supplied by value in any SIP request or response method that is permitted to contain a body (i.e., not a BYE request). Is BYE the only SIP request that can't contain a body? Or should that be "e.g."? (I'm asking; I don't know the answer.) -- Section 5.3 -- It is RECOMMENDED that access networks supply the data specified in this document by reference, but they MAY provide the data by value. Here's the SHOULD/MAY problem without an "if" to mitigate it. In this case, I suggest explaining: NEW It is RECOMMENDED that access networks supply the data specified in this document by reference. While it's permissible to provide the data by value, this can expose private information [and/or whatever other explanation]. END -- Section 10.1 -- Thanks for providing guidance to the expert reviewers; that's really helpful. -- Section 11 -- Is the comma in "Christian, Militeau" spurious? -- Appendix A -- You appear to have turned the RELAX NG schema from RFC 6351 into an XML schema and put it here, but then labelled it as informational -- a hedge, I guess, in case there's a mistake in this version. Why does it need to be included here? And how much review has it actually had, to make sure that there weren't any mistakes in the conversion? From nobody Wed Sep 2 07:52:47 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3181B4598; Wed, 2 Sep 2015 07:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 sMPdFT8DRvsV; Wed, 2 Sep 2015 07:52:43 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 17ED01B4597; Wed, 2 Sep 2015 07:52:43 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t82Ek5Eu031967; Wed, 2 Sep 2015 10:52:40 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1wp13n06wg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 10:52:40 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 2 Sep 2015 10:52:38 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) Thread-Index: AQHQ5Y8C1Qw9fTR1hU6qymoWFTGx9A== Date: Wed, 2 Sep 2015 14:52:37 +0000 Message-ID: <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> In-Reply-To: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.128.33] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:52:45 -0000 SeKAmW0gb2theSB3aXRoIHRoZSBNVVNUIE5PVCBleGNlcHQsIGFuZCBJIGNhbiBpbWFnaW5lIG90 aGVyIHVzZXMgZm9yIHRoZXNlIHRoYXQgd2lsbCB3b3JrIGZpbmUgaWYgd2Ugd3JpdGUgYSBkb2N1 bWVudCB0aGF0IGV4cGxhaW5zIHRoZW0uDQoNCknigJltIHN0cm9uZ2x5IGFnYWluc3Qgc3RhbmRh cmRzIHRyYWNrIGZvciBleHRlbnNpb25zLiAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG9yZ2FuaXph dGlvbnMgd2hvIGhhdmUgZXhwZXJ0aXNlIHRoYXQgbmVlZCB0byBiZSBhYmxlIHRvIGRlZmluZSB0 aGUgZGF0YS4gIFdlIGNhbuKAmXQgYmUgZXhwZXJ0cyBpbiBhbGwgdGhpbmdzLiAgQW4gZXhhbXBs ZSBpcyB0aGF0IHdl4oCZcmUgZ29pbmcgdG8gZXh0ZW5kIGZvciBtZWRpY2FsIGRhdGEgdXNlZnVs IHRvIGEgZmlyc3QgcmVzcG9uZGVyLiAgQ2xlYXJseSBoYXMgbWFqb3IgcHJpdmFjeSBpc3N1ZXMs IGJ1dCB3ZeKAmXJlIG5vdCB0aGUgZXhwZXJ0cyBpbiB0aGF0LCBhbmQgdGhvc2UgdGhhdCBhcmUg ZG9u4oCZdCB3cml0ZSBSRkNzLiAgTkVOQSwgdGhlIDktMS0xIG9yZ2FuaXphdGlvbiBpbiBOb3J0 aCBBbWVyaWNhIGlzIHdvcmtpbmcgb24gZXh0ZW5zaW9ucyBmb3IgbG9jYXRpb24gcmVsYXRlZCBk YXRhLCBhbmQgYWxzbyBrbm93cyAxMFggbW9yZSBhYm91dCBsb2NhdGlvbiBkYXRhIGZvciBlbWVy Z2VuY3kgcmVzcG9uc2UgdGhhbiBJRVRGIGRvZXMuICBXZSBuZWVkIHRvIGxldCB0aGUgZXhwZXJ0 cyBkbyB0aGVpciBqb2JzLg0KDQpCcmlhbg0KDQo+IE9uIFNlcCAxLCAyMDE1LCBhdCA0OjQ3IFBN LCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPiAN Cj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWVjcml0LWFkZGl0aW9uYWwtZGF0YS0zNDogRGlzY3Vzcw0K PiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJh Z3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4g DQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiBJJ3ZlIHR3byB0aGlu Z3MgSSdkIGxpa2UgdG8gY2hhdCBhYm91dC4gKE5vdGU6IEknbSBub3QgdHJ5aW5nDQo+IGhlcmUg dG8gaW5zaXN0IG9uIG15IHByZWZlcnJlZCBvdXRjb21lLCBidXQgSSB3b3VsZCBsaWtlIHRvDQo+ IGhhdmUgdGhlIGRpc2N1c3Npb24gb3IgZWxzZSBiZSBwb2ludGVkIGF0IHdoZXJlIHRoZSBXRyAN Cj4gYWxyZWFkeSBkaWQgdGhhdC4pDQo+IA0KPiAoMSkgc2VjdGlvbiAzOiBZb3Ugc2F5IHRoZXNl IE1BWSBiZSB1c2VkLiAgSSdtIG5vdA0KPiBzdXJlIHRoYXQncyBhIGdvb2Qgb3B0aW9uLiAgSSB0 aGluayB0aGUgZGF0YQ0KPiBtaW5pbWlzYXRpb24gcmVjb21tZW5kYXRpb25zIGFyZ3VlZCBmb3Ig aW4gUkZDNjk3MyBhbmQNCj4gUkZDNzI1OCB3b3VsZCBhcmd1ZSB0byBhZGQgYSBNVVNUIE5PVC4g Rm9yIGV4YW1wbGUsDQo+IHNheWluZyB0aGF0IHRoZXNlIGFkZGl0aW9uYWwgZGF0YSBNVVNUIE5P VCBiZSBzZW50IGluDQo+IGFueSBub24tZW1lcmdlbmN5IGNhbGwgd2l0aG91dCBleHBsaWNpdCB1 c2VyDQo+IHBlcm1pc3Npb24gb24gYSBwZXItY2FsbCBiYXNpcyBvciBzb21ldGhpbmcgc2ltaWxh cj8NCj4gSSBoYXZlIHRvIGFkbWl0IEknbSBuZXJ2b3VzIHRoYXQgZGVmaW5pbmcgYWxsIG9mIHRo ZXNlDQo+IG1heSBtZWFuIHRoYXQgc29tZSBVQSBzb21ld2hlcmUgc3RhcnRzIHNlbmRpbmcgc29t ZSBvZg0KPiB0aGVtIGluIG90aGVyIGNhbGxzIHdpdGhvdXQgYXNraW5nLiBBIHJlc3RyaWN0aW9u DQo+IGFsb25nIHRob3NlIGxpbmVzIHdvdWxkIGFsc28gYmUgbW9yZSBpbiBsaW5lIHdpdGgNCj4g d2VicnRjIHRvbyBwZXJoYXBzLiBCdXQgbWF5YmUgdGhpcyB3YXMgZGlzY3Vzc2VkIGluDQo+IHRo ZSBXRywgaGF2aW5nIGNvbnNpZGVyZWQgdGhvc2UgcHJpdmFjeSBpc3N1ZXMgLSB3YXMNCj4gaXQ/ IEVpdGhlciB3YXksIHdvdWxkIGFkZGluZyBzdWNoIGEgIk1VU1QgTk9UIGV4Y2VwdA0KPiBpZi4u LiIgYmUgYSBnb29kIHBsYW4/ICA0LjMuNCBpcyBhIGdvb2QgZXhhbXBsZSBvZiB0aGUNCj4ga2lu ZCBvZiB0aGluZyBJJ2Qgbm90IHdhbnQgZWFzaWx5IGVtaXR0ZWQgaW4gYSBjYWxsLg0KPiANCj4g KDIpIEknZCBsaWtlIHRvIChwZXJoYXBzIGJyaWVmbHkpIGFyZ3VlIHRoYXQgdGhlDQo+IHJlZ2lz dHJpZXMgaGVyZSBzaG91bGQgcmVxdWlyZSBtb3JlIHRoYW4gZXhwZXJ0DQo+IHJldmlldy4gRXh0 ZW5zaWJpbGl0eSBpbiBkZWFsaW5nIHdpdGggd2hhdCB3aWxsDQo+IGluZXZpdGFibHkgYmUgaGln aGx5IHByaXZhY3kgc2Vuc2l0aXZlIGRhdGEgc3RydWN0dXJlcw0KPiB0aGF0IGFyZSB2dWxuZXJh YmxlIHRvIG1pc3VzZSBvbmNlIHJlZ2lzdGVyZWQgc2VlbXMgdG8NCj4gcGVyaGFwcyBjYWxsIGZv ciBhIG1vcmUgc3RyaW5nZW50IHJlZ2lzdHJhdGlvbiByZWdpbWUuDQo+IFRoZSBkb2N1bWVudCBp dHNlbGYgYWxzbyBhcmd1ZXMgKGluIDQuMy43KSB0aGF0IGFkZGluZw0KPiBuZXcga2luZHMgb2Yg ZGF0YSBoZXJlIGNhbiBiZSBjb3VudGVyIHByb2R1Y3RpdmUgZm9yDQo+IGVtZXJnZW5jeSBjYWxs IGhhbmRsaW5nLCBzbyBiZWluZyBtb3JlIGNvbnNlcnZhdGl2ZSBpbg0KPiB3aGF0IHdlIGFkZCBz ZWVtcyB1bnVzdWFsbHkgY29ycmVjdCBoZXJlLiBJJ2QgbGlrZSB0bw0KPiBzdWdnZXN0IHdlIHJl cXVpcmUgc3RhbmRhcmRzIHRyYWNrIGZvciBleHRlbnNpb25zLg0KPiBUaGUgZm9sbG93aW5nIHZl cnkgcmVjZW50IC0wMCBkcmFmdCBbMV0gbWFrZXMgc29tZQ0KPiByZWxhdGVkIGFyZ3VtZW50cyAo YnV0IG9mIGNvdXJzZSBoYXMgbm8gc3RhbmRpbmcgaW4NCj4gdGhlIElFVEYgc28gaXMganVzdCBv ZmZlcmVkIGFzIGEgd2F5IHRvIGF2b2lkDQo+IHJlcGVhdGluZyBzb21lIGFyZ3VtZW50cywgbm90 IGFzIGFuIGFwcGVhbCB0bw0KPiBhdXRob3JpdHkuKQ0KPiANCj4gICBbMV0NCj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5vdHRpbmdoYW0tdHJhbnNwb3J0LW1ldGFkYXRhLWlt cGFjdC0wMA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiANCj4gDQo+IC0gYWJzdHJhY3Q6IHRoZSAib3IgYnkgcmVmZXJlbmNlIiBwb2ludCBp cyBtYWRlIHR3aWNlDQo+IGluIHRoZSBhYnN0cmFjdA0KPiANCj4gLSBpbnRybzogZmxvb3IgcGxh bnM/IEhWQUMgc3RhdHVzPyByZWFsbHk/IFdoeSBub3QNCj4gY29udGFjdCBsaXN0cz8gcHJveGlt aXR5IG9mIGZyaWVuZHM/IFRoYXQgKG9yDQo+IGluZmVycmluZyBhcyBtdWNoKSBzZWVtcyB0byBt ZSB0byBiZSBnb2luZyB0b28gZmFyLCBpZg0KPiBhcHBsaWVkIHRvIGFsbCBjYWxscy4gSSdkIHNh eSBqdXN0IHNheWluZyB0aGF0IHRoaXMNCj4gY291bGQgYmUgZXh0ZW5kZWQgaW4gZnV0dXJlIGJ5 IG90aGVyIHN0YW5kYXJkcy10cmFjaw0KPiBzcGVjaWZpY2F0aW9ucyBpcyBlbm91Z2guIChTZWUg YWxzbyBkaXNjdXNzIHBvaW50cyBhYm92ZSkNCj4gDQo+IC0gaW50cm86IFdlZGRpbmcgYW5uaXZl cnNhcnk/IFRoYXQncyBzdXJlbHkgbm90DQo+IHJlbGV2YW50IHRvIGEgUFNBUC4gDQo+IA0KPiAt IGZpZ3VyZSA1OiAicHJpc29uIiBpcyBvdXQgb2YgY29udGV4dCBoZXJlLCBJJ2Qgc3VnZ2VzdCAN Cj4gZGVsZXRpbmcgaXQuIElmIG5vdCwgd2h5IG5vdCBhZGQgaG9zcGl0YWwsIHBvd2VyIHN0YXRp b24gDQo+IGFuZCBtYW55IG90aGVyIGtpbmRzIG9mIGJ1aWxkaW5nPyBUaGVyZSBtYXkgYmUgc29t ZSANCj4gY291bnRyeSBzcGVjaWZpYyBpc3N1ZSBvciB0ZWNobmljYWwgaGVyZSwgYnV0IGxhYmVs bGluZyANCj4gdGhhdCB3aXRoICJwcmlzb24iIHNlZW1zIGluYXBwcm9wcmlhdGUgdG8gbWUuIA0K PiANCj4gLSA0LjMuODogc29ycnkgSSBkb24ndCBnZXQgdGhlIHByaXZhY3kgYXJndW1lbnQsIGNh bg0KPiB5b3UgdHJ5IGV4cGxhaW4gaXQgdG8gbWU/ICAoSSBkaWRuJ3Qga25vdyBpdCB3YXMNCj4g cG9zc2libGUgdG8gdGVtcHQgYW4gaW1wbGVtZW50YXRpb24sIHNvIHRoZSBsYW5ndWFnZQ0KPiB0 aGVyZSBjb3VsZCBiZSBpbXByb3ZlZCBmb3Igc3VyZTotKQ0KPiANCj4gLSBzZWN0aW9uIDU6IGdv b2QgdGhhdCB0aGlzIGlzIEhUVFBTIG9ubHkuIEkgdGhpbmsNCj4gcHJvdmlzaW9uaW5nIHRoZSBQ S0kgZm9yIHN1Y2ggYSB0aGluZyBpcyBlYXNpbHkgZG9uZQ0KPiB0aGVzZSBkYXlzIGFuZCBpcyBy aWdodGx5IG5vdCBvcHRpb25hbC4gSXQgbWlnaHQgYmUNCj4gdXNlZnVsIHRvIHNheSB0aGF0IFRM UyBoZXJlIG5lZWRzIHRvIGZvbGxvdyBCQ1AxOTUuICBJDQo+IGFncmVlIHdpdGggdGhlIGVhcmxp ZXIgY29tbWVudCB0aGF0IHlvdSBzaG91bGQgYmUNCj4gY2xlYXIgYXMgdG8gd2hlbiBtdXR1YWxs eSBhdXRoZW50aWNhdGVkIFRMUyBpcw0KPiByZXF1aXJlZC4gVGhlIHNlY2RpciByZXZpZXcgWzJd IGFsc28gcmFpc2VkIHNpbWlsYXINCj4gaXNzdWVzIGFuZCBpdCdkIGJlIGdvb2QgdG8gc2VlIHJl c3BvbnNlcyB0byB0aGF0IHRvby4NCj4gKFllcywgdGhhdCByZXZpZXcgb25seSBhcnJpdmVkIHRv ZGF5IHNvIGl0J3MgZW50aXJlbHkNCj4gcmVhc29uYWJsZSB0byBub3QgaGF2ZSByZXNwb25kZWQg c28gZmFyLikNCj4gDQo+ICAgWzJdDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDU5ODIuaHRtbA0KPiANCj4gLSBzZWN0aW9uIDg6IHRo ZSBzaXplcyBvZiB0aGUgdmFyaW91cyBhZGRpdGlvbmFsIGRhdGENCj4gaXRlbXMgaGVyZSBjb3Vs ZCBiZSBjaGFyYWN0ZXJpc3RpYyBhbmQgbGVhayB2YWx1ZQ0KPiBpbmZvcm1hdGlvbiByZWdhcmRs ZXNzIG9mIFRMUyBvciBub3QtVExTIC0gcGVyaGFwcyBhZGQNCj4gYSB3YXJuaW5nIHRoYXQgdGhl c2UgbWF5IGVuYWJsZSByZWxhdGl2ZWx5IHNpbXBsZQ0KPiB0cmFmZmljIGFuYWx5c2lzLiBBbmQg d291bGRuJ3QgaXQgYmUgbmljZSBpZiBzb21lb25lDQo+IGhhZCBkb25lIHRoZSBhbmFseXNpcyBv ZiB0aGlzIHBvdGVudGlhbCB2dWxuZXJhYmlsaXR5Pw0KPiBUaGlzIGlzIGJ0dyBhIHJlYWwgaXNz dWUgLSByZWNhbGwgdGhhdCBhdmF0YXIgaWNvbg0KPiBpbWFnZSBzaXplIHdhcyB1c2FibGUgdG8g aWRlbnRpZnkgMzArJSBvZiBjb250YWN0cyBpbg0KPiBvbmUgc29jaWFsIG5ldHdvcmsgZXZlbiBv dmVyIFRMUywgYnV0IGJlZm9yZSB0aGUNCj4gcHJvdmlkZXIgY2Fub25pY2FsaXNlZCB0aGUgYXZh dGFyIGltYWdlIHNpemVzLiANCj4gDQo+IC0gVGhhbmtzIGZvciBzZWN0aW9uIDkuIEdvb2Qgam9i Lg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg== From nobody Wed Sep 2 07:57:48 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DD91B39BA; Wed, 2 Sep 2015 07:57:46 -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 WjhFLoyNRGaK; Wed, 2 Sep 2015 07:57: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 6091A1B3313; Wed, 2 Sep 2015 07:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2FA24BE7D; Wed, 2 Sep 2015 15:57:41 +0100 (IST) 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 2ODQ4TdOb40P; Wed, 2 Sep 2015 15:57:41 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC2CABE5D; Wed, 2 Sep 2015 15:57:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441205861; bh=TsDyRobVMmxwYQxhIeJKe8wy/me/ChsT/+MipIp9ses=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jfuV2kn4o+Je1UlERtUXH13qbSVj0GQPtiD3OzoHfeuRQh16PJjZ8ut1haaaw0Eq0 U4OHW5zOwK9eLbd2C/PKODjegVJp3uvMXmMAdCsV5Y/wZ3DcLn559hUbtfMgNt1vM5 J+xbdSx0CYpF97glRzyynG2oNBilgFxPwSPeobxM= To: "Rosen, Brian" References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E70E64.9060601@cs.tcd.ie> Date: Wed, 2 Sep 2015 15:57:40 +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: <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , The IESG , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 14:57:46 -0000 On 02/09/15 15:52, Rosen, Brian wrote: > I’m okay with the MUST NOT except, and I can imagine other uses for > these that will work fine if we write a document that explains them. Cool, should be relatively easy to work out words if everyone agrees on that. > > I’m strongly against standards track for extensions. There are a > number of organizations who have expertise that need to be able to > define the data. We can’t be experts in all things. An example is > that we’re going to extend for medical data useful to a first > responder. Clearly has major privacy issues, but we’re not the > experts in that, and those that are don’t write RFCs. NENA, the > 9-1-1 organization in North America is working on extensions for > location related data, and also knows 10X more about location data > for emergency response than IETF does. We need to let the experts do > their jobs. Fair point. If we had a way to say "IETF standards-track or a standard from an emergency services SDO" I'd be fine with that. I don't think we do have a way to say that though, other than by writing guidance in the IANA considerations section to that effect. Maybe someone who is better at IANA minutiae can figure out a way to get that effect? Cheers, S. > > Brian > >> On Sep 1, 2015, at 4:47 PM, Stephen Farrell >> wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ecrit-additional-data-34: Discuss >> >> 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.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> I've two things I'd like to chat about. (Note: I'm not trying >> here to insist on my preferred outcome, but I would like to have >> the discussion or else be pointed at where the WG already did >> that.) >> >> (1) section 3: You say these MAY be used. I'm not sure that's a >> good option. I think the data minimisation recommendations argued >> for in RFC6973 and RFC7258 would argue to add a MUST NOT. For >> example, saying that these additional data MUST NOT be sent in any >> non-emergency call without explicit user permission on a per-call >> basis or something similar? I have to admit I'm nervous that >> defining all of these may mean that some UA somewhere starts >> sending some of them in other calls without asking. A restriction >> along those lines would also be more in line with webrtc too >> perhaps. But maybe this was discussed in the WG, having considered >> those privacy issues - was it? Either way, would adding such a >> "MUST NOT except if..." be a good plan? 4.3.4 is a good example of >> the kind of thing I'd not want easily emitted in a call. >> >> (2) I'd like to (perhaps briefly) argue that the registries here >> should require more than expert review. Extensibility in dealing >> with what will inevitably be highly privacy sensitive data >> structures that are vulnerable to misuse once registered seems to >> perhaps call for a more stringent registration regime. The document >> itself also argues (in 4.3.7) that adding new kinds of data here >> can be counter productive for emergency call handling, so being >> more conservative in what we add seems unusually correct here. I'd >> like to suggest we require standards track for extensions. The >> following very recent -00 draft [1] makes some related arguments >> (but of course has no standing in the IETF so is just offered as a >> way to avoid repeating some arguments, not as an appeal to >> authority.) >> >> [1] >> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - abstract: the "or by reference" point is made twice >> in the abstract >> >> - intro: floor plans? HVAC status? really? Why not contact lists? >> proximity of friends? That (or inferring as much) seems to me to be >> going too far, if applied to all calls. I'd say just saying that >> this could be extended in future by other standards-track >> specifications is enough. (See also discuss points above) >> >> - intro: Wedding anniversary? That's surely not relevant to a PSAP. >> >> >> - figure 5: "prison" is out of context here, I'd suggest deleting >> it. If not, why not add hospital, power station and many other >> kinds of building? There may be some country specific issue or >> technical here, but labelling that with "prison" seems >> inappropriate to me. >> >> - 4.3.8: sorry I don't get the privacy argument, can you try >> explain it to me? (I didn't know it was possible to tempt an >> implementation, so the language there could be improved for >> sure:-) >> >> - section 5: good that this is HTTPS only. I think provisioning the >> PKI for such a thing is easily done these days and is rightly not >> optional. It might be useful to say that TLS here needs to follow >> BCP195. I agree with the earlier comment that you should be clear >> as to when mutually authenticated TLS is required. The secdir >> review [2] also raised similar issues and it'd be good to see >> responses to that too. (Yes, that review only arrived today so it's >> entirely reasonable to not have responded so far.) >> >> [2] >> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html >> >> - section 8: the sizes of the various additional data items here >> could be characteristic and leak value information regardless of >> TLS or not-TLS - perhaps add a warning that these may enable >> relatively simple traffic analysis. And wouldn't it be nice if >> someone had done the analysis of this potential vulnerability? This >> is btw a real issue - recall that avatar icon image size was usable >> to identify 30+% of contacts in one social network even over TLS, >> but before the provider canonicalised the avatar image sizes. >> >> - Thanks for section 9. Good job. >> >> >> _______________________________________________ Ecrit mailing list >> Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit > From nobody Wed Sep 2 08:09:19 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFBD1B39DE; Wed, 2 Sep 2015 08:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 ULP-zqtZfD7K; Wed, 2 Sep 2015 08:09:12 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 3D81F1A0018; Wed, 2 Sep 2015 08:09:11 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t82F6G5D002327; Wed, 2 Sep 2015 11:09:06 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1wnx6ggfag-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 11:09:06 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Wed, 2 Sep 2015 11:09:05 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) Thread-Index: AQHQ5Y8C1Qw9fTR1hU6qymoWFTGx9A== Date: Wed, 2 Sep 2015 15:09:04 +0000 Message-ID: <2FD7DCB7-5E1E-4D74-A966-3964FBD76151@neustar.biz> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> <55E70E64.9060601@cs.tcd.ie> In-Reply-To: <55E70E64.9060601@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.128.33] Content-Type: text/plain; charset="utf-8" Content-ID: <7430BC00908C76429751FEFA8C3900DC@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , The IESG , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:09:15 -0000 4oCcRG9jdW1lbnQgUmVxdWlyZWTigJ0gYW5kIOKAnEV4cGVydCBSZXZpZXfigJ0gd2l0aCBndWlk YW5jZSB0byB0aGUgZXhwZXJ0Pw0KDQpCcmlhbg0KDQo+IE9uIFNlcCAyLCAyMDE1LCBhdCA3OjU3 IEFNLCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0K PiANCj4gDQo+IA0KPiBPbiAwMi8wOS8xNSAxNTo1MiwgUm9zZW4sIEJyaWFuIHdyb3RlOg0KPj4g SeKAmW0gb2theSB3aXRoIHRoZSBNVVNUIE5PVCBleGNlcHQsIGFuZCBJIGNhbiBpbWFnaW5lIG90 aGVyIHVzZXMgZm9yDQo+PiB0aGVzZSB0aGF0IHdpbGwgd29yayBmaW5lIGlmIHdlIHdyaXRlIGEg ZG9jdW1lbnQgdGhhdCBleHBsYWlucyB0aGVtLg0KPiANCj4gQ29vbCwgc2hvdWxkIGJlIHJlbGF0 aXZlbHkgZWFzeSB0byB3b3JrIG91dCB3b3JkcyBpZiBldmVyeW9uZQ0KPiBhZ3JlZXMgb24gdGhh dC4NCj4gDQo+PiANCj4+IEnigJltIHN0cm9uZ2x5IGFnYWluc3Qgc3RhbmRhcmRzIHRyYWNrIGZv ciBleHRlbnNpb25zLiAgVGhlcmUgYXJlIGENCj4+IG51bWJlciBvZiBvcmdhbml6YXRpb25zIHdo byBoYXZlIGV4cGVydGlzZSB0aGF0IG5lZWQgdG8gYmUgYWJsZSB0bw0KPj4gZGVmaW5lIHRoZSBk YXRhLiAgV2UgY2Fu4oCZdCBiZSBleHBlcnRzIGluIGFsbCB0aGluZ3MuICBBbiBleGFtcGxlIGlz DQo+PiB0aGF0IHdl4oCZcmUgZ29pbmcgdG8gZXh0ZW5kIGZvciBtZWRpY2FsIGRhdGEgdXNlZnVs IHRvIGEgZmlyc3QNCj4+IHJlc3BvbmRlci4gIENsZWFybHkgaGFzIG1ham9yIHByaXZhY3kgaXNz dWVzLCBidXQgd2XigJlyZSBub3QgdGhlDQo+PiBleHBlcnRzIGluIHRoYXQsIGFuZCB0aG9zZSB0 aGF0IGFyZSBkb27igJl0IHdyaXRlIFJGQ3MuICBORU5BLCB0aGUNCj4+IDktMS0xIG9yZ2FuaXph dGlvbiBpbiBOb3J0aCBBbWVyaWNhIGlzIHdvcmtpbmcgb24gZXh0ZW5zaW9ucyBmb3INCj4+IGxv Y2F0aW9uIHJlbGF0ZWQgZGF0YSwgYW5kIGFsc28ga25vd3MgMTBYIG1vcmUgYWJvdXQgbG9jYXRp b24gZGF0YQ0KPj4gZm9yIGVtZXJnZW5jeSByZXNwb25zZSB0aGFuIElFVEYgZG9lcy4gIFdlIG5l ZWQgdG8gbGV0IHRoZSBleHBlcnRzIGRvDQo+PiB0aGVpciBqb2JzLg0KPiANCj4gRmFpciBwb2lu dC4gSWYgd2UgaGFkIGEgd2F5IHRvIHNheSAiSUVURiBzdGFuZGFyZHMtdHJhY2sgb3IgYSBzdGFu ZGFyZA0KPiBmcm9tIGFuIGVtZXJnZW5jeSBzZXJ2aWNlcyBTRE8iIEknZCBiZSBmaW5lIHdpdGgg dGhhdC4gSSBkb24ndCB0aGluayB3ZQ0KPiBkbyBoYXZlIGEgd2F5IHRvIHNheSB0aGF0IHRob3Vn aCwgb3RoZXIgdGhhbiBieSB3cml0aW5nIGd1aWRhbmNlIGluDQo+IHRoZSBJQU5BIGNvbnNpZGVy YXRpb25zIHNlY3Rpb24gdG8gdGhhdCBlZmZlY3QuIE1heWJlIHNvbWVvbmUgd2hvIGlzDQo+IGJl dHRlciBhdCBJQU5BIG1pbnV0aWFlIGNhbiBmaWd1cmUgb3V0IGEgd2F5IHRvIGdldCB0aGF0IGVm ZmVjdD8NCj4gDQo+IENoZWVycywNCj4gUy4NCj4gDQo+IA0KPiANCj4+IA0KPj4gQnJpYW4NCj4+ IA0KPj4+IE9uIFNlcCAxLCAyMDE1LCBhdCA0OjQ3IFBNLCBTdGVwaGVuIEZhcnJlbGwNCj4+PiA8 c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+Pj4gDQo+Pj4gU3RlcGhlbiBGYXJy ZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvciANCj4+PiBk cmFmdC1pZXRmLWVjcml0LWFkZGl0aW9uYWwtZGF0YS0zNDogRGlzY3Vzcw0KPj4+IA0KPj4+IFdo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvDQo+Pj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+Pj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+Pj4gDQo+Pj4gDQo+Pj4gUGxlYXNlIHJlZmVyIHRvDQo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIGZvciBt b3JlDQo+Pj4gaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4+PiANCj4+PiANCj4+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kDQo+Pj4gaGVyZTogDQo+Pj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEvDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IA0KPj4+IA0KPiBESVNDVVNT Og0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4gSSd2ZSB0d28g dGhpbmdzIEknZCBsaWtlIHRvIGNoYXQgYWJvdXQuIChOb3RlOiBJJ20gbm90IHRyeWluZw0KPj4+ IGhlcmUgdG8gaW5zaXN0IG9uIG15IHByZWZlcnJlZCBvdXRjb21lLCBidXQgSSB3b3VsZCBsaWtl IHRvIGhhdmUNCj4+PiB0aGUgZGlzY3Vzc2lvbiBvciBlbHNlIGJlIHBvaW50ZWQgYXQgd2hlcmUg dGhlIFdHIGFscmVhZHkgZGlkDQo+Pj4gdGhhdC4pDQo+Pj4gDQo+Pj4gKDEpIHNlY3Rpb24gMzog WW91IHNheSB0aGVzZSBNQVkgYmUgdXNlZC4gIEknbSBub3Qgc3VyZSB0aGF0J3MgYQ0KPj4+IGdv b2Qgb3B0aW9uLiAgSSB0aGluayB0aGUgZGF0YSBtaW5pbWlzYXRpb24gcmVjb21tZW5kYXRpb25z IGFyZ3VlZA0KPj4+IGZvciBpbiBSRkM2OTczIGFuZCBSRkM3MjU4IHdvdWxkIGFyZ3VlIHRvIGFk ZCBhIE1VU1QgTk9ULiBGb3INCj4+PiBleGFtcGxlLCBzYXlpbmcgdGhhdCB0aGVzZSBhZGRpdGlv bmFsIGRhdGEgTVVTVCBOT1QgYmUgc2VudCBpbiBhbnkNCj4+PiBub24tZW1lcmdlbmN5IGNhbGwg d2l0aG91dCBleHBsaWNpdCB1c2VyIHBlcm1pc3Npb24gb24gYSBwZXItY2FsbA0KPj4+IGJhc2lz IG9yIHNvbWV0aGluZyBzaW1pbGFyPyBJIGhhdmUgdG8gYWRtaXQgSSdtIG5lcnZvdXMgdGhhdA0K Pj4+IGRlZmluaW5nIGFsbCBvZiB0aGVzZSBtYXkgbWVhbiB0aGF0IHNvbWUgVUEgc29tZXdoZXJl IHN0YXJ0cw0KPj4+IHNlbmRpbmcgc29tZSBvZiB0aGVtIGluIG90aGVyIGNhbGxzIHdpdGhvdXQg YXNraW5nLiBBIHJlc3RyaWN0aW9uIA0KPj4+IGFsb25nIHRob3NlIGxpbmVzIHdvdWxkIGFsc28g YmUgbW9yZSBpbiBsaW5lIHdpdGggd2VicnRjIHRvbw0KPj4+IHBlcmhhcHMuIEJ1dCBtYXliZSB0 aGlzIHdhcyBkaXNjdXNzZWQgaW4gdGhlIFdHLCBoYXZpbmcgY29uc2lkZXJlZA0KPj4+IHRob3Nl IHByaXZhY3kgaXNzdWVzIC0gd2FzIGl0PyBFaXRoZXIgd2F5LCB3b3VsZCBhZGRpbmcgc3VjaCBh DQo+Pj4gIk1VU1QgTk9UIGV4Y2VwdCBpZi4uLiIgYmUgYSBnb29kIHBsYW4/ICA0LjMuNCBpcyBh IGdvb2QgZXhhbXBsZSBvZg0KPj4+IHRoZSBraW5kIG9mIHRoaW5nIEknZCBub3Qgd2FudCBlYXNp bHkgZW1pdHRlZCBpbiBhIGNhbGwuDQo+Pj4gDQo+Pj4gKDIpIEknZCBsaWtlIHRvIChwZXJoYXBz IGJyaWVmbHkpIGFyZ3VlIHRoYXQgdGhlIHJlZ2lzdHJpZXMgaGVyZQ0KPj4+IHNob3VsZCByZXF1 aXJlIG1vcmUgdGhhbiBleHBlcnQgcmV2aWV3LiBFeHRlbnNpYmlsaXR5IGluIGRlYWxpbmcNCj4+ PiB3aXRoIHdoYXQgd2lsbCBpbmV2aXRhYmx5IGJlIGhpZ2hseSBwcml2YWN5IHNlbnNpdGl2ZSBk YXRhDQo+Pj4gc3RydWN0dXJlcyB0aGF0IGFyZSB2dWxuZXJhYmxlIHRvIG1pc3VzZSBvbmNlIHJl Z2lzdGVyZWQgc2VlbXMgdG8gDQo+Pj4gcGVyaGFwcyBjYWxsIGZvciBhIG1vcmUgc3RyaW5nZW50 IHJlZ2lzdHJhdGlvbiByZWdpbWUuIFRoZSBkb2N1bWVudA0KPj4+IGl0c2VsZiBhbHNvIGFyZ3Vl cyAoaW4gNC4zLjcpIHRoYXQgYWRkaW5nIG5ldyBraW5kcyBvZiBkYXRhIGhlcmUNCj4+PiBjYW4g YmUgY291bnRlciBwcm9kdWN0aXZlIGZvciBlbWVyZ2VuY3kgY2FsbCBoYW5kbGluZywgc28gYmVp bmcNCj4+PiBtb3JlIGNvbnNlcnZhdGl2ZSBpbiB3aGF0IHdlIGFkZCBzZWVtcyB1bnVzdWFsbHkg Y29ycmVjdCBoZXJlLiBJJ2QNCj4+PiBsaWtlIHRvIHN1Z2dlc3Qgd2UgcmVxdWlyZSBzdGFuZGFy ZHMgdHJhY2sgZm9yIGV4dGVuc2lvbnMuIFRoZQ0KPj4+IGZvbGxvd2luZyB2ZXJ5IHJlY2VudCAt MDAgZHJhZnQgWzFdIG1ha2VzIHNvbWUgcmVsYXRlZCBhcmd1bWVudHMNCj4+PiAoYnV0IG9mIGNv dXJzZSBoYXMgbm8gc3RhbmRpbmcgaW4gdGhlIElFVEYgc28gaXMganVzdCBvZmZlcmVkIGFzIGEN Cj4+PiB3YXkgdG8gYXZvaWQgcmVwZWF0aW5nIHNvbWUgYXJndW1lbnRzLCBub3QgYXMgYW4gYXBw ZWFsIHRvIA0KPj4+IGF1dGhvcml0eS4pDQo+Pj4gDQo+Pj4gWzFdIA0KPj4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ub3R0aW5naGFtLXRyYW5zcG9ydC1tZXRhZGF0YS1pbXBh Y3QtMDANCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IENPTU1F TlQ6IA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4gLSBhYnN0 cmFjdDogdGhlICJvciBieSByZWZlcmVuY2UiIHBvaW50IGlzIG1hZGUgdHdpY2UNCj4+PiBpbiB0 aGUgYWJzdHJhY3QNCj4+PiANCj4+PiAtIGludHJvOiBmbG9vciBwbGFucz8gSFZBQyBzdGF0dXM/ IHJlYWxseT8gV2h5IG5vdCBjb250YWN0IGxpc3RzPw0KPj4+IHByb3hpbWl0eSBvZiBmcmllbmRz PyBUaGF0IChvciBpbmZlcnJpbmcgYXMgbXVjaCkgc2VlbXMgdG8gbWUgdG8gYmUNCj4+PiBnb2lu ZyB0b28gZmFyLCBpZiBhcHBsaWVkIHRvIGFsbCBjYWxscy4gSSdkIHNheSBqdXN0IHNheWluZyB0 aGF0DQo+Pj4gdGhpcyBjb3VsZCBiZSBleHRlbmRlZCBpbiBmdXR1cmUgYnkgb3RoZXIgc3RhbmRh cmRzLXRyYWNrIA0KPj4+IHNwZWNpZmljYXRpb25zIGlzIGVub3VnaC4gKFNlZSBhbHNvIGRpc2N1 c3MgcG9pbnRzIGFib3ZlKQ0KPj4+IA0KPj4+IC0gaW50cm86IFdlZGRpbmcgYW5uaXZlcnNhcnk/ IFRoYXQncyBzdXJlbHkgbm90IHJlbGV2YW50IHRvIGEgUFNBUC4NCj4+PiANCj4+PiANCj4+PiAt IGZpZ3VyZSA1OiAicHJpc29uIiBpcyBvdXQgb2YgY29udGV4dCBoZXJlLCBJJ2Qgc3VnZ2VzdCBk ZWxldGluZw0KPj4+IGl0LiBJZiBub3QsIHdoeSBub3QgYWRkIGhvc3BpdGFsLCBwb3dlciBzdGF0 aW9uIGFuZCBtYW55IG90aGVyDQo+Pj4ga2luZHMgb2YgYnVpbGRpbmc/IFRoZXJlIG1heSBiZSBz b21lIGNvdW50cnkgc3BlY2lmaWMgaXNzdWUgb3INCj4+PiB0ZWNobmljYWwgaGVyZSwgYnV0IGxh YmVsbGluZyB0aGF0IHdpdGggInByaXNvbiIgc2VlbXMNCj4+PiBpbmFwcHJvcHJpYXRlIHRvIG1l Lg0KPj4+IA0KPj4+IC0gNC4zLjg6IHNvcnJ5IEkgZG9uJ3QgZ2V0IHRoZSBwcml2YWN5IGFyZ3Vt ZW50LCBjYW4geW91IHRyeQ0KPj4+IGV4cGxhaW4gaXQgdG8gbWU/ICAoSSBkaWRuJ3Qga25vdyBp dCB3YXMgcG9zc2libGUgdG8gdGVtcHQgYW4NCj4+PiBpbXBsZW1lbnRhdGlvbiwgc28gdGhlIGxh bmd1YWdlIHRoZXJlIGNvdWxkIGJlIGltcHJvdmVkIGZvcg0KPj4+IHN1cmU6LSkNCj4+PiANCj4+ PiAtIHNlY3Rpb24gNTogZ29vZCB0aGF0IHRoaXMgaXMgSFRUUFMgb25seS4gSSB0aGluayBwcm92 aXNpb25pbmcgdGhlDQo+Pj4gUEtJIGZvciBzdWNoIGEgdGhpbmcgaXMgZWFzaWx5IGRvbmUgdGhl c2UgZGF5cyBhbmQgaXMgcmlnaHRseSBub3QNCj4+PiBvcHRpb25hbC4gSXQgbWlnaHQgYmUgdXNl ZnVsIHRvIHNheSB0aGF0IFRMUyBoZXJlIG5lZWRzIHRvIGZvbGxvdw0KPj4+IEJDUDE5NS4gIEkg YWdyZWUgd2l0aCB0aGUgZWFybGllciBjb21tZW50IHRoYXQgeW91IHNob3VsZCBiZSBjbGVhcg0K Pj4+IGFzIHRvIHdoZW4gbXV0dWFsbHkgYXV0aGVudGljYXRlZCBUTFMgaXMgcmVxdWlyZWQuIFRo ZSBzZWNkaXINCj4+PiByZXZpZXcgWzJdIGFsc28gcmFpc2VkIHNpbWlsYXIgaXNzdWVzIGFuZCBp dCdkIGJlIGdvb2QgdG8gc2VlDQo+Pj4gcmVzcG9uc2VzIHRvIHRoYXQgdG9vLiAoWWVzLCB0aGF0 IHJldmlldyBvbmx5IGFycml2ZWQgdG9kYXkgc28gaXQncw0KPj4+IGVudGlyZWx5IHJlYXNvbmFi bGUgdG8gbm90IGhhdmUgcmVzcG9uZGVkIHNvIGZhci4pDQo+Pj4gDQo+Pj4gWzJdIA0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDU5 ODIuaHRtbA0KPj4+IA0KPj4+IC0gc2VjdGlvbiA4OiB0aGUgc2l6ZXMgb2YgdGhlIHZhcmlvdXMg YWRkaXRpb25hbCBkYXRhIGl0ZW1zIGhlcmUNCj4+PiBjb3VsZCBiZSBjaGFyYWN0ZXJpc3RpYyBh bmQgbGVhayB2YWx1ZSBpbmZvcm1hdGlvbiByZWdhcmRsZXNzIG9mDQo+Pj4gVExTIG9yIG5vdC1U TFMgLSBwZXJoYXBzIGFkZCBhIHdhcm5pbmcgdGhhdCB0aGVzZSBtYXkgZW5hYmxlDQo+Pj4gcmVs YXRpdmVseSBzaW1wbGUgdHJhZmZpYyBhbmFseXNpcy4gQW5kIHdvdWxkbid0IGl0IGJlIG5pY2Ug aWYNCj4+PiBzb21lb25lIGhhZCBkb25lIHRoZSBhbmFseXNpcyBvZiB0aGlzIHBvdGVudGlhbCB2 dWxuZXJhYmlsaXR5PyBUaGlzDQo+Pj4gaXMgYnR3IGEgcmVhbCBpc3N1ZSAtIHJlY2FsbCB0aGF0 IGF2YXRhciBpY29uIGltYWdlIHNpemUgd2FzIHVzYWJsZQ0KPj4+IHRvIGlkZW50aWZ5IDMwKyUg b2YgY29udGFjdHMgaW4gb25lIHNvY2lhbCBuZXR3b3JrIGV2ZW4gb3ZlciBUTFMsDQo+Pj4gYnV0 IGJlZm9yZSB0aGUgcHJvdmlkZXIgY2Fub25pY2FsaXNlZCB0aGUgYXZhdGFyIGltYWdlIHNpemVz Lg0KPj4+IA0KPj4+IC0gVGhhbmtzIGZvciBzZWN0aW9uIDkuIEdvb2Qgam9iLg0KPj4+IA0KPj4+ IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEVj cml0IG1haWxpbmcgbGlzdCANCj4+PiBFY3JpdEBpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+PiANCg0K From nobody Wed Sep 2 08:14:31 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302981B4A56; Wed, 2 Sep 2015 08:14:30 -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 poiPPrJ1tLvZ; Wed, 2 Sep 2015 08:14:28 -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 A70561B3CF3; Wed, 2 Sep 2015 08:14:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70085BE38; Wed, 2 Sep 2015 16:14:26 +0100 (IST) 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 gMZ7IT9rPodz; Wed, 2 Sep 2015 16:14:26 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C051BDD0; Wed, 2 Sep 2015 16:14:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441206866; bh=tY9bNfNPF4lMyMv3EP73VzAOBhgXOUmEKMt15+fbNtw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hHTqtKEVrmWOQhLwsJEL8HmJCocw3CxAf45i4tTgE8ScyAUreKs2CRXeb9CfieWfu i9L10AEYpijigzbfola0nDE7T8GqnVoG1fo5BBJai+C0/dVMwEfH3qra+b1ZwJKJO4 uOjLpHmS8c0r1UMAkZyuJWIM6S1UDD2kzcdW1jqU= To: "Rosen, Brian" References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> <55E70E64.9060601@cs.tcd.ie> <2FD7DCB7-5E1E-4D74-A966-3964FBD76151@neustar.biz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E71252.5040603@cs.tcd.ie> Date: Wed, 2 Sep 2015 16:14:26 +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: <2FD7DCB7-5E1E-4D74-A966-3964FBD76151@neustar.biz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:14:30 -0000 On 02/09/15 16:09, Rosen, Brian wrote: > “Document Required” and “Expert Review” with guidance to the expert? Yeah that might be best I guess, if the guidance says something the equivalent of "standards-track or a specification from a emergency services SDO" Do I recall right that this draft already sets up one registry that essentially lists that kind of emergency services SDO? If so, then an option might be to require that the specification be from one of those and to require IESG approval for getting added to that registry. We have a similar sort of setup for SDOs that do some media type stuff, so this isn't that innovative, if the list of relevant SDOs is likely smallish and stable. Cheers, S. > > Brian > >> On Sep 2, 2015, at 7:57 AM, Stephen Farrell wrote: >> >> >> >> On 02/09/15 15:52, Rosen, Brian wrote: >>> I’m okay with the MUST NOT except, and I can imagine other uses for >>> these that will work fine if we write a document that explains them. >> >> Cool, should be relatively easy to work out words if everyone >> agrees on that. >> >>> >>> I’m strongly against standards track for extensions. There are a >>> number of organizations who have expertise that need to be able to >>> define the data. We can’t be experts in all things. An example is >>> that we’re going to extend for medical data useful to a first >>> responder. Clearly has major privacy issues, but we’re not the >>> experts in that, and those that are don’t write RFCs. NENA, the >>> 9-1-1 organization in North America is working on extensions for >>> location related data, and also knows 10X more about location data >>> for emergency response than IETF does. We need to let the experts do >>> their jobs. >> >> Fair point. If we had a way to say "IETF standards-track or a standard >> from an emergency services SDO" I'd be fine with that. I don't think we >> do have a way to say that though, other than by writing guidance in >> the IANA considerations section to that effect. Maybe someone who is >> better at IANA minutiae can figure out a way to get that effect? >> >> Cheers, >> S. >> >> >> >>> >>> Brian >>> >>>> On Sep 1, 2015, at 4:47 PM, Stephen Farrell >>>> wrote: >>>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-ecrit-additional-data-34: Discuss >>>> >>>> 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.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>> information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found >>>> here: >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> >> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> >>>> >> I've two things I'd like to chat about. (Note: I'm not trying >>>> here to insist on my preferred outcome, but I would like to have >>>> the discussion or else be pointed at where the WG already did >>>> that.) >>>> >>>> (1) section 3: You say these MAY be used. I'm not sure that's a >>>> good option. I think the data minimisation recommendations argued >>>> for in RFC6973 and RFC7258 would argue to add a MUST NOT. For >>>> example, saying that these additional data MUST NOT be sent in any >>>> non-emergency call without explicit user permission on a per-call >>>> basis or something similar? I have to admit I'm nervous that >>>> defining all of these may mean that some UA somewhere starts >>>> sending some of them in other calls without asking. A restriction >>>> along those lines would also be more in line with webrtc too >>>> perhaps. But maybe this was discussed in the WG, having considered >>>> those privacy issues - was it? Either way, would adding such a >>>> "MUST NOT except if..." be a good plan? 4.3.4 is a good example of >>>> the kind of thing I'd not want easily emitted in a call. >>>> >>>> (2) I'd like to (perhaps briefly) argue that the registries here >>>> should require more than expert review. Extensibility in dealing >>>> with what will inevitably be highly privacy sensitive data >>>> structures that are vulnerable to misuse once registered seems to >>>> perhaps call for a more stringent registration regime. The document >>>> itself also argues (in 4.3.7) that adding new kinds of data here >>>> can be counter productive for emergency call handling, so being >>>> more conservative in what we add seems unusually correct here. I'd >>>> like to suggest we require standards track for extensions. The >>>> following very recent -00 draft [1] makes some related arguments >>>> (but of course has no standing in the IETF so is just offered as a >>>> way to avoid repeating some arguments, not as an appeal to >>>> authority.) >>>> >>>> [1] >>>> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >>>> >>>> >>>> >>>> >> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> >>>> >> - abstract: the "or by reference" point is made twice >>>> in the abstract >>>> >>>> - intro: floor plans? HVAC status? really? Why not contact lists? >>>> proximity of friends? That (or inferring as much) seems to me to be >>>> going too far, if applied to all calls. I'd say just saying that >>>> this could be extended in future by other standards-track >>>> specifications is enough. (See also discuss points above) >>>> >>>> - intro: Wedding anniversary? That's surely not relevant to a PSAP. >>>> >>>> >>>> - figure 5: "prison" is out of context here, I'd suggest deleting >>>> it. If not, why not add hospital, power station and many other >>>> kinds of building? There may be some country specific issue or >>>> technical here, but labelling that with "prison" seems >>>> inappropriate to me. >>>> >>>> - 4.3.8: sorry I don't get the privacy argument, can you try >>>> explain it to me? (I didn't know it was possible to tempt an >>>> implementation, so the language there could be improved for >>>> sure:-) >>>> >>>> - section 5: good that this is HTTPS only. I think provisioning the >>>> PKI for such a thing is easily done these days and is rightly not >>>> optional. It might be useful to say that TLS here needs to follow >>>> BCP195. I agree with the earlier comment that you should be clear >>>> as to when mutually authenticated TLS is required. The secdir >>>> review [2] also raised similar issues and it'd be good to see >>>> responses to that too. (Yes, that review only arrived today so it's >>>> entirely reasonable to not have responded so far.) >>>> >>>> [2] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html >>>> >>>> - section 8: the sizes of the various additional data items here >>>> could be characteristic and leak value information regardless of >>>> TLS or not-TLS - perhaps add a warning that these may enable >>>> relatively simple traffic analysis. And wouldn't it be nice if >>>> someone had done the analysis of this potential vulnerability? This >>>> is btw a real issue - recall that avatar icon image size was usable >>>> to identify 30+% of contacts in one social network even over TLS, >>>> but before the provider canonicalised the avatar image sizes. >>>> >>>> - Thanks for section 9. Good job. >>>> >>>> >>>> _______________________________________________ Ecrit mailing list >>>> Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit >>> > From nobody Wed Sep 2 08:39:24 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6F71B2B97; Wed, 2 Sep 2015 08:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 ohSvemGKiEb0; Wed, 2 Sep 2015 08:39:17 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 173E51B4723; Wed, 2 Sep 2015 08:38:31 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t82Fc4Zv024496; Wed, 2 Sep 2015 11:38:26 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1wnx6gggu5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Sep 2015 11:38:26 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Wed, 2 Sep 2015 11:38:25 -0400 From: "Rosen, Brian" To: Stephen Farrell Thread-Topic: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) Thread-Index: AQHQ5Y8C1Qw9fTR1hU6qymoWFTGx9A== Date: Wed, 2 Sep 2015 15:38:25 +0000 Message-ID: <8542E871-DAB1-4703-84C0-F90D50441569@neustar.biz> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> <55E70E64.9060601@cs.tcd.ie> <2FD7DCB7-5E1E-4D74-A966-3964FBD76151@neustar.biz> <55E71252.5040603@cs.tcd.ie> In-Reply-To: <55E71252.5040603@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.128.33] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-02_06:2015-09-02,2015-09-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:39:20 -0000 Tm8sIHRoZXJlIGlzIG5vIHN1Y2ggbGlzdC4gIFRoZXJlIGlzIGEgcmVnaXN0cnkgb2YgaWRlbnRp ZmllcnMgYXNzaWduZWQgYnkgb3RoZXIgYXV0aG9yaXRpZXMsIHdoaWNoIGlzIHdoYXQgSSB0aGlu ayB5b3UgYXJlIHRoaW5raW5nIGFib3V0LiAgQnV0IHRoYXQgbGlzdCBpcyBub3QgYSBsaXN0IG9m IGVudGl0aWVzIHdobyBwcm9kdWNlIHN0YW5kYXJkcy4gIEl0IGhhcHBlbnMgdGhhdCBORU5BIGhh cyBhbiBJRCBzZXJpZXMsIGFuZCBkb2VzIHN0YW5kYXJkcywgYnV0IHRoZXJlIGFyZSBwbGVudHkg b2YgZXhhbXBsZXMgb2Ygc3RhbmRhcmRzIG9yZ2FuaXphdGlvbnMgd2hvIGRvbuKAmXQgaGF2ZSBp ZGVudGlmaWVyIHNlcmllcyBhbmQgb3RoZXJzIHRoYXQgaGF2ZSBpZGVudGlmaWVycyBzZXJpZXMg YnV0IGRvbuKAmXQgcHJvZHVjZSBzdGFuZGFyZHMuICBJ4oCZbSBjb25maWRlbnQgYW4gZXhwZXJ0 IGNhbiBkaXN0aW5ndWlzaCB3aGVuIGEgZG9jdW1lbnQgY29tZXMgZnJvbSBhbiBhcHByb3ByaWF0 ZSBvcmdhbml6YXRpb24uDQoNCkJyaWFuDQo+IE9uIFNlcCAyLCAyMDE1LCBhdCA4OjE0IEFNLCBT dGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPiANCj4g DQo+IA0KPiBPbiAwMi8wOS8xNSAxNjowOSwgUm9zZW4sIEJyaWFuIHdyb3RlOg0KPj4g4oCcRG9j dW1lbnQgUmVxdWlyZWTigJ0gYW5kIOKAnEV4cGVydCBSZXZpZXfigJ0gd2l0aCBndWlkYW5jZSB0 byB0aGUgZXhwZXJ0Pw0KPiANCj4gWWVhaCB0aGF0IG1pZ2h0IGJlIGJlc3QgSSBndWVzcywgaWYg dGhlIGd1aWRhbmNlIHNheXMgc29tZXRoaW5nDQo+IHRoZSBlcXVpdmFsZW50IG9mICJzdGFuZGFy ZHMtdHJhY2sgb3IgYSBzcGVjaWZpY2F0aW9uIGZyb20gYQ0KPiA8cmVjb2duaXplZD8+IGVtZXJn ZW5jeSBzZXJ2aWNlcyBTRE8iDQo+IA0KPiBEbyBJIHJlY2FsbCByaWdodCB0aGF0IHRoaXMgZHJh ZnQgYWxyZWFkeSBzZXRzIHVwIG9uZSByZWdpc3RyeSB0aGF0DQo+IGVzc2VudGlhbGx5IGxpc3Rz IHRoYXQga2luZCBvZiBlbWVyZ2VuY3kgc2VydmljZXMgU0RPPyBJZiBzbywgdGhlbg0KPiBhbiBv cHRpb24gbWlnaHQgYmUgdG8gcmVxdWlyZSB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGJlIGZyb20g b25lDQo+IG9mIHRob3NlIGFuZCB0byByZXF1aXJlIElFU0cgYXBwcm92YWwgZm9yIGdldHRpbmcg YWRkZWQgdG8gdGhhdA0KPiByZWdpc3RyeS4gV2UgaGF2ZSBhIHNpbWlsYXIgc29ydCBvZiBzZXR1 cCBmb3IgU0RPcyB0aGF0IGRvIHNvbWUNCj4gbWVkaWEgdHlwZSBzdHVmZiwgc28gdGhpcyBpc24n dCB0aGF0IGlubm92YXRpdmUsIGlmIHRoZSBsaXN0IG9mDQo+IHJlbGV2YW50IFNET3MgaXMgbGlr ZWx5IHNtYWxsaXNoIGFuZCBzdGFibGUuDQo+IA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiANCj4+ IA0KPj4gQnJpYW4NCj4+IA0KPj4+IE9uIFNlcCAyLCAyMDE1LCBhdCA3OjU3IEFNLCBTdGVwaGVu IEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPj4+IA0KPj4+IA0K Pj4+IA0KPj4+IE9uIDAyLzA5LzE1IDE1OjUyLCBSb3NlbiwgQnJpYW4gd3JvdGU6DQo+Pj4+IEni gJltIG9rYXkgd2l0aCB0aGUgTVVTVCBOT1QgZXhjZXB0LCBhbmQgSSBjYW4gaW1hZ2luZSBvdGhl ciB1c2VzIGZvcg0KPj4+PiB0aGVzZSB0aGF0IHdpbGwgd29yayBmaW5lIGlmIHdlIHdyaXRlIGEg ZG9jdW1lbnQgdGhhdCBleHBsYWlucyB0aGVtLg0KPj4+IA0KPj4+IENvb2wsIHNob3VsZCBiZSBy ZWxhdGl2ZWx5IGVhc3kgdG8gd29yayBvdXQgd29yZHMgaWYgZXZlcnlvbmUNCj4+PiBhZ3JlZXMg b24gdGhhdC4NCj4+PiANCj4+Pj4gDQo+Pj4+IEnigJltIHN0cm9uZ2x5IGFnYWluc3Qgc3RhbmRh cmRzIHRyYWNrIGZvciBleHRlbnNpb25zLiAgVGhlcmUgYXJlIGENCj4+Pj4gbnVtYmVyIG9mIG9y Z2FuaXphdGlvbnMgd2hvIGhhdmUgZXhwZXJ0aXNlIHRoYXQgbmVlZCB0byBiZSBhYmxlIHRvDQo+ Pj4+IGRlZmluZSB0aGUgZGF0YS4gIFdlIGNhbuKAmXQgYmUgZXhwZXJ0cyBpbiBhbGwgdGhpbmdz LiAgQW4gZXhhbXBsZSBpcw0KPj4+PiB0aGF0IHdl4oCZcmUgZ29pbmcgdG8gZXh0ZW5kIGZvciBt ZWRpY2FsIGRhdGEgdXNlZnVsIHRvIGEgZmlyc3QNCj4+Pj4gcmVzcG9uZGVyLiAgQ2xlYXJseSBo YXMgbWFqb3IgcHJpdmFjeSBpc3N1ZXMsIGJ1dCB3ZeKAmXJlIG5vdCB0aGUNCj4+Pj4gZXhwZXJ0 cyBpbiB0aGF0LCBhbmQgdGhvc2UgdGhhdCBhcmUgZG9u4oCZdCB3cml0ZSBSRkNzLiAgTkVOQSwg dGhlDQo+Pj4+IDktMS0xIG9yZ2FuaXphdGlvbiBpbiBOb3J0aCBBbWVyaWNhIGlzIHdvcmtpbmcg b24gZXh0ZW5zaW9ucyBmb3INCj4+Pj4gbG9jYXRpb24gcmVsYXRlZCBkYXRhLCBhbmQgYWxzbyBr bm93cyAxMFggbW9yZSBhYm91dCBsb2NhdGlvbiBkYXRhDQo+Pj4+IGZvciBlbWVyZ2VuY3kgcmVz cG9uc2UgdGhhbiBJRVRGIGRvZXMuICBXZSBuZWVkIHRvIGxldCB0aGUgZXhwZXJ0cyBkbw0KPj4+ PiB0aGVpciBqb2JzLg0KPj4+IA0KPj4+IEZhaXIgcG9pbnQuIElmIHdlIGhhZCBhIHdheSB0byBz YXkgIklFVEYgc3RhbmRhcmRzLXRyYWNrIG9yIGEgc3RhbmRhcmQNCj4+PiBmcm9tIGFuIGVtZXJn ZW5jeSBzZXJ2aWNlcyBTRE8iIEknZCBiZSBmaW5lIHdpdGggdGhhdC4gSSBkb24ndCB0aGluayB3 ZQ0KPj4+IGRvIGhhdmUgYSB3YXkgdG8gc2F5IHRoYXQgdGhvdWdoLCBvdGhlciB0aGFuIGJ5IHdy aXRpbmcgZ3VpZGFuY2UgaW4NCj4+PiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRv IHRoYXQgZWZmZWN0LiBNYXliZSBzb21lb25lIHdobyBpcw0KPj4+IGJldHRlciBhdCBJQU5BIG1p bnV0aWFlIGNhbiBmaWd1cmUgb3V0IGEgd2F5IHRvIGdldCB0aGF0IGVmZmVjdD8NCj4+PiANCj4+ PiBDaGVlcnMsDQo+Pj4gUy4NCj4+PiANCj4+PiANCj4+PiANCj4+Pj4gDQo+Pj4+IEJyaWFuDQo+ Pj4+IA0KPj4+Pj4gT24gU2VwIDEsIDIwMTUsIGF0IDQ6NDcgUE0sIFN0ZXBoZW4gRmFycmVsbA0K Pj4+Pj4gPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBT dGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yIA0KPj4+Pj4gZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEtMzQ6IERpc2N1c3MN Cj4+Pj4+IA0KPj4+Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCj4+Pj4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPj4+Pj4gY3V0IHRoaXMg aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4g UGxlYXNlIHJlZmVyIHRvDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9yIG1vcmUNCj4+Pj4+IGluZm9ybWF0aW9uIGFib3V0 IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ Pj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZA0KPj4+Pj4gaGVyZTogDQo+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWVjcml0LWFkZGl0aW9uYWwtZGF0YS8NCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4gRElTQ1VTUzoN Cj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ IEkndmUgdHdvIHRoaW5ncyBJJ2QgbGlrZSB0byBjaGF0IGFib3V0LiAoTm90ZTogSSdtIG5vdCB0 cnlpbmcNCj4+Pj4+IGhlcmUgdG8gaW5zaXN0IG9uIG15IHByZWZlcnJlZCBvdXRjb21lLCBidXQg SSB3b3VsZCBsaWtlIHRvIGhhdmUNCj4+Pj4+IHRoZSBkaXNjdXNzaW9uIG9yIGVsc2UgYmUgcG9p bnRlZCBhdCB3aGVyZSB0aGUgV0cgYWxyZWFkeSBkaWQNCj4+Pj4+IHRoYXQuKQ0KPj4+Pj4gDQo+ Pj4+PiAoMSkgc2VjdGlvbiAzOiBZb3Ugc2F5IHRoZXNlIE1BWSBiZSB1c2VkLiAgSSdtIG5vdCBz dXJlIHRoYXQncyBhDQo+Pj4+PiBnb29kIG9wdGlvbi4gIEkgdGhpbmsgdGhlIGRhdGEgbWluaW1p c2F0aW9uIHJlY29tbWVuZGF0aW9ucyBhcmd1ZWQNCj4+Pj4+IGZvciBpbiBSRkM2OTczIGFuZCBS RkM3MjU4IHdvdWxkIGFyZ3VlIHRvIGFkZCBhIE1VU1QgTk9ULiBGb3INCj4+Pj4+IGV4YW1wbGUs IHNheWluZyB0aGF0IHRoZXNlIGFkZGl0aW9uYWwgZGF0YSBNVVNUIE5PVCBiZSBzZW50IGluIGFu eQ0KPj4+Pj4gbm9uLWVtZXJnZW5jeSBjYWxsIHdpdGhvdXQgZXhwbGljaXQgdXNlciBwZXJtaXNz aW9uIG9uIGEgcGVyLWNhbGwNCj4+Pj4+IGJhc2lzIG9yIHNvbWV0aGluZyBzaW1pbGFyPyBJIGhh dmUgdG8gYWRtaXQgSSdtIG5lcnZvdXMgdGhhdA0KPj4+Pj4gZGVmaW5pbmcgYWxsIG9mIHRoZXNl IG1heSBtZWFuIHRoYXQgc29tZSBVQSBzb21ld2hlcmUgc3RhcnRzDQo+Pj4+PiBzZW5kaW5nIHNv bWUgb2YgdGhlbSBpbiBvdGhlciBjYWxscyB3aXRob3V0IGFza2luZy4gQSByZXN0cmljdGlvbiAN Cj4+Pj4+IGFsb25nIHRob3NlIGxpbmVzIHdvdWxkIGFsc28gYmUgbW9yZSBpbiBsaW5lIHdpdGgg d2VicnRjIHRvbw0KPj4+Pj4gcGVyaGFwcy4gQnV0IG1heWJlIHRoaXMgd2FzIGRpc2N1c3NlZCBp biB0aGUgV0csIGhhdmluZyBjb25zaWRlcmVkDQo+Pj4+PiB0aG9zZSBwcml2YWN5IGlzc3VlcyAt IHdhcyBpdD8gRWl0aGVyIHdheSwgd291bGQgYWRkaW5nIHN1Y2ggYQ0KPj4+Pj4gIk1VU1QgTk9U IGV4Y2VwdCBpZi4uLiIgYmUgYSBnb29kIHBsYW4/ICA0LjMuNCBpcyBhIGdvb2QgZXhhbXBsZSBv Zg0KPj4+Pj4gdGhlIGtpbmQgb2YgdGhpbmcgSSdkIG5vdCB3YW50IGVhc2lseSBlbWl0dGVkIGlu IGEgY2FsbC4NCj4+Pj4+IA0KPj4+Pj4gKDIpIEknZCBsaWtlIHRvIChwZXJoYXBzIGJyaWVmbHkp IGFyZ3VlIHRoYXQgdGhlIHJlZ2lzdHJpZXMgaGVyZQ0KPj4+Pj4gc2hvdWxkIHJlcXVpcmUgbW9y ZSB0aGFuIGV4cGVydCByZXZpZXcuIEV4dGVuc2liaWxpdHkgaW4gZGVhbGluZw0KPj4+Pj4gd2l0 aCB3aGF0IHdpbGwgaW5ldml0YWJseSBiZSBoaWdobHkgcHJpdmFjeSBzZW5zaXRpdmUgZGF0YQ0K Pj4+Pj4gc3RydWN0dXJlcyB0aGF0IGFyZSB2dWxuZXJhYmxlIHRvIG1pc3VzZSBvbmNlIHJlZ2lz dGVyZWQgc2VlbXMgdG8gDQo+Pj4+PiBwZXJoYXBzIGNhbGwgZm9yIGEgbW9yZSBzdHJpbmdlbnQg cmVnaXN0cmF0aW9uIHJlZ2ltZS4gVGhlIGRvY3VtZW50DQo+Pj4+PiBpdHNlbGYgYWxzbyBhcmd1 ZXMgKGluIDQuMy43KSB0aGF0IGFkZGluZyBuZXcga2luZHMgb2YgZGF0YSBoZXJlDQo+Pj4+PiBj YW4gYmUgY291bnRlciBwcm9kdWN0aXZlIGZvciBlbWVyZ2VuY3kgY2FsbCBoYW5kbGluZywgc28g YmVpbmcNCj4+Pj4+IG1vcmUgY29uc2VydmF0aXZlIGluIHdoYXQgd2UgYWRkIHNlZW1zIHVudXN1 YWxseSBjb3JyZWN0IGhlcmUuIEknZA0KPj4+Pj4gbGlrZSB0byBzdWdnZXN0IHdlIHJlcXVpcmUg c3RhbmRhcmRzIHRyYWNrIGZvciBleHRlbnNpb25zLiBUaGUNCj4+Pj4+IGZvbGxvd2luZyB2ZXJ5 IHJlY2VudCAtMDAgZHJhZnQgWzFdIG1ha2VzIHNvbWUgcmVsYXRlZCBhcmd1bWVudHMNCj4+Pj4+ IChidXQgb2YgY291cnNlIGhhcyBubyBzdGFuZGluZyBpbiB0aGUgSUVURiBzbyBpcyBqdXN0IG9m ZmVyZWQgYXMgYQ0KPj4+Pj4gd2F5IHRvIGF2b2lkIHJlcGVhdGluZyBzb21lIGFyZ3VtZW50cywg bm90IGFzIGFuIGFwcGVhbCB0byANCj4+Pj4+IGF1dGhvcml0eS4pDQo+Pj4+PiANCj4+Pj4+IFsx XSANCj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ub3R0aW5naGFtLXRy YW5zcG9ydC1tZXRhZGF0YS1pbXBhY3QtMDANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IENPTU1FTlQ6IA0KPj4+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4gLSBhYnN0cmFjdDogdGhlICJv ciBieSByZWZlcmVuY2UiIHBvaW50IGlzIG1hZGUgdHdpY2UNCj4+Pj4+IGluIHRoZSBhYnN0cmFj dA0KPj4+Pj4gDQo+Pj4+PiAtIGludHJvOiBmbG9vciBwbGFucz8gSFZBQyBzdGF0dXM/IHJlYWxs eT8gV2h5IG5vdCBjb250YWN0IGxpc3RzPw0KPj4+Pj4gcHJveGltaXR5IG9mIGZyaWVuZHM/IFRo YXQgKG9yIGluZmVycmluZyBhcyBtdWNoKSBzZWVtcyB0byBtZSB0byBiZQ0KPj4+Pj4gZ29pbmcg dG9vIGZhciwgaWYgYXBwbGllZCB0byBhbGwgY2FsbHMuIEknZCBzYXkganVzdCBzYXlpbmcgdGhh dA0KPj4+Pj4gdGhpcyBjb3VsZCBiZSBleHRlbmRlZCBpbiBmdXR1cmUgYnkgb3RoZXIgc3RhbmRh cmRzLXRyYWNrIA0KPj4+Pj4gc3BlY2lmaWNhdGlvbnMgaXMgZW5vdWdoLiAoU2VlIGFsc28gZGlz Y3VzcyBwb2ludHMgYWJvdmUpDQo+Pj4+PiANCj4+Pj4+IC0gaW50cm86IFdlZGRpbmcgYW5uaXZl cnNhcnk/IFRoYXQncyBzdXJlbHkgbm90IHJlbGV2YW50IHRvIGEgUFNBUC4NCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiAtIGZpZ3VyZSA1OiAicHJpc29uIiBpcyBvdXQgb2YgY29udGV4dCBoZXJlLCBJ J2Qgc3VnZ2VzdCBkZWxldGluZw0KPj4+Pj4gaXQuIElmIG5vdCwgd2h5IG5vdCBhZGQgaG9zcGl0 YWwsIHBvd2VyIHN0YXRpb24gYW5kIG1hbnkgb3RoZXINCj4+Pj4+IGtpbmRzIG9mIGJ1aWxkaW5n PyBUaGVyZSBtYXkgYmUgc29tZSBjb3VudHJ5IHNwZWNpZmljIGlzc3VlIG9yDQo+Pj4+PiB0ZWNo bmljYWwgaGVyZSwgYnV0IGxhYmVsbGluZyB0aGF0IHdpdGggInByaXNvbiIgc2VlbXMNCj4+Pj4+ IGluYXBwcm9wcmlhdGUgdG8gbWUuDQo+Pj4+PiANCj4+Pj4+IC0gNC4zLjg6IHNvcnJ5IEkgZG9u J3QgZ2V0IHRoZSBwcml2YWN5IGFyZ3VtZW50LCBjYW4geW91IHRyeQ0KPj4+Pj4gZXhwbGFpbiBp dCB0byBtZT8gIChJIGRpZG4ndCBrbm93IGl0IHdhcyBwb3NzaWJsZSB0byB0ZW1wdCBhbg0KPj4+ Pj4gaW1wbGVtZW50YXRpb24sIHNvIHRoZSBsYW5ndWFnZSB0aGVyZSBjb3VsZCBiZSBpbXByb3Zl ZCBmb3INCj4+Pj4+IHN1cmU6LSkNCj4+Pj4+IA0KPj4+Pj4gLSBzZWN0aW9uIDU6IGdvb2QgdGhh dCB0aGlzIGlzIEhUVFBTIG9ubHkuIEkgdGhpbmsgcHJvdmlzaW9uaW5nIHRoZQ0KPj4+Pj4gUEtJ IGZvciBzdWNoIGEgdGhpbmcgaXMgZWFzaWx5IGRvbmUgdGhlc2UgZGF5cyBhbmQgaXMgcmlnaHRs eSBub3QNCj4+Pj4+IG9wdGlvbmFsLiBJdCBtaWdodCBiZSB1c2VmdWwgdG8gc2F5IHRoYXQgVExT IGhlcmUgbmVlZHMgdG8gZm9sbG93DQo+Pj4+PiBCQ1AxOTUuICBJIGFncmVlIHdpdGggdGhlIGVh cmxpZXIgY29tbWVudCB0aGF0IHlvdSBzaG91bGQgYmUgY2xlYXINCj4+Pj4+IGFzIHRvIHdoZW4g bXV0dWFsbHkgYXV0aGVudGljYXRlZCBUTFMgaXMgcmVxdWlyZWQuIFRoZSBzZWNkaXINCj4+Pj4+ IHJldmlldyBbMl0gYWxzbyByYWlzZWQgc2ltaWxhciBpc3N1ZXMgYW5kIGl0J2QgYmUgZ29vZCB0 byBzZWUNCj4+Pj4+IHJlc3BvbnNlcyB0byB0aGF0IHRvby4gKFllcywgdGhhdCByZXZpZXcgb25s eSBhcnJpdmVkIHRvZGF5IHNvIGl0J3MNCj4+Pj4+IGVudGlyZWx5IHJlYXNvbmFibGUgdG8gbm90 IGhhdmUgcmVzcG9uZGVkIHNvIGZhci4pDQo+Pj4+PiANCj4+Pj4+IFsyXSANCj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDU5ODIu aHRtbA0KPj4+Pj4gDQo+Pj4+PiAtIHNlY3Rpb24gODogdGhlIHNpemVzIG9mIHRoZSB2YXJpb3Vz IGFkZGl0aW9uYWwgZGF0YSBpdGVtcyBoZXJlDQo+Pj4+PiBjb3VsZCBiZSBjaGFyYWN0ZXJpc3Rp YyBhbmQgbGVhayB2YWx1ZSBpbmZvcm1hdGlvbiByZWdhcmRsZXNzIG9mDQo+Pj4+PiBUTFMgb3Ig bm90LVRMUyAtIHBlcmhhcHMgYWRkIGEgd2FybmluZyB0aGF0IHRoZXNlIG1heSBlbmFibGUNCj4+ Pj4+IHJlbGF0aXZlbHkgc2ltcGxlIHRyYWZmaWMgYW5hbHlzaXMuIEFuZCB3b3VsZG4ndCBpdCBi ZSBuaWNlIGlmDQo+Pj4+PiBzb21lb25lIGhhZCBkb25lIHRoZSBhbmFseXNpcyBvZiB0aGlzIHBv dGVudGlhbCB2dWxuZXJhYmlsaXR5PyBUaGlzDQo+Pj4+PiBpcyBidHcgYSByZWFsIGlzc3VlIC0g cmVjYWxsIHRoYXQgYXZhdGFyIGljb24gaW1hZ2Ugc2l6ZSB3YXMgdXNhYmxlDQo+Pj4+PiB0byBp ZGVudGlmeSAzMCslIG9mIGNvbnRhY3RzIGluIG9uZSBzb2NpYWwgbmV0d29yayBldmVuIG92ZXIg VExTLA0KPj4+Pj4gYnV0IGJlZm9yZSB0aGUgcHJvdmlkZXIgY2Fub25pY2FsaXNlZCB0aGUgYXZh dGFyIGltYWdlIHNpemVzLg0KPj4+Pj4gDQo+Pj4+PiAtIFRoYW5rcyBmb3Igc2VjdGlvbiA5LiBH b29kIGpvYi4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBFY3JpdCBtYWlsaW5nIGxpc3QgDQo+Pj4+PiBFY3JpdEBp ZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4+ IA0KPj4gDQoNCg== From nobody Wed Sep 2 08:42:45 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6A1B3393; Wed, 2 Sep 2015 08:42:34 -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 Y3UbsSrzMwV8; Wed, 2 Sep 2015 08:42: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 69B401A00E4; Wed, 2 Sep 2015 08:42:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E895BE7D; Wed, 2 Sep 2015 16:42:30 +0100 (IST) 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 8iq_NjRfFf29; Wed, 2 Sep 2015 16:42:30 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E05D6BE5D; Wed, 2 Sep 2015 16:42:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441208549; bh=bglrPYeXNLWr8xYUsKdyYTQoeWLTND9c7aXkrF+ldJ0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dp0rGNnerU+x5o23DijT+KDx//kLn1Evq5Ue3Ip7uYG/YUb0F3exwYSjv30hU0qWi P34Ud/eXFCBRoq/uYVRmhZwUX6L1aAVmvRuHxd96AK01M70a5QGwtc3MZiRHO3eIB4 QZBuPl8tlM8slJn96UTYiUt1L7BLtVuVnfeiCBaA= To: "Rosen, Brian" References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <0A860905-0339-4F7A-AB74-272B405C1496@neustar.biz> <55E70E64.9060601@cs.tcd.ie> <2FD7DCB7-5E1E-4D74-A966-3964FBD76151@neustar.biz> <55E71252.5040603@cs.tcd.ie> <8542E871-DAB1-4703-84C0-F90D50441569@neustar.biz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55E718E5.5050008@cs.tcd.ie> Date: Wed, 2 Sep 2015 16:42:29 +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: <8542E871-DAB1-4703-84C0-F90D50441569@neustar.biz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , The IESG , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 15:42:34 -0000 On 02/09/15 16:38, Rosen, Brian wrote: > No, there is no such list. There is a registry of identifiers > assigned by other authorities, which is what I think you are thinking > about. But that list is not a list of entities who produce > standards. It happens that NENA has an ID series, and does > standards, but there are plenty of examples of standards > organizations who don’t have identifier series and others that have > identifiers series but don’t produce standards. I’m confident an > expert can distinguish when a document comes from an appropriate > organization. Fair enough. I'd clear the discuss on that basis anyway. Cheers, S. > > Brian >> On Sep 2, 2015, at 8:14 AM, Stephen Farrell >> wrote: >> >> >> >> On 02/09/15 16:09, Rosen, Brian wrote: >>> “Document Required” and “Expert Review” with guidance to the >>> expert? >> >> Yeah that might be best I guess, if the guidance says something the >> equivalent of "standards-track or a specification from a >> emergency services SDO" >> >> Do I recall right that this draft already sets up one registry >> that essentially lists that kind of emergency services SDO? If so, >> then an option might be to require that the specification be from >> one of those and to require IESG approval for getting added to >> that registry. We have a similar sort of setup for SDOs that do >> some media type stuff, so this isn't that innovative, if the list >> of relevant SDOs is likely smallish and stable. >> >> Cheers, S. >> >> >>> >>> Brian >>> >>>> On Sep 2, 2015, at 7:57 AM, Stephen Farrell >>>> wrote: >>>> >>>> >>>> >>>> On 02/09/15 15:52, Rosen, Brian wrote: >>>>> I’m okay with the MUST NOT except, and I can imagine other >>>>> uses for these that will work fine if we write a document >>>>> that explains them. >>>> >>>> Cool, should be relatively easy to work out words if everyone >>>> agrees on that. >>>> >>>>> >>>>> I’m strongly against standards track for extensions. There >>>>> are a number of organizations who have expertise that need to >>>>> be able to define the data. We can’t be experts in all >>>>> things. An example is that we’re going to extend for medical >>>>> data useful to a first responder. Clearly has major privacy >>>>> issues, but we’re not the experts in that, and those that are >>>>> don’t write RFCs. NENA, the 9-1-1 organization in North >>>>> America is working on extensions for location related data, >>>>> and also knows 10X more about location data for emergency >>>>> response than IETF does. We need to let the experts do their >>>>> jobs. >>>> >>>> Fair point. If we had a way to say "IETF standards-track or a >>>> standard from an emergency services SDO" I'd be fine with that. >>>> I don't think we do have a way to say that though, other than >>>> by writing guidance in the IANA considerations section to that >>>> effect. Maybe someone who is better at IANA minutiae can figure >>>> out a way to get that effect? >>>> >>>> Cheers, S. >>>> >>>> >>>> >>>>> >>>>> Brian >>>>> >>>>>> On Sep 1, 2015, at 4:47 PM, Stephen Farrell >>>>>> wrote: >>>>>> >>>>>> Stephen Farrell has entered the following ballot position >>>>>> for draft-ietf-ecrit-additional-data-34: Discuss >>>>>> >>>>>> 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.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT >>>>>> positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be >>>>>> found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>>> I've two things I'd like to chat about. (Note: I'm not trying >>>>>> here to insist on my preferred outcome, but I would like to >>>>>> have the discussion or else be pointed at where the WG >>>>>> already did that.) >>>>>> >>>>>> (1) section 3: You say these MAY be used. I'm not sure >>>>>> that's a good option. I think the data minimisation >>>>>> recommendations argued for in RFC6973 and RFC7258 would >>>>>> argue to add a MUST NOT. For example, saying that these >>>>>> additional data MUST NOT be sent in any non-emergency call >>>>>> without explicit user permission on a per-call basis or >>>>>> something similar? I have to admit I'm nervous that >>>>>> defining all of these may mean that some UA somewhere >>>>>> starts sending some of them in other calls without asking. >>>>>> A restriction along those lines would also be more in line >>>>>> with webrtc too perhaps. But maybe this was discussed in >>>>>> the WG, having considered those privacy issues - was it? >>>>>> Either way, would adding such a "MUST NOT except if..." be >>>>>> a good plan? 4.3.4 is a good example of the kind of thing >>>>>> I'd not want easily emitted in a call. >>>>>> >>>>>> (2) I'd like to (perhaps briefly) argue that the registries >>>>>> here should require more than expert review. Extensibility >>>>>> in dealing with what will inevitably be highly privacy >>>>>> sensitive data structures that are vulnerable to misuse >>>>>> once registered seems to perhaps call for a more stringent >>>>>> registration regime. The document itself also argues (in >>>>>> 4.3.7) that adding new kinds of data here can be counter >>>>>> productive for emergency call handling, so being more >>>>>> conservative in what we add seems unusually correct here. >>>>>> I'd like to suggest we require standards track for >>>>>> extensions. The following very recent -00 draft [1] makes >>>>>> some related arguments (but of course has no standing in >>>>>> the IETF so is just offered as a way to avoid repeating >>>>>> some arguments, not as an appeal to authority.) >>>>>> >>>>>> [1] >>>>>> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>>> - abstract: the "or by reference" point is made twice >>>>>> in the abstract >>>>>> >>>>>> - intro: floor plans? HVAC status? really? Why not contact >>>>>> lists? proximity of friends? That (or inferring as much) >>>>>> seems to me to be going too far, if applied to all calls. >>>>>> I'd say just saying that this could be extended in future >>>>>> by other standards-track specifications is enough. (See >>>>>> also discuss points above) >>>>>> >>>>>> - intro: Wedding anniversary? That's surely not relevant to >>>>>> a PSAP. >>>>>> >>>>>> >>>>>> - figure 5: "prison" is out of context here, I'd suggest >>>>>> deleting it. If not, why not add hospital, power station >>>>>> and many other kinds of building? There may be some country >>>>>> specific issue or technical here, but labelling that with >>>>>> "prison" seems inappropriate to me. >>>>>> >>>>>> - 4.3.8: sorry I don't get the privacy argument, can you >>>>>> try explain it to me? (I didn't know it was possible to >>>>>> tempt an implementation, so the language there could be >>>>>> improved for sure:-) >>>>>> >>>>>> - section 5: good that this is HTTPS only. I think >>>>>> provisioning the PKI for such a thing is easily done these >>>>>> days and is rightly not optional. It might be useful to say >>>>>> that TLS here needs to follow BCP195. I agree with the >>>>>> earlier comment that you should be clear as to when >>>>>> mutually authenticated TLS is required. The secdir review >>>>>> [2] also raised similar issues and it'd be good to see >>>>>> responses to that too. (Yes, that review only arrived today >>>>>> so it's entirely reasonable to not have responded so far.) >>>>>> >>>>>> [2] >>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html >>>>>> >>>>>> >>>>>> - section 8: the sizes of the various additional data items here >>>>>> could be characteristic and leak value information >>>>>> regardless of TLS or not-TLS - perhaps add a warning that >>>>>> these may enable relatively simple traffic analysis. And >>>>>> wouldn't it be nice if someone had done the analysis of >>>>>> this potential vulnerability? This is btw a real issue - >>>>>> recall that avatar icon image size was usable to identify >>>>>> 30+% of contacts in one social network even over TLS, but >>>>>> before the provider canonicalised the avatar image sizes. >>>>>> >>>>>> - Thanks for section 9. Good job. >>>>>> >>>>>> >>>>>> _______________________________________________ Ecrit >>>>>> mailing list Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>> > From nobody Wed Sep 2 13:20:44 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707781B332D; Wed, 2 Sep 2015 13:20:43 -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 367WB-AULCq9; Wed, 2 Sep 2015 13:20:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F61B3175; Wed, 2 Sep 2015 13:20:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150902202042.15232.48041.idtracker@ietfa.amsl.com> Date: Wed, 02 Sep 2015 13:20:42 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Brian Haberman's No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 20:20:43 -0000 Brian Haberman has entered the following ballot position for draft-ietf-ecrit-additional-data-34: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have no objections to the publication of this document. - I find text like "Optional for blocks supplied by the originating device, mandatory otherwise" in multiple places in this specification. Is there a reason for not saying "originating devices MAY supply this information, all other entities MUST supply this information" or some such? - I look forward to the resolution of Stephen's DISCUSS points. From nobody Wed Sep 2 15:20:02 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD251B391E for ; Wed, 2 Sep 2015 15:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 wesBpTM9XSVu for ; Wed, 2 Sep 2015 15:19:58 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (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 AC8B71B37C3 for ; Wed, 2 Sep 2015 15:19:58 -0700 (PDT) Received: by qkdv1 with SMTP id v1so13941306qkd.0 for ; Wed, 02 Sep 2015 15:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kEkY7w/8/cR9B8yt/DIViK9q6rBz1xUDNsxtPyL1//E=; b=ZSL9JxZ+hs4Fha9H9/w0ZCsP783lOmChA2ls1NC18E7A/eLf3+LDqwKiBF8fuHDbOn 3Gx7h55jDb9qi9dOIsMwGCSSl92Ow1dz+zxyWNHH0urw7lWDKVlbEZx/M5bGSvDl7IW9 SKLrUh14IVDOJm2fqwi2e6tM52CK2DbBmwJfzp/4ymBmE3jLGMaFrCpXhMEyvMip+VDs jnIihHy8o/NkzhlavutofSlWPXaG1nUxLdAXTCMMfGRQd/oEgm6zZM4t4ki4kqLV5Yi9 ne0qv1aQk77SkAqaKsIMMPyOKzh0f3DrkSs3as2QX4xktDV15s0Mv0186SUAK/jvjZwl HSsg== X-Gm-Message-State: ALoCoQnx70qlf+rYSMkoxFtYxYq1G7vwR+G4xUCf3Kya03KtjQapax2iomD4Pbc5a4Tg8UZfl2BB X-Received: by 10.55.48.5 with SMTP id w5mr31178852qkw.94.1441232397843; Wed, 02 Sep 2015 15:19:57 -0700 (PDT) Received: from ngunter2-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id 49sm13679416qgh.4.2015.09.02.15.19.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Sep 2015 15:19:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Rosen In-Reply-To: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> Date: Wed, 2 Sep 2015 15:17:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 22:20:01 -0000 I=E2=80=99m going to let other authors comment on the MIME stuff.=20 I=E2=80=99ve had a conversation with Simon Perrault who is the Expert = on vCard things, and convinced him that =E2=80=9CMain=E2=80=9D was a = reasonable addition. I=E2=80=99ll give you the use case we discussed: An employee at an enterprise places an emergency call to report a fire. = The PBX is configured to put the callers vCard on the call. The = responder needs to contact the front desk, rather than the caller. The = main number is the right way to do that. It=E2=80=99s not, in any way, = a =E2=80=9Cpreference=E2=80=9D value. I can=E2=80=99t think of a better = name that =E2=80=9Cmain=E2=80=9D. I don=E2=80=99t have a problem adding = more motivating text. On the schema, we are trapped in the problem that we really need an XML = schema to match what else is going on in the call data, but the vCard is = Relax NG. We provided the schema as informational for just the reason = you suggest - in case of an error, it=E2=80=99s the Relax NG schema that = is correct. It originated with the vCard guys, we copied it, and = we=E2=80=99ve looked at it to see that it is up to date. =20 Brian > On Sep 1, 2015, at 10:00 PM, Barry Leiba = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: Discuss >=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 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Two things are incorrect and need fixing: >=20 > ---- In Section 4, you have "tel" and "TYPE", and "property" and > "parameter" reversed in the explanation about the "main" parameter = value. > The sentence is also confusingly worded. Try this (and see also my > comments on this bit, below): >=20 > NEW > This document adds a new parameter value called "main" to the > "TYPE" parameter of the "tel" property. > END >=20 > ---- In Section 6, there are problems in the MIME structure in the > examples (figures 16 and 17). >=20 > 1. The XML content should be indented at least as much as the SIP > headers, so you should either make sure that all XML lines are = indented > at least 6 characters, or you should make the SIP headers be indented > only by 3. >=20 > 2. There should not be a blank line between the Content-Type and > Content-Length headers. >=20 > 3. There should not be a blank line after each boundary line; the part > headers should start immediately, as the first blank line ends the > headers. >=20 > 4. There should be a blank line between the Content-Disposition header > and the XML content; that blank line ends the part headers and signals > the start of the part body. >=20 > 5. The intermediate boundary lines should not have the trailing "--"; > that's reserved for the ending boundary. The intermediates should all = be > "--boundary1". >=20 > 6. Figure 17 is missing the ending boundary, "--boundary1--", at the = very > end of the figure. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Throughout the document: > The current term is "media type", not "MIME type". It would be good = if > you can change that throughout the document. >=20 > -- Section 3 -- > A tiny, tiny point: I don't think the MAY in the last sentence is = really > a 2119 key word, and suggest making it lower case. >=20 > -- Section 4 -- >=20 > In an xCard there is no way to > specify a "main" telephone number. These numbers are useful to > emergency responders who are called to a large enterprise. This > document adds a new property value to the "tel" property of the TYPE > parameter called "main". >=20 > This doesn't explain sufficiently what you're after. I initially > wondered why the PREF parameter didn't give you what you need (PREF=3D1,= > this is my main phone number). It was only when I read the = registration > in Section 10 that I understood. I'd suggest a value other than = "main", > but I can't think of one right away. At the least, please add more = text > here to explain what you mean by "main". >=20 > I'll also note that none of the examples include the new "main" = parameter > value. Given that you're creating the value, it might be good to show = it > in use. >=20 > -- Section 4.1.5 -- >=20 > The Data > Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 = format > fully specified with country code. If a TEL URI is not = available, > it MAY be a generic SIP URI. >=20 > 2119 key word problem @1: "you SHOULD do X, but you MAY do Y instead."=20= > MAY contradicts the SHOULD. It's not so bad here because your "if" > restricts the MAY (Section 5.3 isn't that way; see below), but I'd = prefer > it if you'd change it to something like "If a TEL URI is not = available, a > generic SIP URI is acceptable." Or perhaps "A generic SIP URI is > acceptable only if a TEL URI is not available," which is a little > stronger. >=20 > -- Section 4.4.2 -- >=20 > If more than one property is provided, a parameter from the > vCard Property Value registry MUST be specified on each . >=20 > Do you really want that MUST, rather than a SHOULD? Are you really > saying that if there are multiple phone numbers but I don't know their > TYPE values, it's better to pick one and send only that one than it is = to > send you all of them just in case? >=20 > -- Section 5.1 -- >=20 > The data may also be supplied by value in any SIP request or = response > method that is permitted to contain a body (i.e., not a BYE = request). >=20 > Is BYE the only SIP request that can't contain a body? Or should that = be > "e.g."? (I'm asking; I don't know the answer.) >=20 > -- Section 5.3 -- >=20 > It is RECOMMENDED that access networks supply the data specified in > this document by reference, but they MAY provide the data by value. >=20 > Here's the SHOULD/MAY problem without an "if" to mitigate it. In this > case, I suggest explaining: >=20 > NEW > It is RECOMMENDED that access networks supply the data specified in > this document by reference. While it's permissible to provide the > data by value, this can expose private information [and/or whatever > other explanation]. > END >=20 > -- Section 10.1 -- > Thanks for providing guidance to the expert reviewers; that's really > helpful. >=20 > -- Section 11 -- > Is the comma in "Christian, Militeau" spurious? >=20 > -- Appendix A -- > You appear to have turned the RELAX NG schema from RFC 6351 into an = XML > schema and put it here, but then labelled it as informational -- a = hedge, > I guess, in case there's a mistake in this version. Why does it need = to > be included here? And how much review has it actually had, to make = sure > that there weren't any mistakes in the conversion? >=20 >=20 From nobody Wed Sep 2 19:21:18 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC01B5498; Wed, 2 Sep 2015 19:21:14 -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 C4fMwwFDmpaw; Wed, 2 Sep 2015 19:21:13 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 30E971B4D4B; Wed, 2 Sep 2015 19:21:13 -0700 (PDT) Received: by vkaw128 with SMTP id w128so16767361vka.2; Wed, 02 Sep 2015 19:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=N7mMnpUBMvs+9Jd3wtHOk9u3gekZxqOTZNq8lM4OWMQ=; b=03zEOjfcyiCly7k/jzyfsNJ9saWbxLnJN/H2jiOiHlF+CTQmYzUIPTt9m+yvSUyvoy XHAjACR9WbbqQitOv2F1uHsXlriX/PAb1ltK724zrRSSwL8/a4n9dvKo5iwjiZUe/Rz6 yPcdG+kEAL1OCotTIg5U3Q0Z0q/5Z1EhndVLRkYp+WvRt13FJY7SFnB4wiJE6BSNNFw4 SYgl89tqaeOkQ7L7EqbVWPd3jOat1tr7SKTgtNJIPSq8IU/njut9EHfArmSJBFtxZABV gWfiurSPrwoF9+KGHKCN8FIkkDwMV0BlKi6b31VAQw4q4KHdr0GRhJNUUJoZOhvAclvO zjDA== MIME-Version: 1.0 X-Received: by 10.52.38.197 with SMTP id i5mr42123061vdk.52.1441246872245; Wed, 02 Sep 2015 19:21:12 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Wed, 2 Sep 2015 19:21:12 -0700 (PDT) In-Reply-To: <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> Date: Wed, 2 Sep 2015 22:21:12 -0400 X-Google-Sender-Auth: K1pH1yzHw1ADv63bixJ9nv7HoJM Message-ID: From: Barry Leiba To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 02:21:14 -0000 > An employee at an enterprise places an emergency call to report a fire. > The PBX is configured to put the callers vCard on the call. The responde= r > needs to contact the front desk, rather than the caller. The main number > is the right way to do that. Yes, I understood that after reading the text in the IANA registration section, but not after reading the text in Section 4. That's why I asked for more text in Section 4 explaining it. > It=E2=80=99s not, in any way, a =E2=80=9Cpreference=E2=80=9D value. I ca= n=E2=80=99t think of a better name > that =E2=80=9Cmain=E2=80=9D. I don=E2=80=99t have a problem adding more = motivating text. I've asked a few other people to look at it, and they, too, didn't get "main", but they, too, had trouble coming up with a better name. Maybe we shouldn't try to hard to make a very short name, and use a longer one such as "main-office", or "front-desk", or some such. That plus more explanation in that paragraph in Section 4 should make it all better. (But note, too, that this isn't a blocking comment. I think it should be explained better, and I'd like you to do that, but I'm not going to hold up the document for it if you'd rather not change the name of the parameter value.) > On the schema, we are trapped in the problem that we really need an > XML schema to match what else is going on in the call data, but the > vCard is Relax NG. We provided the schema as informational for just > the reason you suggest - in case of an error, it=E2=80=99s the Relax NG s= chema > that is correct. It originated with the vCard guys, we copied it, and > we=E2=80=99ve looked at it to see that it is up to date. Ack. That's a good enough explanation for me, and thanks. Barry From nobody Wed Sep 2 20:22:53 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABE01B36C6; Wed, 2 Sep 2015 20:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 Ar0c19uXViJx; Wed, 2 Sep 2015 20:22:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5B1B3803; Wed, 2 Sep 2015 20:22:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> Date: Wed, 02 Sep 2015 20:22:50 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 03:22:51 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-ecrit-additional-data-34: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note that Stephen hasn't cleared his Discuss yet, so I'll let that play out (and thanks to all who are busily Discussing it), but just for the record, I'm also confused between The intent is that every emergency call carry the information described here using the mechanisms described here. and (paraphrasing) "we aren't the experts on extending this mechanism, and we can't say who is, but there's more than one set of experts" This tussle sounds like a fork waiting to happen. Is that going to be a problem? One answer could be "if it is, we aren't the ones who are going to have to solve it", but I thought I'd ask. From nobody Thu Sep 3 06:19:19 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B281B33D0; Thu, 3 Sep 2015 06:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 aaNEpRx9r2qL; Thu, 3 Sep 2015 06:19:02 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 ECCB81A0061; Thu, 3 Sep 2015 06:19:01 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t83DImqi016929; Thu, 3 Sep 2015 09:18:59 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1wpeavsa11-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 03 Sep 2015 09:18:59 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 3 Sep 2015 09:18:59 -0400 From: "Rosen, Brian" To: Spencer Dawkins Thread-Topic: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) Thread-Index: AQHQ5ksX/XUbW5vVRkCFqQMIhONZWw== Date: Thu, 3 Sep 2015 13:18:58 +0000 Message-ID: <6FD306C8-8C2F-4CAA-B3ED-827540FD70CC@neustar.biz> References: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> In-Reply-To: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.16] Content-Type: text/plain; charset="utf-8" Content-ID: <2290CF90B529494E94A31261E906185C@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-03_06:2015-09-03,2015-09-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 13:19:10 -0000 Tm90IGV2ZXJ5IGNhbGwgaGFzIGV2ZXJ5IGJsb2NrLiAgVGhlcmUgaXMgb25seSBvbmUgYmxvY2sg dGhhdCBpcyByZXF1aXJlZCwgd2hpY2ggaXMg4oCcd2hvIHNlbnQgdGhlIGRhdGHigJ0uICBUaGF0 IGJsb2NrIGluY2x1ZGVzIGNvbnRhY3QgaW5mby4gIFdlIHdhbnQgZXZlcnkgZW50aXR5IHRvIGhh bmRsZXMgdGhlIGNhbGwgdG8gc3VwcGx5IGF0IGxlYXN0IHRoYXQgYmxvY2suICBJZiB5b3UgaGF2 ZSBtb3JlIGluZm8sIHBsZWFzZSBzZW5kIGl0LCBidXQgYXQgbGVhc3QgdGVsbCBtZSBob3cgdG8g Y29udGFjdCB5b3UuICBUaGlzIGNvcnJlc3BvbmRzIHRvIHRoZSBjdXJyZW50IG1lY2hhbmlzbXMg aW4gTm9ydGggQW1lcmljYSBhbmQgZWxzZXdoZXJlOiBtb2JpbGUgbmV0d29ya3Mgb25seSBzdXBw bHkgdGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIG9wZXJhdG9yIGhhbmRsaW5nIHRoZSBjYWxs LCB3aXJlbGluZSBuZXR3b3JrcyBzdXBwbHkgdGhhdCBhbmQgYWxzbyBhIHN1YnNjcmliZXIgbmFt ZS9hZGRyZXNzLiANCg0KVGhlIGV4dGVuc2lvbiBpcyBhZGRpdGlvbmFsIGJsb2NrcyBvZiBkYXRh LCBhbmQgd2UgaGF2ZSB0byBhbGxvdyBvdGhlcnMgdG8gZGVmaW5lIGJsb2Nrcy4gIE1hbnkgb2Yg dGhvc2UgYmxvY2tzIHdvdWxkbuKAmXQgbWFrZSBzZW5zZSBmb3IsIGFzIGFuIGV4YW1wbGUsIGEg Y2FycmllciB0byBwcm92aWRlLiAgT3RoZXJzIG1pZ2h0IG5vdCBtYWtlIHNlbnNlIGZvciBhbnlv bmUgZXhjZXB0LCBzYXksIGFuIGVudGVycHJpc2UgdG8gc3VwcGx5Lg0KDQpCcmlhbg0KDQo+IE9u IFNlcCAyLCAyMDE1LCBhdCAxMToyMiBQTSwgU3BlbmNlciBEYXdraW5zIDxzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBTcGVuY2VyIERhd2tpbnMgaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtZWNyaXQt YWRkaXRpb25hbC1kYXRhLTM0OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcw0KPiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBh bG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVjcml0LWFkZGl0aW9u YWwtZGF0YS8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiBJIG5vdGUgdGhhdCBTdGVwaGVuIGhhc24ndCBjbGVhcmVkIGhpcyBE aXNjdXNzIHlldCwgc28gSSdsbCBsZXQgdGhhdCBwbGF5DQo+IG91dCAoYW5kIHRoYW5rcyB0byBh bGwgd2hvIGFyZSBidXNpbHkgRGlzY3Vzc2luZyBpdCksIGJ1dCBqdXN0IGZvciB0aGUNCj4gcmVj b3JkLCBJJ20gYWxzbyBjb25mdXNlZCBiZXR3ZWVuIA0KPiANCj4gICBUaGUgaW50ZW50DQo+ICAg aXMgdGhhdCBldmVyeSBlbWVyZ2VuY3kgY2FsbCBjYXJyeSB0aGUgaW5mb3JtYXRpb24gZGVzY3Jp YmVkIGhlcmUNCj4gICB1c2luZyB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaGVyZS4NCj4gDQo+ IGFuZCAocGFyYXBocmFzaW5nKQ0KPiANCj4gIndlIGFyZW4ndCB0aGUgZXhwZXJ0cyBvbiBleHRl bmRpbmcgdGhpcyBtZWNoYW5pc20sIGFuZCB3ZSBjYW4ndCBzYXkgd2hvDQo+IGlzLCBidXQgdGhl cmUncyBtb3JlIHRoYW4gb25lIHNldCBvZiBleHBlcnRzIg0KPiANCj4gVGhpcyB0dXNzbGUgc291 bmRzIGxpa2UgYSBmb3JrIHdhaXRpbmcgdG8gaGFwcGVuLg0KPiANCj4gSXMgdGhhdCBnb2luZyB0 byBiZSBhIHByb2JsZW0/IE9uZSBhbnN3ZXIgY291bGQgYmUgImlmIGl0IGlzLCB3ZSBhcmVuJ3QN Cj4gdGhlIG9uZXMgd2hvIGFyZSBnb2luZyB0byBoYXZlIHRvIHNvbHZlIGl0IiwgYnV0IEkgdGhv dWdodCBJJ2QgYXNrLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg== From nobody Thu Sep 3 06:38:01 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206341A1A76; Thu, 3 Sep 2015 06:37:58 -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 PPxMrWkPNCiN; Thu, 3 Sep 2015 06:37:55 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 915D61B36F6; Thu, 3 Sep 2015 06:37:36 -0700 (PDT) Received: by vkaw128 with SMTP id w128so24301332vka.2; Thu, 03 Sep 2015 06:37:35 -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=d0dyX8WQWmdBSNr3CTQDHTtivbJQLx+bMMmLQjS5wVw=; b=p0It4fSiQRa9qMvop6oEmgfPolWd4TG+CsxbQfd5lfVSK5aclVV11ONWT2ek7ZyUSL s1iIz0SAFnTsN4DbTJ8dbK3wMsPm9D+yaIxiBjqvJMhoghr9elG5rXaek9Irb/CVbvIX V/nJPzEyx6zW7fNxhCgTPYCJ4UAP8C7SihL/cnzORe9x9zdM5Z02qDb6Kk6XPZWKl+uD hiJCmih9C+JOOFsoxLf87ePH4/ErWCfegoZzPneMrRM5stgeKcbI3uwyYaIH1nI78df0 YtQyRw2BTlcArHPZ59KyVgIqjCKJLh7rDyi10GATmeDaDW4DaRDGHT8pYcxc/2kP0k/f LUDA== MIME-Version: 1.0 X-Received: by 10.53.13.231 with SMTP id fb7mr4974284vdd.47.1441287455603; Thu, 03 Sep 2015 06:37:35 -0700 (PDT) Received: by 10.31.225.132 with HTTP; Thu, 3 Sep 2015 06:37:35 -0700 (PDT) In-Reply-To: <6FD306C8-8C2F-4CAA-B3ED-827540FD70CC@neustar.biz> References: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> <6FD306C8-8C2F-4CAA-B3ED-827540FD70CC@neustar.biz> Date: Thu, 3 Sep 2015 08:37:35 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=001a1135f75acf843b051ed7e290 Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 13:37:58 -0000 --001a1135f75acf843b051ed7e290 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Brian, On Thu, Sep 3, 2015 at 8:18 AM, Rosen, Brian wrote: > Not every call has every block. There is only one block that is required= , > which is =E2=80=9Cwho sent the data=E2=80=9D. That block includes contac= t info. We want > every entity to handles the call to supply at least that block. If you > have more info, please send it, but at least tell me how to contact you. > This corresponds to the current mechanisms in North America and elsewhere= : > mobile networks only supply the identity of the network operator handling > the call, wireline networks supply that and also a subscriber name/addres= s. > > The extension is additional blocks of data, and we have to allow others t= o > define blocks. Many of those blocks wouldn=E2=80=99t make sense for, as = an > example, a carrier to provide. Others might not make sense for anyone > except, say, an enterprise to supply. Thanks for the quick feedback. I see the problem - I should be reading The intent is that every emergency call carry the information described here using the mechanisms described here. as The intent is that every emergency call *that carries* the information described here *uses* the mechanisms described here. and doesn't go off the reservation and send it some other way. Am I getting that right? Thanks, Spencer > Brian > > > On Sep 2, 2015, at 11:22 PM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-ecrit-additional-data-34: 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.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I note that Stephen hasn't cleared his Discuss yet, so I'll let that pl= ay > > out (and thanks to all who are busily Discussing it), but just for the > > record, I'm also confused between > > > > The intent > > is that every emergency call carry the information described here > > using the mechanisms described here. > > > > and (paraphrasing) > > > > "we aren't the experts on extending this mechanism, and we can't say wh= o > > is, but there's more than one set of experts" > > > > This tussle sounds like a fork waiting to happen. > > > > Is that going to be a problem? One answer could be "if it is, we aren't > > the ones who are going to have to solve it", but I thought I'd ask. > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > --001a1135f75acf843b051ed7e290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Thu, Sep 3, 2015 at 8:18 AM, Rosen, Brian &l= t;Brian.Rosen@= neustar.biz> wrote:
Not every call has ev= ery block.=C2=A0 There is only one block that is required, which is =E2=80= =9Cwho sent the data=E2=80=9D.=C2=A0 That block includes contact info.=C2= =A0 We want every entity to handles the call to supply at least that block.= =C2=A0 If you have more info, please send it, but at least tell me how to c= ontact you.=C2=A0 This corresponds to the current mechanisms in North Ameri= ca and elsewhere: mobile networks only supply the identity of the network o= perator handling the call, wireline networks supply that and also a subscri= ber name/address.

The extension is additional blocks of data, and we have to allow others to = define blocks.=C2=A0 Many of those blocks wouldn=E2=80=99t make sense for, = as an example, a carrier to provide.=C2=A0 Others might not make sense for = anyone except, say, an enterprise to supply.

Thanks for the quick feedback.

I see the problem= - I should be reading=C2=A0

=C2=A0 =C2=A0The intent
=C2=A0 = =C2=A0is that every emergency call carry the information described here
=C2=A0 =C2=A0using the mechanisms described here.

<= div>as=C2=A0
=
=C2=A0 =C2=A0The intent
=C2=A0 =C2=A0is that every emergency call *that carries* the informati= on described here
=C2=A0 =C2=A0*uses* the mechanisms des= cribed here.
=

and doesn't go off the = reservation and send it some other way.=C2=A0

Am I getting that right?

Thanks,

Spencer
=C2=A0
Bria= n

> On Sep 2, 2015, at 11:22 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote: >
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ecrit-additional-data-34: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/= doc/draft-ietf-ecrit-additional-data/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I note that Stephen hasn't cleared his Discuss yet, so I'll le= t that play
> out (and thanks to all who are busily Discussing it), but just for the=
> record, I'm also confused between
>
>=C2=A0 =C2=A0The intent
>=C2=A0 =C2=A0is that every emergency call carry the information describ= ed here
>=C2=A0 =C2=A0using the mechanisms described here.
>
> and (paraphrasing)
>
> "we aren't the experts on extending this mechanism, and we ca= n't say who
> is, but there's more than one set of experts"
>
> This tussle sounds like a fork waiting to happen.
>
> Is that going to be a problem? One answer could be "if it is, we = aren't
> the ones who are going to have to solve it", but I thought I'= d ask.
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit


--001a1135f75acf843b051ed7e290-- From nobody Thu Sep 3 07:30:32 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971F01A92BA; Thu, 3 Sep 2015 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 0btmosAz5taB; Thu, 3 Sep 2015 07:30:18 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 A486B1A0273; Thu, 3 Sep 2015 07:30:18 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t83EN8lx000916; Thu, 3 Sep 2015 10:30:16 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1wpht6hh69-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 03 Sep 2015 10:30:16 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Thu, 3 Sep 2015 10:30:14 -0400 From: "Rosen, Brian" To: Spencer Dawkins at IETF Thread-Topic: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) Thread-Index: AQHQ5ksX/XUbW5vVRkCFqQMIhONZWw== Date: Thu, 3 Sep 2015 14:30:13 +0000 Message-ID: <493EE964-FD7E-4C87-BD65-A202A1EA1F32@neustar.biz> References: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> <6FD306C8-8C2F-4CAA-B3ED-827540FD70CC@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.16] Content-Type: multipart/alternative; boundary="_000_493EE964FD7E4C87BD65A202A1EA1F32neustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-03_08:2015-09-03,2015-09-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:30:25 -0000 --_000_493EE964FD7E4C87BD65A202A1EA1F32neustarbiz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCwgc29ydCBvZi4gIFdlIHJlYWxseSBkbyB3YW50IGV2ZXJ5IGVtZXJnZW5jeSBjYWxsIHRv IGF0IGxlYXN0IGhhdmUgdGhhdCBpZGVudGl0eSBibG9jay4NCg0KV2XigJlsbCBuZWVkIHRvIGVk aXQgdGhlIHRleHQgdG8gc2F5IG1vcmUgY2xlYXJseSB3aGF0IHdlIG1lYW4uICBJIHNlZSB0d28g d2F5cyB0byBlZGl0Og0K4oCmZXZlcnkgZW1lcmdlbmN5IGNhbGwgY2FycnkgYXQgbGVhc3Qgc29t ZSBvZiB0aGUgaW5mb3JtYXRpb27igKYuDQoNCm9yDQouLmV2ZXJ5IHByb3ZpZGVyIGluIHRoZSBw YXRoIG9mIHRoZSBjYWxsIHByb3ZpZGUgYXQgbGVhc3Qgc29tZSBvZiB0aGUgaW5mb3JtYXRpb24g 4oCmDQoNCkJyaWFuDQoNCg0KDQpPbiBTZXAgMywgMjAxNSwgYXQgOTozNyBBTSwgU3BlbmNlciBE YXdraW5zIGF0IElFVEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVu Y2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSwgQnJpYW4sDQoNCk9uIFRo dSwgU2VwIDMsIDIwMTUgYXQgODoxOCBBTSwgUm9zZW4sIEJyaWFuIDxCcmlhbi5Sb3NlbkBuZXVz dGFyLmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+PiB3cm90ZToNCk5vdCBldmVy eSBjYWxsIGhhcyBldmVyeSBibG9jay4gIFRoZXJlIGlzIG9ubHkgb25lIGJsb2NrIHRoYXQgaXMg cmVxdWlyZWQsIHdoaWNoIGlzIOKAnHdobyBzZW50IHRoZSBkYXRh4oCdLiAgVGhhdCBibG9jayBp bmNsdWRlcyBjb250YWN0IGluZm8uICBXZSB3YW50IGV2ZXJ5IGVudGl0eSB0byBoYW5kbGVzIHRo ZSBjYWxsIHRvIHN1cHBseSBhdCBsZWFzdCB0aGF0IGJsb2NrLiAgSWYgeW91IGhhdmUgbW9yZSBp bmZvLCBwbGVhc2Ugc2VuZCBpdCwgYnV0IGF0IGxlYXN0IHRlbGwgbWUgaG93IHRvIGNvbnRhY3Qg eW91LiAgVGhpcyBjb3JyZXNwb25kcyB0byB0aGUgY3VycmVudCBtZWNoYW5pc21zIGluIE5vcnRo IEFtZXJpY2EgYW5kIGVsc2V3aGVyZTogbW9iaWxlIG5ldHdvcmtzIG9ubHkgc3VwcGx5IHRoZSBp ZGVudGl0eSBvZiB0aGUgbmV0d29yayBvcGVyYXRvciBoYW5kbGluZyB0aGUgY2FsbCwgd2lyZWxp bmUgbmV0d29ya3Mgc3VwcGx5IHRoYXQgYW5kIGFsc28gYSBzdWJzY3JpYmVyIG5hbWUvYWRkcmVz cy4NCg0KVGhlIGV4dGVuc2lvbiBpcyBhZGRpdGlvbmFsIGJsb2NrcyBvZiBkYXRhLCBhbmQgd2Ug aGF2ZSB0byBhbGxvdyBvdGhlcnMgdG8gZGVmaW5lIGJsb2Nrcy4gIE1hbnkgb2YgdGhvc2UgYmxv Y2tzIHdvdWxkbuKAmXQgbWFrZSBzZW5zZSBmb3IsIGFzIGFuIGV4YW1wbGUsIGEgY2FycmllciB0 byBwcm92aWRlLiAgT3RoZXJzIG1pZ2h0IG5vdCBtYWtlIHNlbnNlIGZvciBhbnlvbmUgZXhjZXB0 LCBzYXksIGFuIGVudGVycHJpc2UgdG8gc3VwcGx5Lg0KDQpUaGFua3MgZm9yIHRoZSBxdWljayBm ZWVkYmFjay4NCg0KSSBzZWUgdGhlIHByb2JsZW0gLSBJIHNob3VsZCBiZSByZWFkaW5nDQoNCiAg IFRoZSBpbnRlbnQNCiAgIGlzIHRoYXQgZXZlcnkgZW1lcmdlbmN5IGNhbGwgY2FycnkgdGhlIGlu Zm9ybWF0aW9uIGRlc2NyaWJlZCBoZXJlDQogICB1c2luZyB0aGUgbWVjaGFuaXNtcyBkZXNjcmli ZWQgaGVyZS4NCg0KYXMNCg0KICAgVGhlIGludGVudA0KICAgaXMgdGhhdCBldmVyeSBlbWVyZ2Vu Y3kgY2FsbCAqdGhhdCBjYXJyaWVzKiB0aGUgaW5mb3JtYXRpb24gZGVzY3JpYmVkIGhlcmUNCiAg ICp1c2VzKiB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaGVyZS4NCg0KYW5kIGRvZXNuJ3QgZ28g b2ZmIHRoZSByZXNlcnZhdGlvbiBhbmQgc2VuZCBpdCBzb21lIG90aGVyIHdheS4NCg0KQW0gSSBn ZXR0aW5nIHRoYXQgcmlnaHQ/DQoNClRoYW5rcywNCg0KU3BlbmNlcg0KDQpCcmlhbg0KDQo+IE9u IFNlcCAyLCAyMDE1LCBhdCAxMToyMiBQTSwgU3BlbmNlciBEYXdraW5zIDxzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiB3 cm90ZToNCj4NCj4gU3BlbmNlciBEYXdraW5zIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWVjcml0LWFkZGl0aW9uYWwtZGF0YS0zNDog Tm8gT2JqZWN0aW9uDQo+DQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiBpbnRy b2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4NCj4NCj4gUGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KPg0KPg0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhLw0KPg0KPg0KPg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gSSBub3RlIHRoYXQg U3RlcGhlbiBoYXNuJ3QgY2xlYXJlZCBoaXMgRGlzY3VzcyB5ZXQsIHNvIEknbGwgbGV0IHRoYXQg cGxheQ0KPiBvdXQgKGFuZCB0aGFua3MgdG8gYWxsIHdobyBhcmUgYnVzaWx5IERpc2N1c3Npbmcg aXQpLCBidXQganVzdCBmb3IgdGhlDQo+IHJlY29yZCwgSSdtIGFsc28gY29uZnVzZWQgYmV0d2Vl bg0KPg0KPiAgIFRoZSBpbnRlbnQNCj4gICBpcyB0aGF0IGV2ZXJ5IGVtZXJnZW5jeSBjYWxsIGNh cnJ5IHRoZSBpbmZvcm1hdGlvbiBkZXNjcmliZWQgaGVyZQ0KPiAgIHVzaW5nIHRoZSBtZWNoYW5p c21zIGRlc2NyaWJlZCBoZXJlLg0KPg0KPiBhbmQgKHBhcmFwaHJhc2luZykNCj4NCj4gIndlIGFy ZW4ndCB0aGUgZXhwZXJ0cyBvbiBleHRlbmRpbmcgdGhpcyBtZWNoYW5pc20sIGFuZCB3ZSBjYW4n dCBzYXkgd2hvDQo+IGlzLCBidXQgdGhlcmUncyBtb3JlIHRoYW4gb25lIHNldCBvZiBleHBlcnRz Ig0KPg0KPiBUaGlzIHR1c3NsZSBzb3VuZHMgbGlrZSBhIGZvcmsgd2FpdGluZyB0byBoYXBwZW4u DQo+DQo+IElzIHRoYXQgZ29pbmcgdG8gYmUgYSBwcm9ibGVtPyBPbmUgYW5zd2VyIGNvdWxkIGJl ICJpZiBpdCBpcywgd2UgYXJlbid0DQo+IHRoZSBvbmVzIHdobyBhcmUgZ29pbmcgdG8gaGF2ZSB0 byBzb2x2ZSBpdCIsIGJ1dCBJIHRob3VnaHQgSSdkIGFzay4NCj4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0 DQo+IEVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCg0K --_000_493EE964FD7E4C87BD65A202A1EA1F32neustarbiz_ Content-Type: text/html; charset="utf-8" Content-ID: <007DF9FEB930DA43B555789F07E9A751@neustar.biz> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KV2VsbCwgc29ydCBvZi4gJm5ic3A7 V2UgcmVhbGx5IGRvIHdhbnQgZXZlcnkgZW1lcmdlbmN5IGNhbGwgdG8gYXQgbGVhc3QgaGF2ZSB0 aGF0IGlkZW50aXR5IGJsb2NrLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+V2XigJlsbCBuZWVkIHRvIGVkaXQgdGhlIHRleHQgdG8gc2F5IG1vcmUg Y2xlYXJseSB3aGF0IHdlIG1lYW4uICZuYnNwO0kgc2VlIHR3byB3YXlzIHRvIGVkaXQ6PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPuKApmV2ZXJ5IGVtZXJnZW5jeSBjYWxsIGNhcnJ5IGF0IGxlYXN0IHNv bWUgb2YgdGhlIGluZm9ybWF0aW9u4oCmLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+b3ImbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Li5ldmVyeSBwcm92aWRlciBpbiB0aGUgcGF0aCBvZiB0aGUgY2FsbCBwcm92aWRlIGF0IGxlYXN0 IHNvbWUgb2YgdGhlIGluZm9ybWF0aW9uIOKApjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnJpYW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMywgMjAxNSwgYXQgOTozNyBBTSwgU3BlbmNl ciBEYXdraW5zIGF0IElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRm QGdtYWlsLmNvbSIgY2xhc3M9IiI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGksIEJyaWFuLA0KPGRpdiBj bGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij5PbiBUaHUsIFNlcCAzLCAyMDE1IGF0IDg6MTggQU0sIFJvc2VuLCBCcmlhbiA8c3BhbiBkaXI9 Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+ Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRo OjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxl OnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KTm90IGV2ZXJ5IGNhbGwgaGFzIGV2ZXJ5IGJsb2Nr LiZuYnNwOyBUaGVyZSBpcyBvbmx5IG9uZSBibG9jayB0aGF0IGlzIHJlcXVpcmVkLCB3aGljaCBp cyDigJx3aG8gc2VudCB0aGUgZGF0YeKAnS4mbmJzcDsgVGhhdCBibG9jayBpbmNsdWRlcyBjb250 YWN0IGluZm8uJm5ic3A7IFdlIHdhbnQgZXZlcnkgZW50aXR5IHRvIGhhbmRsZXMgdGhlIGNhbGwg dG8gc3VwcGx5IGF0IGxlYXN0IHRoYXQgYmxvY2suJm5ic3A7IElmIHlvdSBoYXZlIG1vcmUgaW5m bywgcGxlYXNlIHNlbmQgaXQsIGJ1dA0KIGF0IGxlYXN0IHRlbGwgbWUgaG93IHRvIGNvbnRhY3Qg eW91LiZuYnNwOyBUaGlzIGNvcnJlc3BvbmRzIHRvIHRoZSBjdXJyZW50IG1lY2hhbmlzbXMgaW4g Tm9ydGggQW1lcmljYSBhbmQgZWxzZXdoZXJlOiBtb2JpbGUgbmV0d29ya3Mgb25seSBzdXBwbHkg dGhlIGlkZW50aXR5IG9mIHRoZSBuZXR3b3JrIG9wZXJhdG9yIGhhbmRsaW5nIHRoZSBjYWxsLCB3 aXJlbGluZSBuZXR3b3JrcyBzdXBwbHkgdGhhdCBhbmQgYWxzbyBhIHN1YnNjcmliZXIgbmFtZS9h ZGRyZXNzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBleHRlbnNpb24gaXMgYWRk aXRpb25hbCBibG9ja3Mgb2YgZGF0YSwgYW5kIHdlIGhhdmUgdG8gYWxsb3cgb3RoZXJzIHRvIGRl ZmluZSBibG9ja3MuJm5ic3A7IE1hbnkgb2YgdGhvc2UgYmxvY2tzIHdvdWxkbuKAmXQgbWFrZSBz ZW5zZSBmb3IsIGFzIGFuIGV4YW1wbGUsIGEgY2FycmllciB0byBwcm92aWRlLiZuYnNwOyBPdGhl cnMgbWlnaHQgbm90IG1ha2Ugc2Vuc2UgZm9yIGFueW9uZSBleGNlcHQsIHNheSwgYW4gZW50ZXJw cmlzZSB0byBzdXBwbHkuPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzIGZvciB0aGUgcXVpY2sgZmVlZGJhY2suPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J IHNlZSB0aGUgcHJvYmxlbSAtIEkgc2hvdWxkIGJlIHJlYWRpbmcmbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuODAwMDAwMTkwNzM0OXB4IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VGhl IGludGVudDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgiIGNsYXNz PSIiPiZuYnNwOyAmbmJzcDtpcyB0aGF0IGV2ZXJ5IGVtZXJnZW5jeSBjYWxsIGNhcnJ5IHRoZSBp bmZvcm1hdGlvbiBkZXNjcmliZWQgaGVyZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44 MDAwMDAxOTA3MzQ5cHgiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAw MDAxOTA3MzQ5cHgiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDt1c2luZyB0aGUgbWVjaGFuaXNtcyBk ZXNjcmliZWQgaGVyZS48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuODAwMDAwMTkwNzM0OXB4IiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuODAwMDAwMTkwNzM0OXB4IiBjbGFzcz0iIj5hcyZuYnNwOzwvc3Bhbj48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDtUaGUgaW50ZW50PC9zcGFuPjxiciBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDcz NDlweCIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDlw eCIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2lzIHRoYXQgZXZlcnkgZW1lcmdlbmN5IGNhbGwgKnRo YXQgY2FycmllcyogdGhlIGluZm9ybWF0aW9uIGRlc2NyaWJlZCBoZXJlPC9zcGFuPjxiciBzdHls ZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDlweCIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDlweCIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyp1c2Vz KiB0aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaGVyZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3 MzQ5cHgiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgiIGNsYXNzPSIiPmFu ZCBkb2Vzbid0IGdvIG9mZiB0aGUgcmVzZXJ2YXRpb24gYW5kIHNlbmQgaXQgc29tZSBvdGhlciB3 YXkuJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjgwMDAwMDE5MDczNDlweCIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDcz NDlweCIgY2xhc3M9IiI+QW0gSSBnZXR0aW5nIHRoYXQgcmlnaHQ/PC9zcGFuPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDlweCIgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjgwMDAwMDE5MDczNDlweCIgY2xhc3M9IiI+VGhhbmtzLDwvc3Bh bj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAx OTA3MzQ5cHgiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi44MDAwMDAxOTA3MzQ5cHgiIGNsYXNzPSIi PlNwZW5jZXI8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQp O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KQnJpYW48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPjxiciBjbGFzcz0iIj4NCiZn dDsgT24gU2VwIDIsIDIwMTUsIGF0IDExOjIyIFBNLCBTcGVuY2VyIERhd2tpbnMgJmx0OzxhIGhy ZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+c3BlbmNl cmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyBTcGVuY2VyIERhd2tpbnMgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KJmd0OyBkcmFmdC1pZXRmLWVj cml0LWFkZGl0aW9uYWwtZGF0YS0zNDogTm8gT2JqZWN0aW9uPGJyIGNsYXNzPSIiPg0KJmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyIGNsYXNzPSIiPg0KJmd0OyBlbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpczxiciBjbGFzcz0iIj4NCiZndDsgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7IFBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0 YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxiciBjbGFzcz0iIj4NCiZndDsgZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnIgY2xhc3M9 IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVGhlIGRvY3Vt ZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJl OjxiciBjbGFzcz0iIj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEvIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhLzwvYT48YnIgY2xhc3M9IiI+DQom Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7IENPTU1FTlQ6PGJyIGNsYXNzPSIi Pg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgSSBub3RlIHRoYXQgU3RlcGhlbiBoYXNuJ3QgY2xlYXJlZCBoaXMgRGlzY3VzcyB5ZXQsIHNv IEknbGwgbGV0IHRoYXQgcGxheTxiciBjbGFzcz0iIj4NCiZndDsgb3V0IChhbmQgdGhhbmtzIHRv IGFsbCB3aG8gYXJlIGJ1c2lseSBEaXNjdXNzaW5nIGl0KSwgYnV0IGp1c3QgZm9yIHRoZTxiciBj bGFzcz0iIj4NCiZndDsgcmVjb3JkLCBJJ20gYWxzbyBjb25mdXNlZCBiZXR3ZWVuPGJyIGNsYXNz PSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7VGhlIGludGVudDxiciBj bGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7aXMgdGhhdCBldmVyeSBlbWVyZ2VuY3kgY2FsbCBj YXJyeSB0aGUgaW5mb3JtYXRpb24gZGVzY3JpYmVkIGhlcmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5i c3A7ICZuYnNwO3VzaW5nIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBoZXJlLjxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IGFuZCAocGFyYXBocmFzaW5nKTxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZxdW90O3dlIGFyZW4ndCB0aGUgZXhwZXJ0cyBv biBleHRlbmRpbmcgdGhpcyBtZWNoYW5pc20sIGFuZCB3ZSBjYW4ndCBzYXkgd2hvPGJyIGNsYXNz PSIiPg0KJmd0OyBpcywgYnV0IHRoZXJlJ3MgbW9yZSB0aGFuIG9uZSBzZXQgb2YgZXhwZXJ0cyZx dW90OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFRoaXMgdHVzc2xlIHNv dW5kcyBsaWtlIGEgZm9yayB3YWl0aW5nIHRvIGhhcHBlbi48YnIgY2xhc3M9IiI+DQomZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyBJcyB0aGF0IGdvaW5nIHRvIGJlIGEgcHJvYmxlbT8gT25lIGFuc3dl ciBjb3VsZCBiZSAmcXVvdDtpZiBpdCBpcywgd2UgYXJlbid0PGJyIGNsYXNzPSIiPg0KJmd0OyB0 aGUgb25lcyB3aG8gYXJlIGdvaW5nIHRvIGhhdmUgdG8gc29sdmUgaXQmcXVvdDssIGJ1dCBJIHRo b3VnaHQgSSdkIGFzay48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyBFY3JpdCBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIgY2xh c3M9IiI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0IiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQ8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_493EE964FD7E4C87BD65A202A1EA1F32neustarbiz_-- From nobody Thu Sep 3 08:38:52 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08641B32EB; Thu, 3 Sep 2015 08:38:46 -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 A0z-zn621mr7; Thu, 3 Sep 2015 08:38:43 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 3C1BC1A9107; Thu, 3 Sep 2015 08:38:32 -0700 (PDT) Received: by vkbc123 with SMTP id c123so26544407vkb.3; Thu, 03 Sep 2015 08:38:31 -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=j7JJ9ubnTIEws0gPiiXbc3UO02SKp2CwQmtXoufon9k=; b=eFvT9TQAtC2MB5TDvz1umZqVe5Jhf6opaaZZCGasnHUb9q7RHaTC6fL8rMCWDVOFY1 Q7n4PSzaxOyQt8F4CGcJVvtJMiZcqh+Z0huT3X8vwxutIyE+RIj51e8Sg/8gmJ+4W11l MLUnTPFStf3qokHvWy+uaWg5FOjYlH3grzLAdQZKJ/E20bfe3L+NV1nPU+jgQN3MC8Y0 BaK1SLpK8SCIuikc0nhBUQgw2bCjcVRw0RXZj5MA7nQn1CLhlehI4nKPwfYrxWkKRvPZ RINkFft8SFkxjvYQFbKNJjWNYvnvqdG5XWwwTyoE2k+jp69kR2RdGqvF0qnC3yN9tt3N nj8w== MIME-Version: 1.0 X-Received: by 10.52.120.15 with SMTP id ky15mr2481856vdb.33.1441294711296; Thu, 03 Sep 2015 08:38:31 -0700 (PDT) Received: by 10.31.225.132 with HTTP; Thu, 3 Sep 2015 08:38:31 -0700 (PDT) In-Reply-To: <493EE964-FD7E-4C87-BD65-A202A1EA1F32@neustar.biz> References: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> <6FD306C8-8C2F-4CAA-B3ED-827540FD70CC@neustar.biz> <493EE964-FD7E-4C87-BD65-A202A1EA1F32@neustar.biz> Date: Thu, 3 Sep 2015 10:38:31 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=089e013a293c4899b9051ed993aa Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , The IESG , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 15:38:46 -0000 --089e013a293c4899b9051ed993aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Brian, On Thu, Sep 3, 2015 at 9:30 AM, Rosen, Brian wrote: > Well, sort of. We really do want every emergency call to at least have > that identity block. > > We=E2=80=99ll need to edit the text to say more clearly what we mean. I = see two > ways to edit: > =E2=80=A6every emergency call carry at least some of the information=E2= =80=A6. > > or > ..every provider in the path of the call provide at least some of the > information =E2=80=A6 > At this point, it sounds like you're poised to Do The Right Thing. Thanks! > > Brian > > > > On Sep 3, 2015, at 9:37 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Brian, > > On Thu, Sep 3, 2015 at 8:18 AM, Rosen, Brian > wrote: > >> Not every call has every block. There is only one block that is >> required, which is =E2=80=9Cwho sent the data=E2=80=9D. That block incl= udes contact info. >> We want every entity to handles the call to supply at least that block. = If >> you have more info, please send it, but at least tell me how to contact >> you. This corresponds to the current mechanisms in North America and >> elsewhere: mobile networks only supply the identity of the network opera= tor >> handling the call, wireline networks supply that and also a subscriber >> name/address. >> >> The extension is additional blocks of data, and we have to allow others >> to define blocks. Many of those blocks wouldn=E2=80=99t make sense for,= as an >> example, a carrier to provide. Others might not make sense for anyone >> except, say, an enterprise to supply. > > > Thanks for the quick feedback. > > I see the problem - I should be reading > > The intent > is that every emergency call carry the information described here > using the mechanisms described here. > > as > > The intent > is that every emergency call *that carries* the information described > here > *uses* the mechanisms described here. > > and doesn't go off the reservation and send it some other way. > > Am I getting that right? > > Thanks, > > Spencer > > >> Brian >> >> > On Sep 2, 2015, at 11:22 PM, Spencer Dawkins < >> spencerdawkins.ietf@gmail.com> wrote: >> > >> > Spencer Dawkins has entered the following ballot position for >> > draft-ietf-ecrit-additional-data-34: 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 thi= s >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I note that Stephen hasn't cleared his Discuss yet, so I'll let that >> play >> > out (and thanks to all who are busily Discussing it), but just for the >> > record, I'm also confused between >> > >> > The intent >> > is that every emergency call carry the information described here >> > using the mechanisms described here. >> > >> > and (paraphrasing) >> > >> > "we aren't the experts on extending this mechanism, and we can't say w= ho >> > is, but there's more than one set of experts" >> > >> > This tussle sounds like a fork waiting to happen. >> > >> > Is that going to be a problem? One answer could be "if it is, we aren'= t >> > the ones who are going to have to solve it", but I thought I'd ask. >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> >> > > --089e013a293c4899b9051ed993aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Thu, Sep 3, 2015 at 9:30 AM, Rosen, Brian &l= t;Brian.Rosen@= neustar.biz> wrote:
Well, sort of.=C2=A0 We really do want every emergency call to at least hav= e that identity block.

We=E2=80=99ll need to edit the text to say more clearly what we mean.= =C2=A0 I see two ways to edit:
=E2=80=A6every emergency call carry at least some of the information= =E2=80=A6.

or=C2=A0
..every provider in the path of the call provide at least some of the = information =E2=80=A6

At this p= oint, it sounds like you're poised to Do The Right Thing. Thanks!
=
=C2=A0

Brian



On Sep 3, 2015, at 9:37 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gm= ail.com> wrote:

Hi, Brian,

On Thu, Sep 3, 2015 at 8:18 AM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
Not every call has every block.=C2=A0 There is only one block that is requi= red, which is =E2=80=9Cwho sent the data=E2=80=9D.=C2=A0 That block include= s contact info.=C2=A0 We want every entity to handles the call to supply at= least that block.=C2=A0 If you have more info, please send it, but at least tell me how to contact you.=C2=A0 This corresponds to the current= mechanisms in North America and elsewhere: mobile networks only supply the= identity of the network operator handling the call, wireline networks supp= ly that and also a subscriber name/address.

The extension is additional blocks of data, and we have to allow others to = define blocks.=C2=A0 Many of those blocks wouldn=E2=80=99t make sense for, = as an example, a carrier to provide.=C2=A0 Others might not make sense for = anyone except, say, an enterprise to supply.

Thanks for the quick feedback.

I see the problem - I should be reading=C2=A0

=C2=A0 =C2=A0The intent
=C2=A0 =C2=A0is that every eme= rgency call carry the information described here
=C2=A0 =C2=A0using the mechani= sms described here.

as=C2=A0

=C2=A0 =C2=A0The intent
=C2=A0 =C2=A0is that every eme= rgency call *that carries* the information described here
=C2=A0 =C2=A0*uses* the mechan= isms described here.

and doesn't go off th= e reservation and send it some other way.=C2=A0

Am I getting that right?<= /span>

Thanks,

Spencer
=C2=A0
Brian

> On Sep 2, 2015, at 11:22 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com= > wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ecrit-additional-data-34: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I note that Stephen hasn't cleared his Discuss yet, so I'll le= t that play
> out (and thanks to all who are busily Discussing it), but just for the=
> record, I'm also confused between
>
>=C2=A0 =C2=A0The intent
>=C2=A0 =C2=A0is that every emergency call carry the information describ= ed here
>=C2=A0 =C2=A0using the mechanisms described here.
>
> and (paraphrasing)
>
> "we aren't the experts on extending this mechanism, and we ca= n't say who
> is, but there's more than one set of experts"
>
> This tussle sounds like a fork waiting to happen.
>
> Is that going to be a problem? One answer could be "if it is, we = aren't
> the ones who are going to have to solve it", but I thought I'= d ask.
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org=
> https://www.ietf.org/mailman/listinfo/ecrit




--089e013a293c4899b9051ed993aa-- From nobody Wed Sep 9 17:45:01 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F721B4FB5 for ; Wed, 9 Sep 2015 17:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ikTd8nuAs3hE for ; Wed, 9 Sep 2015 17:44:56 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 49DE31B4FB1 for ; Wed, 9 Sep 2015 17:44:55 -0700 (PDT) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 09 Sep 2015 20:44:54 -0400 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 9 Sep 2015 20:44:54 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 9 Sep 2015 20:44:53 -0400 From: Andrew Allen To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-ecall and the liaison sent to 3GPP Thread-Index: AdDrYbM+8dHfLXh9SoO9/96kK9TF6g== Date: Thu, 10 Sep 2015 00:44:52 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233A4DF19CXMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] draft-ietf-ecrit-ecall and the liaison sent to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 00:45:00 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233A4DF19CXMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alissa asked me to send to the list a summary of what I sent earlier to the= authors, AD and chairs regarding draft-ietf-ecrit-ecall and the liaison se= nt to 3GPP in June. I have looked into the current status of the liaison an= d the NG eCall work in 3GPP and provide you my feedback on this. Note that = although I am the 3GPP-IETF coordination team lead I am providing this in a= n unofficial personal capacity as these are my personal opinions and have n= ot been discussed or endorsed by 3GPP. The current situation regarding the NG eCall work in 3GPP is that a work it= em description (this performs a somewhat similar role to an IETF WG charter= and WG milestones in scoping and authorizing work) on "Evolution to an Int= ernetworking with eCall in IMS" (EIEI) (http://www.3gpp.org/ftp/tsg_sa/TSG_= SA/TSGS_68/Docs/SP-150275.zip) and 3 Change Requests to TS 22.101 were appr= oved (http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_68/Docs/SP-150276.zip of w= hich CR0498R2 is probably the most interesting) in June 2015. This work ite= m description currently only covers the requirements work which will be par= t of 3GPP release 14. Modification to this work item description will be re= quired to authorize 3GPP SA2 to do the architectural analysis and a new CT = work item will be required for CT1 and other CT WGs to start on the stage 3= protocol work. Release 13 is the current release that 3GPP is trying to co= mplete by the end of 2015 so this release 14 work will likely not have a ve= ry high priority in 3GPP CT1 until the release 13 work is completed. Since the draft contains a protocol solution, detailed feedback on that sol= ution should come from 3GPP CT1. 3GPP CT1 had a meeting in August but witho= ut SA2 making some decisions on this in terms of the architectural impacts = based on the agreed requirements it is problematic for CT1 to provide any f= ormal detailed feedback. The liaison was presented at the CT1 but was only = noted. The next CT1 meeting is in October but the week before the next SA2= meeting and then SA2 and CT1 don't meet again until after the next IETF me= eting in November. I believe the SA1 part of the work is mainly done based = on the referenced change requests however since SA1 responsibility is only = for requirements it would inappropriate for them to provide technical feedb= ack on the contents of the solution. I therefore think it is quite unlikely that any formal technical feedback o= n the solution in the draft will be received by ECRIT from 3GPP before the = end of 2015. You may get some polite acknowledgement and some similar infor= mation to what I have provided informally here prior to that. I hope this helps with understanding the status of the work in 3GPP and wor= k planning for ECRIT. Andrew --_000_BBF5DDFE515C3946BC18D733B20DAD233A4DF19CXMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alissa asked me to send to the list a summary of wha= t I sent earlier to the authors, AD and chairs regarding draft-ietf-ecrit-ecall and the liaison sent to = 3GPP in June. I have looked into the current status of the liaison and the = NG eCall work in 3GPP and provide you my feedback on this. Note that althou= gh I am the 3GPP-IETF coordination team lead I am providing this in an unofficial personal capacity as these = are my personal opinions and have not been discussed or endorsed by 3GPP.

 =

The current situation re= garding the NG eCall work in 3GPP is that a work item description (this per= forms a somewhat similar role to an IETF WG charter and WG milestones in sc= oping and authorizing work) on “Evolution to an Internetworking with eCall in IMS” (EIEI) (http://www.3gpp.o= rg/ftp/tsg_sa/TSG_SA/TSGS_68/Docs/SP-150275.zip) and 3 Change Requests to TS 22.101 were approved (http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_68/Docs/SP-150= 276.zip of which CR0498R2 is probably the most interest= ing) in June 2015. This work item description currently only covers the req= uirements work which will be part of 3GPP release 14. Modification to this = work item description will be required to authorize 3GPP SA2 to do the architectural analysis and a new CT work i= tem will be required for CT1 and other CT WGs to start on the stage 3 proto= col work. Release 13 is the current release that 3GPP is trying to complete= by the end of 2015 so this release 14 work will likely not have a very high priority in 3GPP CT1 until the re= lease 13 work is completed.

 =

Since the draft contains= a protocol solution, detailed feedback on that solution should come from 3= GPP CT1. 3GPP CT1 had a meeting in August but without SA2 making some decis= ions on this in terms of the architectural impacts based on the agreed requirements it is problematic for CT1 to prov= ide any formal detailed feedback. The liaison was presented at the CT1 but = was only noted.  The next CT1 meeting is in October but the week befor= e the next SA2 meeting and then SA2 and CT1 don’t meet again until after the next IETF meeting in November. = I believe the SA1 part of the work is mainly done based on the referenced c= hange requests however since SA1 responsibility is only for requirements it= would inappropriate for them to provide technical feedback on the contents of the solution.

 =

I therefore think it is = quite unlikely that any formal technical feedback on the solution in the dr= aft will be received by ECRIT from 3GPP before the end of 2015. You may get= some polite acknowledgement and some similar information to what I have provided informally here prior to that.=

 =

I hope this helps with u= nderstanding the status of the work in 3GPP and work planning for ECRIT.

 =

Andrew=

 

--_000_BBF5DDFE515C3946BC18D733B20DAD233A4DF19CXMB122CNCrimnet_-- From nobody Sun Sep 13 16:52:01 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE5F1B3E55; Sun, 13 Sep 2015 16:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, 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 QbYH4q6_rEQU; Sun, 13 Sep 2015 16:51:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986EB1B3E53; Sun, 13 Sep 2015 16:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442188314; x=1473724314; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=CL1gNIsCPV5ewBPSHKz4yiQFp6T2RmYnnPi15WrUQHM=; b=C5xDvi3P+BP9TFOEfzBVxyG4+KxRmqb/moVkHxCQ1LWSeaWrfiLNBraA A1Qrwv9kZMmaHPP1WC3YpJys8sPKaIMj/d1UqH4T3ZuU2PDeb1cU2U8M5 sAdwBA0iRcDppur9Ls9TUsJ8mprJlYYB9K2NNJzd7DkXxN5V7Ob0Ky6uR E=; X-IronPort-AV: E=McAfee;i="5700,7163,7923"; a="231244010" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 13 Sep 2015 16:51:31 -0700 X-IronPort-AV: E=Sophos;i="5.17,524,1437462000"; d="scan'208";a="34141720" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Sep 2015 16:51:30 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 13 Sep 2015 16:51:28 -0700 Message-ID: In-Reply-To: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 13 Sep 2015 16:51:26 -0700 To: Ben Campbell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 23:51:57 -0000 Sorry for the delay, I am back at work and working through my email. Thanks, Ben, for your detailed review and comments; I appreciate it. Please see in-line. At 7:42 AM -0700 9/1/15, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: Yes > > 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [Edit: I asked a question below about what happens if you dereference a > block, and find the URL points to something other than what you expected. > On reflection, I should expand that to ask how dereferencing errors > should be handled in general.] In general, since this is an emergency call, we want the call to go through even if there are errors. It's better that the call go through with some data blocks missing or unusable than for the call to fail. > > This draft was clearly lots of work; thanks for making it happen. > However, I have a number of comments: > > The shepherd's writeup indicates that no XML or media type reviews were > required-but this document contains a lot of XML (examples and schema), > and a number of media type registrations. Is that an error in the > writeup, > or have those reviews been skipped? Hannes extracted the XML schemas and examples and validated them. As a result, a number of fixes were made a few months back. The draft was updated to add Appendix B ("XML Validation") to mention a few issues that may commonly arise when extracting XML examples or schema, and to note that extracted schemas are available temporarily at a URL, to be replaced with IANA's repository after publication. > This draft implicitly assumes that the emergency calls are signaled with > SIP. I don't dispute that assumption, but I think it should it's worth a > paragraph stating it explicitly. The Introduction says: This document extends the basic set of data communicated with an IP- based emergency call, as described in [RFC6443] and [RFC6881] Both those RFCs are explicitly SIP-based. However, I'd be happy to change the text from "IP-based" to "SIP-based" if people feel it would add clarity. E.g., to: This document extends the basic set of data communicated with a SIP- based emergency call, as described in [RFC6443] and [RFC6881] Or perhaps to: This document extends the basic set of data communicated with a Session Initiation Protocol (SIP) based emergency call, as described in [RFC6443] and [RFC6881] Let me know if you feel this change would be helpful. > -- section 2, 2nd paragraph: > Are there any considerations for services provided with no "company" or > "service provider" behind them? For example, lets say an individual > hosts > some VoIP related services for her own use (e.g. a SIP registrar, maybe > a > stun/turn server,etc) Are those in scope? I'm guessing not, since they > would > be unlikely to be registered with NENA, but it would be worth saying > that > explicitly. Such calls are possible and would be supported and can be done in compliance with the document. The originating device adds a device info and provider info block (the latter with device owner information, as per the document). Since there would be no further service providers, no additional blocks would be added. The document even explicitly mentions this case in Section 5 bullet 2: The device MUST provide one if it knows no service provider is in the path of the call. The device MAY insert one if it uses a service provider. > -- 3: > Is there a critical need for the bit about "certain private-use > situations"? That seems like license for abuse, without more elaboration > about "prexisting relationship" and "privacy issues addressed". The reason for that text is to permit re-use of the mechanisms within private telematics calls between a vehicle and a telematics service center (which in turn simplifies the use of the mechanisms when such calls are emergency calls from the telematics service center to a PSAP). The text appears as an exception to a ban on using the mechanisms outside of an emergency call, so without it, such use would be violating the RFC. I thought the text was pretty restrictive, since it says: certain private-use situations where the endpoints have a preexisting relationship and privacy issues are addressed within the relationship or do not apply because of it If you still feel this text is a "license for abuse" I'd be open to tightening it, but it seems pretty limited to me. > -- 4, third paragraph from end: > Can you elaborate on what you mean by "at > the same time"? Does that mean for the same call? Occurring in some > interval > of time ? This is a good question and I can see a use for some clarification here. What this is trying to say is that when a service provider processes a call it adds various blocks, all of which are linked by having the same value. There may be situations where the same provider processes a call more than once (possibly in different roles), and in those cases, each time it processes the call, it would add a set of bocks with a new value. I've added the following text for clarification: (In certain situations, the same provider might process a call more than once, likely in different roles, and in such cases, each time it processes the call, it adds a new set of bocks with a new value.) > -- 4.1.4 > Is a provider limited to one type? If the same provider provides > services in multiple categories, would they create multiple instances? A provider is limited to identifying itself as one type, but if it processes a call more than once (e.g., in different roles), it adds a set of blocks each time, and so would likely use a different value each time. But in most cases, each provider touches a call just once, with one value. It would pick the most appropriate value. > -- 4.1.5: > Do you intend 24x7 support to be a prerequisite to be a data > provider? It's not within scope of the IETF to make this requirement, but the expectation is that calls will be processed by mainstream providers who have 24/7 support for PSAPs. > -- 4.1.7, Description: "Although multiple elements may be > contained > in a structure only one element SHOULD be provided. If more > than > one appears, the first SHOULD be used." > When might it be reasonable to violate either of these SHOULDs? If the > receiver should only look at the first entry why are multiple entries > allowed at all? I think these are SHOULD rather than MUST because it won't break anything if they are violated, and there might be weird edge cases we aren't thinking about. > Also, it seems like there are vcard fields that are not useful to this > purpose and might still have privacy implications. Do we really need > people > to send everything? The text does not mandate which fields to send. It encourages sending all fields because there are some unusual circumstances where a seemingly irrelevant field might be useful to a call-taker (e.g., anniversary might conceivably be useful with a suicidal caller) and suggests a minimum set. > -- 4.2.1, How Used..., last sentence: > The term "wireless "needs more > precision if you're going to use it in a 2119 expression. With a Wi-Fi > handset connected to a wired Internet service count as wireless? How > about a > cordless phone? Good point. I changed the text to be more clear: Because the usefulness is unknown (and less clear) for cellular, this element is OPTIONAL for commercial mobile radio services (e.g., cellular) and REQUIRED otherwise. > -- Figure 5: > -Can the list of wireless types change over time? The range of services included in "wireless" will expand over time, e.g., when 5G is deployed it will count. > -I don't understand the full definition of "temp". Are these terms > defined somewhere? These are common industry terms, although in many cases these are specific to wireline service, so "temp" will become less common. In high-turnover situations such as college dorms, wireline providers often put service into this state when one person moves out. It allows a new person to move in, plug in a phone, and establish service in an automated way via the phone. Similarly, if a wireline provider suspends service due to non-payment, they may leave the service in this state. > -Do you really want "POTS" vs "PSTN"? > -Is VoIP intentionally limited to OTT services? I think we do want POTS but I changed VOIP to OTT to be more clear, and added "digital" for non-POTS, non-OTT wireline service. > -- 4.3.3: > What if the device model designation is not a number? It's fine if it contains non-digit characters (which is fairly common for model numbers of all sorts of devices). The XML schema defines it as a string. > -- 5, list item 1: "The "purpose" parameter also indicates the kind of > data > (by its MIME subtype) that is available at the URI" > What happens if the URL points to something other than the indicated > thing? Then the PSAP doesn't get what it expects, and likely will ignore the retrieved data, and the call will be processed as if the block wasn't provided at all. The PSAP will likely file a discrepancy report with the provider, which is done out of band. If the information in the block is potentially urgent for handling the call, the call-taker or a supervisor might contact the provider's PSAP support line. > - list item 2, last sentence: > I gathered this section was an overview, since > you have detailed procedures later. Please consider moving 2119 language > to > that section. To do that, I'd have to add it to both 5.2 ("Transmitting Blocks by Reference using the Element") and 5.3 (" Transmitting Blocks by Value using the Element"), which seems awkward. I think it's better to have the normative language in one common place. > -- Section 5, last paragraph: "only blocks in the registry are permitted > to > be sent using the mechanisms specified in this document" > Are implementations supposed to check the registry at run time? (Also, > that > language sounds like it should be normative.) There's no requirement or expectation for run-time checks of the registry, because applications will only access those blocks they are interested in. It's likely that software updates for PSAP and responder equipment will add support for any blocks defined since the previous release, and as matter of local configuration (e.g., policy establishment), individual PSAPs and responders will select those supported blocks that they are interested in. > -- 5.1, last paragraph: "More than one Call-Info header field with a > purpose > value starting with 'EmergencyCallData' can be expected, but at least > one > MUST be provided. The device MUST provide one if it knows no service > provider is in the path of the call." > What's the scope of the first MUST? Emergency calls? Is it possible the > device doesn't know whether there is a service provider in the path? > Should > this say it MUST insert unless it knows there is a service provider in > tHe > path? The scope of the document is explicitly restricted to emergency calls in section 3 ("Document Scope"). The device may not know, in which case it needs to include one. I've reworded the text to be: The device MUST provide one unless it knows that a service provider is in the path of the call. The device MAY insert one if it uses a service provider. Each service provider in the path of an emergency call MUST insert its own. > -- 8: > It might be worth discussing the potential harm done by a malicious > proxy > modifying a data element, or a compromised data source return incorrect > information when dereferencing a URL. If an element in the call path is compromised and under the control of an attacker, it can wreak havoc, but this is generally true for any system that isn't using end-to-end protection, and even then is true if an endpoint is compromised. I'm not sure what would be helpful to say about this in the Security Considerations section. > The first paragraph REQUIRES verification of requester credentials, but > does > specify the form of those credentials. Subsequent text talks about > client-certs and PKI verification. Are other forms of credentials > allows? > (HTTP-digest, application level logins, etc). If client-certs are > required, > please say that explicitly. The intent is to require that HTTPS with a client-side certificate be used. I've added text to say so. > - "PSAPs and responder agencies SHOULD deploy a PKI " > When might they not? What if they don't? I think the problem is simply that the IETF lacks scope to dictate to PSAPs and responder agencies outside the use of the mechanisms defined here, so I reworded this from "SHOULD" to "are strongly advised to". The new text is: When information is provided by reference, HTTPS is REQUIRED for dereferencing, the requestor MUST use a client certificate to authenticate the HTTP request, and the provider of the information is REQUIRED to validate the credentials provided by the requester. While the creation of a public key infrastructure (PKI) that has global scope may be difficult, the alternatives to creating devices and services that can provide critical information securely are more daunting. The provider of the information MAY enforce any policy it wishes to use, but PSAPs and responder agencies are strongly advised to deploy a PKI so that providers of additional data can check the certificate of the client (the requester) and decide the appropriate policy to enforce based on that certificate. > > - "emergency services authorities could obtain a credential from the DNS > entry of the domain" > Can you elaborate on that or cite something? Good catch; I added a reference to DANE (RFC 6698). > - paragraph starting with "Much of the information supplied by service > providers and devices is private and confidential": > Seems like that should go in the privacy considerations. (And probably > also > the intro.) This exact paragraph is already in the Introduction, and the Privacy Considerations section has words to the same effect but in somewhat more detail. So, I just deleted the paragraph from the Security Considerations section. > -- section 10: > Many of the registry policies require experts to access > whether an organization might be "legitimate" or "relevant". Are these > reasonable expectations on the DEs? (I don't know the answer.) I think so, because I think the designated expert will only reject a registration in very clear cases. > Nits and Editorial Comments: > > -- 4.2.1, Description: Currently, the only valid entries are... > Current as of when? I suggest "The initially valid entries are..." This was changed recently (maybe in -33 or -34) to say "Currently, the only valid entries are...." Is that OK? > > -- 4.2.1, How Used... : "... service provider does not know ..." > Does not know...what? (That's part of a long, convoluted sentence. > Please consider > breaking it into simpler sentences.) > > "... it is known to be valuable." > Known by whom? I've reworded the text to: This is non-authoritative: There are situations where the service provider does not know the type of service (e.g., anonymous pre-paid service). The type of service does not necessarily reflect the nature of the premises (e.g., a business line installed in a residence, or cellular service). The registry does not contain all possible values for all situations. Hence, this is at best advisory information, but since it mimics a similar capability in some current emergency calling systems (e.g., a field in the Automatic Location Information (ALI) information used with legacy North American wireline systems), it is known to be valuable to PSAPs. > -- 4.3.1, Description: "It is possible to receive two Additional Data > Associated with a Call data structures,..." (Occurs in several places.) > The naming is confusing. It's easy to read "additional data associated > with..." > as it's plain English meaning, rather than as a name. I suggest doing > something more distinctive than capital letters. Perhaps quotes, or even > an > abbreviation. Good point. I reworded the text to be simpler: It is possible to receive two Device Information blocks, one provided by the device and one from the service provider. > -- 4.3.7: That seems odd for this to be a subsection of the device > information function. On reflection, I agree. I moved section 4.3.6 to be new top-level section 5, and section 4.3.7 to be new subsection 5.1, and added a reference in new section 5 to section 4.3.5. > -- section 5: > It seems awkard to use a numbered list for elements that are > close to a page long each. This forces each to be a single, overlong > paragraph. Please consider subsections. I share your frustration, but unfortunately, if I switch to subsections the text that follows the section will be orphaned, since XML2RFC doesn't permit top-level text following a subsection. > -- section 5, list item 2: "circumstances about the provision of the > location" > I'm not sure I understand the meaning of "provision" in this > context. It just means providing the location (who provided it, etc.) > - Sentence starting with: "When the access network provider" > This sentence provides context information that would have been useful to > have at > the start of the section. OK, I moved this to be the third sentence in the section. > -- 5.4, 2nd paragraph: > I think people are going to be confused and look for > "by-reference" in 3204 or 3459. It might be worth re-citing 5621. Good idea. Added. > --10: > > Some sections reference tables from other sections, and some include the > tables directly. It would be nice to be consistent, one way or the other. I cleaned this up in -33 or -34 to move them all to be in the discussion sections, with the IANA section referencing them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Television is simply automated day-dreaming. --Lee Lovinger, _Quote_, July 30, 1967 From nobody Sun Sep 13 17:12:02 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5801B422B; Sun, 13 Sep 2015 17:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 dfcp8zjno5tv; Sun, 13 Sep 2015 17:12:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF041B41B2; Sun, 13 Sep 2015 17:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442189520; x=1473725520; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=/EIvpgGxpn0V0VqcCXkUcz3UwzA9qL74bau52U+slno=; b=yAGc+MdKYuvJT8pGpLyJbXKbzTPt9XUg4E3fw5SCqhquGC/NEtkSBDHt oX+pUpSHiKTLkPk/DrAsOkRSFZnoM1HuKADf/mSm5PcMlIUGeMZ1idqDU njpuOjlEUZQBruEfELPnWo9AHoF2MGmr7aPoxkXLhlcVm0yoqx7DnH3jv w=; X-IronPort-AV: E=McAfee;i="5700,7163,7923"; a="231245106" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Sep 2015 17:12:00 -0700 X-IronPort-AV: E=Sophos;i="5.17,524,1437462000"; d="scan'208";a="1001203144" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Sep 2015 17:11:59 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 13 Sep 2015 17:11:58 -0700 Message-ID: In-Reply-To: <20150901150330.25509.74890.idtracker@ietfa.amsl.com> References: <20150901150330.25509.74890.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 13 Sep 2015 17:06:58 -0700 To: Alvaro Retana , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Alvaro Retana's No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 00:12:01 -0000 At 8:03 AM -0700 9/1/15, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Given that the intent of the document "is that every emergency call carry > the information described here using the mechanisms described here", and > that additional information is being introduced as 'Required', shouldn't > it update RFC6443 and/or at least RFC6881? Hi Alvaro, Thanks for the comment. This sounds reasonable to me, so I added both RFCs to the "Updates" section. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I love the smell of excessive quoting in the morning. --Steve Dorner From nobody Sun Sep 13 23:13:50 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679B91B303B for ; Sun, 13 Sep 2015 23:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 cEVDIvy3kNBi for ; Sun, 13 Sep 2015 23:13:46 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 ADC191B4E71 for ; Sun, 13 Sep 2015 23:13:46 -0700 (PDT) Received: by padhk3 with SMTP id hk3so134085648pad.3 for ; Sun, 13 Sep 2015 23:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bGm4LqQ0kHRJ5izqI020ISYLIvciXLfCgj3OKFR/qdU=; b=bwXQjRMqWtMHV9AwRa3NrVEw5XIyrPNgFVQwIv7MIWoLjjOU6XsGVWzzMaGIfu5HIY yvFAs2vbe3yM+FL+0B07mJJkj0OTMRvouyPF+yJBabqchSNgEDLmeZhLsIIzOe85f4If dOyPZk+BfOaXgMz13CO1d569Wj/sLpJ/CBMPfDWOM244P0sNgBOHo0V70dM70pkkjGYh NcpuRvKq5NHD5fLhG7n+0r38rh98OZ1C6dGJBIim9c7wN6IXJ3sDuUre7pItRN9fg9Ds cSZsWXcP253JzEGZFJBaliPwqlg5NlgfI/AYivfzDFCI6vTs07qIaghYJi8hSpAwToNj 9Faw== X-Received: by 10.68.88.69 with SMTP id be5mr31225570pbb.105.1442211226353; Sun, 13 Sep 2015 23:13:46 -0700 (PDT) Received: from [192.168.1.11] (124-168-146-53.dyn.iinet.net.au. [124.168.146.53]) by smtp.gmail.com with ESMTPSA id tc8sm13732060pbc.43.2015.09.13.23.13.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Sep 2015 23:13:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Mon, 14 Sep 2015 16:13:41 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> To: Roger Marshall X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 06:13:48 -0000 Hi Roger et al, It has now been nearly two weeks since you sent this to the list and the = update was published during the last IETF meeting. This seems like plenty of time for Keith to have replied with further = comments. Can we please forward with this document? Cheers James > On 1 Sep 2015, at 9:18 am, Roger Marshall = wrote: >=20 > Keith, do the changes that James offered satisfy your issues? =20 >=20 > -roger. >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James = Winterbottom > Sent: Sunday, August 09, 2015 2:00 AM > To: ecrit_ietf.org > Subject: [Ecrit] draft-ietf-ecrit-held-routing >=20 > Hi All, >=20 > The only comments received during the WGLC were from Keith Drage and I = believe that I addressed all of these in a rev of the draft but I = haven=E2=80=99t heard anything back. >=20 > Keith, can you please confirm that your issues have all been addressed = by the new text and if they have then can we please move the draft = forward? >=20 > Cheers > James >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. From nobody Mon Sep 14 00:43:57 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E49F1A9173 for ; Mon, 14 Sep 2015 00:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 bwjTeULW4m8H for ; Mon, 14 Sep 2015 00:43:54 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 F0C531B4406 for ; Mon, 14 Sep 2015 00:43:47 -0700 (PDT) Received: by qkcf65 with SMTP id f65so54826629qkc.3 for ; Mon, 14 Sep 2015 00:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KfA1ONLXVqfIpDnFv0FxaHGTwy8N4SDwZZx5ud+ILNw=; b=J9NkI4GU/ZaweNXT10t+tPm9QNYKCZVLx2FeTbz/nArYVwldV5Gapkw7JFaYt9+vjf ab3US4CvFvMGnknR+9+5/q7ppjsoUKRCD7M+ESnoORubIkf2MhoAx/dmuMW0FNDwxCuE AQQrR8fnUXFjlxAufBcdI2JKIOeWQyxoI0CkA54DIULimnWIApWsvxDzIWIOdqsIvfoU b8CnWnQ0fZSOo7Nkq5TnFRas5QpDJO3qppBXOUDJ0gulDAjEeUiXqINhzLryD49qVytX i7i0dYo3tfRdBKUx6FRUWBcwAqINEXlpkU1BLilWjr9mj3su/3GbRelK/m7vIr2J2SUF B/Rw== MIME-Version: 1.0 X-Received: by 10.55.24.78 with SMTP id j75mr19762640qkh.95.1442216624174; Mon, 14 Sep 2015 00:43:44 -0700 (PDT) Received: by 10.55.22.203 with HTTP; Mon, 14 Sep 2015 00:43:43 -0700 (PDT) In-Reply-To: <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> Date: Mon, 14 Sep 2015 09:43:43 +0200 Message-ID: From: Laura Liess To: James Winterbottom Content-Type: multipart/alternative; boundary=001a11441e56afa471051fb039c4 Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 07:43:55 -0000 --001a11441e56afa471051fb039c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Keith is active on 3GPP mailing lists, so I think we would have heard from him if he would have objections to how his comment were addressed. I think we can move forward with the draft now. Thank you Laura 2015-09-14 8:13 GMT+02:00 James Winterbottom : > Hi Roger et al, > > It has now been nearly two weeks since you sent this to the list and the > update was published during the last IETF meeting. > This seems like plenty of time for Keith to have replied with further > comments. Can we please forward with this document? > > Cheers > James > > > > On 1 Sep 2015, at 9:18 am, Roger Marshall > wrote: > > > > Keith, do the changes that James offered satisfy your issues? > > > > -roger. > > > > -----Original Message----- > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James > Winterbottom > > Sent: Sunday, August 09, 2015 2:00 AM > > To: ecrit_ietf.org > > Subject: [Ecrit] draft-ietf-ecrit-held-routing > > > > Hi All, > > > > The only comments received during the WGLC were from Keith Drage and I > believe that I addressed all of these in a rev of the draft but I haven= =E2=80=99t > heard anything back. > > > > Keith, can you please confirm that your issues have all been addressed > by the new text and if they have then can we please move the draft forwar= d? > > > > Cheers > > James > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > CONFIDENTIALITY NOTICE: The information contained in this message may b= e > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --001a11441e56afa471051fb039c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Keith is active on 3GPP mailing lists, so I thin= k we would have heard from him if he would have objections to how his comme= nt were addressed. I think we can move forward with the draft now.

<= /div>Thank you
Laura

2015-09-14 8:13 GMT+02:00 James Winterbottom <a.james.winterbottom@gmail.com>:
Hi Roger et al,

It has now been nearly two weeks since you sent this to the list and the up= date was published during the last IETF meeting.
This seems like plenty of time for Keith to have replied with further comme= nts. Can we please forward with this document?

Cheers
James


> On 1 Sep 2015, at 9:18 am, Roger Marshall <RMarshall@telecomsys.com> wrote:
>
> Keith, do the changes that James offered satisfy your issues?
>
> -roger.
>
> -----Original Message-----
> From: Ecrit [mailto:ecrit-bo= unces@ietf.org] On Behalf Of James Winterbottom
> Sent: Sunday, August 09, 2015 2:00 AM
> To: ecrit_ietf.org
> Subject: [Ecrit] draft-ietf-ecrit-held-routing
>
> Hi All,
>
> The only comments received during the WGLC were from Keith Drage and I= believe that I addressed all of these in a rev of the draft but I haven=E2= =80=99t heard anything back.
>
> Keith, can you please confirm that your issues have all been addressed= by the new text and if they have then can we please move the draft forward= ?
>
> Cheers
> James
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
> CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended recipient, o= r responsible for delivering this message to the intended recipient, any re= view, forwarding, dissemination, distribution or copying of this communicat= ion or any attachment(s) is strictly prohibited. If you have received this = message in error, please notify the sender immediately, and delete it and a= ll attachments from your computer and network.

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

--001a11441e56afa471051fb039c4-- From nobody Mon Sep 14 09:27:04 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C671B3DBD; Mon, 14 Sep 2015 09:27:02 -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_50=0.8, 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] 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 vfTZKkvQoCba; Mon, 14 Sep 2015 09:26:56 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B61E1B3C8A; Mon, 14 Sep 2015 09:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442248016; x=1473784016; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=iTJFYB2nVlSWZzu9jVH7D8EUyIjhP1khCxAq+UCWLDA=; b=yRwo3hTjskr22mtLknC/zlXOYE5M8czO8njJ7gFofps99Hg0KVtVdrrM rROJboDt/hLJ1pacSoAc8uZg3VkWio1eqTHpqLSrYm7WPopZlkbqSwS1L nXK68P3nVWTC+b6v2+mWBIguwC9V6A4HLlgp7KonPc1u8GdTuAtsc9ctL w=; X-IronPort-AV: E=McAfee;i="5700,7163,7923"; a="231398955" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2015 09:26:55 -0700 X-IronPort-AV: E=Sophos;i="5.17,529,1437462000"; d="scan'208";a="975737541" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Sep 2015 09:26:54 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Sep 2015 09:26:53 -0700 Message-ID: In-Reply-To: References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 14 Sep 2015 09:26:51 -0700 To: Ben Campbell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Additional-data formatting nit (was "Re: Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:27:02 -0000 At 4:51 PM -0700 9/13/15, Randall Gellens wrote: >> -- section 5: >> It seems awkard to use a numbered list for elements that are >> close to a page long each. This forces each to be a single, overlong >> paragraph. Please consider subsections. > > I share your frustration, but unfortunately, if I switch to > subsections the text that follows the section will be orphaned, > since XML2RFC doesn't permit top-level text following a subsection. It occurred to me after I replied that I can make pseudo paragraph breaks by using . I've updated this text to do so and hence is easier to read. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I think we'd get fewer weird bug reports if we stopped selling our software off planet. From nobody Mon Sep 14 10:01:35 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51921B385B for ; Mon, 14 Sep 2015 10:01:33 -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 XmLGJ462kv00 for ; Mon, 14 Sep 2015 10:01:32 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6D81B384D for ; Mon, 14 Sep 2015 10:01:31 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-01v.sys.comcast.net with comcast id H50r1r003516pyw0151X5x; Mon, 14 Sep 2015 17:01:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id H51W1r00d3Ge9ey0151Xds; Mon, 14 Sep 2015 17:01:31 +0000 To: ecrit@ietf.org References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <55F6FD69.6070305@alum.mit.edu> Date: Mon, 14 Sep 2015 13:01:29 -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=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1442250091; bh=Y/EWNsE38VzZUvVdfqQh8H6qJnUu9j+nsvV1nxVcY+M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=R/J9riBq0izrifykf/oJgah4Ig3kZ3PCZE7bqY2cUXIEHCR5n0WytwQJOjQjAprhB 2OsMi8kGzV/g4DC4uuoyWahbuzLsI3jPt5Ea3fn+qSU5l7GvNISrhjLiR1NvbpZfVS 5cVa2xXCfL2F0pjvQNWeW7emfmvH0RmOiHDIPa6BsXtsheTcZRIAEaENX7wMya/bg9 ILtrImBXZfpVWIPQPOT5arsCzY0tuCx1OyuxVoPazWiMfg/yPq0r3dImMsimv9t5Qf 5jAlgrTtOXV/vgSZIO7/MZNn6ZLC7th5FWveHqRTgCCPoymuifbOsqJQpWaQNBajY+ pUQVPeelz1EFw== Archived-At: Subject: Re: [Ecrit] Additional-data formatting nit (was "Re: Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 17:01:34 -0000 On 9/14/15 12:26 PM, Randall Gellens wrote: > At 4:51 PM -0700 9/13/15, Randall Gellens wrote: > >>> -- section 5: >>> It seems awkard to use a numbered list for elements that are >>> close to a page long each. This forces each to be a single, overlong >>> paragraph. Please consider subsections. >> >> I share your frustration, but unfortunately, if I switch to >> subsections the text that follows the section will be orphaned, since >> XML2RFC doesn't permit top-level text following a subsection. > > It occurred to me after I replied that I can make pseudo paragraph > breaks by using . I've updated this text to do so and hence is > easier to read. IIUC, the two list elements correspond 1:1 with the subsections 5.1 and 5.2. Why can't you trim the list elements down to their first sentence. Then move the rest of the text into the corresponding subsection? Some minor rewording should make that work. Thanks, Paul From nobody Mon Sep 14 18:42:38 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7391A88D4 for ; Mon, 14 Sep 2015 18:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 x6hdE8plorg2 for ; Mon, 14 Sep 2015 18:42:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C701B3D39 for ; Mon, 14 Sep 2015 18:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442281265; x=1473817265; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=BBa7GYEd7kXraCo7bcOC0MxWnjKrMxY/93dIHGjzY/k=; b=L26h/6CiFSGlb/Iwya+ywolygp0Mzsyq4yJ8vGa38GWQKnJz98NCliZZ VUGpFjt2096f3jCJxKyIUz546y9dsOSV1N8JIxPxMzFHr/eDzIVt2QiDi 4nVytRDaltethy9PGDLjLxn+XErCutmCccn4YyhRIZNPk5EhjR3hggsml M=; X-IronPort-AV: E=McAfee;i="5700,7163,7924"; a="231486128" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 14 Sep 2015 18:41:05 -0700 X-IronPort-AV: E=Sophos;i="5.17,532,1437462000"; d="scan'208";a="34152050" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Sep 2015 18:41:04 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Sep 2015 18:41:03 -0700 Message-ID: In-Reply-To: <55F6FD69.6070305@alum.mit.edu> References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <55F6FD69.6070305@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Mon, 14 Sep 2015 18:39:05 -0700 To: Paul Kyzivat , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] Additional-data formatting nit (was "Re: Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 01:42:36 -0000 At 1:01 PM -0400 9/14/15, Paul Kyzivat wrote: > On 9/14/15 12:26 PM, Randall Gellens wrote: >> At 4:51 PM -0700 9/13/15, Randall Gellens wrote: >> >>>> -- section 5: >>>> It seems awkard to use a numbered list for elements that are >>>> close to a page long each. This forces each to be a single, overlong >>>> paragraph. Please consider subsections. >>> >>> I share your frustration, but unfortunately, if I switch to >>> subsections the text that follows the section will be orphaned, since >>> XML2RFC doesn't permit top-level text following a subsection. >> >> It occurred to me after I replied that I can make pseudo paragraph >> breaks by using . I've updated this text to do so and hence is >> easier to read. > > IIUC, the two list elements correspond 1:1 with the subsections 5.1 and 5.2. > > Why can't you trim the list elements down to their first sentence. > Then move the rest of the text into the corresponding subsection? > Some minor rewording should make that work. The two list elements provide an overview, with details in 5.1, 5.2, and 5.3, so it's not 1:1. I think with the it looks much better. have a look at -35 when it's uploaded and see if you still think the material needs to be reworded. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Ninety percent of the politicians give the other ten percent a bad name. --Henry Kissinger From nobody Mon Sep 14 18:58:30 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9D1B2A90; Mon, 14 Sep 2015 18:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 EMWMYkyEvLDi; Mon, 14 Sep 2015 18:58:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769DA1ACD4B; Mon, 14 Sep 2015 18:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442282303; x=1473818303; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=yVHtueiOJG72IlcBp6qUJ7zeShAE/+LgGALAX7YdopQ=; b=WcGoJ1dDcmF6kO2xytu+7Y+4NLlNRr+KE3FVxycKYteZybMIER8bemSj TxQKOlkkFkBLX7T8l+EIkv+R0bUwNNrExxLPDJAiOEVtY4oKZ4lM/2Mw4 Omvl0UZR7KqtqTtDKZIr9BdpminGmZEYaNE5NRgfL5vOXNsL9Q1EKupsk g=; X-IronPort-AV: E=McAfee;i="5700,7163,7924"; a="138575315" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2015 18:58:09 -0700 X-IronPort-AV: E=Sophos;i="5.17,532,1437462000"; d="scan'208";a="975970826" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Sep 2015 18:58:09 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 14 Sep 2015 18:58:06 -0700 Message-ID: In-Reply-To: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 14 Sep 2015 18:56:16 -0700 To: Stephen Farrell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 01:58:26 -0000 Hi Stephen and everyone, Thanks for your comments. Please see in-line. At 4:47 PM -0700 9/1/15, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: Discuss > > 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I've two things I'd like to chat about. (Note: I'm not trying > here to insist on my preferred outcome, but I would like to > have the discussion or else be pointed at where the WG > already did that.) > > (1) section 3: You say these MAY be used. I'm not > sure that's a good option. I think the data > minimisation recommendations argued for in RFC6973 and > RFC7258 would argue to add a MUST NOT. For example, > saying that these additional data MUST NOT be sent in > any non-emergency call without explicit user > permission on a per-call basis or something similar? > I have to admit I'm nervous that defining all of these > may mean that some UA somewhere starts sending some of > them in other calls without asking. A restriction > along those lines would also be more in line with > webrtc too perhaps. But maybe this was discussed in > the WG, having considered those privacy issues - was > it? Either way, would adding such a "MUST NOT except > if..." be a good plan? 4.3.4 is a good example of the > kind of thing I'd not want easily emitted in a call. There are two subissues here: the non-use of normative language, and the recognition that there are limited non-emergency cases where this can be used. The document originally had normative language here, but there was some small discussion in ECRIT meetings and email based on (if I recall correctly), an objection from Keith Drage that the document couldn't impose these blanket mandates; Keith wanted the document to say only that use outside of an emergency call was undefined, but I wanted something stronger, so added text that it was not appropriate. I don't mind if we want to go back to being normative, but I wanted to point out that it was changed based on Keith's objection. The permission for certain private-use cases is to permit telematics service providers to use the same mechanisms on both legs of a call: between the vehicle and the telematics service center, and between the telematics service center and the PSAP; further, it makes sense to use the same mechanisms between the vehicle and telematics service center in all calls, since the service center call handler determines if a call is an emergency or not (as opposed to the vehicle in the direct case). This is a very limited case, and it matches how things work in circuit-switched calls. > (2) I'd like to (perhaps briefly) argue that the > registries here should require more than expert > review. Extensibility in dealing with what will > inevitably be highly privacy sensitive data structures > that are vulnerable to misuse once registered seems to > perhaps call for a more stringent registration regime. > The document itself also argues (in 4.3.7) that adding > new kinds of data here can be counter productive for > emergency call handling, so being more conservative in > what we add seems unusually correct here. I'd like to > suggest we require standards track for extensions. > The following very recent -00 draft [1] makes some > related arguments (but of course has no standing in > the IETF so is just offered as a way to avoid > repeating some arguments, not as an appeal to > authority.) > > [1] > https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 We've had some discussion on this point alone. I changed all instances where the text said: The expert should determine that the entity requesting a new value is relevant for this service element To add an example that the entity is a recognized emergency-related SDO: The expert should determine that the entity requesting a new value is relevant for this service element (e.g., a recognized emergency services related SDO) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - abstract: the "or by reference" point is made twice > in the abstract I don't think it's duplicative, since the first time says that this document does it both ways, and the second time says that previous mechanisms also did it both ways. > - intro: floor plans? HVAC status? really? Why not > contact lists? proximity of friends? That (or > inferring as much) seems to me to be going too far, if > applied to all calls. I'd say just saying that this > could be extended in future by other standards-track > specifications is enough. (See also discuss points above) This text is informative and explanatory, it helps the reader understand what is meant by information about a location, and mentions specific types of data that NENA is in fact working on. Both proximity of friends and contact lists seem like data associated with a caller, which NENA has also worked on and defined a separate, out-of-band mechanism for (the data is held by a third party, a registry of third parties is available to the PSAP, who queries them). > - intro: Wedding anniversary? That's surely not > relevant to a PSAP. The text in question mentions it only as an example of personal data that might seem to indicate that vcard should be categorized as data about the caller rather than data about the call. The draft does not require that anniversary date be sent (and in fact doesn't mandate which vcard fields are to be sent), although it's conceivable that a wedding anniversary might be useful to a PSAP call taker in some circumstances (such as when a caller might be suicidal). > - figure 5: "prison" is out of context here, I'd suggest > deleting it. If not, why not add hospital, power station > and many other kinds of building? There may be some > country specific issue or technical here, but labelling > that with "prison" seems inappropriate to me. We've discussed this in other email, but the short answer is that this matches capabilities provided in legacy emergency services systems, and we don't want to lose functionality. It's quite common for calls from prisons to be treated very differently than other calls, and this isn't the case for power stations, hospitals, etc. > - 4.3.8: sorry I don't get the privacy argument, can > you try explain it to me? (I didn't know it was > possible to tempt an implementation, so the language > there could be improved for sure:-) I've reworded the text in question so it should be much clearer now: Privacy: Information sent as a device/service-specific additional data URL in the DeviceInfo block is by reference (not by value), which inherently provides some additional privacy protection (since the requester needs to supply a certificate which is verified by the supplier). > - section 5: good that this is HTTPS only. I think > provisioning the PKI for such a thing is easily done > these days and is rightly not optional. It might be > useful to say that TLS here needs to follow BCP195. I > agree with the earlier comment that you should be > clear as to when mutually authenticated TLS is > required. The secdir review [2] also raised similar > issues and it'd be good to see responses to that too. > (Yes, that review only arrived today so it's entirely > reasonable to not have responded so far.) > > [2] > https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html I'm working through my email and the comments on this document, so I'll respond to that message on its own. In response to other comments, I've clarified that when dereferencing blocks passed by reference, the requester supplies a client-side certificate which the supplier checks to uphold its policy (e.g., that the requester is an emergency services entity possessing a certificate issued by an emergency services CA). > - section 8: the sizes of the various additional data > items here could be characteristic and leak value > information regardless of TLS or not-TLS - perhaps add > a warning that these may enable relatively simple > traffic analysis. And wouldn't it be nice if someone > had done the analysis of this potential vulnerability? > This is btw a real issue - recall that avatar icon > image size was usable to identify 30+% of contacts in > one social network even over TLS, but before the > provider canonicalised the avatar image sizes. Given the restricted scope (emergency calls only), I'm not sure what would be useful to say here. It's not expected that the same device issues a large number of emergency calls. > - Thanks for section 9. Good job. Thank you. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Bankruptcy as a solution is kind of un-American. --Tom Horton, Chief Financial Officer American Airlines, reported in USA Today, 6 April 2006. From nobody Tue Sep 15 08:56:56 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84671B30A9; Tue, 1 Sep 2015 08:03:31 -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 CqOeDlacAoit; Tue, 1 Sep 2015 08:03:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C961A6FB0; Tue, 1 Sep 2015 08:03:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150901150330.25509.74890.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 08:03:30 -0700 Archived-At: X-Mailman-Approved-At: Tue, 15 Sep 2015 08:56:55 -0700 Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Alvaro Retana's No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 15:03:32 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-ecrit-additional-data-34: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given that the intent of the document “is that every emergency call carry the information described here using the mechanisms described here”, and that additional information is being introduced as ‘Required’, shouldn’t it update RFC6443 and/or at least RFC6881? From nobody Tue Sep 15 16:11:34 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02D61B2DB7; Tue, 15 Sep 2015 16:11:32 -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_50=0.8, 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] 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 vkrje8SR7AuF; Tue, 15 Sep 2015 16:11:31 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7221B2D92; Tue, 15 Sep 2015 16:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442358691; x=1473894691; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=ksUHOp9DzXbQdwGkxNn9JXXUr+A+wndmtTrSxsc/gso=; b=jaxb3QYosHLMTXMYoIgqAYKUKBtpqTOig+J3xO/vIDnf0F12UWJY+QjX 0IXVuyJLYT0tl+AI3KPBb7QD6Dj0W8cQp5WlYmX2KBC3qXZbFaDaGs2Lv LAvKpEBbul9QzUmTr/NiPIsiXBj/TmU+O020gVEo+hFVZDqF6WpEhDHm0 g=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97919268" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 15 Sep 2015 16:11:31 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="33673171" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 16:11:30 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 16:11:28 -0700 Message-ID: In-Reply-To: References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 16:11:26 -0700 To: Barry Leiba , Brian Rosen From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 23:11:33 -0000 At 10:21 PM -0400 9/2/15, Barry Leiba wrote: > I've asked a few other people to look at it, and they, too, didn't get > "main", but they, too, had trouble coming up with a better name. > Maybe we shouldn't try to hard to make a very short name, and use a > longer one such as "main-office", or "front-desk", or some such. That > plus more explanation in that paragraph in Section 4 should make it > all better. I'd be happy to change the term "main" to something else, provided we can agree on something. Perhaps "reception" or "main number" or "attendant"? I'm kind of leaning toward "attendant" but would like to hear from others. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- When you are in trouble, people who call to sympathize are really looking for he particulars. --Edgar Watson Howe From nobody Tue Sep 15 17:23:44 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F571B2F4F; Tue, 15 Sep 2015 17:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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] 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 A8cs8j0tZ7sB; Tue, 15 Sep 2015 17:23:39 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844E51B2F44; Tue, 15 Sep 2015 17:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442363020; x=1473899020; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=OtTITZSGmck03HWm3cc1BiMFGyHJawUqRldyWly8q+Y=; b=okDL5KCL3FCgWPQMf1kDF49Ak6jkXQSqCFazSarOnoVXn2U9XlWm0uBE QkYP74iiZpDca5lxOFSkTfRgBe8kmhJwS3z2ejPlNZK6yTBlzozT25o1A vZ5zh0yJ5x1Iel8NEjY+6gWQvYFuPg3YwtCwheaTTT83dbTpSJ51ztcT7 Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="96729731" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 17:23:39 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1055543959" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 17:23:39 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 17:23:37 -0700 Message-ID: In-Reply-To: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 17:23:36 -0700 To: Barry Leiba , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:23:42 -0000 At 10:00 PM -0700 9/1/15, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: Discuss > > 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Two things are incorrect and need fixing: > > ---- In Section 4, you have "tel" and "TYPE", and "property" and > "parameter" reversed in the explanation about the "main" parameter value. > The sentence is also confusingly worded. Try this (and see also my > comments on this bit, below): > > NEW > This document adds a new parameter value called "main" to the > "TYPE" parameter of the "tel" property. > END Thanks for catching the error and suggesting improved wording. I've changed the text accordingly. > ---- In Section 6, there are problems in the MIME structure in the > examples (figures 16 and 17). > > 1. The XML content should be indented at least as much as the SIP > headers, so you should either make sure that all XML lines are indented > at least 6 characters, or you should make the SIP headers be indented > only by 3. Yes, the indenting in the examples was messed up. Thanks for pointing it out. I've fixed it up (also, many of the continuation lines were weirdly indented, and much of the XML examples were inconsistently indented). > 2. There should not be a blank line between the Content-Type and > Content-Length headers. No, there shouldn't. Thanks for pointing it out. > 3. There should not be a blank line after each boundary line; the part > headers should start immediately, as the first blank line ends the > headers. Indeed. Thanks for catching this. > 4. There should be a blank line between the Content-Disposition header > and the XML content; that blank line ends the part headers and signals > the start of the part body. Indeed so, thank you. > 5. The intermediate boundary lines should not have the trailing "--"; > that's reserved for the ending boundary. The intermediates should all be > "--boundary1". Yes, these were sloppy errors. Thanks for catching them. > 6. Figure 17 is missing the ending boundary, "--boundary1--", at the very > end of the figure. Fixed, thanks. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Throughout the document: > The current term is "media type", not "MIME type". It would be good if > you can change that throughout the document. Good point. I also fixed "MIME subtype." > -- Section 3 -- > A tiny, tiny point: I don't think the MAY in the last sentence is really > a 2119 key word, and suggest making it lower case. Correct, either the section is normative or it isn't. I also took the opportunity to clarify what is meant by "private-use". > -- Section 4 -- > > In an xCard there is no way to > specify a "main" telephone number. These numbers are useful to > emergency responders who are called to a large enterprise. This > document adds a new property value to the "tel" property of the TYPE > parameter called "main". > > This doesn't explain sufficiently what you're after. I initially > wondered why the PREF parameter didn't give you what you need (PREF=1, > this is my main phone number). It was only when I read the registration > in Section 10 that I understood. I'd suggest a value other than "main", > but I can't think of one right away. At the least, please add more text > here to explain what you mean by "main". I've added text in Section 4 to help explain this: "(that is, a primary contact number, typically of an enterprise, as opposed to a direct dial number of an individual employee)". > I'll also note that none of the examples include the new "main" parameter > value. Given that you're creating the value, it might be good to show it > in use. Good point. I've fixed that. > -- Section 4.1.5 -- > > The Data > Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format > fully specified with country code. If a TEL URI is not available, > it MAY be a generic SIP URI. > > 2119 key word problem @1: "you SHOULD do X, but you MAY do Y instead." > MAY contradicts the SHOULD. It's not so bad here because your "if" > restricts the MAY (Section 5.3 isn't that way; see below), but I'd prefer > it if you'd change it to something like "If a TEL URI is not available, a > generic SIP URI is acceptable." Or perhaps "A generic SIP URI is > acceptable only if a TEL URI is not available," which is a little > stronger. I didn't see a problem here because "SHOULD" means "do it this way unless there's a really good reason why you can't, and you fully understand the implications", while the "if ... MAY" lists one such really good reason. But, I don't really care, and because you think it's confusing, I'm happy to change the "MAY" to "is acceptable." > -- Section 4.4.2 -- > > If more than one property is provided, a parameter from the > vCard Property Value registry MUST be specified on each . > > Do you really want that MUST, rather than a SHOULD? Are you really > saying that if there are multiple phone numbers but I don't know their > TYPE values, it's better to pick one and send only that one than it is to > send you all of them just in case? Good point. I'll switch it to a MAY. > -- Section 5.1 -- > > The data may also be supplied by value in any SIP request or response > method that is permitted to contain a body (i.e., not a BYE request). > > Is BYE the only SIP request that can't contain a body? Or should that be > "e.g."? (I'm asking; I don't know the answer.) Per RFC 2543: Requests MAY contain message bodies unless otherwise noted. Within this specification, the BYE request MUST NOT contain a message body. ... All responses MAY include a body. So, I suppose some other RFC could define a new request that isn't permitted to carry a body. I'm not sure it's worth worrying about. If I change it to "e.g.," that would imply that there are such requests now. > -- Section 5.3 -- > > It is RECOMMENDED that access networks supply the data specified in > this document by reference, but they MAY provide the data by value. > > Here's the SHOULD/MAY problem without an "if" to mitigate it. In this > case, I suggest explaining: > > NEW > It is RECOMMENDED that access networks supply the data specified in > this document by reference. While it's permissible to provide the > data by value, this can expose private information [and/or whatever > other explanation]. > END Good point. I reworded it to be: It is RECOMMENDED that access networks supply the data specified in this document by reference, because PIDF-LOs can be fetched by a client or other entity and stored locally, so providing the data by value risks exposing private information to a larger audience. > -- Section 10.1 -- > Thanks for providing guidance to the expert reviewers; that's really > helpful. Thanks. > -- Section 11 -- > Is the comma in "Christian, Militeau" spurious? Indeed so. Thanks for catching that! > -- Appendix A -- > You appear to have turned the RELAX NG schema from RFC 6351 into an XML > schema and put it here, but then labelled it as informational -- a hedge, > I guess, in case there's a mistake in this version. Why does it need to > be included here? And how much review has it actually had, to make sure > that there weren't any mistakes in the conversion? This was discussed and resolved in separate email. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Scandal is gossip made tedious by morality. --Oscar Wilde From nobody Tue Sep 15 17:30:01 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C8A1B2F80; Tue, 15 Sep 2015 17:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 763rrXX5WIEz; Tue, 15 Sep 2015 17:29:56 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C493F1B2F7C; Tue, 15 Sep 2015 17:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442363395; x=1473899395; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=HVIOzuZrz3FzET68iRPh4iJoGvYZzDOewfKB2cUpi3E=; b=O5+DUi564y++xSWAE6FG2dVvoRUDnysnkOkgU5j2GwEZ3Z5JmxM/qugy GY3ekdeWAROfC2kCRe9pE6xZR3lBAI/kP6VB+AllFOJype86SxTst1Ehb UESf+qsh/FP/YOUkiYK2f7Vq2OvCn+8BvvTZx08RcqsNQy3ofnMfArR/Z A=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="96730008" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 15 Sep 2015 17:29:55 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="33673840" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 17:29:54 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 17:29:53 -0700 Message-ID: In-Reply-To: <20150902202042.15232.48041.idtracker@ietfa.amsl.com> References: <20150902202042.15232.48041.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 17:29:51 -0700 To: Brian Haberman , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Brian Haberman's No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:29:57 -0000 At 1:20 PM -0700 9/2/15, Brian Haberman wrote: > Brian Haberman has entered the following ballot position for > draft-ietf-ecrit-additional-data-34: 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have no objections to the publication of this document. > > - I find text like "Optional for blocks supplied by the originating > device, mandatory otherwise" in multiple places in this specification. > Is there a reason for not saying "originating devices MAY supply this > information, all other entities MUST supply this information" or some > such? The reason is simply that this text is in the "Use:" field of a block definition, where the usual values are "required", "conditional", and "optional". > - I look forward to the resolution of Stephen's DISCUSS points. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The Macintosh may only have 10% of the market, but it is clearly the top 10%. --Douglas Adams, 1996 WWDC. From nobody Tue Sep 15 17:38:16 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668D11B2FAB; Tue, 15 Sep 2015 17:38:12 -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 HHeVfSHNcbg2; Tue, 15 Sep 2015 17:38:11 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 51FF71B2FA8; Tue, 15 Sep 2015 17:38:11 -0700 (PDT) Received: by vkao3 with SMTP id o3so79011225vka.2; Tue, 15 Sep 2015 17:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BsA7sYW8T6xx1cnk4uBT1di25SmM1m09mUkx+xnGVLc=; b=kcTHmt4+iqd7zU50opUdK/BPIYZTN97OM9aewUXOh0aVzojQLzrvKV41YiuUUVkqQm ct10rqW2QSk9yHhylK6O9rw9h1eozY930S/0/ec5/+ZDmAkE8fWyyA24IqcwU8YzSAqY Jpc84tzqO96+6HeAXNhFlE961ULUvq09V1bD6JAQuFQ4ki1/Bvt8GnuVRr/6QgdYGdbY LFOaEC8BtjK4fJb2Ded2vv/uEo4bTM3kWETjfooejCxvuETgFjL8GLxH1wMIUPqnl659 NqOEE2x6VQPJtppa45ZbgF1NS9XNURepdO6CF54O27LhAdPMdaBlUQcXiJcsWuTIdCIR xw4g== MIME-Version: 1.0 X-Received: by 10.31.33.141 with SMTP id h135mr22571346vkh.130.1442363890232; Tue, 15 Sep 2015 17:38:10 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 15 Sep 2015 17:38:10 -0700 (PDT) In-Reply-To: References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> Date: Tue, 15 Sep 2015 20:38:10 -0400 X-Google-Sender-Auth: bUF2IDoqPbmhkx-9W-2vtnBpAR8 Message-ID: From: Barry Leiba To: Randall Gellens Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org, The IESG Subject: Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:38:12 -0000 Hi, Randy... thanks for resolving all this, and I think there's nothing more that needs to be said about any of it. Just to confirm on a couple of them: > I've added text in Section 4 to help explain this: "(that is, a primary > contact number, typically of an enterprise, as opposed to a direct dial > number of an individual employee)". That looks great, and should be enough to explain it; thanks. >> Is BYE the only SIP request that can't contain a body? Or should that be >> "e.g."? (I'm asking; I don't know the answer.) ... > So, I suppose some other RFC could define a new request that isn't permitted > to carry a body. I'm not sure it's worth worrying about. If I change it to > "e.g.," that would imply that there are such requests now. But there are none other than BYE *now*, right? So that's fine, then: leave it as it is, and thanks for the answer. > Good point. I reworded it to be: > > It is RECOMMENDED that access networks supply the data specified in > this document by reference, because PIDF-LOs can be fetched by a > client or other entity and stored locally, so providing the data by > value risks exposing private information to a larger audience. Nice. Discuss will clear when I can check the update, and, again, thanks for sorting it all out. Barry From nobody Tue Sep 15 17:40:39 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F1A1B2FB2; Tue, 15 Sep 2015 17:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 eohOzq0_uwGj; Tue, 15 Sep 2015 17:40:35 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 CE5961B2FB0; Tue, 15 Sep 2015 17:40:34 -0700 (PDT) Received: by vkao3 with SMTP id o3so79036456vka.2; Tue, 15 Sep 2015 17:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d1CwN33WvPsKNPnEUrXvP2I9NulZnLKW31Q8GGJmhVQ=; b=QLS0iu8vE/sd1+g/lTBGbg2SAsgojPkawDSLFQHSza1imzIPHo5QWINzdA66yb4csk e08fbVvcA7nLd+kMPrwC/wtK8xNpqUZTJeEsJxNABJ9BzeCseTttUrp8mmtvEN+Js9JC nXtHA1/Zlh8fFv6eFFQBKReCIKn0ZV63C63ugwX1w7Wjyjp+5bD25TkM+a2EjUlWjk7P oEOhga3raFVukJpZcryljvrA+yiLDriUfC0YNmih4ef6wIm1BMrUs5cZqm7iWhhUtaOq KCyM0ULC6KDjCH8/hKJ+noACVsBJsxzNvXgX1AndG4brk8JcYJmR5w82TFp8aibDGg+Z UhsQ== MIME-Version: 1.0 X-Received: by 10.31.170.80 with SMTP id t77mr18740228vke.156.1442364033981; Tue, 15 Sep 2015 17:40:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 15 Sep 2015 17:40:33 -0700 (PDT) In-Reply-To: References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> Date: Tue, 15 Sep 2015 20:40:33 -0400 X-Google-Sender-Auth: Hyf96Rwr7xaJCGCltZrLlpZApwQ Message-ID: From: Barry Leiba To: Randall Gellens Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:40:36 -0000 >> I've asked a few other people to look at it, and they, too, didn't get >> "main", but they, too, had trouble coming up with a better name. >> Maybe we shouldn't try to hard to make a very short name, and use a >> longer one such as "main-office", or "front-desk", or some such. That >> plus more explanation in that paragraph in Section 4 should make it >> all better. > > I'd be happy to change the term "main" to something else, provided we can > agree on something. Perhaps "reception" or "main number" or "attendant"? > I'm kind of leaning toward "attendant" but would like to hear from others. "Attendant" doesn't sound great to me, but I don't object to it. Yes, other ideas would help, if anyone has them. Note that this is *not* part of my DISCUSS, as you've put in clarifying text. So let's try to find a better term, but let's not get *too* wrapped up in it. Barry From nobody Wed Sep 16 06:14:58 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176781B34BB for ; Wed, 16 Sep 2015 06:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 ShFdF3ngoLCU for ; Wed, 16 Sep 2015 06:14:55 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (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 186C71B34B2 for ; Wed, 16 Sep 2015 06:14:55 -0700 (PDT) Received: by qkdw123 with SMTP id w123so85840419qkd.0 for ; Wed, 16 Sep 2015 06:14:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=way7ZI4cOFtAdpmUSj8MfMeFet/kfMEF2KxfOPpgVeU=; b=SPf5JpYq5ciaPqqL3I0HpaicRe52twSH8qCBJqiFKKlR4CnzWb4oMIka/A8NsRDGku D7l+96zPA2gPEtNLTn3e2vqYkPKxZ8cpJSA+EbH43CIJOhWY9ph2kdvSqUmx3Nt/lgpv K295ZMe3SBsHy6gdjoDY6WP52XeSF6n/J1nKMjd6sjb5ZsrnYXfhditm3jSVLgJz68VF 9tTKFf4ftbmi0VB+VJRFS368MKXqwoCpWPRiXbJJVfn637pPVJdS14a1vaOnpI5uB/QS 59vAKTTRjRq4k2UdY+enGm+JWAV5sFfabea0ifDEI7tWE2oDX00qfSxyqiLAZH2L8DnJ HLow== X-Gm-Message-State: ALoCoQk2KyOpSCQqc3zPgaLPX4+YxxMSxhBlPXlMZRwi6tQuuftZ0aAW4tkYoB6WLCcCKMiAz+zx X-Received: by 10.55.17.12 with SMTP id b12mr40137614qkh.69.1442409294078; Wed, 16 Sep 2015 06:14:54 -0700 (PDT) Received: from [10.33.192.36] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id k32sm9988482qkh.39.2015.09.16.06.14.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 06:14:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B71FD8C5-E225-4FCC-BD21-28E111889FC6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brian Rosen In-Reply-To: Date: Wed, 16 Sep 2015 09:14:48 -0400 Message-Id: <31E9105C-CE37-47CD-8361-7BE2A49E0E7B@brianrosen.net> References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ECRIT mailing list , draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, Barry Leiba , ecrit-chairs@ietf.org Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:14:57 -0000 --Apple-Mail=_B71FD8C5-E225-4FCC-BD21-28E111889FC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would prefer =E2=80=9CMain=E2=80=9D. These days, it may not answer at = a reception area, and may or may not have someone called = =E2=80=9Cattendant=E2=80=9D. Brian > On Sep 15, 2015, at 9:21 PM, Randall Gellens = wrote: >=20 > At 8:40 PM -0400 9/15/15, Barry Leiba wrote: >=20 >> >> I've asked a few other people to look at it, and they, too, = didn't get >>>> "main", but they, too, had trouble coming up with a better name. >>>> Maybe we shouldn't try to hard to make a very short name, and use = a >>>> longer one such as "main-office", or "front-desk", or some such. = That >>>> plus more explanation in that paragraph in Section 4 should make = it >>>> all better. >>>=20 >>> I'd be happy to change the term "main" to something else, provided = we can >> > agree on something. Perhaps "reception" or "main number" or = "attendant"? >>> I'm kind of leaning toward "attendant" but would like to hear from = others. >>=20 >> "Attendant" doesn't sound great to me, but I don't object to it. = Yes, >> other ideas would help, if anyone has them. >>=20 >> Note that this is *not* part of my DISCUSS, as you've put in >> clarifying text. So let's try to find a better term, but let's not >> get *too* wrapped up in it. >=20 > I'm fine with any of the ones: "reception" or "main number" or = "attendant" or another one if someone comes up with it. Otherwise it'll = stay "main". >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The "press conference" is a politician's way of being informative > without saying anything. Should he accidentally say something, he > has at his side a "press officer" who immediately explains it away > by "clarifying" it. -- Emery Kellen --Apple-Mail=_B71FD8C5-E225-4FCC-BD21-28E111889FC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I would prefer =E2=80=9CMain=E2=80=9D.  These days, it = may not answer at a reception area, and may or may not have someone = called =E2=80=9Cattendant=E2=80=9D.

Brian

On = Sep 15, 2015, at 9:21 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:

At 8:40 PM -0400 9/15/15, Barry Leiba = wrote:

 >>  I've asked a few other people to = look at it, and they, too, didn't get
 "main", but they, too, had trouble coming up with a = better name.
 Maybe we shouldn't try to hard to make = a very short name, and use a
 longer one such as = "main-office", or "front-desk", or some such.  That
 plus more explanation in that paragraph in Section 4 = should make it
 all better.

I'd be happy to change the term = "main" to something else, provided we can
 > agree on something.  Perhaps = "reception" or "main number" or "attendant"?
I'm kind of leaning toward "attendant" but = would like to hear from others.

"Attendant" doesn't sound great to me, but I don't object to = it.  Yes,
other ideas would help, if anyone has = them.

Note that this is *not* part of my = DISCUSS, as you've put in
clarifying text.  So let's = try to find a better term, but let's not
get *too* wrapped = up in it.

I'm fine with any of the ones: "reception" or = "main number" or "attendant" or another one if someone comes up with it. = Otherwise it'll stay "main".


-- 
Randall Gellens
Opinions are personal;    facts = are suspect;    I speak for myself only
-------------- Randomly selected tag: = ---------------
The "press conference" is = a politician's way of being informative
without saying anything. Should he accidentally = say something, he
has at his side a "press = officer" who immediately explains it away
by "clarifying" it. =             &n= bsp;           &nbs= p;     -- Emery = Kellen

= --Apple-Mail=_B71FD8C5-E225-4FCC-BD21-28E111889FC6-- From nobody Wed Sep 16 08:32:03 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4901ACDBD; Wed, 16 Sep 2015 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 K_fEHd1lNw0F; Wed, 16 Sep 2015 08:32:00 -0700 (PDT) Received: from server907.appriver.com (server907a.appriver.com [204.232.250.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4654C1ACD5A; Wed, 16 Sep 2015 08:31:57 -0700 (PDT) X-Note-AR-ScanTimeLocal: 9/16/2015 11:31:54 AM X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: Too many policies to list X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 7/30/2015 9:40:34 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-206/SG:2 9/16/2015 11:31:21 AM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.982504 Source White X-Signature-Violations: 0-0-0-5971-c X-Note-419: 31.2433 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 9/16/2015 11:31:40 AM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G259 G260 G261 G262 G266 G267 G386 G403 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.1.2) with ESMTPS id 21297486; Wed, 16 Sep 2015 11:31:54 -0400 Received: from E16DN02A-S1E7.exg7.exghost.local (192.168.246.86) by E16DN02A-S1E7.exg7.exghost.local (192.168.246.86) with Microsoft SMTP Server (TLS) id 15.1.225.41; Wed, 16 Sep 2015 11:31:54 -0400 Received: from E16DN02A-S1E7.exg7.exghost.local ([fe80::f97c:f696:c575:464e]) by E16DN02A-S1E7.exg7.exghost.local ([fe80::f97c:f696:c575:464e%25]) with mapi id 15.01.0225.041; Wed, 16 Sep 2015 11:31:54 -0400 From: Matt Serra To: Randall Gellens , Barry Leiba , Brian Rosen Thread-Topic: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") Thread-Index: AQHQ8BhQq+nyowJXUk+qvNb4nTn7DJ4/R7dg Date: Wed, 16 Sep 2015 15:31:54 +0000 Message-ID: <80e64b552e2e4367bd3fbb73a115a19d@ravemobilesafety.com> References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.244.1] x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 15:32:01 -0000 An alternative more generic name for TYPE could be "preferred" or "primary"= or something to describe that this is the first number they should try to = call from amongst other contact info provided in the xCARD. This may better convey what we are trying to distinguish, and work for a br= oader set of non-office environments, so long as folks feel it is not too r= edundant with "PREF" (I'm not sure how well implemented PREF is, so we may = not be able to count on it being used extensively) -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com]=20 Sent: Tuesday, September 15, 2015 7:11 PM To: Barry Leiba; Brian Rosen Cc: draft-ietf-ecrit-additional-data@ietf.org; ecrit@ietf.org; draft-ietf-e= crit-additional-data.ad@ietf.org; The IESG; draft-ietf-ecrit-additional-dat= a.shepherd@ietf.org; ecrit-chairs@ietf.org Subject: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on dra= ft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") At 10:21 PM -0400 9/2/15, Barry Leiba wrote: > I've asked a few other people to look at it, and they, too, didn't=20 > get "main", but they, too, had trouble coming up with a better name. > Maybe we shouldn't try to hard to make a very short name, and use a =20 > longer one such as "main-office", or "front-desk", or some such. That =20 > plus more explanation in that paragraph in Section 4 should make it =20 > all better. I'd be happy to change the term "main" to something else, provided we can a= gree on something. Perhaps "reception" or "main number" or "attendant"? I= 'm kind of leaning toward "attendant" but would like to hear from others. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- When you are in troub= le, people who call to sympathize are really looking for he particulars. --Edgar Watson Howe From nobody Wed Sep 16 11:19:33 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF991A87C9; Wed, 16 Sep 2015 11:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 uJdJ9oocwXKJ; Wed, 16 Sep 2015 11:19:27 -0700 (PDT) Received: from server907.appriver.com (server907a.appriver.com [204.232.250.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9E61A87D1; Wed, 16 Sep 2015 11:19:26 -0700 (PDT) X-Note-AR-ScanTimeLocal: 9/16/2015 2:19:24 PM X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Policy: Too many policies to list X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 7/30/2015 9:40:34 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-192/SG:2 9/16/2015 2:19:24 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.985298 Source White X-Signature-Violations: 0-0-0-8660-c X-Note-419: 15.6257 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 9/16/2015 2:19:05 PM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G259 G260 G261 G262 G266 G267 G386 G403 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.1.2) with ESMTPS id 21345629; Wed, 16 Sep 2015 14:19:24 -0400 Received: from E16DN02A-S1E7.exg7.exghost.local (192.168.246.86) by E16DN02A-S1E7.exg7.exghost.local (192.168.246.86) with Microsoft SMTP Server (TLS) id 15.1.225.41; Wed, 16 Sep 2015 14:19:24 -0400 Received: from E16DN02A-S1E7.exg7.exghost.local ([fe80::f97c:f696:c575:464e]) by E16DN02A-S1E7.exg7.exghost.local ([fe80::f97c:f696:c575:464e%25]) with mapi id 15.01.0225.041; Wed, 16 Sep 2015 14:19:24 -0400 From: Matt Serra To: Randall Gellens , Barry Leiba , Brian Rosen Thread-Topic: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") Thread-Index: AQHQ8JsEzvWS/ZRnuEeGojxuzwNtZ54/dyJQ Date: Wed, 16 Sep 2015 18:19:23 +0000 Message-ID: <7846dd18b353459fa77ce308180e25fb@ravemobilesafety.com> References: <20150902050002.26200.88084.idtracker@ietfa.amsl.com> <4F870B86-6AD1-4B9D-9990-DB4FFBA55CB5@brianrosen.net> <80e64b552e2e4367bd3fbb73a115a19d@ravemobilesafety.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.244.1] x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:19:29 -0000 I'm fine with "main-number" -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com]=20 Sent: Wednesday, September 16, 2015 12:16 PM To: Matt Serra; Randall Gellens; Barry Leiba; Brian Rosen Cc: draft-ietf-ecrit-additional-data@ietf.org; ecrit@ietf.org; draft-ietf-e= crit-additional-data.ad@ietf.org; The IESG; draft-ietf-ecrit-additional-dat= a.shepherd@ietf.org; ecrit-chairs@ietf.org Subject: RE: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on= draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") My concern is that "preferred" is too generic and doesn't convey the sense = of a main number for an organization. I realize there are often automated = attendants, but still think "attendant" would cover most cases. However, h= ow about using "main-number"? At 3:31 PM +0000 9/16/15, Matt Serra wrote: > An alternative more generic name for TYPE could be "preferred" or=20 > "primary" or something to describe that this is the first number they=20 > should try to call from amongst other contact info provided in the=20 > xCARD. > > This may better convey what we are trying to distinguish, and work=20 > for a broader set of non-office environments, so long as folks feel it=20 > is not too redundant with "PREF" (I'm not sure how well implemented=20 > PREF is, so we may not be able to count on it being used extensively) > > -----Original Message----- > From: Randall Gellens [mailto:randy@qti.qualcomm.com] > Sent: Tuesday, September 15, 2015 7:11 PM > To: Barry Leiba; Brian Rosen > Cc: draft-ietf-ecrit-additional-data@ietf.org; ecrit@ietf.org;=20 > draft-ietf-ecrit-additional-data.ad@ietf.org; The IESG;=20 > draft-ietf-ecrit-additional-data.shepherd@ietf.org; > ecrit-chairs@ietf.org > Subject: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss=20 > on draft-ietf-ecrit-additional-data-34: (with DISCUSS and > COMMENT)") > > At 10:21 PM -0400 9/2/15, Barry Leiba wrote: > >> I've asked a few other people to look at it, and they, too, didn't =20 >> get "main", but they, too, had trouble coming up with a better name. >> Maybe we shouldn't try to hard to make a very short name, and use a =20 >> longer one such as "main-office", or "front-desk", or some such. =20 >> That plus more explanation in that paragraph in Section 4 should=20 >> make it all better. > > I'd be happy to change the term "main" to something else, provided we=20 > can agree on something. Perhaps "reception" or "main number" or=20 > "attendant"? I'm kind of leaning toward "attendant" but would like to=20 > hear from others. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- When you are in=20 > trouble, people who call to sympathize are really > looking for he particulars. --Edgar Watson Howe -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- XML is crap. Really. = There are no excuses. XML is nasty to parse for humans, and it's a disaster= to parse even for computers. There's just no reason for that horrible crap= to exist. --Linus Torvalds, March 6, 2014 From nobody Wed Sep 16 12:49:33 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A421A01F9; Wed, 16 Sep 2015 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hz-XzAxoWNM7; Wed, 16 Sep 2015 12:49:30 -0700 (PDT) Received: from smtp2.portlandoregon.gov (smtp2.portlandoregon.gov [74.120.152.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0001A0195; Wed, 16 Sep 2015 12:49:30 -0700 (PDT) Received: from smtp2 (127.0.0.1) id hv73sk0171sp; Wed, 16 Sep 2015 12:49:28 -0700 (envelope-from ) Received: from HUB3.rose.portland.local ([10.106.253.11]) by smtp2 (SonicWALL 7.4.9.2791) with ESMTP id 201509161949280228002; Wed, 16 Sep 2015 12:49:28 -0700 Received: from MAIL3.rose.portland.local ([fe80::e8b9:f9a7:3821:f9a4]) by hub3 ([10.106.253.11]) with mapi; Wed, 16 Sep 2015 12:49:18 -0700 From: "Schlesinger, Jerry" To: Randall Gellens Date: Wed, 16 Sep 2015 12:49:21 -0700 Thread-Topic: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") Thread-Index: AdDwuCACy3RpJtIbTXO0P21/3s0Vyg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.4.9.2791 X-Mlf-UniqueId: o201509161949280228002 Archived-At: Cc: "draft-ietf-ecrit-additional-data.ad@ietf.org" , "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:49:32 -0000 For consideration: "main establishment" or "main establishment number" as = we're discussing how to reach (call back) an establishment (business, dorm,= hotel, etc.); not an individual's contact number. By the way, if you goog= le main phone or main phone number, hundreds of businesses come up with the= ir main/switchboard number. So main or main number is probably good enough= . Jerry -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Matt Serra Sent: Wednesday, September 16, 2015 11:19 AM To: Randall Gellens; Barry Leiba; Brian Rosen Cc: draft-ietf-ecrit-additional-data@ietf.org; ecrit@ietf.org; draft-ietf-e= crit-additional-data.ad@ietf.org; ecrit-chairs@ietf.org; draft-ietf-ecrit-a= dditional-data.shepherd@ietf.org; The IESG Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on= draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") I'm fine with "main-number" -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Wednesday, September 16, 2015 12:16 PM To: Matt Serra; Randall Gellens; Barry Leiba; Brian Rosen Cc: draft-ietf-ecrit-additional-data@ietf.org; ecrit@ietf.org; draft-ietf-e= crit-additional-data.ad@ietf.org; The IESG; draft-ietf-ecrit-additional-dat= a.shepherd@ietf.org; ecrit-chairs@ietf.org Subject: RE: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on= draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") My concern is that "preferred" is too generic and doesn't convey the sense = of a main number for an organization. I realize there are often automated = attendants, but still think "attendant" would cover most cases. However, h= ow about using "main-number"? At 3:31 PM +0000 9/16/15, Matt Serra wrote: > An alternative more generic name for TYPE could be "preferred" or=20 > "primary" or something to describe that this is the first number they=20 > should try to call from amongst other contact info provided in the=20 > xCARD. > > This may better convey what we are trying to distinguish, and work=20 > for a broader set of non-office environments, so long as folks feel it=20 > is not too redundant with "PREF" (I'm not sure how well implemented=20 > PREF is, so we may not be able to count on it being used extensively) > > -----Original Message----- > From: Randall Gellens [mailto:randy@qti.qualcomm.com] > Sent: Tuesday, September 15, 2015 7:11 PM > To: Barry Leiba; Brian Rosen > Cc: draft-ietf-ecrit-additional-data@ietf.org; ecrit@ietf.org;=20 > draft-ietf-ecrit-additional-data.ad@ietf.org; The IESG;=20 > draft-ietf-ecrit-additional-data.shepherd@ietf.org; > ecrit-chairs@ietf.org > Subject: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss=20 > on draft-ietf-ecrit-additional-data-34: (with DISCUSS and > COMMENT)") > > At 10:21 PM -0400 9/2/15, Barry Leiba wrote: > >> I've asked a few other people to look at it, and they, too, didn't=20 >> get "main", but they, too, had trouble coming up with a better name. >> Maybe we shouldn't try to hard to make a very short name, and use a=20 >> longer one such as "main-office", or "front-desk", or some such. >> That plus more explanation in that paragraph in Section 4 should=20 >> make it all better. > > I'd be happy to change the term "main" to something else, provided we=20 > can agree on something. Perhaps "reception" or "main number" or=20 > "attendant"? I'm kind of leaning toward "attendant" but would like to=20 > hear from others. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- When you are in=20 > trouble, people who call to sympathize are really > looking for he particulars. --Edgar Watson Howe -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- XML is crap. Really. = There are no excuses. XML is nasty to parse for humans, and it's a disaster= to parse even for computers. There's just no reason for that horrible crap= to exist. --Linus Torvalds, March 6, 2014 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Sep 16 12:54:53 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEAF1A0338; Wed, 16 Sep 2015 12:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 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, MIME_HTML_ONLY=0.723, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, 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 wAAUiWcHC-BO; Wed, 16 Sep 2015 12:54:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688B11A0264; Wed, 16 Sep 2015 12:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442433287; x=1473969287; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=aHbuBJuJAlR2ry39Y5MSS/bMgpXRMicDN1NzhO1L178=; b=YyY4MyNMqUZmhx0SFhsZt4u+YDkXQ8t2GkpchvWv6lw3LxX+muUt+oVG 6Q4ga1ghjtPHtAzK2Wk19dyszSjdhju9lqZz4S7V398lfP0yM4tmvSjl/ NXIB0sThSs1IAtKMDFVvji5aFK/eaNeiefzMyS2zZOvjaVGnnFVQxhL94 Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="231897197" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 12:54:47 -0700 X-IronPort-AV: E=Sophos;i="5.17,541,1437462000"; d="scan'208,217";a="977103587" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 12:54:46 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 12:54:45 -0700 Message-ID: In-Reply-To: <493EE964-FD7E-4C87-BD65-A202A1EA1F32@neustar.biz> References: <20150903032250.19421.48240.idtracker@ietfa.amsl.com> <6FD306C8-8C2F-4CAA-B3ED-827540FD70CC@neustar.biz> <493EE964-FD7E-4C87-BD65-A202A1EA1F32@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 12:54:41 -0700 To: "Rosen, Brian" , Spencer Dawkins at IETF From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.ad@ietf.org" , "ecrit-chairs@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , The IESG Subject: Re: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:54:49 -0000 Re: [Ecrit] Spencer Dawkins' No Objection on draft-ietf-e
Either "at least some" or "as much ... as possible"?

So,

OLD:

   The intent is that every emergency call carry the
   information described here using the mechanisms described here.

NEW:

   The intent is that every emergency call carry at least some of
   the information described here using the mechanisms described
   here.

OR:

   The intent is that every emergency call carry as much as possible
   of the information described here using the mechanisms described
   here.



At 2:30 PM +0000 9/3/15, Brian Rosen wrote:

Well, sort of.  We really do want every emergency call to at least have that identity block.

We'll need to edit the text to say more clearly what we mean.  I see two ways to edit:
=8Aevery emergency call carry at least some of the information=8A.

or
..every provider in the path of the call provide at least some of the information =8A

Brian



On Sep 3, 2015, at 9:37 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Brian,

On Thu, Sep 3, 2015 at 8:18 AM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
Not every call has every block.  There is only one block that is required, which is "who sent the data".  That block includes contact info.  We want every entity to handles the call to supply at least that block.  If you have more info, please send it, but at least tell me how to contact you.  This corresponds to the current mechanisms in North America and elsewhere: mobile networks only supply the identity of the network operator handling the call, wireline networks supply that and also a subscriber name/address.

The extension is additional blocks of data, and we have to allow others to define blocks.  Many of those blocks wouldn't make sense for, as an example, a carrier to provide.  Others might not make sense for anyone except, say, an enterprise to supply.

Thanks for the quick feedback.

I see the problem - I should be reading

   The intent
   is that every emergency call carry the information described here
   using the mechanisms described here.

as

   The intent
   is that every emergency call *that carries* the information described here
   *uses* the mechanisms described here.

and doesn't go off the reservation and send it some other way.

Am I getting that right?

Thanks,

Spencer
 
Brian

> On Sep 2, 2015, at 11:22 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ecrit-additional-data-34: 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.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I note that Stephen hasn't cleared his Discuss yet, so I'll let that play
> out (and thanks to all who are busily Discussing it), but just for the
> record, I'm also confused between
>
>   The intent
>   is that every emergency call carry the information described here
>   using the mechanisms described here.
>
> and (paraphrasing)
>
> "we aren't the experts on extending this mechanism, and we can't say who
> is, but there's more than one set of experts"
>
> This tussle sounds like a fork waiting to happen.
>
> Is that going to be a problem? One answer could be "if it is, we aren't
> the ones who are going to have to solve it", but I thought I'd ask.
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
  "When I use a word," Humpty Dumpty said, in a rather scornful
tone, "it means just what I choose it to mean -- neither more nor less.
  "The question is," said Alice, "whether you can make words mean
so many different things."
  "The question is," said Humpty Dumpty, "which is to be master  --
that's all."
From nobody Wed Sep 16 15:28:14 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1BB1A88FC; Wed, 16 Sep 2015 15:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 bly4AO0EweVT; Wed, 16 Sep 2015 15:28:12 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B691A88DA; Wed, 16 Sep 2015 15:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442442484; x=1473978484; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=hnwF35DoaF3Pfs8aDK7cc7CKmNGAl7lREAmooyceRwQ=; b=ItGpnu/R4SLRc2I90/R0tdlTp5yIYJhlMvtuEhWnHlSkQKbMT0QGYI0K 4Z+WZQ0UC1iFFWI5qJa5MlbU/emB1IAzr1Soc9yIlRaWQ8P61MBc0G3k4 kIMTKfMRAgPv0YUg5HEuegwkRBil9hgcxBRI4dxYY7XPEsqPKKaYPSxZN I=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="231913404" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 15:28:04 -0700 X-IronPort-AV: E=Sophos;i="5.17,542,1437462000"; d="scan'208";a="977170212" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 15:28:04 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 15:28:03 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 15:28:02 -0700 To: "Schlesinger, Jerry" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "draft-ietf-ecrit-additional-data.ad@ietf.org" , "draft-ietf-ecrit-additional-data@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-additional-data.shepherd@ietf.org" , "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)") X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 22:28:13 -0000 At 12:49 PM -0700 9/16/15, Jerry Schlesinger wrote: > For consideration: "main establishment" or "main establishment > number" as we're discussing how to reach (call back) an > establishment (business, dorm, hotel, etc.); not an individual's > contact number. By the way, if you google main phone or main phone > number, hundreds of businesses come up with their main/switchboard > number. So main or main number is probably good enough I'm going to go with "main-number" unless there are objections. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Tax reform means "Don't tax you, don't tax me, tax that fellow behind the tree." --Russell Long From nobody Wed Sep 16 17:14:47 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D77F1A90D9; Wed, 16 Sep 2015 17:14:44 -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 iKb876vui_lo; Wed, 16 Sep 2015 17:14:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3FB1A90C1; Wed, 16 Sep 2015 17:14:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150917001442.21069.67644.idtracker@ietfa.amsl.com> Date: Wed, 16 Sep 2015 17:14:42 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-35.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 00:14:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-35.txt Pages : 112 Date : 2015-09-16 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much as possible of the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-35 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-35 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 18 00:33:49 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FED1A90FA; Fri, 18 Sep 2015 00:33:48 -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 NxORQc7NKx4F; Fri, 18 Sep 2015 00:33:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 074CD1A00E7; Fri, 18 Sep 2015 00:33:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150918073347.6605.63392.idtracker@ietfa.amsl.com> Date: Fri, 18 Sep 2015 00:33:47 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-additional-data-35: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 07:33:48 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ecrit-additional-data-35: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks so much for addressing all my comments -- version -35 looks really good. A minor thing that the RFC Editor will correct anyway, but if you happen to do another round of changes: You have "mime" in lower case in three places (in Sections 4.2, 4.3, and 4.5), and they should be upper-cased. From nobody Fri Sep 18 09:13:39 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A891A0146; Fri, 18 Sep 2015 09:13: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 FXy2csh4TivK; Fri, 18 Sep 2015 09:13:35 -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 468201A0141; Fri, 18 Sep 2015 09:13:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B447BE5C; Fri, 18 Sep 2015 17:13:33 +0100 (IST) 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 szexmP_ra21P; Fri, 18 Sep 2015 17:13:33 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3121BBE57; Fri, 18 Sep 2015 17:13:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442592813; bh=jhW5oMU4afCDGV2odOZqPsqa8kga47nbUreFF5XiYSY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Mvj8bywtu3lCM837eNKwBjKcorNw26NkVL1q4fEiFDicPdj/Aw8/XAIyWMF6dtRAO XHkyjQhWcgXDyxyTx0yDtTbAGM2FV0MOqItxqbsPz7lMefjT9smZsYTVBC/A9ueesf LjLBgiXKKN4wtmPZkXYN/JLtGVMN6rY4dCBwFLUs= To: Randall Gellens , The IESG References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <55FC382B.3000801@cs.tcd.ie> Date: Fri, 18 Sep 2015 17:13: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 16:13:38 -0000 Hiya, On 15/09/15 02:56, Randall Gellens wrote: > Hi Stephen and everyone, > > Thanks for your comments. Please see in-line. > > At 4:47 PM -0700 9/1/15, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ecrit-additional-data-34: Discuss >> >> 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.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> I've two things I'd like to chat about. (Note: I'm not trying >> here to insist on my preferred outcome, but I would like to >> have the discussion or else be pointed at where the WG >> already did that.) >> >> (1) section 3: You say these MAY be used. I'm not >> sure that's a good option. I think the data >> minimisation recommendations argued for in RFC6973 and >> RFC7258 would argue to add a MUST NOT. For example, >> saying that these additional data MUST NOT be sent in >> any non-emergency call without explicit user >> permission on a per-call basis or something similar? >> I have to admit I'm nervous that defining all of these >> may mean that some UA somewhere starts sending some of >> them in other calls without asking. A restriction >> along those lines would also be more in line with >> webrtc too perhaps. But maybe this was discussed in >> the WG, having considered those privacy issues - was >> it? Either way, would adding such a "MUST NOT except >> if..." be a good plan? 4.3.4 is a good example of the >> kind of thing I'd not want easily emitted in a call. > > There are two subissues here: the non-use of normative language, and the > recognition that there are limited non-emergency cases where this can be > used. The document originally had normative language here, but there > was some small discussion in ECRIT meetings and email based on (if I > recall correctly), an objection from Keith Drage that the document > couldn't impose these blanket mandates; Keith wanted the document to say > only that use outside of an emergency call was undefined, but I wanted > something stronger, so added text that it was not appropriate. I don't > mind if we want to go back to being normative, but I wanted to point out > that it was changed based on Keith's objection. The permission for > certain private-use cases is to permit telematics service providers to > use the same mechanisms on both legs of a call: between the vehicle and > the telematics service center, and between the telematics service center > and the PSAP; further, it makes sense to use the same mechanisms between > the vehicle and telematics service center in all calls, since the > service center call handler determines if a call is an emergency or not > (as opposed to the vehicle in the direct case). This is a very limited > case, and it matches how things work in circuit-switched calls. Hmm... in earlier emails with Brian Rosen, I thought we were heading towards a "MUST NOT except" direction? The changes in -35 don't seem to me to going there at all. Was there discussion between authors or the WG on this or do we just have diverging author opinions? On the current text change in section 3, I don't know what a "telematics" service provider is (really, it was maybe a meaningful term here in the early 1990's but is no longer) and the "or other" clause waters any restriction down to nothing at all since any relevant entity here is some kind of service provider. How about saying: "This data MUST NOT be sent for calls that are not clearly emergency calls. Generic implementations (e.g. of a SIP UA) MUST only send this data for an emergency call. Specialised user agents that need to send this data in a possibly non-emergency call ought be described in specialised RFCs that justify the need for that data." I would suggest deleting the text added here between -34 and -35. I would prefer a 2119 normative statement in this case, as I think (some of) the customers for UAs here are the sort who do pay attention to that kind of thing. > > >> (2) I'd like to (perhaps briefly) argue that the >> registries here should require more than expert >> review. Extensibility in dealing with what will >> inevitably be highly privacy sensitive data structures >> that are vulnerable to misuse once registered seems to >> perhaps call for a more stringent registration regime. >> The document itself also argues (in 4.3.7) that adding >> new kinds of data here can be counter productive for >> emergency call handling, so being more conservative in >> what we add seems unusually correct here. I'd like to >> suggest we require standards track for extensions. >> The following very recent -00 draft [1] makes some >> related arguments (but of course has no standing in >> the IETF so is just offered as a way to avoid >> repeating some arguments, not as an appeal to >> authority.) >> >> [1] >> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >> > > We've had some discussion on this point alone. I changed all instances > where the text said: > > The expert should determine that the entity requesting a new value is > relevant for this service element > > To add an example that the entity is a recognized emergency-related SDO: > > The expert should determine that the entity requesting a new value is > relevant for this service element (e.g., a recognized emergency services > related SDO) That's a good change and I've cleared that part of the discuss. As a non-blocking comment, I'd suggest explaining the issue at the start of section 11 as well as in the subsections and I wondered if that phrasing might also apply to other 11.1.x subsections, but I'm ok that the expert once alerted to this will probably do the right thing. The other stuff below is fine. Cheers, S. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - abstract: the "or by reference" point is made twice >> in the abstract > > I don't think it's duplicative, since the first time says that this > document does it both ways, and the second time says that previous > mechanisms also did it both ways. > >> - intro: floor plans? HVAC status? really? Why not >> contact lists? proximity of friends? That (or >> inferring as much) seems to me to be going too far, if >> applied to all calls. I'd say just saying that this >> could be extended in future by other standards-track >> specifications is enough. (See also discuss points above) > > This text is informative and explanatory, it helps the reader understand > what is meant by information about a location, and mentions specific > types of data that NENA is in fact working on. Both proximity of friends > and contact lists seem like data associated with a caller, which NENA > has also worked on and defined a separate, out-of-band mechanism for > (the data is held by a third party, a registry of third parties is > available to the PSAP, who queries them). > >> - intro: Wedding anniversary? That's surely not >> relevant to a PSAP. > > The text in question mentions it only as an example of personal data > that might seem to indicate that vcard should be categorized as data > about the caller rather than data about the call. The draft does not > require that anniversary date be sent (and in fact doesn't mandate which > vcard fields are to be sent), although it's conceivable that a wedding > anniversary might be useful to a PSAP call taker in some circumstances > (such as when a caller might be suicidal). > >> - figure 5: "prison" is out of context here, I'd suggest >> deleting it. If not, why not add hospital, power station >> and many other kinds of building? There may be some >> country specific issue or technical here, but labelling >> that with "prison" seems inappropriate to me. > > We've discussed this in other email, but the short answer is that this > matches capabilities provided in legacy emergency services systems, and > we don't want to lose functionality. It's quite common for calls from > prisons to be treated very differently than other calls, and this isn't > the case for power stations, hospitals, etc. > >> - 4.3.8: sorry I don't get the privacy argument, can >> you try explain it to me? (I didn't know it was >> possible to tempt an implementation, so the language >> there could be improved for sure:-) > > I've reworded the text in question so it should be much clearer now: > > Privacy: Information sent as a device/service-specific additional > data URL in the DeviceInfo block is by reference (not by value), > which inherently provides some additional privacy protection > (since the requester needs to supply a certificate which is > verified by the supplier). > > >> - section 5: good that this is HTTPS only. I think >> provisioning the PKI for such a thing is easily done >> these days and is rightly not optional. It might be >> useful to say that TLS here needs to follow BCP195. I >> agree with the earlier comment that you should be >> clear as to when mutually authenticated TLS is >> required. The secdir review [2] also raised similar >> issues and it'd be good to see responses to that too. >> (Yes, that review only arrived today so it's entirely >> reasonable to not have responded so far.) >> >> [2] >> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html > > I'm working through my email and the comments on this document, so I'll > respond to that message on its own. In response to other comments, I've > clarified that when dereferencing blocks passed by reference, the > requester supplies a client-side certificate which the supplier checks > to uphold its policy (e.g., that the requester is an emergency services > entity possessing a certificate issued by an emergency services CA). > > >> - section 8: the sizes of the various additional data >> items here could be characteristic and leak value >> information regardless of TLS or not-TLS - perhaps add >> a warning that these may enable relatively simple >> traffic analysis. And wouldn't it be nice if someone >> had done the analysis of this potential vulnerability? >> This is btw a real issue - recall that avatar icon >> image size was usable to identify 30+% of contacts in >> one social network even over TLS, but before the >> provider canonicalised the avatar image sizes. > > Given the restricted scope (emergency calls only), I'm not sure what > would be useful to say here. It's not expected that the same device > issues a large number of emergency calls. > >> - Thanks for section 9. Good job. > > Thank you. > From nobody Fri Sep 18 11:04:28 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652771B2ECC; Fri, 18 Sep 2015 11:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 LOCWNRy3MZlO; Fri, 18 Sep 2015 11:04:23 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AF71B2EC6; Fri, 18 Sep 2015 11:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442599463; x=1474135463; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=zus3YNqIAwHXwrZdocAdIrr/s9fVI+B987T6YjSpang=; b=eYUXWc3w1H3npg4bhThYP0flmDmv+sBVFT0cD4rZFfNpcNunth9MzE5p kzFJYmym2YoZYDbN5gmJ0t4voxzP8LyHubMEH3Or2Zs3QjM1t6arigPRy BmkmnOQWVFUdtuXAKNsTLpn5GxEvrRK1Uu8Oi6nq1vOnJ5iZUdXkU/hKp Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7928"; a="96926045" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Sep 2015 11:04:22 -0700 X-IronPort-AV: E=Sophos;i="5.17,554,1437462000"; d="scan'208";a="978132549" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Sep 2015 11:04:21 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 18 Sep 2015 11:04:21 -0700 Message-ID: In-Reply-To: <55FC382B.3000801@cs.tcd.ie> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <55FC382B.3000801@cs.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Fri, 18 Sep 2015 11:04:18 -0700 To: Stephen Farrell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 18:04:26 -0000 Hi Stephen, At 5:13 PM +0100 9/18/15, Stephen Farrell wrote: > Hiya, > > On 15/09/15 02:56, Randall Gellens wrote: >> Hi Stephen and everyone, >> >> Thanks for your comments. Please see in-line. >> >> At 4:47 PM -0700 9/1/15, Stephen Farrell wrote: >> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-ecrit-additional-data-34: Discuss >>> >>> 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.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> I've two things I'd like to chat about. (Note: I'm not trying >>> here to insist on my preferred outcome, but I would like to >>> have the discussion or else be pointed at where the WG >>> already did that.) >>> >>> (1) section 3: You say these MAY be used. I'm not >>> sure that's a good option. I think the data >>> minimisation recommendations argued for in RFC6973 and >>> RFC7258 would argue to add a MUST NOT. For example, >>> saying that these additional data MUST NOT be sent in >>> any non-emergency call without explicit user >>> permission on a per-call basis or something similar? >>> I have to admit I'm nervous that defining all of these >>> may mean that some UA somewhere starts sending some of >>> them in other calls without asking. A restriction >>> along those lines would also be more in line with >>> webrtc too perhaps. But maybe this was discussed in >>> the WG, having considered those privacy issues - was >>> it? Either way, would adding such a "MUST NOT except >>> if..." be a good plan? 4.3.4 is a good example of the >>> kind of thing I'd not want easily emitted in a call. >> >> There are two subissues here: the non-use of normative language, and the >> recognition that there are limited non-emergency cases where this can be >> used. The document originally had normative language here, but there >> was some small discussion in ECRIT meetings and email based on (if I >> recall correctly), an objection from Keith Drage that the document >> couldn't impose these blanket mandates; Keith wanted the document to say >> only that use outside of an emergency call was undefined, but I wanted >> something stronger, so added text that it was not appropriate. I don't >> mind if we want to go back to being normative, but I wanted to point out >> that it was changed based on Keith's objection. The permission for >> certain private-use cases is to permit telematics service providers to >> use the same mechanisms on both legs of a call: between the vehicle and >> the telematics service center, and between the telematics service center >> and the PSAP; further, it makes sense to use the same mechanisms between >> the vehicle and telematics service center in all calls, since the >> service center call handler determines if a call is an emergency or not >> (as opposed to the vehicle in the direct case). This is a very limited >> case, and it matches how things work in circuit-switched calls. > > Hmm... in earlier emails with Brian Rosen, I thought we were heading > towards a "MUST NOT except" direction? The changes in -35 don't seem > to me to going there at all. Was there discussion between authors or > the WG on this or do we just have diverging author opinions? I think Brian had forgotten that the switch in the text from normative to descriptive language was based on Keith's objection, which was discussed in an ECRIT session and then referred to in others during document status updates. > On the current text change in section 3, I don't know what a > "telematics" service provider is (really, it was maybe a meaningful > term here in the early 1990's but is no longer) and the "or other" > clause waters any restriction down to nothing at all since any > relevant entity here is some kind of service provider. I think the term "telematics service provider" is pretty clear, much more so now than in the '90s, since all major vehicle manufacturers now have telematics systems with emergency capabilities, and those that don't currently have them will be deploying them within a couple of years. Back in the '90s there were only a few, such as OnStar. Brian and I have talked to various vehicle and solution vendors who have expressed a desire to use the same mechanism on both legs of a call. Further, in a system such as OnStar, vehicle-initiated emergency calls go to the service center and likely will be placed as normal, not emergency calls (which in cellular systems generally follow a specific set of steps, including an emergency registration followed by an emergency session establishment, which has difficulties when the call is placed to a third-party and not a PSAP). The current wording seems more restrictive to me than you seem to think. The current wording says "communications between a ... service provider and dedicated equipment ... where the endpoints have a preexisting relationship and privacy issues are addressed within the relationship" which seems to me to rule out casual use. There needs to be a service provider who has dedicated equipment and there needs to be a preexisting relationship that addresses privacy issues. General softphone implementations are not going to transmit the data except in an emergency call. Only software on dedicated devices will send the data on other classes of calls. > How about saying: "This data MUST NOT be sent for calls that are > not clearly emergency calls. Generic implementations (e.g. of a > SIP UA) MUST only send this data for an emergency call. > Specialised user agents that need to send this data in a possibly > non-emergency call ought be described in specialised RFCs that > justify the need for that data." I think we already make the point that general-purpose implementations won't send the data except in an emergency call (although maybe we could call this out to make it even more clear), but expecting telematics service providers to publish RFCs seems way too high a burden, and for no benefit, since such specialized implementations are the only ones that would send the data on other call types. > I would suggest deleting the text added here between -34 and -35. > > I would prefer a 2119 normative statement in this case, as I think > (some of) the customers for UAs here are the sort who do pay > attention to that kind of thing. This was originally 2119 normative language but was changed after Keith's objection. > >> (2) I'd like to (perhaps briefly) argue that the >>> registries here should require more than expert >>> review. Extensibility in dealing with what will >>> inevitably be highly privacy sensitive data structures >>> that are vulnerable to misuse once registered seems to >>> perhaps call for a more stringent registration regime. >>> The document itself also argues (in 4.3.7) that adding >>> new kinds of data here can be counter productive for >>> emergency call handling, so being more conservative in >>> what we add seems unusually correct here. I'd like to >>> suggest we require standards track for extensions. >>> The following very recent -00 draft [1] makes some >>> related arguments (but of course has no standing in >>> the IETF so is just offered as a way to avoid >>> repeating some arguments, not as an appeal to > >> authority.) >>> >>> [1] >>> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >>> >> >> We've had some discussion on this point alone. I changed all instances >> where the text said: >> >> The expert should determine that the entity requesting a new value is >> relevant for this service element >> >> To add an example that the entity is a recognized emergency-related SDO: >> >> The expert should determine that the entity requesting a new value is > > relevant for this service element (e.g., a recognized emergency services > > related SDO) > > That's a good change and I've cleared that part of the discuss. > As a non-blocking comment, I'd suggest explaining the issue > at the start of section 11 as well as in the subsections and > I wondered if that phrasing might also apply to other 11.1.x > subsections, but I'm ok that the expert once alerted to this > will probably do the right thing. I've added the following new paragraph to Section 11: For several of the sub-registries, "Expert Review" is the criteria for adding new entries. As discussed in Section 5, it can be counterproductive to register new types of data, and as discussed in Section 10, data sent as part of an emergency call can be very privacy-sensitive. In some cases, it is anticipated that various standards bodies dealing with emergency services might need to register new values, and in those cases text below advises the designed expert to verify that the entity requesting the registration is relevant (e.g., a recognized emergency services related SDO). In other cases, especially those where the trade-off between the potential benefit versus danger of new registrations is more conservative (such as Section 11.1.9), "Specification Required" is the criteria, which is a higher hurdle and also implicitly includes an expert review. > > The other stuff below is fine. > > Cheers, > S. > >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - abstract: the "or by reference" point is made twice >>> in the abstract >> >> I don't think it's duplicative, since the first time says that this >> document does it both ways, and the second time says that previous >> mechanisms also did it both ways. >> >>> - intro: floor plans? HVAC status? really? Why not >>> contact lists? proximity of friends? That (or >>> inferring as much) seems to me to be going too far, if >>> applied to all calls. I'd say just saying that this >>> could be extended in future by other standards-track >>> specifications is enough. (See also discuss points above) >> >> This text is informative and explanatory, it helps the reader understand >> what is meant by information about a location, and mentions specific >> types of data that NENA is in fact working on. Both proximity of friends >> and contact lists seem like data associated with a caller, which NENA >> has also worked on and defined a separate, out-of-band mechanism for >> (the data is held by a third party, a registry of third parties is >> available to the PSAP, who queries them). >> >>> - intro: Wedding anniversary? That's surely not >>> relevant to a PSAP. >> >> The text in question mentions it only as an example of personal data >> that might seem to indicate that vcard should be categorized as data >> about the caller rather than data about the call. The draft does not >> require that anniversary date be sent (and in fact doesn't mandate which >> vcard fields are to be sent), although it's conceivable that a wedding >> anniversary might be useful to a PSAP call taker in some circumstances >> (such as when a caller might be suicidal). >> >>> - figure 5: "prison" is out of context here, I'd suggest >>> deleting it. If not, why not add hospital, power station >>> and many other kinds of building? There may be some >>> country specific issue or technical here, but labelling >>> that with "prison" seems inappropriate to me. >> >> We've discussed this in other email, but the short answer is that this >> matches capabilities provided in legacy emergency services systems, and > > we don't want to lose functionality. It's quite common for calls from >> prisons to be treated very differently than other calls, and this isn't >> the case for power stations, hospitals, etc. >> >>> - 4.3.8: sorry I don't get the privacy argument, can >>> you try explain it to me? (I didn't know it was >>> possible to tempt an implementation, so the language >>> there could be improved for sure:-) >> >> I've reworded the text in question so it should be much clearer now: >> >> Privacy: Information sent as a device/service-specific additional >> data URL in the DeviceInfo block is by reference (not by value), >> which inherently provides some additional privacy protection >> (since the requester needs to supply a certificate which is >> verified by the supplier). >> >> >>> - section 5: good that this is HTTPS only. I think >>> provisioning the PKI for such a thing is easily done >>> these days and is rightly not optional. It might be >>> useful to say that TLS here needs to follow BCP195. I >>> agree with the earlier comment that you should be >>> clear as to when mutually authenticated TLS is >>> required. The secdir review [2] also raised similar >>> issues and it'd be good to see responses to that too. >>> (Yes, that review only arrived today so it's entirely >>> reasonable to not have responded so far.) >>> >>> [2] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html >> >> I'm working through my email and the comments on this document, so I'll >> respond to that message on its own. In response to other comments, I've >> clarified that when dereferencing blocks passed by reference, the >> requester supplies a client-side certificate which the supplier checks >> to uphold its policy (e.g., that the requester is an emergency services >> entity possessing a certificate issued by an emergency services CA). >> >> >>> - section 8: the sizes of the various additional data >>> items here could be characteristic and leak value >>> information regardless of TLS or not-TLS - perhaps add >>> a warning that these may enable relatively simple >>> traffic analysis. And wouldn't it be nice if someone >>> had done the analysis of this potential vulnerability? >>> This is btw a real issue - recall that avatar icon >>> image size was usable to identify 30+% of contacts in >>> one social network even over TLS, but before the >>> provider canonicalised the avatar image sizes. >> >> Given the restricted scope (emergency calls only), I'm not sure what >> would be useful to say here. It's not expected that the same device >> issues a large number of emergency calls. >> >>> - Thanks for section 9. Good job. >> >> Thank you. >> -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Life is ... a shopping mall ... where items such as worldly success, love of music, a strong backhand, close relationships with your family, a few good friends and countless other things are on sale. The commodity with which they are purchased is not money, but time. --William Rehnquist From nobody Fri Sep 18 11:12:15 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583B81B2F54; Fri, 18 Sep 2015 11:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 g72hAxrvbP8U; Fri, 18 Sep 2015 11:12:13 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92F91B2F52; Fri, 18 Sep 2015 11:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442599933; x=1474135933; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=ec2nm/BmIxQbx6Faope0NjBeX8FLCWyZzdA6x+EotBc=; b=kJycQlug79Fn9PMbtnqtmUWwe29bgMUJ0RImF+BJzz2AYqLDJiiz4sw0 YpDueXDCywTSmh2+CX2DDU9HrW102OuavUDJmUzFZckrWBgjUWsc7NV7w W3JXffHTkxJo2xbck+QhBS5G4mYc0RTuCw5qSIzYp2uy9hyzVtMMzDopu M=; X-IronPort-AV: E=McAfee;i="5700,7163,7928"; a="139379856" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Sep 2015 11:12:12 -0700 X-IronPort-AV: E=Sophos;i="5.17,554,1437462000"; d="scan'208";a="1003960375" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Sep 2015 11:12:12 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 18 Sep 2015 11:12:11 -0700 Message-ID: In-Reply-To: <20150918073347.6605.63392.idtracker@ietfa.amsl.com> References: <20150918073347.6605.63392.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Fri, 18 Sep 2015 11:09:46 -0700 To: Barry Leiba , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-additional-data-35: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 18:12:14 -0000 Hi Barry, At 12:33 AM -0700 9/18/15, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-ecrit-additional-data-35: 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks so much for addressing all my comments -- version -35 looks really > good. > > A minor thing that the RFC Editor will correct anyway, but if you happen > to do another round of changes: You have "mime" in lower case in three > places (in Sections 4.2, 4.3, and 4.5), and they should be upper-cased. I did make some changes in response to Stephen's email, and included the case correction on "MIME". Thanks for catching it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- You see, wire telegraph is a kind of very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates in exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. --Albert Einstein From nobody Fri Sep 18 14:38:28 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77061B35E8; Fri, 18 Sep 2015 14:38:26 -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 yHCgN8jadWtP; Fri, 18 Sep 2015 14:38:22 -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 286C61B35A6; Fri, 18 Sep 2015 14:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B504BE50; Fri, 18 Sep 2015 22:38:18 +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 eqL6LMkw3MhA; Fri, 18 Sep 2015 22:38:14 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D199ABE53; Fri, 18 Sep 2015 22:38:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442612293; bh=QjZ1cvlTRgRxw8JBUz4Dcl8xM624OpvJPKH7JZCqd64=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Ls+G2CMk2hEZZOH0R9vMLva/kyAe/uS7DARXu138Hrd9xjI2JNrGSCzSMhctX9YKA gFgJZtQOt0KAlY9cuPq94IjkFo5IJqmv/3930pKQutZuyh1NtGTJQ+9+yiUqErHJrl 2H7wBI2TSYMsGMTQgh0V7nyOe7iD4wNlfye0bpkk= To: Randall Gellens , The IESG References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <55FC382B.3000801@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55FC8444.4060309@cs.tcd.ie> Date: Fri, 18 Sep 2015 22:38:12 +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: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 21:38:26 -0000 On 18/09/15 19:04, Randall Gellens wrote: > Hi Stephen, > > At 5:13 PM +0100 9/18/15, Stephen Farrell wrote: > >> Hiya, >> >> On 15/09/15 02:56, Randall Gellens wrote: >>> Hi Stephen and everyone, >>> >>> Thanks for your comments. Please see in-line. >>> >>> At 4:47 PM -0700 9/1/15, Stephen Farrell wrote: >>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-ecrit-additional-data-34: Discuss >>>> >>>> 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.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> I've two things I'd like to chat about. (Note: I'm not trying >>>> here to insist on my preferred outcome, but I would like to >>>> have the discussion or else be pointed at where the WG >>>> already did that.) >>>> >>>> (1) section 3: You say these MAY be used. I'm not >>>> sure that's a good option. I think the data >>>> minimisation recommendations argued for in RFC6973 and >>>> RFC7258 would argue to add a MUST NOT. For example, >>>> saying that these additional data MUST NOT be sent in >>>> any non-emergency call without explicit user >>>> permission on a per-call basis or something similar? >>>> I have to admit I'm nervous that defining all of these >>>> may mean that some UA somewhere starts sending some of >>>> them in other calls without asking. A restriction >>>> along those lines would also be more in line with >>>> webrtc too perhaps. But maybe this was discussed in >>>> the WG, having considered those privacy issues - was >>>> it? Either way, would adding such a "MUST NOT except >>>> if..." be a good plan? 4.3.4 is a good example of the >>>> kind of thing I'd not want easily emitted in a call. >>> >>> There are two subissues here: the non-use of normative language, and >>> the >>> recognition that there are limited non-emergency cases where this >>> can be >>> used. The document originally had normative language here, but there >>> was some small discussion in ECRIT meetings and email based on (if I >>> recall correctly), an objection from Keith Drage that the document >>> couldn't impose these blanket mandates; Keith wanted the document to >>> say >>> only that use outside of an emergency call was undefined, but I wanted >>> something stronger, so added text that it was not appropriate. I don't >>> mind if we want to go back to being normative, but I wanted to point >>> out >>> that it was changed based on Keith's objection. The permission for >>> certain private-use cases is to permit telematics service providers to >>> use the same mechanisms on both legs of a call: between the vehicle and >>> the telematics service center, and between the telematics service >>> center >>> and the PSAP; further, it makes sense to use the same mechanisms >>> between >>> the vehicle and telematics service center in all calls, since the >>> service center call handler determines if a call is an emergency or not >>> (as opposed to the vehicle in the direct case). This is a very limited >>> case, and it matches how things work in circuit-switched calls. >> >> Hmm... in earlier emails with Brian Rosen, I thought we were heading >> towards a "MUST NOT except" direction? The changes in -35 don't seem >> to me to going there at all. Was there discussion between authors or >> the WG on this or do we just have diverging author opinions? > > I think Brian had forgotten that the switch in the text from normative > to descriptive language was based on Keith's objection, which was > discussed in an ECRIT session and then referred to in others during > document status updates. Hmm again;-) I'm not so pushed about the use or lack of normative language (though I do prefer it in this case) as with what is said. And there seems to me to be quite a divergence between what Brian was saying and what you're saying. (Which is entirely fine and could be meaningful to you folks too, or just something I'm mixed up about.) > > >> On the current text change in section 3, I don't know what a >> "telematics" service provider is (really, it was maybe a meaningful >> term here in the early 1990's but is no longer) and the "or other" >> clause waters any restriction down to nothing at all since any >> relevant entity here is some kind of service provider. > > I think the term "telematics service provider" is pretty clear, much > more so now than in the '90s, I may be an outlier here, but I do think the opposite. The set of things at [1] better match my understanding of the term. Or maybe it's more of a US-centric usage? Or it could just have changed over time I guess. [1] https://scholar.google.com/scholar?q=telematics&hl=en&as_sdt=0%2C5&as_ylo=&as_yhi=1993 If you do keep that term, maybe add a reference. Or say "vehicle tracking services" or something that'll still work even if the terminology wanders again. > since all major vehicle manufacturers now > have telematics systems with emergency capabilities, and those that > don't currently have them will be deploying them within a couple of > years. Back in the '90s there were only a few, such as OnStar. Brian > and I have talked to various vehicle and solution vendors who have > expressed a desire to use the same mechanism on both legs of a call. > Further, in a system such as OnStar, vehicle-initiated emergency calls > go to the service center and likely will be placed as normal, not > emergency calls (which in cellular systems generally follow a specific > set of steps, including an emergency registration followed by an > emergency session establishment, which has difficulties when the call is > placed to a third-party and not a PSAP). > > The current wording seems more restrictive to me than you seem to > think. Right, I think we're seeing different meanings in the text. And that's probably a signal that a bit more work's needed. But I'm out of time right now, I'll look at it again over the weekend and maybe get inspired. Or maybe someone else will be. Cheers, S. > The current wording says "communications between a ... service > provider and dedicated equipment ... where the endpoints have a > preexisting relationship and privacy issues are addressed within the > relationship" which seems to me to rule out casual use. There needs to > be a service provider who has dedicated equipment and there needs to be > a preexisting relationship that addresses privacy issues. General > softphone implementations are not going to transmit the data except in > an emergency call. Only software on dedicated devices will send the > data on other classes of calls. > >> How about saying: "This data MUST NOT be sent for calls that are >> not clearly emergency calls. Generic implementations (e.g. of a >> SIP UA) MUST only send this data for an emergency call. >> Specialised user agents that need to send this data in a possibly >> non-emergency call ought be described in specialised RFCs that >> justify the need for that data." > > I think we already make the point that general-purpose implementations > won't send the data except in an emergency call (although maybe we could > call this out to make it even more clear), but expecting telematics > service providers to publish RFCs seems way too high a burden, and for > no benefit, since such specialized implementations are the only ones > that would send the data on other call types. > >> I would suggest deleting the text added here between -34 and -35. >> >> I would prefer a 2119 normative statement in this case, as I think >> (some of) the customers for UAs here are the sort who do pay >> attention to that kind of thing. > > This was originally 2119 normative language but was changed after > Keith's objection. > > >> >> (2) I'd like to (perhaps briefly) argue that the >>>> registries here should require more than expert >>>> review. Extensibility in dealing with what will >>>> inevitably be highly privacy sensitive data structures >>>> that are vulnerable to misuse once registered seems to >>>> perhaps call for a more stringent registration regime. >>>> The document itself also argues (in 4.3.7) that adding >>>> new kinds of data here can be counter productive for >>>> emergency call handling, so being more conservative in >>>> what we add seems unusually correct here. I'd like to >>>> suggest we require standards track for extensions. >>>> The following very recent -00 draft [1] makes some >>>> related arguments (but of course has no standing in >>>> the IETF so is just offered as a way to avoid >>>> repeating some arguments, not as an appeal to >> >> authority.) >>>> >>>> [1] >>>> >>>> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >>>> >>>> >>> >>> We've had some discussion on this point alone. I changed all instances >>> where the text said: >>> >>> The expert should determine that the entity requesting a new >>> value is >>> relevant for this service element >>> >>> To add an example that the entity is a recognized emergency-related >>> SDO: >>> >>> The expert should determine that the entity requesting a new >>> value is >> > relevant for this service element (e.g., a recognized emergency >> services >> > related SDO) >> >> That's a good change and I've cleared that part of the discuss. >> As a non-blocking comment, I'd suggest explaining the issue >> at the start of section 11 as well as in the subsections and >> I wondered if that phrasing might also apply to other 11.1.x >> subsections, but I'm ok that the expert once alerted to this >> will probably do the right thing. > > I've added the following new paragraph to Section 11: > > For several of the sub-registries, "Expert Review" is the criteria > for adding new entries. As discussed in Section 5, it can be > counterproductive to register new types of data, and as discussed in > Section 10, data sent as part of an emergency call can be very > privacy-sensitive. In some cases, it is anticipated that various > standards bodies dealing with emergency services might need to > register new values, and in those cases text below advises the > designed expert to verify that the entity requesting the registration > is relevant (e.g., a recognized emergency services related SDO). In > other cases, especially those where the trade-off between the > potential benefit versus danger of new registrations is more > conservative (such as Section 11.1.9), "Specification Required" is > the criteria, which is a higher hurdle and also implicitly includes > an expert review. > > > >> >> The other stuff below is fine. >> >> Cheers, >> S. >> >>> >>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> - abstract: the "or by reference" point is made twice >>>> in the abstract >>> >>> I don't think it's duplicative, since the first time says that this >>> document does it both ways, and the second time says that previous >>> mechanisms also did it both ways. >>> >>>> - intro: floor plans? HVAC status? really? Why not >>>> contact lists? proximity of friends? That (or >>>> inferring as much) seems to me to be going too far, if >>>> applied to all calls. I'd say just saying that this >>>> could be extended in future by other standards-track >>>> specifications is enough. (See also discuss points above) >>> >>> This text is informative and explanatory, it helps the reader >>> understand >>> what is meant by information about a location, and mentions specific >>> types of data that NENA is in fact working on. Both proximity of >>> friends >>> and contact lists seem like data associated with a caller, which NENA >>> has also worked on and defined a separate, out-of-band mechanism for >>> (the data is held by a third party, a registry of third parties is >>> available to the PSAP, who queries them). >>> >>>> - intro: Wedding anniversary? That's surely not >>>> relevant to a PSAP. >>> >>> The text in question mentions it only as an example of personal data >>> that might seem to indicate that vcard should be categorized as data >>> about the caller rather than data about the call. The draft does not >>> require that anniversary date be sent (and in fact doesn't mandate >>> which >>> vcard fields are to be sent), although it's conceivable that a wedding >>> anniversary might be useful to a PSAP call taker in some circumstances >>> (such as when a caller might be suicidal). >>> >>>> - figure 5: "prison" is out of context here, I'd suggest >>>> deleting it. If not, why not add hospital, power station >>>> and many other kinds of building? There may be some >>>> country specific issue or technical here, but labelling >>>> that with "prison" seems inappropriate to me. >>> >>> We've discussed this in other email, but the short answer is that this >>> matches capabilities provided in legacy emergency services systems, and >> > we don't want to lose functionality. It's quite common for calls >> from >>> prisons to be treated very differently than other calls, and this isn't >>> the case for power stations, hospitals, etc. >>> >>>> - 4.3.8: sorry I don't get the privacy argument, can >>>> you try explain it to me? (I didn't know it was >>>> possible to tempt an implementation, so the language >>>> there could be improved for sure:-) >>> >>> I've reworded the text in question so it should be much clearer now: >>> >>> Privacy: Information sent as a device/service-specific additional >>> data URL in the DeviceInfo block is by reference (not by value), >>> which inherently provides some additional privacy protection >>> (since the requester needs to supply a certificate which is >>> verified by the supplier). >>> >>> >>>> - section 5: good that this is HTTPS only. I think >>>> provisioning the PKI for such a thing is easily done >>>> these days and is rightly not optional. It might be >>>> useful to say that TLS here needs to follow BCP195. I >>>> agree with the earlier comment that you should be >>>> clear as to when mutually authenticated TLS is >>>> required. The secdir review [2] also raised similar >>>> issues and it'd be good to see responses to that too. >>>> (Yes, that review only arrived today so it's entirely >>>> reasonable to not have responded so far.) >>>> >>>> [2] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html >>> >>> I'm working through my email and the comments on this document, so I'll >>> respond to that message on its own. In response to other comments, >>> I've >>> clarified that when dereferencing blocks passed by reference, the >>> requester supplies a client-side certificate which the supplier checks >>> to uphold its policy (e.g., that the requester is an emergency services >>> entity possessing a certificate issued by an emergency services CA). >>> >>> >>>> - section 8: the sizes of the various additional data >>>> items here could be characteristic and leak value >>>> information regardless of TLS or not-TLS - perhaps add >>>> a warning that these may enable relatively simple >>>> traffic analysis. And wouldn't it be nice if someone >>>> had done the analysis of this potential vulnerability? >>>> This is btw a real issue - recall that avatar icon >>>> image size was usable to identify 30+% of contacts in >>>> one social network even over TLS, but before the >>>> provider canonicalised the avatar image sizes. >>> >>> Given the restricted scope (emergency calls only), I'm not sure what >>> would be useful to say here. It's not expected that the same device >>> issues a large number of emergency calls. >>> >>>> - Thanks for section 9. Good job. >>> >>> Thank you. >>> > > > From nobody Fri Sep 18 15:17:07 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210E11A00D4; Fri, 18 Sep 2015 15:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 bUHQXUgziyq1; Fri, 18 Sep 2015 15:16:59 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D24D1A00C2; Fri, 18 Sep 2015 15:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442614619; x=1474150619; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=p8xt8UPrIaztbeZ7TzxGfyIU0Y+Q0Hj6bNl7K7XVYu4=; b=XQeW4Yf628qHxOmpD1lwQWrxlRg97VZFkggduJO2Lej27GICEOLwe4I9 +5dDXI+hou5QOEwJWpt3MYa0EgD2FiQA1n+N6an4VJBOW40Erl5SB4B9g +laIaUEHwt3e5UDc8G6RbaojWahejvNRj9PZt5w+KCoDVZ/0gjhbvkuWl I=; X-IronPort-AV: E=McAfee;i="5700,7163,7928"; a="98139384" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 18 Sep 2015 15:16:59 -0700 X-IronPort-AV: E=Sophos;i="5.17,554,1437462000"; d="scan'208";a="34190464" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Sep 2015 15:16:57 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 18 Sep 2015 15:16:56 -0700 Message-ID: In-Reply-To: <55FC8444.4060309@cs.tcd.ie> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <55FC382B.3000801@cs.tcd.ie> <55FC8444.4060309@cs.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Fri, 18 Sep 2015 15:16:54 -0700 To: Stephen Farrell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 22:17:03 -0000 At 10:38 PM +0100 9/18/15, Stephen Farrell wrote: > On 18/09/15 19:04, Randall Gellens wrote: >> Hi Stephen, >> >> At 5:13 PM +0100 9/18/15, Stephen Farrell wrote: >> >>> Hiya, >>> >>> On 15/09/15 02:56, Randall Gellens wrote: >>>> Hi Stephen and everyone, >>>> >>>> Thanks for your comments. Please see in-line. >>>> >>>> At 4:47 PM -0700 9/1/15, Stephen Farrell wrote: >>>> >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-ecrit-additional-data-34: Discuss >>>>> >>>>> 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.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> I've two things I'd like to chat about. (Note: I'm not trying >>>>> here to insist on my preferred outcome, but I would like to >>>>> have the discussion or else be pointed at where the WG >>>>> already did that.) >>>>> >>>>> (1) section 3: You say these MAY be used. I'm not >>>>> sure that's a good option. I think the data >>>>> minimisation recommendations argued for in RFC6973 and >>>>> RFC7258 would argue to add a MUST NOT. For example, >>>>> saying that these additional data MUST NOT be sent in >>>>> any non-emergency call without explicit user >>>>> permission on a per-call basis or something similar? >>>>> I have to admit I'm nervous that defining all of these >>>>> may mean that some UA somewhere starts sending some of >>>>> them in other calls without asking. A restriction >>>>> along those lines would also be more in line with >>>>> webrtc too perhaps. But maybe this was discussed in >>>>> the WG, having considered those privacy issues - was >>>>> it? Either way, would adding such a "MUST NOT except >>>>> if..." be a good plan? 4.3.4 is a good example of the >>>>> kind of thing I'd not want easily emitted in a call. >>>> >>>> There are two subissues here: the non-use of normative language, and >>>> the >>>> recognition that there are limited non-emergency cases where this >>>> can be >>>> used. The document originally had normative language here, but there >>>> was some small discussion in ECRIT meetings and email based on (if I >>>> recall correctly), an objection from Keith Drage that the document >>>> couldn't impose these blanket mandates; Keith wanted the document to >>>> say >>>> only that use outside of an emergency call was undefined, but I wanted >>>> something stronger, so added text that it was not appropriate. I don't >>>> mind if we want to go back to being normative, but I wanted to point >>>> out >>>> that it was changed based on Keith's objection. The permission for >>>> certain private-use cases is to permit telematics service providers to >>>> use the same mechanisms on both legs of a call: between the vehicle and >>>> the telematics service center, and between the telematics service >>>> center >>>> and the PSAP; further, it makes sense to use the same mechanisms >>>> between >>>> the vehicle and telematics service center in all calls, since the >>>> service center call handler determines if a call is an emergency or not > >>> (as opposed to the vehicle in the direct case). This is a very limited >>>> case, and it matches how things work in circuit-switched calls. >>> >>> Hmm... in earlier emails with Brian Rosen, I thought we were heading >>> towards a "MUST NOT except" direction? The changes in -35 don't seem >>> to me to going there at all. Was there discussion between authors or >>> the WG on this or do we just have diverging author opinions? >> >> I think Brian had forgotten that the switch in the text from normative >> to descriptive language was based on Keith's objection, which was >> discussed in an ECRIT session and then referred to in others during >> document status updates. > > Hmm again;-) I'm not so pushed about the use or lack of normative > language (though I do prefer it in this case) as with what is > said. And there seems to me to be quite a divergence between what > Brian was saying and what you're saying. (Which is entirely fine > and could be meaningful to you folks too, or just something I'm > mixed up about.) Sorry, I am not seeing the difference. The current text says "not appropriate...with non-emergency calls" and then adds the "however" which is the equivalent of the "except". And that "however" is quite restrictive since it only applies to service providers with dedicated devices. > >> On the current text change in section 3, I don't know what a >>> "telematics" service provider is (really, it was maybe a meaningful >>> term here in the early 1990's but is no longer) and the "or other" >>> clause waters any restriction down to nothing at all since any >>> relevant entity here is some kind of service provider. >> >> I think the term "telematics service provider" is pretty clear, much >> more so now than in the '90s, > > I may be an outlier here, but I do think the opposite. The set of > things at [1] better match my understanding of the term. Or maybe > it's more of a US-centric usage? Or it could just have changed over > time I guess. > > [1] > > https://scholar.google.com/scholar?q=telematics&hl=en&as_sdt=0%2C5&as_ylo=&as_yhi=1993 > > If you do keep that term, maybe add a reference. Or say "vehicle > tracking services" or something that'll still work even if the > terminology wanders again. The link you gave is searching for the term "telematics," which I agree is very broad and covers many things. The term we use is "telematics service provider", which is more specific and has a generally-accepted meaning. See, e.g.," https://www.google.com/search?q=%22telematics+service+provider%22&ie=utf-8&oe=utf-8 > > since all major vehicle manufacturers now >> have telematics systems with emergency capabilities, and those that >> don't currently have them will be deploying them within a couple of >> years. Back in the '90s there were only a few, such as OnStar. Brian >> and I have talked to various vehicle and solution vendors who have >> expressed a desire to use the same mechanism on both legs of a call. >> Further, in a system such as OnStar, vehicle-initiated emergency calls >> go to the service center and likely will be placed as normal, not >> emergency calls (which in cellular systems generally follow a specific >> set of steps, including an emergency registration followed by an >> emergency session establishment, which has difficulties when the call is >> placed to a third-party and not a PSAP). >> >> The current wording seems more restrictive to me than you seem to >> think. > > Right, I think we're seeing different meanings in the text. And > that's probably a signal that a bit more work's needed. But I'm > out of time right now, I'll look at it again over the weekend and > maybe get inspired. Or maybe someone else will be. Can you elaborate as to what your concern is? I think the current text is clear that general-purpose implements won't send this data except in an emergency call. Some dedicated devices that have a pre-existing relationship with a service provider in which privacy issues are addressed are permitted to do so. What's the problem? Also, you didn't reply to the text I added to satisfy your concern with the IANA considerations section. > > The current wording says "communications between a ... service > > provider and dedicated equipment ... where the endpoints have a >> preexisting relationship and privacy issues are addressed within the >> relationship" which seems to me to rule out casual use. There needs to >> be a service provider who has dedicated equipment and there needs to be >> a preexisting relationship that addresses privacy issues. General >> softphone implementations are not going to transmit the data except in >> an emergency call. Only software on dedicated devices will send the >> data on other classes of calls. >> >>> How about saying: "This data MUST NOT be sent for calls that are >>> not clearly emergency calls. Generic implementations (e.g. of a >>> SIP UA) MUST only send this data for an emergency call. >>> Specialised user agents that need to send this data in a possibly >>> non-emergency call ought be described in specialised RFCs that >>> justify the need for that data." >> >> I think we already make the point that general-purpose implementations >> won't send the data except in an emergency call (although maybe we could >> call this out to make it even more clear), but expecting telematics >> service providers to publish RFCs seems way too high a burden, and for >> no benefit, since such specialized implementations are the only ones >> that would send the data on other call types. >> >>> I would suggest deleting the text added here between -34 and -35. >>> >>> I would prefer a 2119 normative statement in this case, as I think >>> (some of) the customers for UAs here are the sort who do pay >>> attention to that kind of thing. >> >> This was originally 2119 normative language but was changed after >> Keith's objection. >> >> >>> >> (2) I'd like to (perhaps briefly) argue that the >>>>> registries here should require more than expert >>>>> review. Extensibility in dealing with what will >>>>> inevitably be highly privacy sensitive data structures >>>>> that are vulnerable to misuse once registered seems to >>>>> perhaps call for a more stringent registration regime. >>>>> The document itself also argues (in 4.3.7) that adding >>>>> new kinds of data here can be counter productive for >>>>> emergency call handling, so being more conservative in >>>>> what we add seems unusually correct here. I'd like to >>>>> suggest we require standards track for extensions. >>>>> The following very recent -00 draft [1] makes some >>>>> related arguments (but of course has no standing in >>>>> the IETF so is just offered as a way to avoid >>>>> repeating some arguments, not as an appeal to >>> >> authority.) >>>>> >>>>> [1] >>>>> >>>>> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00 >>>>> >>>>> >>>> >>>> We've had some discussion on this point alone. I changed all instances >>>> where the text said: >>>> >>>> The expert should determine that the entity requesting a new >>>> value is >>>> relevant for this service element >>>> >>>> To add an example that the entity is a recognized emergency-related >>>> SDO: >>>> >>>> The expert should determine that the entity requesting a new >>>> value is >>> > relevant for this service element (e.g., a recognized emergency >>> services >>> > related SDO) >>> >>> That's a good change and I've cleared that part of the discuss. >>> As a non-blocking comment, I'd suggest explaining the issue >>> at the start of section 11 as well as in the subsections and >>> I wondered if that phrasing might also apply to other 11.1.x >>> subsections, but I'm ok that the expert once alerted to this >>> will probably do the right thing. >> >> I've added the following new paragraph to Section 11: >> >> For several of the sub-registries, "Expert Review" is the criteria >> for adding new entries. As discussed in Section 5, it can be >> counterproductive to register new types of data, and as discussed in >> Section 10, data sent as part of an emergency call can be very >> privacy-sensitive. In some cases, it is anticipated that various >> standards bodies dealing with emergency services might need to >> register new values, and in those cases text below advises the > > designed expert to verify that the entity requesting the registration >> is relevant (e.g., a recognized emergency services related SDO). In >> other cases, especially those where the trade-off between the >> potential benefit versus danger of new registrations is more >> conservative (such as Section 11.1.9), "Specification Required" is >> the criteria, which is a higher hurdle and also implicitly includes >> an expert review. >> >> >> >>> >>> The other stuff below is fine. >>> >>> Cheers, >>> S. >>> >>>> >>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> - abstract: the "or by reference" point is made twice >>>>> in the abstract >>>> >>>> I don't think it's duplicative, since the first time says that this >>>> document does it both ways, and the second time says that previous >>>> mechanisms also did it both ways. >>>> >>>>> - intro: floor plans? HVAC status? really? Why not >>>>> contact lists? proximity of friends? That (or >>>>> inferring as much) seems to me to be going too far, if >>>>> applied to all calls. I'd say just saying that this >>>>> could be extended in future by other standards-track >>>>> specifications is enough. (See also discuss points above) >>>> >>>> This text is informative and explanatory, it helps the reader >>>> understand >>>> what is meant by information about a location, and mentions specific >>>> types of data that NENA is in fact working on. Both proximity of >>>> friends >>>> and contact lists seem like data associated with a caller, which NENA >>>> has also worked on and defined a separate, out-of-band mechanism for >>>> (the data is held by a third party, a registry of third parties is >>>> available to the PSAP, who queries them). >>>> >>>>> - intro: Wedding anniversary? That's surely not >>>>> relevant to a PSAP. >>>> >>>> The text in question mentions it only as an example of personal data >>>> that might seem to indicate that vcard should be categorized as data >>>> about the caller rather than data about the call. The draft does not >>>> require that anniversary date be sent (and in fact doesn't mandate >>>> which >>>> vcard fields are to be sent), although it's conceivable that a wedding >>>> anniversary might be useful to a PSAP call taker in some circumstances >>>> (such as when a caller might be suicidal). >>>> >>>>> - figure 5: "prison" is out of context here, I'd suggest >>>>> deleting it. If not, why not add hospital, power station >>>>> and many other kinds of building? There may be some >>>>> country specific issue or technical here, but labelling >>>>> that with "prison" seems inappropriate to me. >>>> >>>> We've discussed this in other email, but the short answer is that this >>>> matches capabilities provided in legacy emergency services systems, and >>> > we don't want to lose functionality. It's quite common for calls >>> from >>>> prisons to be treated very differently than other calls, and this isn't >>>> the case for power stations, hospitals, etc. >>>> >>>>> - 4.3.8: sorry I don't get the privacy argument, can >>>>> you try explain it to me? (I didn't know it was >>>>> possible to tempt an implementation, so the language >>>>> there could be improved for sure:-) >>>> >>>> I've reworded the text in question so it should be much clearer now: >>>> >>>> Privacy: Information sent as a device/service-specific additional >>>> data URL in the DeviceInfo block is by reference (not by value), >>>> which inherently provides some additional privacy protection >>>> (since the requester needs to supply a certificate which is >>>> verified by the supplier). >>>> >>>> >>>>> - section 5: good that this is HTTPS only. I think >>>>> provisioning the PKI for such a thing is easily done >>>>> these days and is rightly not optional. It might be >>>>> useful to say that TLS here needs to follow BCP195. I >>>>> agree with the earlier comment that you should be >>>>> clear as to when mutually authenticated TLS is > >>>> required. The secdir review [2] also raised similar >>>>> issues and it'd be good to see responses to that too. >>>>> (Yes, that review only arrived today so it's entirely >>>>> reasonable to not have responded so far.) >>>>> >>>>> [2] >>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html >>>> >>>> I'm working through my email and the comments on this document, so I'll >>>> respond to that message on its own. In response to other comments, >>>> I've >>>> clarified that when dereferencing blocks passed by reference, the >>>> requester supplies a client-side certificate which the supplier checks >>>> to uphold its policy (e.g., that the requester is an emergency services >>>> entity possessing a certificate issued by an emergency services CA). >>>> >>>> >>>>> - section 8: the sizes of the various additional data >>>>> items here could be characteristic and leak value >>>>> information regardless of TLS or not-TLS - perhaps add >>>>> a warning that these may enable relatively simple >>>>> traffic analysis. And wouldn't it be nice if someone >>>>> had done the analysis of this potential vulnerability? >>>>> This is btw a real issue - recall that avatar icon >>>>> image size was usable to identify 30+% of contacts in >>>>> one social network even over TLS, but before the >>>>> provider canonicalised the avatar image sizes. >>>> >>>> Given the restricted scope (emergency calls only), I'm not sure what >>>> would be useful to say here. It's not expected that the same device >>>> issues a large number of emergency calls. >>>> >>>>> - Thanks for section 9. Good job. >>>> >>>> Thank you. >>>> >> >> >> -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Manual Writer's Creed: Garbage in, gospel out. From nobody Tue Sep 22 14:11:42 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47B51A1B60; Tue, 22 Sep 2015 14:11: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_50=0.8, 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] 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 8Am9N2IxCNpr; Tue, 22 Sep 2015 14:11:37 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3A21B2E65; Tue, 22 Sep 2015 14:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442956297; x=1474492297; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=v3ydAPTHprRS9wS3HFqOP+7qwhYPnEIZFxw+n6KCneE=; b=a2vY4KEz0ru/WIp8Wozfk68N5jq/9rhN410KxIscjgjrfTth3uBrmvrO 1Essiy5Z6TBVC2G7ftvsldO3zQVsHtPJGZRl3tMeo3nVSPgjU24zn2O92 Qbebkb6MRfe0wqq8tDXG4oLIYLMgcax8q7GATislPyw3iclMEwBYcDU9N w=; X-IronPort-AV: E=McAfee;i="5700,7163,7932"; a="140005641" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 22 Sep 2015 14:11:36 -0700 X-IronPort-AV: E=Sophos;i="5.17,574,1437462000"; d="scan'208";a="33731129" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Sep 2015 14:11:35 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 22 Sep 2015 14:11:35 -0700 Message-ID: In-Reply-To: References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <55FC382B.3000801@cs.tcd.ie> <55FC8444.4060309@cs.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Tue, 22 Sep 2015 14:11:33 -0700 To: Stephen Farrell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, Brian Rosen , draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 21:11:38 -0000 Hi Stephen, I haven't seen a reply to my message from Friday 3:16 PM PDT regarding the scope language, nor my message from Friday 11:04 AM PDT which had proposed text for the IANA Considerations section. All other DISCUSSes and comments have been resolved. Perhaps we can chat on the phone for 20 minutes or so? Let me know your availability today and the next couple of days. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I can't stand Country music, but I don't mean to denigrate people who do. And for people who do like to listen to Country music, to denigrate someone means to belittle them. --anon From nobody Tue Sep 22 14:24:43 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0661A1B2EB8; Tue, 22 Sep 2015 14:24:39 -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 rG6DlMvXWs2l; Tue, 22 Sep 2015 14:24:37 -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 A00C61B2E98; Tue, 22 Sep 2015 14:24:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E6D8BE2E; Tue, 22 Sep 2015 22:24:35 +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 kj7EOv9T4Tvz; Tue, 22 Sep 2015 22:24:34 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0B220BDF9; Tue, 22 Sep 2015 22:24:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442957074; bh=chaW4SsaP972GjjEApbms/D7hpMxYBlJTwyCyfAghcE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=h1pJiq8m/BE7+gD3pPPAijm4HDQClLKKdZFrMZDNRydJPFhjAAVXvkifU9rdUehPs 4g9cFDAeZHeac9X/x8RYee75DWFE5EmL6CP3AueKLpMUyYWfTtLaeQJWJJFvNRYyTX uZjbdNaFcK3pXYgNMOTGDbBKEWzZCzqm+QycDT6s= To: Randall Gellens , The IESG References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <55FC382B.3000801@cs.tcd.ie> <55FC8444.4060309@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5601C710.4050001@cs.tcd.ie> Date: Tue, 22 Sep 2015 22:24:32 +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: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, Brian Rosen , draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 21:24:39 -0000 Hiya, On 22/09/15 22:11, Randall Gellens wrote: > Hi Stephen, > > I haven't seen a reply to my message from Friday 3:16 PM PDT regarding > the scope language, nor my message from Friday 11:04 AM PDT which had > proposed text for the IANA Considerations section. > > All other DISCUSSes and comments have been resolved. Perhaps we can > chat on the phone for 20 minutes or so? Let me know your availability > today and the next couple of days. Not great, as I'll be at the Marnew workshop. [1] We could do a call early next week though. How's Monday at 1600 UTC? Cheers, S. [1] https://www.iab.org/activities/workshops/marnew/ > From nobody Tue Sep 22 14:43:11 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F92A1A8ACC; Tue, 22 Sep 2015 14:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 arDPHxa54Quf; Tue, 22 Sep 2015 14:43:06 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0133E1A8AC9; Tue, 22 Sep 2015 14:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442958186; x=1474494186; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=Eq6y37pRAGsrVP4OFHVsRA52+CINPc3Q9chHz9WpL7c=; b=A48ymypZvJyPZ19AdBPUNtyJUwMKGMBgs86CJq93fVysxZqYnBpG1wV+ fveTLrcyzU1LCV7pGPNIN0fQ5TptLZWwNPfFj+18QugZ67UvcTHmk3sy6 kH/KSEqAYmM1x98xxA7xwQDQHoc35yCRhIHb6jFo6wuh2kGIk4/RJcsDl Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7932"; a="232956331" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2015 14:43:06 -0700 X-IronPort-AV: E=Sophos;i="5.17,574,1437462000"; d="scan'208";a="1006149882" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Sep 2015 14:43:05 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 22 Sep 2015 14:43:04 -0700 Message-ID: In-Reply-To: <5601C710.4050001@cs.tcd.ie> References: <20150901234754.5160.40078.idtracker@ietfa.amsl.com> <55FC382B.3000801@cs.tcd.ie> <55FC8444.4060309@cs.tcd.ie> <5601C710.4050001@cs.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Tue, 22 Sep 2015 14:43:02 -0700 To: Stephen Farrell , The IESG From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, Brian Rosen , draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 21:43:07 -0000 Hi Stephen, Would 17:30 UTC on Monday work? At 10:24 PM +0100 9/22/15, Stephen Farrell wrote: > Hiya, > > On 22/09/15 22:11, Randall Gellens wrote: >> Hi Stephen, >> >> I haven't seen a reply to my message from Friday 3:16 PM PDT regarding >> the scope language, nor my message from Friday 11:04 AM PDT which had >> proposed text for the IANA Considerations section. >> >> All other DISCUSSes and comments have been resolved. Perhaps we can >> chat on the phone for 20 minutes or so? Let me know your availability >> today and the next couple of days. > > Not great, as I'll be at the Marnew workshop. [1] We could do a call > early next week though. How's Monday at 1600 UTC? > > Cheers, > S. > > [1] https://www.iab.org/activities/workshops/marnew/ > >> -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A politician will always be there when he needs you. --Richard Smolik From nobody Fri Sep 25 12:18:52 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000D61A8905 for ; Fri, 25 Sep 2015 12:18:50 -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 EDzs4wixFrzz for ; Fri, 25 Sep 2015 12:18:49 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (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 9F1AB1A8900 for ; Fri, 25 Sep 2015 12:18:48 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t8PJIhr0028193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Sep 2015 12:18:44 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.231]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 12:18:43 -0700 From: Roger Marshall To: James Winterbottom Thread-Topic: [Ecrit] draft-ietf-ecrit-held-routing Thread-Index: AQHQ0oHdzIsQK6ZQJUCOLHhQGQsfRZ4m4OtAgBVYaoCAEa9DcA== Date: Fri, 25 Sep 2015 19:18:43 +0000 Message-ID: References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> In-Reply-To: <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 19:18:51 -0000 SmFtZXM6DQpZZXMuICBXZSB3aWxsIHN1Ym1pdCBhbiBJRVNHIHJlcXVlc3QgZm9yIHRoaXMgZHJh ZnQgc29vbi4NCg0KLXJvZ2VyLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog SmFtZXMgV2ludGVyYm90dG9tIFttYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29t XSANClNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDEzLCAyMDE1IDExOjE0IFBNDQpUbzogUm9nZXIg TWFyc2hhbGwNCkNjOiBlY3JpdF9pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQt aWV0Zi1lY3JpdC1oZWxkLXJvdXRpbmcNCg0KSGkgUm9nZXIgZXQgYWwsDQoNCkl0IGhhcyBub3cg YmVlbiBuZWFybHkgdHdvIHdlZWtzIHNpbmNlIHlvdSBzZW50IHRoaXMgdG8gdGhlIGxpc3QgYW5k IHRoZSB1cGRhdGUgd2FzIHB1Ymxpc2hlZCBkdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nLg0K VGhpcyBzZWVtcyBsaWtlIHBsZW50eSBvZiB0aW1lIGZvciBLZWl0aCB0byBoYXZlIHJlcGxpZWQg d2l0aCBmdXJ0aGVyIGNvbW1lbnRzLiBDYW4gd2UgcGxlYXNlIGZvcndhcmQgd2l0aCB0aGlzIGRv Y3VtZW50Pw0KDQpDaGVlcnMNCkphbWVzDQoNCg0KPiBPbiAxIFNlcCAyMDE1LCBhdCA5OjE4IGFt LCBSb2dlciBNYXJzaGFsbCA8Uk1hcnNoYWxsQHRlbGVjb21zeXMuY29tPiB3cm90ZToNCj4gDQo+ IEtlaXRoLCBkbyB0aGUgY2hhbmdlcyB0aGF0IEphbWVzIG9mZmVyZWQgc2F0aXNmeSB5b3VyIGlz c3Vlcz8gIA0KPiANCj4gLXJvZ2VyLg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSmFtZXMgV2ludGVyYm90dG9tDQo+IFNlbnQ6IFN1bmRheSwgQXVndXN0IDA5LCAyMDE1IDI6 MDAgQU0NCj4gVG86IGVjcml0X2lldGYub3JnDQo+IFN1YmplY3Q6IFtFY3JpdF0gZHJhZnQtaWV0 Zi1lY3JpdC1oZWxkLXJvdXRpbmcNCj4gDQo+IEhpIEFsbCwNCj4gDQo+IFRoZSBvbmx5IGNvbW1l bnRzIHJlY2VpdmVkIGR1cmluZyB0aGUgV0dMQyB3ZXJlIGZyb20gS2VpdGggRHJhZ2UgYW5kIEkg YmVsaWV2ZSB0aGF0IEkgYWRkcmVzc2VkIGFsbCBvZiB0aGVzZSBpbiBhIHJldiBvZiB0aGUgZHJh ZnQgYnV0IEkgaGF2ZW7igJl0IGhlYXJkIGFueXRoaW5nIGJhY2suDQo+IA0KPiBLZWl0aCwgY2Fu IHlvdSBwbGVhc2UgY29uZmlybSB0aGF0IHlvdXIgaXNzdWVzIGhhdmUgYWxsIGJlZW4gYWRkcmVz c2VkIGJ5IHRoZSBuZXcgdGV4dCBhbmQgaWYgdGhleSBoYXZlIHRoZW4gY2FuIHdlIHBsZWFzZSBt b3ZlIHRoZSBkcmFmdCBmb3J3YXJkPw0KPiANCj4gQ2hlZXJzDQo+IEphbWVzDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWls aW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdA0KPiANCj4gQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZpbGVnZWQgYW5kL29y IGNvbmZpZGVudGlhbC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3Ig cmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSByZXZpZXcsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1 dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBhbnkgYXR0YWNobWVudChz KSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3Nh Z2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgYW5kIGRl bGV0ZSBpdCBhbmQgYWxsIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlciBhbmQgbmV0d29y ay4NCg0K From nobody Fri Sep 25 12:35:25 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9D1A893B for ; Fri, 25 Sep 2015 12:35:23 -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, MIME_QP_LONG_LINE=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 FeejEvG-3u5U for ; Fri, 25 Sep 2015 12:35:20 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 2D9AE1A8931 for ; Fri, 25 Sep 2015 12:35:20 -0700 (PDT) Received: by padhy16 with SMTP id hy16so114039914pad.1 for ; Fri, 25 Sep 2015 12:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SzhQ72AK+fb63ZGd2V0XXCzr2PsIcYDa0yeHTB8P0CA=; b=e/7g8R3yyKmhwTdbuezzxRcY+zNJsiD2OwJfAPdTmpQj75iyykV2MUFGKXKZfX8dbs rC57SWq8RSIRlviszCJ16iBsse9FBp3Y8EBrsbWF94ITHx1bFiZ5QhJ1SjRudQDkHr8h yLCXUrZIcPAzxgSWK7HNc191k5DqmikceZEgBZZ20zAQtuJ+mPMVF5Fl/GF+AdtF2bob 1zGT7hp2llF4ei4DzB84Uq+tAV++KuHwGXTo3hGaZhpyE57xUdx2guc4wRsZWnOrr8i8 m3CFZUAw5Y1nnieunwMoGa7B/YsMch9vV+jOGk7YiTgO3Gp5Egnk3U9OVjKfx2FqpoQH tmrA== X-Received: by 10.66.139.133 with SMTP id qy5mr9534763pab.44.1443209719877; Fri, 25 Sep 2015 12:35:19 -0700 (PDT) Received: from [192.168.1.13] (202-159-130-160.dyn.iinet.net.au. [202.159.130.160]) by smtp.gmail.com with ESMTPSA id qp5sm5326064pbc.0.2015.09.25.12.35.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Sep 2015 12:35:19 -0700 (PDT) References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8C88AF66-276F-40DC-8B08-6D3D3C280A75@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Sat, 26 Sep 2015 05:35:16 +1000 To: Roger Marshall Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 19:35:23 -0000 Thanks Roger Sent from my iPhone > On 26 Sep 2015, at 5:18 am, Roger Marshall wrot= e: >=20 > James: > Yes. We will submit an IESG request for this draft soon. >=20 > -roger. >=20 > -----Original Message----- > From: James Winterbottom [mailto:a.james.winterbottom@gmail.com]=20 > Sent: Sunday, September 13, 2015 11:14 PM > To: Roger Marshall > Cc: ecrit_ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing >=20 > Hi Roger et al, >=20 > It has now been nearly two weeks since you sent this to the list and the u= pdate was published during the last IETF meeting. > This seems like plenty of time for Keith to have replied with further comm= ents. Can we please forward with this document? >=20 > Cheers > James >=20 >=20 >> On 1 Sep 2015, at 9:18 am, Roger Marshall wrot= e: >>=20 >> Keith, do the changes that James offered satisfy your issues? =20 >>=20 >> -roger. >>=20 >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbott= om >> Sent: Sunday, August 09, 2015 2:00 AM >> To: ecrit_ietf.org >> Subject: [Ecrit] draft-ietf-ecrit-held-routing >>=20 >> Hi All, >>=20 >> The only comments received during the WGLC were from Keith Drage and I be= lieve that I addressed all of these in a rev of the draft but I haven=E2=80=99= t heard anything back. >>=20 >> Keith, can you please confirm that your issues have all been addressed by= the new text and if they have then can we please move the draft forward? >>=20 >> Cheers >> James >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may be p= rivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review, f= orwarding, dissemination, distribution or copying of this communication or a= ny attachment(s) is strictly prohibited. If you have received this message i= n error, please notify the sender immediately, and delete it and all attachm= ents from your computer and network. >=20