From nobody Wed Jun 17 14:16:21 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 050B21A87C7 for ; Wed, 17 Jun 2015 14:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFIZB-2T0xw4 for ; Wed, 17 Jun 2015 14:16:18 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5337C1A8793 for ; Wed, 17 Jun 2015 14:16:18 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.7/8.14.7) with ESMTP id t5HLGDwH024304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 14:16:13 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.155]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 14:16:13 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: ECRIT meeting agenda time for IETF93 Prague Thread-Index: AdCpQq/44r4/fiGhS/aYC5AKy5uR4Q== Date: Wed, 17 Jun 2015 21:16:12 +0000 Message-ID: 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: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC283C9AFCSEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: Cc: "Alissa Cooper \(alcoop\) \(alcoop@cisco.com\)" , "marc.linsner@cisco.com" Subject: [Ecrit] ECRIT meeting agenda time for IETF93 Prague 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, 17 Jun 2015 21:16:20 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC283C9AFCSEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please let us know this week if you want agenda time your ECRIT related dra= ft(s) at IETF93, and how much time. Roger Marshall & Marc Linsner - ECRIT chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC283C9AFCSEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please let us know this week if you want agenda time your ECRIT rel= ated draft(s) at IETF93, and how much time.

Roger Marshall & Marc Linsner – ECRIT chairs

 

<= meta content=3D"TX_HTML32 11.0.211.501" name=3DGENERATOR>

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 inten= ded recipient, any review, forwarding, dissemination, distribution or copyi= ng of this communication or any attachment(s) is strictly prohibited. If yo= u have received this message in error, please notify the sender immediately= , and delete it and all attachments from your computer and network.<= /p>=0A --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC283C9AFCSEAEXMB2telecom_-- From nobody Fri Jun 19 15:48:29 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 3D69D1A8724 for ; Fri, 19 Jun 2015 15:48:28 -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 NM_9KIq32Gd8 for ; Fri, 19 Jun 2015 15:48:26 -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 95FC51A7D83 for ; Fri, 19 Jun 2015 15:48:26 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so47548255pab.1 for ; Fri, 19 Jun 2015 15:48:26 -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=RKcDeQx42zSDtqiNvaJF5mykAibWnxd1dmeGLdZ3F6E=; b=0VQQU8TdpfA6dtxT+7/SMMxR7ig3sRdxZXK3832oahGjGR/AzfdyHBhwtQF1/u377F wwmKgbDoXi0Otf48P0gfdidpLoTmZLE2UlRTd1r1D+CYo6fL4og+kGeun6eD44f0FRL9 yTkspf9nhbpg6GXWe0yt/VCVYjowaHV1Mz1OQ67g87pcDLpiGIenqv+PEBo718xc8QQJ 9r/wj5SCssSpw42IL6V/FqBKlpto8e85oxTFDhP7jGrPEyzFggyW4G7mETlnzW3gWvoA t11uogcCIblLbj7fD0Bca8UAL0bzOq4nodEh6Bk4hKOYgX02yjdpD6HuCRMBUQtsKU+a uotQ== X-Received: by 10.70.42.37 with SMTP id k5mr36571215pdl.13.1434754106320; Fri, 19 Jun 2015 15:48:26 -0700 (PDT) Received: from [192.168.1.100] ([1.148.58.232]) by mx.google.com with ESMTPSA id i1sm12272047pdm.19.2015.06.19.15.48.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jun 2015 15:48:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> Date: Sat, 20 Jun 2015 08:48:18 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - 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, 19 Jun 2015 22:48:28 -0000 The contents of this draft address the problem recognised in the M/493 = working group. So obviously I support this draft progressing. Cheers James > On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) = wrote: >=20 > All, >=20 > This marks the start of working group last call on this draft. Please = review and send comments to the list by COB, Wednesday June 10th, 2015. >=20 > https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Sun Jun 21 23:32: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 E85261B2D28 for ; Sun, 21 Jun 2015 23:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 Rf4hJzfFpnsI for ; Sun, 21 Jun 2015 23:32:40 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AEC1B2D27 for ; Sun, 21 Jun 2015 23:32:38 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail31.telekom.de with ESMTP; 22 Jun 2015 08:32:35 +0200 X-IronPort-AV: E=Sophos;i="5.13,657,1427752800"; d="scan'208";a="283200671" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 22 Jun 2015 08:32:36 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Mon, 22 Jun 2015 08:32:35 +0200 From: To: , Date: Mon, 22 Jun 2015 08:32:34 +0200 Thread-Topic: [Ecrit] WGLC - draft-ietf-ecrit-held-routing Thread-Index: AdCq4hsYjUF5kozYT9GDktKTYFEYYAB0sndA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> In-Reply-To: <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - 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, 22 Jun 2015 06:32:42 -0000 I support to proceed this draft to WGLC. Best Regards Roland > On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) = wrote: >=20 > All, >=20 > This marks the start of working group last call on this draft. Please re= view and send comments to the list by COB, Wednesday June 10th, 2015. >=20 > https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Jun 23 02:12:54 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 3C5A81AC399 for ; Tue, 23 Jun 2015 02:12:53 -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 seMgD_Pr1GkR for ; Tue, 23 Jun 2015 02:12:51 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 C9A421ABD3E for ; Tue, 23 Jun 2015 02:12:51 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so3142672pab.1 for ; Tue, 23 Jun 2015 02:12:51 -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 :message-id:references:to; bh=YukQCCQkCof6B2B3P40mR1jjLODESC8698QtuuGbD4M=; b=l9mBOw6lFVpkv8zRsI/OA0NnrzTuW2tPwWEJosa2g9DwYTxfx8eVbWshAlYA7AeNsA mP444yTzjx4WKJyfJ9zmTNTG/1qaKpWCLvJ+R4D97N/1BTVK8FGJQj66KYi1WrBVlLvO wb++joCITqpo8zT3P+Z/zq0PJX6JuCjGzcXYTBFggqGXcOcrpESNhMFhie3xWKpWBMCx 0afDlIEtIxCLl+ID58oDeFkuPe5Zof57k2qjKv1hroa6KG4x6kQeaH60ndpMiuNpQXWR oSeW0mEt5jp7YsP4vpo0dkPfX5sbydbDhuIp3Sd9oIcUdXsRo2+7TX6hknIOYgr5WEQT AMMQ== X-Received: by 10.70.29.164 with SMTP id l4mr66982781pdh.32.1435050771570; Tue, 23 Jun 2015 02:12:51 -0700 (PDT) Received: from [192.168.1.100] ([120.153.56.73]) by mx.google.com with ESMTPSA id dl5sm22442307pbd.78.2015.06.23.02.12.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 02:12:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B5644CE4-B6CC-4669-AA34-258749155E4A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: Date: Tue, 23 Jun 2015 19:12:42 +1000 Message-Id: <30070E1A-36B1-4456-8FF1-85D7A5984044@gmail.com> References: To: Roger Marshall X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "marc.linsner@cisco.com" , "Alissa Cooper \(alcoop\) \(alcoop@cisco.com\)" , "ecrit@ietf.org" Subject: Re: [Ecrit] ECRIT meeting agenda time for IETF93 Prague 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, 23 Jun 2015 09:12:53 -0000 --Apple-Mail=_B5644CE4-B6CC-4669-AA34-258749155E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There have been no updates to HELD-Routing since the ones I made just = before the WGLC was made. Cheers James > On 18 Jun 2015, at 7:16 am, Roger Marshall = wrote: >=20 > Please let us know this week if you want agenda time your ECRIT = related draft(s) at IETF93, and how much time. >=20 > Roger Marshall & Marc Linsner =E2=80=93 ECRIT chairs >=20 > =20 >=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. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_B5644CE4-B6CC-4669-AA34-258749155E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

There have been no updates to HELD-Routing = since the ones I made just before the WGLC was made.

Cheers
James


On = 18 Jun 2015, at 7:16 am, Roger Marshall <RMarshall@telecomsys.com> wrote:

Please let us know this week if you want agenda time your = ECRIT related draft(s) at IETF93, and how much time.

Roger Marshall & Marc Linsner =E2=80=93 ECRIT chairs

 

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.

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

= --Apple-Mail=_B5644CE4-B6CC-4669-AA34-258749155E4A-- From nobody Tue Jun 23 07:00:40 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 379531B2C2F for ; Tue, 23 Jun 2015 07:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, 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 LRIgI9jfm4Zq for ; Tue, 23 Jun 2015 07:00:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B51BB1A8A3F for ; Tue, 23 Jun 2015 07:00:37 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 98811FD131318 for ; Tue, 23 Jun 2015 14:00:33 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t5NE08Mi025340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Jun 2015 16:00:23 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 15:59:22 +0200 From: "DRAGE, Keith (Keith)" To: "ecrit@ietf.org" Thread-Topic: Comments on: draft-ietf-ecrit-held-routing-02.txt Thread-Index: AdCtvMsNklT4a6PFQUOOpB/6SU8+vw== Date: Tue, 23 Jun 2015 13:59:21 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69731760@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Comments on: draft-ietf-ecrit-held-routing-02.txt 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, 23 Jun 2015 14:00:40 -0000 I did a somewhat belated full review of the entire document and had the fol= lowing comments. I do not believe any of these comments are particularly co= ntroversial, but they do require some revision: 1) Abstract. The abstract should concentrate on what the document does, rat= her than the motivation. Therefore the words: In many circumstances public LoST servers or a distributed network of forest guides linking public LoST servers is not available. The general ECRIT calling models breakdown without publically accessible LoST servers. Sometimes location servers may have access to emergency routing information. Could be deleted from its current location. It would probably be appropriat= e to a prefix to the remaining 1st sentence that starts, "For cases where l= ocation servers have access to emergency routing information,..." 2) Given that service URNs have certain rules associated with their usage, = surely the normative text needs a normative reference to RFC 5031. The appr= opriate place for this would appear to be in section 4, 2nd paragraph. 3) Section 4, 2nd paragraph currently states: If a service is specified, and the LIS does not understand the requested service then URIs for urn:service:sos are returned. And further A LIS that understands the routing request element but not the specified service URN, returns the routing URIs for the urn:service:sos service. What RFC 5031 states is: Declaration of syntactic structure: The URN consists of a hierarchical service identifier, with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level service', while names to the right are called 'sub-services'. The set of allowable characters is the same as that for domain names [RFC1123] and a subset of the labels allowed in [RFC3958]. Labels are case-insensitive, but MUST be specified in all lower-case. For any given service URN, service- identifiers can be removed right-to-left; the resulting URN is still valid, referring to a more generic service. In other words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs. RFC 5031 is therefore slightly more complex and those rules should be follo= wed. Depending on how the reference proposed in comment 2) is made, that ma= y solve this comment. 4) Section 4, 5th paragraph. Replace "SHALL" by "MUST". The same applies fo= r the 6th paragraph. 5) Section 4. There are normative requirements for "support returning URIs = for urn:service:sos" but no normative requirements for actually doing so. W= hile I guess what is returned may be dependent on policy of the operator of= the LIS, surely something should be stated. 6) Section 4, last paragraph.=20 The LoST Protocol [RFC5222] defines a element that describes a service region and associated service URLs. Reusing this element from LoST to provide the routing URIs was considered. However, this would have meant that several of the mandatory components in the element would have had to contain ambiguous or misleading values. Specifically, the "source" attribute is required to contain a LoST application unique string for the authoritative server. However, in the situations described in this specification there may not be an authoritative LoST server, so any value put into this attribute would be misleading. In addition to this, routing information received in the manner described in this specification should not be cached by the receiver, so detailing when the routing information expires or was last updated is irrelevant. This is apparently motivation rather than mechanism. It would be better tha= t section 4 is solely for the real requirements and that the motivation is = elsewhere. 7) Section 7, section 8: It is not clear to me why the reference is to RFC = 5985 rather than RFC 5687 directly. Could the authors clarify (to the list)= what RFC 5985 adds for the security of the addition of this specific eleme= nt. It may be that the text requires some additional informational text indicat= ing how these documents apply for security and privacy of this specific ele= ment. Regards Keith From nobody Wed Jun 24 00:17: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 309261B3057 for ; Wed, 24 Jun 2015 00:17:13 -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 dnPSOcuyLHFd for ; Wed, 24 Jun 2015 00:17:11 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 372441B3059 for ; Wed, 24 Jun 2015 00:17:09 -0700 (PDT) Received: by pdcu2 with SMTP id u2so24465944pdc.3 for ; Wed, 24 Jun 2015 00:17:09 -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=dfFVaLtwqEBlEuPksuboGVI5jmUhEIGLwS9SHToVv0w=; b=Q2d6wbFvL2q0o49A4vs+YvUB4ZsNOom7313QicPimagEG89vZHbMBTFivok05JCj3W aSOMhJh4CLQTfIcLGU761JMQbtuzronecCkfQLo4NRH7i75jh80R2coxg/U1pm9aGXYT jTEi+osVltYteWi6IJVHCb+NZWSjqx/bFOY44Cri6PBdviVESLM/EtDL0Qmok3oQMGMe Go01PeWIRLIlNBmztqukvyyxw+Irwtd9lc+ntspVfyDWvdwDNcy1JOXZERoA/Zur7iel o0ZrhqJi9OM1RluR6bWuaXjEcLEosKFnaXGqeS3LCGw4yD2govW6E66x0O+pP6eGmFph 8V5g== X-Received: by 10.68.224.35 with SMTP id qz3mr76706845pbc.165.1435130228899; Wed, 24 Jun 2015 00:17:08 -0700 (PDT) Received: from [192.168.1.11] (124-168-164-169.dyn.iinet.net.au. [124.168.164.169]) by mx.google.com with ESMTPSA id jd4sm25536383pbd.46.2015.06.24.00.17.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 00:17:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69731760@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 24 Jun 2015 17:17:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <58A636FE-7CCF-4D0A-A010-E767BC0E0FAA@gmail.com> References: <949EF20990823C4C85C18D59AA11AD8B69731760@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comments on: draft-ietf-ecrit-held-routing-02.txt 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, 24 Jun 2015 07:17:13 -0000 Thanks Keith. I will digest these comments on the weekend and respond. Cheers James > On 23 Jun 2015, at 11:59 pm, DRAGE, Keith (Keith) = wrote: >=20 > I did a somewhat belated full review of the entire document and had = the following comments. I do not believe any of these comments are = particularly controversial, but they do require some revision: >=20 > 1) Abstract. The abstract should concentrate on what the document = does, rather than the motivation. Therefore the words: >=20 > In many circumstances public LoST servers or a distributed network = of > forest guides linking public LoST servers is not available. The > general ECRIT calling models breakdown without publically accessible > LoST servers. Sometimes location servers may have access to > emergency routing information. >=20 > Could be deleted from its current location. It would probably be = appropriate to a prefix to the remaining 1st sentence that starts, "For = cases where location servers have access to emergency routing = information,..." >=20 > 2) Given that service URNs have certain rules associated with their = usage, surely the normative text needs a normative reference to RFC = 5031. The appropriate place for this would appear to be in section 4, = 2nd paragraph. >=20 > 3) Section 4, 2nd paragraph currently states: >=20 > If a service is specified, and the LIS does not > understand the requested service then URIs for urn:service:sos are > returned. >=20 > And further >=20 > A LIS that understands the routing request element but not the > specified service URN, returns the routing URIs for the > urn:service:sos service. >=20 > What RFC 5031 states is: >=20 > Declaration of syntactic structure: The URN consists of a > hierarchical service identifier, with a sequence of labels > separated by periods. The left-most label is the most = significant > one and is called 'top-level service', while names to the right > are called 'sub-services'. The set of allowable characters is = the > same as that for domain names [RFC1123] and a subset of the = labels > allowed in [RFC3958]. Labels are case-insensitive, but MUST be > specified in all lower-case. For any given service URN, service- > identifiers can be removed right-to-left; the resulting URN is > still valid, referring to a more generic service. In other = words, > if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also = valid > service URNs. >=20 > RFC 5031 is therefore slightly more complex and those rules should be = followed. Depending on how the reference proposed in comment 2) is made, = that may solve this comment. >=20 > 4) Section 4, 5th paragraph. Replace "SHALL" by "MUST". The same = applies for the 6th paragraph. >=20 > 5) Section 4. There are normative requirements for "support = returning URIs for urn:service:sos" but no normative requirements for = actually doing so. While I guess what is returned may be dependent on = policy of the operator of the LIS, surely something should be stated. >=20 > 6) Section 4, last paragraph.=20 >=20 > The LoST Protocol [RFC5222] defines a element that > describes a service region and associated service URLs. Reusing = this > element from LoST to provide the routing URIs was considered. > However, this would have meant that several of the mandatory > components in the element would have had to contain > ambiguous or misleading values. Specifically, the "source" = attribute > is required to contain a LoST application unique string for the > authoritative server. However, in the situations described in this > specification there may not be an authoritative LoST server, so any > value put into this attribute would be misleading. In addition to > this, routing information received in the manner described in this > specification should not be cached by the receiver, so detailing = when > the routing information expires or was last updated is irrelevant. >=20 > This is apparently motivation rather than mechanism. It would be = better that section 4 is solely for the real requirements and that the = motivation is elsewhere. >=20 > 7) Section 7, section 8: It is not clear to me why the reference is = to RFC 5985 rather than RFC 5687 directly. Could the authors clarify (to = the list) what RFC 5985 adds for the security of the addition of this = specific element. >=20 > It may be that the text requires some additional informational text = indicating how these documents apply for security and privacy of this = specific element. >=20 > Regards >=20 > Keith >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Sun Jun 28 22:34: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 B278A1A004C for ; Sun, 28 Jun 2015 22:34:00 -0700 (PDT) X-Quarantine-ID: <5cR-M8dSgT7p> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 5cR-M8dSgT7p for ; Sun, 28 Jun 2015 22:33:57 -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 E55511A004B for ; Sun, 28 Jun 2015 22:33: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=1435556036; x=1467092036; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=QtlbE7DTHl5EvyJNNGSqH9zKTfThSC6MNiDH0G+lSnI=; b=aqzbmm5rDRSFe3ZZ3RVvc1gZs16QwehMXXC1cXR9CQBT4npiq/4HJz+k QosjPJqv8UCoV8IpJvIonFDty2SV1FDj9smKn1NAw45LebFZYyb0cqCxN EJBqIqkYU+KEXLlpl8iCK1Rhqw4o/ddU+s/g2Y28KfElagcEMySiLwQf5 0=; X-IronPort-AV: E=McAfee;i="5700,7163,7846"; a="91687980" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2015 22:33:51 -0700 X-IronPort-AV: E=Sophos;i="5.13,697,1427785200"; d="scan'208";a="922294064" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2015 22:33:52 -0700 Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t5T5Xn74006643; Sun, 28 Jun 2015 22:33:51 -0700 X-IronPort-AV: E=Sophos;i="5.13,696,1427785200"; d="scan'208";a="467850692" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.230.183]) by ironmsg02-L.qualcomm.com with ESMTP; 28 Jun 2015 22:33:50 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> X-Mailer: Eudora for Mac OS X Date: Sun, 28 Jun 2015 18:53:06 -0700 To: Alissa Cooper , ecrit@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 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, 29 Jun 2015 05:34:00 -0000 At 3:56 PM -0700 4/30/15, Alissa Cooper wrote: > I have reviewed=20 > draft-ietf-ecrit-additional-data-29 in=20 > preparation for IETF last call. There are a=20 > number of issues that need to be resolved=20 > before the IETF LC can be issued, which I=D5ve=20 > included below as substantive comments and=20 > questions. There is a list of nits at the end=20 > that also need to be fixed. Thank you very much, I appreciate it. I've=20 addressed them below and the -30 has the changes. > > Substantive comments and questions: > > General: > I've asked the shepherd to validate all of the=20 > XML in the document and am waiting to hear back=20 > on that. This is in progress; several small errors have=20 been identified and fixed so far. > > Section 1: > I would suggest adding this text from Section 9=20 > or something like it at the end of the=20 > introduction: > > "Much of the information supplied by service providers and devices is > private and confidential; service providers and devices generally go > to lengths to protect this information; disclosing it in the context > of an emergency call is a trade-off to protect the greater interest > of the customer in an emergency." I agree, done. > > Section 4.1: > I am a little confused about how this section=20 > applies when the data is being provided by the=20 > device. First, this text seems to consider the=20 > device to be a "service provider": > > "This block is intended to be supplied by any service provider in the > path of the call or the access network provider. It includes > identification and contact information. This block SHOULD be > supplied by every service provider in the call path, and by the > access network provider. Devices MAY use this block to provide > identifying information." > > I think this would be clearer if the first=20 > sentence said "any service provider in the path=20 > of the call, the access network provider, or=20 > the device." I agree, done. > > Then later in the section Data Provider ID,=20 > Data Provider ID Series, and Type of Data=20 > Provider are defined. None of these seem to=20 > apply when the data is provided by the device,=20 > and yet they are all listed as required. What=20 > are these elements supposed to contain when the=20 > data is provided by the device? I see in the=20 > example in Section 6 that only Type of Data=20 > Provider is included, and is listed as =D2Other,=D3=20 > which seems less specific than it ideally could=20 > be. In reviewing the various elements in this block,=20 I saw that in some cases there was text=20 explaining how the element is set by the device=20 but not in all cases. I have added text where it=20 was missing and clarified some of the other text.=20 In the Type of Data Provider registry, I expanded=20 the description of the "client" value to be=20 "Originating client/device" to make it clear that=20 this is the appropriate value when set by the=20 device. > Section 4.1.2: > Is there an EENA equivalent of the NENA company=20 > ID? If so, it should be mentioned here. I am not aware that EENA has yet established such=20 a registry, but the 'EENA' value is present in=20 anticipation. > Is it the case that where a=20 > jurisdiction-specific ID exists, it is=20 > preferred over an FQDN? If so, that should be=20 > stated explicitly. Thanks, I have clarified the text to try to make this very clear. > > Section 4.1.5: > "If the call is from a device, this SHOULD be the contact > information of the owner of the device." > > What are the exception cases for this SHOULD?=20 > What should this element be if it is not the=20 > owner's contact info? Normally, the device owner and user are the same,=20 but when they are different, the contact info=20 SHOULD be for the user, but MAY be for the owner.=20 I have clarified the text to make this more clear. > > Section 4.1.6: > By saying the other language tags are=20 > independent of this language element, does that=20 > mean they should be ignored? If so, that should=20 > be stated explicitly. It's not that anything is being ignored, it's=20 that these are entirely separate things. The=20 field in 4.1.6 is for information to a human: it=20 informs the PSAP person who needs to contact the=20 data provider as to the language(s) used by the=20 data provider. If the PSAP needs to contact the=20 data provider, it can be helpful to know in=20 advance the language(s). If the PSAP uses a=20 communication protocol to reach the data=20 provider, that protocol may have language=20 facilities of its own, and if so, those are=20 independent of this field. I've clarified the=20 text. > > Section 4.1.9: > "This element is required if the Data Provider > type is set to "Subcontractor"." > > Subcontractor is not listed as a data provider=20 > type in section 4.1.4, so this doesn't quite=20 > make sense. This is supposed to say "This data is required if=20 the entity providing the data is a=20 subcontractor." Thanks. > > Section 4.2.1: > Shouldn't "use" be listed as conditional? Yes, I agree it is more clear that way. > > Section 4.2.3: > s/MUST NOT/ought not to/ Yes, I agree. > > Section 4.3.4: > I'm curious about the kinds of "investigations"=20 > that PSAPs do and how they have used unique=20 > device IDs in those investigations -- could you=20 > explain? At first blush this seems to require=20 > over-sharing of sensitive data. The most common situation that I'm aware of is=20 repeated false/accidental calls. If there is no=20 callback number or it isn't usable, the PSAP may=20 need to try and track down the device by=20 contacting the service providers in the area. In=20 the case of handsets without current service,=20 they may be able to determine who last had=20 service. There could be other situations where=20 this might be useful (e.g., a disconnected call=20 where the call taker believes there is a need for=20 assistance but was not able to obtain a location=20 or other information). > > Section 4.4.1: > Are there any jurisdiction-specific rules you=20 > can point to that would indicate that having a=20 > single boolean "privacy" value will actually be=20 > interpretable and of use by any PSAP? I find it=20 > a little hard to believe that PSAPs will know=20 > what actions this value is supposed to apply to=20 > (e.g., display, logging, display and logging,=20 > etc.) and what data fields it is supposed to=20 > apply to. Without further definition (or some=20 > compelling evidence that PSAPs in at least some=20 > places have well-specified rules for what to do=20 > when they receive this value), this indicator=20 > seems pretty hand-wavy. I know it's messy to have a single 'privacy' flag=20 whose interpretation is left to each=20 jurisdiction, but this exactly matches the=20 semantics of the equivalent privacy indicator=20 provided in some legacy emergency call systems.=20 I've added some text to this effect. > > Section 4.4.2: > Are there any xCard fields you would recommend=20 > not sending for lack of relevance (e.g.,=20 > anniversary)? That's a good question. The answer is that name,=20 address, and phone number(s) are the minimum, but=20 anything else might potentially be useful in some=20 circumstances. I've added text to this effect. > > Depending on what the answer is to my question=20 > in 4.1.6 about interaction between Data=20 > Provider Language(s) and language tags, there=20 > might need to be text in this section as well=20 > about expected behavior when both are present=20 > and when the data provider is the device. Since these are entirely separate and don't=20 interact, and I've added clarifying text in=20 4.1.6, I don't think anything here is needed,=20 although I'm open to adding additional clarifying=20 text here if you think it helpful. > Section 5.1: > The last paragraph here makes it sound as=20 > though additional data is required to be sent=20 > on every emergency call (i.e., every call with=20 > an emergency service URN in the route header).=20 > Is that the intention? If so, that needs to be=20 > made more clear and should be explained earlier=20 > in the document, preferably in the=20 > introduction. If not, the normative language in=20 > the last paragraph here needs to be fixed. The intent is that every emergency call carry the=20 information described here using the mechanisms=20 described here. I've added text to this effect=20 in both the Abstract and the Introduction.=20 Thanks for pointing out that it wasn't clear that=20 this is the intent. > > Section 6: > The owner/subscriber of this laptop is Hannes=20 > Tschofenig. His contact tel URI is in North=20 > America but his work and home are in Finland.=20 > He is using a VoIP provider that provides its=20 > NENA ProviderID, which I assume indicates that=20 > the service is being provided in North America?=20 > The VoIP provider contact person is located in=20 > the UK, however. And then when the access=20 > network provides the location, it is in=20 > Australia. > > The last bit just seems wrong to me, for a=20 > plausible emergency call. The other bits seem=20 > to amount to a possible (but not likely?)=20 > example scenario but the details require more=20 > narrative explanation in the text.=20 > Alternatively, a simpler or more plausible=20 > example might help readers out more. Wow, I'm quite impressed that you went to this=20 much work! I never expected anyone to pull out=20 each of these parts from an example, put them=20 together, and see if they were internally=20 consistent. The least I can do is try to improve=20 it, so I added 'home' entries to the xCard for=20 , , and for a location within=20 the U.S. to the device-provided info, moved the=20 VoIP provider from London to Iowa (with=20 appropriate address and time zone information),=20 switched the PIDF-LO from the access network to=20 be a U.S. address, and switched the access=20 network provider to be an Access Network type=20 rather than "other". > > Section 8: > "Mechanisms that > protect against eavesdropping (such as Transport Layer Security > (TLS)) SHOULD be preferentially used whenever feasible." > > This needs a sentence about the existing=20 > deployed base of clear text SIP to explain why=20 > this requirement is not a MUST. > > s/HTTPS is specified/HTTPS is REQUIRED/ > > "Data provided by devices by reference have similar credential > validation issues as for service providers, and the solutions are the > same." > > Maybe the solutions are the same, but aren't=20 > the challenges of doing this for every device=20 > much more significant? That seems worth mention. > > s/Service providers SHOULD choose the=20 > latter/Service providers ought to choose the=20 > latter/ > (otherwise this reads like a normative requirement on IMS functionality) Thanks very much for these comments, I've made=20 corrections to section 8 for all of them. > > Section 10.1.1: > "Private entities issuing and using internally-generated IDs are > encouraged to register and use a unique identifier." > > What is meant by "use a unique identifier"? The idea is that some organizations, such as=20 NENA, issue IDs that are unique among all IDs=20 they issue, so a combination of the NENA ID and=20 the fact that it is from NENA is globally unique.=20 Other entities may not have an ID issued by an=20 organization such as NENA, so they are permitted=20 to use their domain name. I've reworded the text=20 to try and make this more clear. > > Section 10.1.8: > It might be useful to give the experts some=20 > additional criteria around weighing privacy vs.=20 > utility trade-offs. E.g., if someone wants to=20 > register the biometric fingerprint used to=20 > authenticate a device as a device ID and few or=20 > no PSAPs can actually make use of it, that may=20 > argue against registering it. I think the text "The expert should ascertain=20 that ... the information [is] useful to PSAPs and=20 responders to uniquely identify a device" would=20 disallow a biometric fingerprint (since it isn't=20 useful for a PSAP, but I'm happy to add more=20 clarifying text here. > > Section 12.2: > I think RFC 3966 should be a normative reference. OK. > > > Nits: > > General: > Why are some of the registry tables in the main=20 > sections of the document and others are in the=20 > IANA Considerations section? Seems like they=20 > should all be one or the other. I moved all the tables to be in the block definitions. > > Section 2: > Citations for vCard and xCard should be added to the last paragraph. Agreed, done. > > Section 4.1.7: > This sentence seems redundant: "For encoding of the xCard this > specification uses the XML-based encoding specified in [RFC6351], > referred to in this document as "xCard"." Yes, it should say "For encoding of the vCard." > =CA=CA=CA=CA > Section 4.2.1: > s/therefore this is/this is/ Done > > s/Figure 22/Section 10.1.2/ Done > > Section 4.2.2: > s/Figure 3/Section 10.1.3/ Done > > Section 4.2.3: > s/Figure 23/Section 10.1.4/ Done > > Section 4.3.6: > A reference to the IEEE 1512 spec should be included. Done > > Section 4.3.7: > s/which allow/that allow/ Done > > "Some standards being developed by other=20 > organizations" -- would be good to provide=20 > citations. I reworded the text to be simpler and avoid the reference. > > Section 4.4.2: > Given that 4.4 says the location provided here=20 > is the contact address and not necessarily the=20 > location of the caller, it seems like this=20 > section needs to explain a little more why a=20 > call taker would use the location provided here. I agree, and added some additional text. > > Section 5.1: > OLD > A Call-info header with a purpose value starting with > 'EmergencyCallData' MUST only be sent on an emergency call > NEW > A Call-info header with a purpose value starting with > 'EmergencyCallData' MUST NOT be sent unless the call is an emergency c= all Edited per Keith's reply to your comment. > =CA > Section 9: > s/The functionality defined in this document,=20 > however/The functionality defined in this=20 > document/ Done. > > Section 10.1.2: > s/A s[RFC4119]hort/A short/ Previously fixed. > > Section 10.1.5: > Seems like this section and Figure 1 should=20 > both use "Token" rather than "Tokenproviderid." Yes, done. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Few people think more than two or three times a year; I have made an international reputation for myself by thinking once a week. --George Bernard Shaw From nobody Sun Jun 28 22:34: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 3CFE91A004B for ; Sun, 28 Jun 2015 22:34:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, 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 sQaOlwC68n_E for ; Sun, 28 Jun 2015 22:33: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 B89321A0039 for ; Sun, 28 Jun 2015 22:33: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=1435556036; x=1467092036; h=message-id:in-reply-to:references:date:to:from:subject; bh=Rkb1ln3mjqJa4WbeIg5yeAsAxBdKBEi2SSBVDqwll0U=; b=arTEretjgPPRdvKQieexwmFPIAGsQoSkAHpIF8EeDL6Atmvz9z6ZhRos FmaNwgJZaxIwCRRmT9I85JQlR/bYomqEYTwEg8IEo08Eqe8Enfy7pfqN+ Bh3l7ESVQQOxrWABQAIZtaeS19JLhG4Ei8TWXSj9mxaLVq4E0C9YuyFHw Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7846"; a="91687979" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2015 22:33:50 -0700 X-IronPort-AV: E=Sophos;i="5.13,696,1427785200"; d="scan'208";a="947078639" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2015 22:33:50 -0700 Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t5T5Xn73006643; Sun, 28 Jun 2015 22:33:49 -0700 X-IronPort-AV: E=Sophos;i="5.13,696,1427785200"; d="scan'208";a="467850690" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.230.183]) by ironmsg02-L.qualcomm.com with ESMTP; 28 Jun 2015 22:33:48 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B6970D7F0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <949EF20990823C4C85C18D59AA11AD8B6970D7F0@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Sun, 28 Jun 2015 18:55:41 -0700 To: "DRAGE, Keith (Keith)" , Alissa Cooper , "ecrit@ietf.org" 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-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 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, 29 Jun 2015 05:34:01 -0000 Hi Keith, Thanks for your comments. I've addressed them in-line below, and changes are in -30. At 11:45 AM +0000 5/1/15, Keith (Keith) DRAGE wrote: > This part of Alissa's review caught my eye because I think the > original intent is wrong, and therefore so is the rewrite: > >> Section 5.1: >> OLD > > A Call-info header with a purpose value starting with >> 'EmergencyCallData' MUST only be sent on an emergency call >> NEW A Call-info header with a purpose value starting with >> 'EmergencyCallData' MUST NOT be sent unless the call is an >> emergency call >> > > Unless this document updates RFC 3261, which it does not, it cannot > preclude any string being sent in the purpose value. > > This is nothing in the original text that is to do with > interoperability, after all the recipient knows from other > information that this is an emergency call, or not an emergency > call. There is therefore no need to protect for wrong usage outside > an emergency call. > > So I believe that there is no need for any normative language here > and rather what is meant is: > > NEW TEXT > > A Call-info header with a purpose value starting with > 'EmergencyCallData' only has meaning in the context of an > emergency call, which can > be ascertained by the presence of an emergency service urn in a Route > header of a SIP message. It has no meaning outside the context > of an emergency call." The intent is not interoperability per se but rather protection. The original text was trying to say "It's a really bad idea to send this data in anything other than an emergency call." It's also true that a purpose value starting with 'EmergencyCallData.' is only defined for use within an emergency call; use outside this context is a Bad Idea as well as undefined. Although there is an exception, which is private emergency call, e.g., the call leg between a vehicle and a service provider call center, but that's a private use between endpoints by prior agreement. Another exception to Keith's proposed text is a test call. I added a modified form of Keith's text: A Call-info header with a purpose value starting with 'EmergencyCallData' only has meaning in the context of an emergency call (including test emergency calls); use in other contexts is undefined and is likely to unnecessarily expose confidential data > > As a result of opening the document again I also noted the > following that would be worthy of comment. > > Section 4.2.3: > > OLD TEXT > ---------- > The URI, when dereferenced, MUST > yield a data structure defined by the Device/service specific > additional data type value. > > The normative requirement here is nothing to do with the > dereferencing. It appears this is a requirement to keep the link > between the URI and the data for a period of time; the period of > time is not specified, but from the subsequent text would appear to > be for the duration a responder might be involved in the emergency > call. > > What is the real requirement here, does it apply to something > within the scope of this document, and can it be tested. The intent of the text is to specify that dereferencing results in a standardized data structure, which is necessary for interoperability; it wasn't intended to require that the reference remain valid for some period of time, although since you bring it up, it would be reasonable to require that it remain valid for a specific period of time after termination of the call. > > Section 5 > ----------- > > OLD TEXT > > Every block must be > one of the types in the registry. > > As specified this can be confused with a normative requirement. The > registry is transient data and therefore cannot be tested against. > It is also unclear what is meant by "type" as multiple types exist > in the document. I assume "service type". I would suggest. > > "All service types used in blocks are expected to be registered" It means the type of data block, that is, which data block, as registered in the Emergency Call Data Types Registry. The document defines a set of data blocks and establishes a registry so that the set can be expanded. The text is trying to say that any of the set of data blocks may be sent, and only registered blocks can be sent, for interoperability (the receiver must know how to interpret the blocks). > > But it is dubious whether we need any sentence at all rather than > the implicit one that says "If a registry is provided for an > element then all values are expected to be registered". It's the corollary of the previous sentence; that is: "One or more blocks [of the registered set of blocks] may be sent. Every block must be [a member of the set]" I've reworded the text to be: One or more blocks of data registered in the Emergency Call Additional Data registry, as defined in Section 10.1.9, can be included or referenced in the SIP signaling (using the Call-Info header field) or in the element of a PIDF-LO. For interoperability, only blocks in the registry are permitted to be sent using the mechanisms specified in this document. > > Section 9 > ---------- > > OLD TEXT > > Local regulations > may govern what data must be provided in emergency calls, but in > general, the emergency call system is aided by the information > described in this document. > > /must be/is/ Agreed. > > Section 10.1.9 > -------------- > > OLD TEXT > > This document creates a new sub-registry called 'Device/Service Data > Type Registry'. As defined in [RFC5226], this registry operates > under "Expert Review" and "Specification Required" rules. > > Expert review and Specification required are two distinct > categories of IANA policy. As written it might be assumed that > either can be used. It is sufficient to say "Specification > required" and then go into details about what the implicit expert > review associated with this policy requires. > > Similar comments apply elsewhere e.g. 10.1.10 Agreed, done. > > Like Alissa I would prefer that all the material that IANA has to > deal with is within the IANA considerations sections, and not > referenced back to other parts of the document (even if that means > duplication of text). Alissa asked that the initial values all be in one place, either all in the block definitions, or all in the IANA section. After discussing with my coauthors, we decided the best approach is to have all tables in the block definitions. > > Section 10.2 > ------------ > > TEXT > > Note that 'EmergencyCallData' > is a compound value; when used as a value of the 'purpose' parameter > of the Call-Info header, 'EmergencyCallData' is immediately followed > by a dot ('.') and a value from the 'Emergency Call Data Types' > registry Section 10.1.10. > > This text would appear to be nothing to do with the registry or the > values placed in the registry. The text is adding a new value to the 'purpose' parameter value registry. The fact that the new value is compound is significant. > > Other comment > ------------- > > RFC 3261 contains the statement in section 16.6. > > The proxy MUST NOT add to, modify, > or remove the message body. > > As this document does not update RFC 3261, I assume any > intermediate SIP entity acting as a proxy can only alter the > Call-Info header and not add to the body. In order to add to the > body it must be a B2BUA. This should be identified somewhere in the > document. I've added text to this effect in section 5.1 > >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Alissa Cooper >> Sent: 30 April 2015 23:57 >> To: ecrit@ietf.org >> Subject: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 >> >> I have reviewed draft-ietf-ecrit-additional-data-29 in >> preparation for IETF last call. There are a number of issues >> that need to be resolved before the IETF LC can be issued, >> which I've included below as substantive comments and >> questions. There is a list of nits at the end that also need >> to be fixed. >> >> Substantive comments and questions: > > >> General: >> I've asked the shepherd to validate all of the XML in the >> document and am waiting to hear back on that. >> >> Section 1: >> I would suggest adding this text from Section 9 or something >> like it at the end of the introduction: >> >> "Much of the information supplied by service providers and devices is >> private and confidential; service providers and devices >> generally go >> to lengths to protect this information; disclosing it in >> the context >> of an emergency call is a trade-off to protect the greater interest > > of the customer in an emergency." >> >> Section 4.1: >> I am a little confused about how this section applies when >> the data is being provided by the device. First, this text >> seems to consider the device to be a "service provider": > > >> "This block is intended to be supplied by any service provider in the >> path of the call or the access network provider. It includes >> identification and contact information. This block SHOULD be >> supplied by every service provider in the call path, and by the >> access network provider. Devices MAY use this block to provide >> identifying information." >> >> I think this would be clearer if the first sentence said "any >> service provider in the path of the call, the access network >> provider, or the device." >> >> Then later in the section Data Provider ID, Data Provider ID >> Series, and Type of Data Provider are defined. None of these >> seem to apply when the data is provided by the device, and >> yet they are all listed as required. What are these elements >> supposed to contain when the data is provided by the device? >> I see in the example in Section 6 that only Type of Data >> Provider is included, and is listed as "Other," which seems >> less specific than it ideally could be. >> >> Section 4.1.2: >> Is there an EENA equivalent of the NENA company ID? If so, it >> should be mentioned here. >> >> Is it the case that where a jurisdiction-specific ID exists, >> it is preferred over an FQDN? If so, that should be stated explicitly. > > >> Section 4.1.5: >> "If the call is from a device, this SHOULD be the contact >> information of the owner of the device." >> >> What are the exception cases for this SHOULD? What should >> this element be if it is not the owner's contact info? >> >> Section 4.1.6: >> By saying the other language tags are independent of this >> language element, does that mean they should be ignored? If >> so, that should be stated explicitly. >> >> Section 4.1.9: >> "This element is required if the Data Provider >> type is set to "Subcontractor"." >> >> Subcontractor is not listed as a data provider type in >> section 4.1.4, so this doesn't quite make sense. >> >> Section 4.2.1: >> Shouldn't "use" be listed as conditional? >> >> Section 4.2.3: >> s/MUST NOT/ought not to/ >> >> Section 4.3.4: >> I'm curious about the kinds of "investigations" that PSAPs do >> and how they have used unique device IDs in those >> investigations -- could you explain? At first blush this >> seems to require over-sharing of sensitive data. >> >> Section 4.4.1: >> Are there any jurisdiction-specific rules you can point to >> that would indicate that having a single boolean "privacy" >> value will actually be interpretable and of use by any PSAP? >> I find it a little hard to believe that PSAPs will know what >> actions this value is supposed to apply to (e.g., display, >> logging, display and logging, etc.) and what data fields it >> is supposed to apply to. Without further definition (or some >> compelling evidence that PSAPs in at least some places have >> well-specified rules for what to do when they receive this >> value), this indicator seems pretty hand-wavy. >> >> Section 4.4.2: >> Are there any xCard fields you would recommend not sending >> for lack of relevance (e.g., anniversary)? >> >> Depending on what the answer is to my question in 4.1.6 about >> interaction between Data Provider Language(s) and language >> tags, there might need to be text in this section as well >> about expected behavior when both are present and when the >> data provider is the device. >> >> Section 5.1: >> The last paragraph here makes it sound as though additional > > data is required to be sent on every emergency call (i.e., >> every call with an emergency service URN in the route >> header). Is that the intention? If so, that needs to be made >> more clear and should be explained earlier in the document, >> preferably in the introduction. If not, the normative >> language in the last paragraph here needs to be fixed. >> >> Section 6: >> The owner/subscriber of this laptop is Hannes Tschofenig. His >> contact tel URI is in North America but his work and home are > > in Finland. He is using a VoIP provider that provides its >> NENA ProviderID, which I assume indicates that the service is >> being provided in North America? The VoIP provider contact >> person is located in the UK, however. And then when the > > access network provides the location, it is in Australia. >> >> The last bit just seems wrong to me, for a plausible >> emergency call. The other bits seem to amount to a possible >> (but not likely?) example scenario but the details require >> more narrative explanation in the text. Alternatively, a >> simpler or more plausible example might help readers out more. >> >> Section 8: >> "Mechanisms that >> protect against eavesdropping (such as Transport Layer Security >> (TLS)) SHOULD be preferentially used whenever feasible." >> >> This needs a sentence about the existing deployed base of >> clear text SIP to explain why this requirement is not a MUST. >> >> s/HTTPS is specified/HTTPS is REQUIRED/ >> >> "Data provided by devices by reference have similar credential >> validation issues as for service providers, and the >> solutions are the >> same." >> >> Maybe the solutions are the same, but aren't the challenges >> of doing this for every device much more significant? That >> seems worth mention. >> >> s/Service providers SHOULD choose the latter/Service >> providers ought to choose the latter/ (otherwise this reads >> like a normative requirement on IMS functionality) >> >> Section 10.1.1: > > "Private entities issuing and using internally-generated IDs are >> encouraged to register and use a unique identifier." >> >> What is meant by "use a unique identifier"? >> >> Section 10.1.8: >> It might be useful to give the experts some additional >> criteria around weighing privacy vs. utility trade-offs. >> E.g., if someone wants to register the biometric fingerprint >> used to authenticate a device as a device ID and few or no >> PSAPs can actually make use of it, that may argue against >> registering it. >> >> Section 12.2: >> I think RFC 3966 should be a normative reference. >> >> >> Nits: >> >> General: >> Why are some of the registry tables in the main sections of >> the document and others are in the IANA Considerations >> section? Seems like they should all be one or the other. >> >> Section 2: >> Citations for vCard and xCard should be added to the last paragraph. >> >> Section 4.1.7: >> This sentence seems redundant: "For encoding of the xCard this >> specification uses the XML-based encoding specified in >> [RFC6351], >> referred to in this document as "xCard"." >> >> Section 4.2.1: >> s/therefore this is/this is/ >> >> s/Figure 22/Section 10.1.2/ >> >> Section 4.2.2: >> s/Figure 3/Section 10.1.3/ >> >> Section 4.2.3: >> s/Figure 23/Section 10.1.4/ >> >> Section 4.3.6: >> A reference to the IEEE 1512 spec should be included. >> >> Section 4.3.7: >> s/which allow/that allow/ >> >> "Some standards being developed by other organizations" -- >> would be good to provide citations. >> >> Section 4.4.2: >> Given that 4.4 says the location provided here is the contact >> address and not necessarily the location of the caller, it >> seems like this section needs to explain a little more why a >> call taker would use the location provided here. >> >> Section 5.1: >> OLD >> A Call-info header with a purpose value starting with >> 'EmergencyCallData' MUST only be sent on an emergency call >> NEW A Call-info header with a purpose value starting with >> 'EmergencyCallData' MUST NOT be sent unless the call is an >> emergency call >> >> Section 9: >> s/The functionality defined in this document, however/The >> functionality defined in this document/ >> >> Section 10.1.2: > > s/A s[RFC4119]hort/A short/ >> >> Section 10.1.5: >> Seems like this section and Figure 1 should both use "Token" >> rather than "Tokenproviderid." >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ > 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: --------------- Any given program costs more and takes longer. From nobody Tue Jun 30 19:37:27 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 D242F1A8840; Tue, 30 Jun 2015 19:37:23 -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 pqEpRtt3LIlQ; Tue, 30 Jun 2015 19:37:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 997BC1A87F2; Tue, 30 Jun 2015 19:37:22 -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.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150701023722.32032.14346.idtracker@ietfa.amsl.com> Date: Tue, 30 Jun 2015 19:37:22 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-30.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: Wed, 01 Jul 2015 02:37:24 -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-30.txt Pages : 109 Date : 2015-06-30 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated has information about the call, the caller or the location which might be helpful for the PSAP to have in handling the emergency. This document describes data structures and a mechanism to convey such data to the PSAP. The intent is that every emergency call carry the information described here using the mechanisms described here. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also 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-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-30 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/