From nobody Wed Nov 4 02:05: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 B29BF1B2C60 for ; Wed, 4 Nov 2015 02:05:19 -0800 (PST) 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 Vnpcvboh-0Gj for ; Wed, 4 Nov 2015 02:05:18 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 2BF461B2C61 for ; Wed, 4 Nov 2015 02:05:18 -0800 (PST) Received: by ykft191 with SMTP id t191so63164740ykf.0 for ; Wed, 04 Nov 2015 02:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=U609Cq6U9hXPA9Vq2dqWD40GRHjomGizc1dlgHcwOEU=; b=jqyRWo/B2v043UoEpOZvG5wBfxSh9LxlwPacoW1K1hpGacEYZgl/EWv4GaWdiaq2of D/Fx7hzu8ML80pvRrcehFykovnIuT259XyH22zJJcxjzRnEHjuP+oh2Hjsq/wKi6FBZ+ xouLfS8xcE/BLvqkEyT/7O9kqFf/Qe0o0HZPWMPTZagVmZqck49E/r97t4KkEpnkATbU wMsKfz8QuF6UUZL0g5VHtkS0AUWVmCQFY5j3AjOsJxhB1v65nmAJwrPYuhZn4v488csr 9DgtlTLApfVI7GRPpgdVxw/s7Jm+3AArUA+8KBqzMe0ri3jAp4mbAlYUWtKgIeBYniLn +d6A== MIME-Version: 1.0 X-Received: by 10.31.15.84 with SMTP id 81mr566471vkp.142.1446631517484; Wed, 04 Nov 2015 02:05:17 -0800 (PST) Received: by 10.31.155.2 with HTTP; Wed, 4 Nov 2015 02:05:17 -0800 (PST) Date: Wed, 4 Nov 2015 11:05:17 +0100 Message-ID: From: Ban Al-Bakri To: ecrit@ietf.org Content-Type: multipart/alternative; boundary=001a11437792b87b6f0523b4250c Archived-At: Subject: [Ecrit] eCall and Car-crash drafts 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, 04 Nov 2015 10:05:19 -0000 --001a11437792b87b6f0523b4250c Content-Type: text/plain; charset=UTF-8 Dear ECRIT group, I was involved in the initial work of the 2 drafts mentioned below. I am glad to see that the drafts look good and seem to be ready for advancement. "draft-ietf-ecrit-ecall-04" < https://tools.ietf.org/html/draft-ietf-ecrit-ecall-04> and "draft-ietf-ecrit-car-crash-04" and "draft-ietf-ecrit-ecall-04" < https://tools.ietf.org/html/draft-ietf-ecrit-car-crash> Best regards, Ban Al-Bakri MeadowCom --001a11437792b87b6f0523b4250c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear ECRIT group,

I was involved in the= initial work of the 2 drafts mentioned below. I am glad to see that the=C2=A0drafts look good and seem to be ready f= or advancement.


and

"draft-ietf-ecrit-car= -crash-04" and "draft-iet= f-ecrit-ecall-04"=C2=A0<https://tools.= ietf.org/html/draft-ietf-ecrit-car-crash>=C2=A0

Best regards,
= Ban Al-Bakri
MeadowCom
--001a11437792b87b6f0523b4250c-- From nobody Wed Nov 4 02:17: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 C4DB71B2C92 for ; Wed, 4 Nov 2015 02:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 uJWHRgeGQ6o1 for ; Wed, 4 Nov 2015 02:17:32 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 4DC6D1B2C8F for ; Wed, 4 Nov 2015 02:17:32 -0800 (PST) Received: by padhx2 with SMTP id hx2so41331853pad.1 for ; Wed, 04 Nov 2015 02:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=xuZD7w552DctJlMEnRL2ajiGIS1EVBEXxMzcR7ewp0M=; b=uVGwJG8zUbKTPs9tnR6M4rj9AXaoOSzXJmHzQMi9fw4g3DmbGT9LrXTH3mtmPKYAL6 S15SXgGpgwTwdlUW+hI3+mM6N0dRMjUFS8DSvOs+JSze5dtoCtpcY1NWvAj5DfzMBt++ ArcDle9uShRujJPClCxnNC8oNtmN+SG5+O6G5EkC8BvO6+WkA/p0uZ1jthJ3mkx6JAVL D1W9ps1AUGr7sa1xMoCdHFC0HVBsJzy6JL7ht9MKGbEc4N29UgdE0uW7uI+qyT90nppc GM0HE1CZWwBXnvfrDIKWYepcavdOSqjxqWBUqXXc9Ep9tkYYfrA3HkUlMUd+c0hghDlL Mnhw== X-Received: by 10.67.13.206 with SMTP id fa14mr792063pad.143.1446632252024; Wed, 04 Nov 2015 02:17:32 -0800 (PST) Received: from [192.168.1.100] ([1.129.94.137]) by smtp.gmail.com with ESMTPSA id pq1sm1061397pbb.91.2015.11.04.02.17.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 02:17:31 -0800 (PST) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_50AFAF14-2272-47EB-A4B5-435899C691EB" Message-Id: <66F409DD-FC40-4860-A77B-9576F81C68D9@gmail.com> Date: Wed, 4 Nov 2015 21:17:27 +1100 To: "ecrit_ietf.org" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Ecrit] Review of draft-ietf-ecrit-ecall-04 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, 04 Nov 2015 10:17:33 -0000 --Apple-Mail=_50AFAF14-2272-47EB-A4B5-435899C691EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, I have reviewed draft-ietf-ecrit-ecall-04 and think it is in good enough = shape to move forward. A couple of nits: The table in section 1 defines IMS as =E2=80=9CInternet Multimedia = Subsystem=E2=80=9D, I believe it is IP Multimedia Subsystem. In section 9.1.1 the element is dealt with. The second example in = 9.1.1.3 shows an with multiple elements, yet I = couldn=E2=80=99t find reference to the element being able to do = this in the text of 9.1.1. Saying this is possible might help a little. Section 9.2.1.1 is the first mention of msgid in the document and it = wasn=E2=80=99t readily apparent to me just what that was without digging = further into the document (a lot further). I think this could be = improved with a bit of a description here. Cheers James --Apple-Mail=_50AFAF14-2272-47EB-A4B5-435899C691EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

I = have reviewed draft-ietf-ecrit-ecall-04 and think it is in good = enough shape to move forward.

A couple of = nits:
The table in section 1 defines IMS as = =E2=80=9CInternet Multimedia Subsystem=E2=80=9D, I believe it is IP = Multimedia Subsystem.

In section 9.1.1 the <ack> element is dealt with. The = second example in 9.1.1.3 shows an <ack> with multiple = <actionResult> elements, yet I couldn=E2=80=99t find reference to = the <ack> element being able to do this in the text of 9.1.1. = Saying this is possible might help a little.

Section 9.2.1.1 is the first mention of = msgid in the document and it wasn=E2=80=99t readily apparent to me just = what that was without digging further into the document (a lot further). = I think this could be improved with a bit of a description = here.


Cheers
James



= --Apple-Mail=_50AFAF14-2272-47EB-A4B5-435899C691EB-- From nobody Wed Nov 4 02:31: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 8255F1A1BB3 for ; Wed, 4 Nov 2015 02:31:29 -0800 (PST) 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 ldwC9IoxI_kA for ; Wed, 4 Nov 2015 02:31:26 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 A768C1B2CF4 for ; Wed, 4 Nov 2015 02:31:26 -0800 (PST) Received: by pabfh17 with SMTP id fh17so49690659pab.0 for ; Wed, 04 Nov 2015 02:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=aD4sws2WMakBXK9m+E4Jmbwd/PrroEnxdr/ZBV+Q340=; b=GqxL9GVr2XLtUEJODZXjvQnt6/4Ea1RZk5zyGIC/mXMT8dT5DN5QK8Q3IQHqnhjwU7 G2LBi8RiLxQAWrHFK10VzzW9+wO91W30j7HypEeHSKCWAORV2ISHC1BXL1cnidHysoI0 21w0LbQ+OZBQjprrBRyjObrn3Iau/uvy1yMe/EcTDg2lzs8tLjt0eiRpxO8msy1p2mPj FaXyJcMtb6Y3spVKGhutf+a5dMhLLUV7QPEAItgmqeth9vZm9VDqTZ3UYMLj4x3uF64u X62bBH6pwftBHb9cSZ/A2cqWOj/BLC7/74Ibry/hS0SDT3H8JcDCwqUtzaaHr3X6n0eg F7Dg== X-Received: by 10.66.172.144 with SMTP id bc16mr927291pac.114.1446633086331; Wed, 04 Nov 2015 02:31:26 -0800 (PST) Received: from [192.168.1.100] ([1.129.82.99]) by smtp.gmail.com with ESMTPSA id z12sm1222330pbt.30.2015.11.04.02.31.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 02:31:25 -0800 (PST) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_87B7454D-C3DD-462C-BF3F-2ED5292F89D5" Message-Id: <364E5659-2773-4C37-A190-A1F402574D18@gmail.com> Date: Wed, 4 Nov 2015 21:31:20 +1100 To: "ecrit_ietf.org" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Ecrit] Progression of draft-ietf-ecrit-car-crash-04 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, 04 Nov 2015 10:31:29 -0000 --Apple-Mail=_87B7454D-C3DD-462C-BF3F-2ED5292F89D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I have read the car crash draft and it seems in pretty good shape to me. = I am fine with this document to move forward. Cheers James --Apple-Mail=_87B7454D-C3DD-462C-BF3F-2ED5292F89D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi All,

I have read = the car crash draft and it seems in pretty good shape to me. I am fine = with this document to move forward.


Cheers
James


= --Apple-Mail=_87B7454D-C3DD-462C-BF3F-2ED5292F89D5-- From nobody Thu Nov 5 01:28: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 508381A902F for ; Thu, 5 Nov 2015 01:28:57 -0800 (PST) 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: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHxWnDiuOeBO for ; Thu, 5 Nov 2015 01:28:51 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ACB861A902B for ; Thu, 5 Nov 2015 01:28:51 -0800 (PST) Received: from dhcp-96-48.meeting.ietf94.jp (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 5 Nov 2015 01:28:50 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <66F409DD-FC40-4860-A77B-9576F81C68D9@gmail.com> References: <66F409DD-FC40-4860-A77B-9576F81C68D9@gmail.com> X-Mailer: Eudora for Mac OS X Date: Thu, 5 Nov 2015 01:22:21 -0800 To: James Winterbottom , "ecrit_ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" 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] Review of draft-ietf-ecrit-ecall-04 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, 05 Nov 2015 09:28:57 -0000 Re: [Ecrit] Review of draft-ietf-ecrit-ecall-04
Hi James,

Thanks very much for your review.  I've fixed all three issues you identified, and they will be in version -05.

At 9:17 PM +1100 11/4/15, James Winterbottom wrote:

Hi All,

I have reviewed draft-ietf-ecrit-ecall-04 and think it is in good enough shape to move forward.

A couple of nits:
The table in section 1 defines IMS as "Internet Multimedia Subsystem", I believe it is IP Multimedia Subsystem.

In section 9.1.1 the <ack> element is dealt with. The second example in 9.1.1.3 shows an <ack> with multiple <actionResult> elements, yet I couldn't find reference to the <ack> element being able to do this in the text of 9.1.1. Saying this is possible might help a little.

Section 9.2.1.1 is the first mention of msgid in the document and it wasn't readily apparent to me just what that was without digging further into the document (a lot further). I think this could be improved with a bit of a description here.


Cheers
James




_______________________________________________
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: ---------------
To travel is to discover that everyone is wrong about other countries.
   --Aldous Huxley
From nobody Thu Nov 5 22:53:56 2015 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BFB1A92E7; Thu, 5 Nov 2015 22:53:55 -0800 (PST) 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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151106065355.1162.71879.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 22:53:55 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-05.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: Fri, 06 Nov 2015 06:53:55 -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 : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-05.txt Pages : 45 Date : 2015-11-05 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles. eCall deployment is required in the very near future in European Union member states, and eCall (and eCall- compatible systems) are also being deployed in other regions. eCall provides an integrated voice path and a standardized set of vehicle, sensor (e.g., crash related), and location data. An eCall is recognized and handled as a specialized form of emergency call and is routed to a specialized eCall-capable Public Safety Answering Point (PSAP) capable of processing the vehicle data and trained in handling emergency calls from vehicles. Currently, eCall functions over circuit-switched cellular telephony; work on next-generation eCall (NG-eCall, sometimes called packet- switched eCall or PS-eCall) is now in process, and this document assists in that work by describing how to support eCall within the IP-based emergency services infrastructure. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the eCall vehicle data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-05 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 Thu Nov 5 22:54:17 2015 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 253F91AC3B9; Thu, 5 Nov 2015 22:54:17 -0800 (PST) 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.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151106065417.948.82899.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 22:54:17 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-05.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: Fri, 06 Nov 2015 06:54:17 -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 : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-05.txt Pages : 26 Date : 2015-11-05 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the differences being that this document makes the MSD data set optional and VEDS mandatory. This document also discusses legacy (curcuit-switched) ACN systems and their migration to next-generation emergency calling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-05 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 Thu Nov 12 11:52: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 A0A6C1B333C for ; Thu, 12 Nov 2015 11:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 3sxSIxzXY_oF for ; Thu, 12 Nov 2015 11:52:49 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF6F1B3339 for ; Thu, 12 Nov 2015 11:52:49 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 643E720416 for ; Thu, 12 Nov 2015 14:52:48 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 12 Nov 2015 14:52:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=5KDkX6okgCW18/LnKGfOvEPWXdA =; b=dEPZXmof+OozkyZmBPRHsfCcE1ND8I67+J+ITE8/GN0j7HYcR+1FLmTS0Uf pF+g2oC0ZWlzgz9j2/8WJboFLQDpVzh9IA1CKWUDEB2h7dwYctjf0pQm0iQPO2qU giirW02aekCp3kutfcsj+ThENx1suUVllQBDWZh8cAiE12kA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=5K DkX6okgCW18/LnKGfOvEPWXdA=; b=GIlyIdzN+hXLVPPJZZ0Y3mWaj1hxA7T5/8 TbSoSbucF3WWPmr+YpLq6FijKBE9JTvJPesP4TSCCkOduE7avrS6xK23zDh5KXlg BEeXC39yf1F094b2XnKcIEXdwF1z3dzUYvfLXFRt+Dfx6FXUnel6EBJJg+w96e92 0IWK0VqKk= X-Sasl-enc: XPk975HH+psJsmTX9R7xufCv8AxUOp8cy/tGZyfx3AWW 1447357967 Received: from dhcp-171-68-20-31.cisco.com (dhcp-171-68-20-31.cisco.com [171.68.20.31]) by mail.messagingengine.com (Postfix) with ESMTPA id B5DFEC016F7 for ; Thu, 12 Nov 2015 14:52:47 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_4C54690E-9565-42C9-9A88-5405D8CA3B84" Message-Id: Date: Thu, 12 Nov 2015 11:52:46 -0800 To: ecrit@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 12 Nov 2015 19:52:51 -0000 --Apple-Mail=_4C54690E-9565-42C9-9A88-5405D8CA3B84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document and it is in good shape. I have a few = items to discuss before issuing the IETF LC and some nits that should be = resolved together with any LC comments. =3D=3D General =3D=3D I do not believe this document updates RFC 6881. This document makes no = recommendation about the circumstances under which the extension it = defines should be used, so it=E2=80=99s not really specifying any kind = of best current practice. In fact, I think a reasonable question one = could ask upon reading this document is =E2=80=9Cwhen should this = extension be used=E2=80=9D? But in any event it seems incorrect to say = it updates RFC 6881. I will note that I am not in the camp that believes that references to = terminology documents need to be normative. That seems particularly true = here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do. =3D=3D Sec 4 =3D=3D I think I understand why the draft describes how the LIS gets the = routing URI from a LoST server in Section 3, but given that the point of = this mechanism is to fill in a gap when there is no LoST server, I = don=E2=80=99t think it=E2=80=99s a point that should be re-emphasized. = So, a suggestion: OLD How the LIS obtains this information is left to implementation, one possible option is that the LIS acquires it from a LoST server, other possibilities are described in Section 3 = . NEW How the LIS obtains this information is left to implementation. Possibilities = are described in Section 3 = . Also, if I=E2=80=99m reading this right, there are two error cases where = the LIS response would be the same: if the LIS doesn=E2=80=99t = understand the extension, and if the LIS cannot obtain routing = information. Why is it okay to have both of these errors look the same = to the client making the request? Would it not be useful for the client = to know whether its request was not understood at all, or whether the = LIS just doesn=E2=80=99t know what URI to send? And if the two cases = really are meant to have the same result, they should be described in = the same way (i.e., shouldn=E2=80=99t the second case say =E2=80=9CMUST = return location as normal=E2=80=9D if it were to match the first case?). =3D=3D Sec 7 =3D=3D There seems to be a bit lurking here that I=E2=80=99d like to = understand: This represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS. What is the valid use case for a LIS to send a routing URI but no = location URI? That is, how does the LIS know how to find the PSAP if it = doesn=E2=80=99t know the location? Is this for those = one-PSAP-for-the-whole-country cases? Understanding that will help make = sense of this recommendation, because on its face it seems to call into = question the third-party authorization model in RFC 6155. That is, if a = third party is appropriately authorized to make a request on behalf of a = Target, why should that party not be trusted with a routing URI in the = absence of a location URI? Nits: =3D=3D Abstract =3D=3D s/This document specifies an extension to the HELD protocol/This = document specifies an extension to the HELD protocol, updating [RFC = 5985],/ =3D=3D Sec 1 =3D=3D s/Networks of forest guides have not eventuated/Networks of forest = guides have not materialized/ s/This document describes adding an extension/This document describes an = extension/ =3D=3D Sec 2 =3D=3D Please expand the acronyms on first use. =3D=3D Sec 3 =3D=3D s/such a HELD/such as HELD/ =3D=3D Sec 7 =3D=3D Expand =E2=80=9CLCP=E2=80=9D on first use. =3D=3D Sec 10 =3D=3D s/Keith Drage ofr/Keith Drage for/ --Apple-Mail=_4C54690E-9565-42C9-9A88-5405D8CA3B84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I have reviewed this document and it is in = good shape. I have a few items to discuss before issuing the IETF LC and = some nits that should be resolved together with any LC = comments.

=3D=3D= General =3D=3D

I do not believe this document updates RFC 6881. This = document makes no recommendation about the circumstances under which the = extension it defines should be used, so it=E2=80=99s not really = specifying any kind of best current practice. In fact, I think a = reasonable question one could ask upon reading this document is =E2=80=9Cw= hen should this extension be used=E2=80=9D? But in any event it seems = incorrect to say it updates RFC 6881.

I will note that I am not in the camp = that believes that references to terminology documents need to be = normative. That seems particularly true here given that the terms being = defined are all entities and realistically the label an entity has on it = does not affect the entity=E2=80=99s ability to properly implement the = HELD protocol. But I will not stand in the way of the WG=E2=80=99s = decision to call out the downrefs in IETF LC and add them to the downref = registry if that=E2=80=99s what you want to do.

=3D=3D Sec 4 =3D=3D

I think I understand why = the draft describes how the LIS gets the routing URI from a LoST server = in Section 3, but given that the point of this mechanism is to fill in a = gap when there is no LoST server, I don=E2=80=99t think it=E2=80=99s a = point that should be re-emphasized. So, a suggestion:

OLD
How the
   LIS obtains this information is left to implementation, one possible
   option is that the LIS acquires it from a LoST server, other
   possibilities are described in Section 3.

NEW
How the
   LIS obtains this information is left to implementation. Possibilities =
are described in Section 3.

Also, if = I=E2=80=99m reading this right, there are two error cases where the LIS = response would be the same: if the LIS doesn=E2=80=99t understand the = extension, and if the LIS cannot obtain routing information. Why is it = okay to have both of these errors look the same to the client making the = request? Would it not be useful for the client to know whether its = request was not understood at all, or whether the LIS just doesn=E2=80=99t= know what URI to send? And if the two cases really are meant to have = the same result, they should be described in the same way (i.e., = shouldn=E2=80=99t the second case say =E2=80=9CMUST return location as = normal=E2=80=9D if it were to match the first = case?).

=3D=3D Sec 7 = =3D=3D

There seems to be a bit lurking here that I=E2=80=99d like to = understand:

This = represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.

What is the valid use case for a = LIS to send a routing URI but no location URI? That is, how does the LIS = know how to find the PSAP if it doesn=E2=80=99t know the location? Is = this for those one-PSAP-for-the-whole-country cases? Understanding that = will help make sense of this recommendation, because on its face it = seems to call into question the third-party authorization model in RFC = 6155. That is, if a third party is appropriately authorized to make a = request on behalf of a Target, why should that party not be trusted with = a routing URI in the absence of a location URI?

Nits:

=3D=3D Abstract =3D=3D

s/This document specifies an extension to the = HELD protocol/This document specifies an extension to the = HELD protocol, updating [RFC 5985],/

=3D=3D Sec 1 =3D=3D

s/Networks of forest = guides have not eventuated/Networks of forest guides have not = materialized/

s/This document describes adding an extension/This document = describes an extension/

=3D=3D Sec 2 =3D=3D
Please expand the acronyms on first = use.

=3D=3D Sec 3 = =3D=3D

s/such a = HELD/such as HELD/

=3D=3D Sec 7 =3D=3D
Expand =E2=80=9CLCP=E2=80=9D = on first use.

=3D=3D Sec 10 = =3D=3D

s/Keith Drage = ofr/Keith Drage for/





= --Apple-Mail=_4C54690E-9565-42C9-9A88-5405D8CA3B84-- From nobody Fri Nov 13 13:24: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 1DEB91B3258 for ; Fri, 13 Nov 2015 13:24:02 -0800 (PST) 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 SamVxVcX8WQD for ; Fri, 13 Nov 2015 13:23:59 -0800 (PST) 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 603721B3268 for ; Fri, 13 Nov 2015 13:23:57 -0800 (PST) Received: by pacej9 with SMTP id ej9so4430201pac.2 for ; Fri, 13 Nov 2015 13:23:57 -0800 (PST) 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=dY85svhfHjkFlKK00fTANIBVBQBDvsavTJYoAD138yE=; b=k0SSC/guVUXrvN8aGM/WOwDmJrsxAm8fHO0SlxJAiKkdVHn7fwwqSBlQNbebmy/RlX f4YUa/4ksc6g7t7bFvLenHpA6+wA3aELED6uRFPK6dDurkMg4zhxmpINvrQStsQIKT0/ 9VWl3lzh34V9hUgLzyGTNIlfuqi1y1BvCUx4BZfwMcnLAngoYm5kp0yEuWMwV0ncHMyH X1jui2cIoq3HCj778/8JGE0qdS2UIaiUY+CO1jAqXtaU9NvmBuW3g3DorVHVewlcFY7a 7WQ5dcT7CcVZSCZRamrge1oGAB90FpOA2IWCnHAm7rQyWKZHIP6uuvIj3ot3eATs/FEQ mOow== X-Received: by 10.69.17.66 with SMTP id gc2mr35487869pbd.24.1447449836971; Fri, 13 Nov 2015 13:23:56 -0800 (PST) Received: from [192.168.1.100] ([1.144.61.11]) by smtp.gmail.com with ESMTPSA id vk10sm3126723pbc.66.2015.11.13.13.23.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 13:23:56 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D213E058-C4D2-47D2-B250-760C4CCC68A3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Sat, 14 Nov 2015 08:23:51 +1100 Message-Id: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> References: To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 13 Nov 2015 21:24:02 -0000 --Apple-Mail=_D213E058-C4D2-47D2-B250-760C4CCC68A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Alissa, Comments inline. Cheers James > On 13 Nov 2015, at 6:52 am, Alissa Cooper wrote: >=20 > I have reviewed this document and it is in good shape. I have a few = items to discuss before issuing the IETF LC and some nits that should be = resolved together with any LC comments. >=20 > =3D=3D General =3D=3D >=20 > I do not believe this document updates RFC 6881. This document makes = no recommendation about the circumstances under which the extension it = defines should be used, so it=E2=80=99s not really specifying any kind = of best current practice. In fact, I think a reasonable question one = could ask upon reading this document is =E2=80=9Cwhen should this = extension be used=E2=80=9D? But in any event it seems incorrect to say = it updates RFC 6881. [AJW] I am not sure that I agree with the assessment of the not updating = RFC 6881. I can see that if a request always contains the option then it = may get a PSAP URI back, if it doesn=E2=80=99t then it can try LoST. The = problem is that in cases where there is no public LoST server, if they = don=E2=80=99t ask for the routing URI then they won=E2=80=99t be able to = route. So in answer to your question, the extension should always be = sent in a request, it may not always get an answer. Even in NENA there = seem to be varying opinions on whether LoST servers will be publicly = assessable or not, so I don=E2=80=99t think that we can assume that LoST = is the public=E2=80=99s answer to all things related to emergency = routing. >=20 > I will note that I am not in the camp that believes that references to = terminology documents need to be normative. That seems particularly true = here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do. [AJW] I don=E2=80=99t mind either way, I was really just following what = seems to be convention. >=20 > =3D=3D Sec 4 =3D=3D >=20 > I think I understand why the draft describes how the LIS gets the = routing URI from a LoST server in Section 3, but given that the point of = this mechanism is to fill in a gap when there is no LoST server, I = don=E2=80=99t think it=E2=80=99s a point that should be re-emphasized. = So, a suggestion: >=20 > OLD > How the > LIS obtains this information is left to implementation, one = possible > option is that the LIS acquires it from a LoST server, other > possibilities are described in Section 3 = . >=20 > NEW > How the > LIS obtains this information is left to implementation. = Possibilities are described in Section 3 = . >=20 [AJW] I am fine with that. I think LoST was actually added to that = sentence as a result of comments in a pervious version. I shall remove = it and replace it with your recommendation. > Also, if I=E2=80=99m reading this right, there are two error cases = where the LIS response would be the same: if the LIS doesn=E2=80=99t = understand the extension, and if the LIS cannot obtain routing = information. Why is it okay to have both of these errors look the same = to the client making the request? Would it not be useful for the client = to know whether its request was not understood at all, or whether the = LIS just doesn=E2=80=99t know what URI to send? And if the two cases = really are meant to have the same result, they should be described in = the same way (i.e., shouldn=E2=80=99t the second case say =E2=80=9CMUST = return location as normal=E2=80=9D if it were to match the first case?). >=20 > =3D=3D Sec 7 =3D=3D >=20 > There seems to be a bit lurking here that I=E2=80=99d like to = understand: >=20 > This represents additional information about the Target, > as a consequence it is recommended that this option only be used = when > a location URI is returned by the LIS. >=20 > What is the valid use case for a LIS to send a routing URI but no = location URI? That is, how does the LIS know how to find the PSAP if it = doesn=E2=80=99t know the location? Is this for those = one-PSAP-for-the-whole-country cases? Understanding that will help make = sense of this recommendation, because on its face it seems to call into = question the third-party authorization model in RFC 6155. That is, if a = third party is appropriately authorized to make a request on behalf of a = Target, why should that party not be trusted with a routing URI in the = absence of a location URI? [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 says = =E2=80=9CA successful response to a location request MUST contain a = PIDF-LO and/or Location URI(s)=E2=80=9D. So what the sentence is really = trying to say is that the LIS shouldn=E2=80=99t return a location value = and the routing information, it should only a location URI when the = routing information is returned. >=20 > Nits: >=20 > =3D=3D Abstract =3D=3D >=20 > s/This document specifies an extension to the HELD protocol/This = document specifies an extension to the HELD protocol, updating [RFC = 5985],/ >=20 > =3D=3D Sec 1 =3D=3D >=20 > s/Networks of forest guides have not eventuated/Networks of forest = guides have not materialized/ >=20 > s/This document describes adding an extension/This document describes = an extension/ >=20 > =3D=3D Sec 2 =3D=3D >=20 > Please expand the acronyms on first use. >=20 > =3D=3D Sec 3 =3D=3D >=20 > s/such a HELD/such as HELD/ >=20 > =3D=3D Sec 7 =3D=3D >=20 > Expand =E2=80=9CLCP=E2=80=9D on first use. >=20 > =3D=3D Sec 10 =3D=3D >=20 > s/Keith Drage ofr/Keith Drage for/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_D213E058-C4D2-47D2-B250-760C4CCC68A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Alissa,

Comments inline.

Cheers
James

On 13 Nov 2015, at 6:52 am, = Alissa Cooper <alissa@cooperw.in> wrote:

I have reviewed this document and it is in good shape. I have = a few items to discuss before issuing the IETF LC and some nits that = should be resolved together with any LC comments.
=3D=3D General =3D=3D

I do not believe this = document updates RFC 6881. This document makes no recommendation about = the circumstances under which the extension it defines should be used, = so it=E2=80=99s not really specifying any kind of best current practice. = In fact, I think a reasonable question one could ask upon reading this = document is =E2=80=9Cwhen should this extension be used=E2=80=9D? But in = any event it seems incorrect to say it updates RFC = 6881.

[AJW] I am not sure = that I agree with the assessment of the not updating RFC 6881. I can see = that if a request always contains the option then it may get a PSAP URI = back, if it doesn=E2=80=99t then it can try LoST. The problem is that in = cases where there is no public LoST server, if they don=E2=80=99t ask = for the routing URI then they won=E2=80=99t be able to route. So in = answer to your question, the extension should always be sent in a = request, it may not always get an answer. Even in NENA there seem to be = varying opinions on whether LoST servers will be publicly assessable or = not, so I don=E2=80=99t think that we can assume that LoST is the = public=E2=80=99s answer to all things related to emergency = routing.


I will = note that I am not in the camp that believes that references to = terminology documents need to be normative. That seems particularly true = here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do.

[AJW] I don=E2=80=99t mind either way, I was really = just following what seems to be convention.


=3D=3D Sec 4 =3D=3D

I think I understand why = the draft describes how the LIS gets the routing URI from a LoST server = in Section 3, but given that the point of this mechanism is to fill in a = gap when there is no LoST server, I don=E2=80=99t think it=E2=80=99s a = point that should be re-emphasized. So, a suggestion:

OLD
How the
   LIS obtains this information is left to implementation, one possible
   option is that the LIS acquires it from a LoST server, other
   possibilities are described in Section 3.

NEW
How the
   LIS obtains this information is left to implementation. Possibilities =
are described in Section 3.


[AJW] I am fine with that. I think LoST was actually = added to that sentence as a result of comments in a pervious version. I = shall remove it and replace it with = your recommendation.

Also, = if I=E2=80=99m reading this right, there are two error cases where the = LIS response would be the same: if the LIS doesn=E2=80=99t understand = the extension, and if the LIS cannot obtain routing information. Why is = it okay to have both of these errors look the same to the client making = the request? Would it not be useful for the client to know whether its = request was not understood at all, or whether the LIS just doesn=E2=80=99t= know what URI to send? And if the two cases really are meant to have = the same result, they should be described in the same way (i.e., = shouldn=E2=80=99t the second case say =E2=80=9CMUST return location as = normal=E2=80=9D if it were to match the first = case?).

=3D=3D Sec 7 = =3D=3D

There seems to be a bit lurking here that I=E2=80=99d like to = understand:

This = represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.

What is the valid use case for a = LIS to send a routing URI but no location URI? That is, how does the LIS = know how to find the PSAP if it doesn=E2=80=99t know the location? Is = this for those one-PSAP-for-the-whole-country cases? Understanding that = will help make sense of this recommendation, because on its face it = seems to call into question the third-party authorization model in RFC = 6155. That is, if a third party is appropriately authorized to make a = request on behalf of a Target, why should that party not be trusted with = a routing URI in the absence of a location = URI?

[AJW] Perhaps this = could be worded better. Section 5.2 of RFC 5985 says =E2=80=9CA = successful response to a location request MUST contain a PIDF-LO and/or = Location URI(s)=E2=80=9D. So what the sentence is really trying to say = is that the LIS shouldn=E2=80=99t return a location value and the = routing information, it should only a location URI when the routing = information is returned.


Nits:

=3D=3D Abstract =3D=3D

s/This document specifies an extension to the = HELD protocol/This document specifies an extension to the = HELD protocol, updating [RFC 5985],/

=3D=3D Sec 1 =3D=3D

s/Networks of forest = guides have not eventuated/Networks of forest guides have not = materialized/

s/This document describes adding an extension/This document = describes an extension/

=3D=3D Sec 2 =3D=3D
Please expand the acronyms on first = use.

=3D=3D Sec 3 = =3D=3D

s/such a = HELD/such as HELD/

=3D=3D Sec 7 =3D=3D
Expand =E2=80=9CLCP=E2=80=9D = on first use.

=3D=3D Sec 10 = =3D=3D

s/Keith Drage = ofr/Keith Drage for/





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

= --Apple-Mail=_D213E058-C4D2-47D2-B250-760C4CCC68A3-- From nobody Mon Nov 16 09:04: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 129971A6F93 for ; Mon, 16 Nov 2015 09:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 PyHcLLOBSPjD for ; Mon, 16 Nov 2015 09:04:27 -0800 (PST) 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 35A811A6FAC for ; Mon, 16 Nov 2015 09:04:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6171220766 for ; Mon, 16 Nov 2015 12:04:25 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 16 Nov 2015 12:04:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=O6pV8 6WcHDWxZ9kEKaeqyqDR0mk=; b=gQ2xRQ5hYWNF+bElHMUBAOdVpp9+fMxr+2FMh W4351A8ScnI1OS/XHouJuxFaiM8Q4WyJ1NWxEvw0F8n99/EIpCjGf6m0I1lTojp1 1MbDGh+NahyCTjZzIK2WHJFsX6SGzkx4xUYR0KsDanYKcAAZFodXxqFAGwWCXQ2s +V59uk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=O6pV86WcHDWxZ9kEKaeqyqDR0mk=; b=qHdUj TahnBJUyEFOIlMUb9XS8xIK+cZ5zVtiYxG0Kak34VexVuHkQ2PSdcbphaUjIirys FYz9ahHwMvzfPJqWImjPC8gzvdt5Xp7/5V0p+sk+BleIA5CxVI0BuFkijhINRBTQ fTqRmAhAtdzQ/gPD8eE2N3zdAbBK5YNsjkgZyg= X-Sasl-enc: BEiDrniN0ZA+mjPPHCoecCfMa5jgfRdFPsevi5kxxaAz 1447693464 Received: from dhcp-171-68-20-102.cisco.com (dhcp-171-68-20-102.cisco.com [171.68.20.102]) by mail.messagingengine.com (Postfix) with ESMTPA id A1E39C018FC; Mon, 16 Nov 2015 12:04:24 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8A264E18-6426-44A5-8B7F-C6E3E45BD916" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> Date: Mon, 16 Nov 2015 09:04:25 -0800 Message-Id: References: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> To: James Winterbottom X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 16 Nov 2015 17:04:31 -0000 --Apple-Mail=_8A264E18-6426-44A5-8B7F-C6E3E45BD916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi James, Thanks, some responses inline. > On Nov 13, 2015, at 1:23 PM, James Winterbottom = wrote: >=20 > Thanks Alissa, >=20 > Comments inline. >=20 > Cheers > James >=20 >> On 13 Nov 2015, at 6:52 am, Alissa Cooper > wrote: >>=20 >> I have reviewed this document and it is in good shape. I have a few = items to discuss before issuing the IETF LC and some nits that should be = resolved together with any LC comments. >>=20 >> =3D=3D General =3D=3D >>=20 >> I do not believe this document updates RFC 6881. This document makes = no recommendation about the circumstances under which the extension it = defines should be used, so it=E2=80=99s not really specifying any kind = of best current practice. In fact, I think a reasonable question one = could ask upon reading this document is =E2=80=9Cwhen should this = extension be used=E2=80=9D? But in any event it seems incorrect to say = it updates RFC 6881. >=20 > [AJW] I am not sure that I agree with the assessment of the not = updating RFC 6881. I can see that if a request always contains the = option then it may get a PSAP URI back, if it doesn=E2=80=99t then it = can try LoST. The problem is that in cases where there is no public LoST = server, if they don=E2=80=99t ask for the routing URI then they won=E2=80=99= t be able to route. So in answer to your question, the extension should = always be sent in a request, it may not always get an answer. Even in = NENA there seem to be varying opinions on whether LoST servers will be = publicly assessable or not, so I don=E2=80=99t think that we can assume = that LoST is the public=E2=80=99s answer to all things related to = emergency routing. Ok. My point is that at present the document doesn=E2=80=99t actually = make the recommendation that implementations should always send the = routing request. It is silent on this. A proper update to RFC 6881 would = explain what the recommendation(s) are for requests and responses and = would use the requirements notation as it is used in 6881 (e.g., =E2=80=9C= ED-, etc.).=20 >=20 >>=20 >> I will note that I am not in the camp that believes that references = to terminology documents need to be normative. That seems particularly = true here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do. >=20 > [AJW] I don=E2=80=99t mind either way, I was really just following = what seems to be convention. Ok, the shepherd write-up says one of the authors wants these to be = normative. >=20 >>=20 >> =3D=3D Sec 4 =3D=3D >>=20 >> I think I understand why the draft describes how the LIS gets the = routing URI from a LoST server in Section 3, but given that the point of = this mechanism is to fill in a gap when there is no LoST server, I = don=E2=80=99t think it=E2=80=99s a point that should be re-emphasized. = So, a suggestion: >>=20 >> OLD >> How the >> LIS obtains this information is left to implementation, one = possible >> option is that the LIS acquires it from a LoST server, other >> possibilities are described in Section 3 = . >>=20 >> NEW >> How the >> LIS obtains this information is left to implementation. = Possibilities are described in Section 3 = . >>=20 >=20 > [AJW] I am fine with that. I think LoST was actually added to that = sentence as a result of comments in a pervious version. I shall remove = it and replace it with your recommendation. >=20 >> Also, if I=E2=80=99m reading this right, there are two error cases = where the LIS response would be the same: if the LIS doesn=E2=80=99t = understand the extension, and if the LIS cannot obtain routing = information. Why is it okay to have both of these errors look the same = to the client making the request? Would it not be useful for the client = to know whether its request was not understood at all, or whether the = LIS just doesn=E2=80=99t know what URI to send? And if the two cases = really are meant to have the same result, they should be described in = the same way (i.e., shouldn=E2=80=99t the second case say =E2=80=9CMUST = return location as normal=E2=80=9D if it were to match the first case?). >>=20 >> =3D=3D Sec 7 =3D=3D >>=20 >> There seems to be a bit lurking here that I=E2=80=99d like to = understand: >>=20 >> This represents additional information about the Target, >> as a consequence it is recommended that this option only be used = when >> a location URI is returned by the LIS. >>=20 >> What is the valid use case for a LIS to send a routing URI but no = location URI? That is, how does the LIS know how to find the PSAP if it = doesn=E2=80=99t know the location? Is this for those = one-PSAP-for-the-whole-country cases? Understanding that will help make = sense of this recommendation, because on its face it seems to call into = question the third-party authorization model in RFC 6155. That is, if a = third party is appropriately authorized to make a request on behalf of a = Target, why should that party not be trusted with a routing URI in the = absence of a location URI? >=20 > [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 = says =E2=80=9CA successful response to a location request MUST contain a = PIDF-LO and/or Location URI(s)=E2=80=9D. So what the sentence is really = trying to say is that the LIS shouldn=E2=80=99t return a location value = and the routing information, it should only a location URI when the = routing information is returned. Not following your last sentence above still, could you re-phrase? Thanks, Alissa >=20 >>=20 >> Nits: >>=20 >> =3D=3D Abstract =3D=3D >>=20 >> s/This document specifies an extension to the HELD protocol/This = document specifies an extension to the HELD protocol, updating [RFC = 5985],/ >>=20 >> =3D=3D Sec 1 =3D=3D >>=20 >> s/Networks of forest guides have not eventuated/Networks of forest = guides have not materialized/ >>=20 >> s/This document describes adding an extension/This document describes = an extension/ >>=20 >> =3D=3D Sec 2 =3D=3D >>=20 >> Please expand the acronyms on first use. >>=20 >> =3D=3D Sec 3 =3D=3D >>=20 >> s/such a HELD/such as HELD/ >>=20 >> =3D=3D Sec 7 =3D=3D >>=20 >> Expand =E2=80=9CLCP=E2=80=9D on first use. >>=20 >> =3D=3D Sec 10 =3D=3D >>=20 >> s/Keith Drage ofr/Keith Drage for/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 --Apple-Mail=_8A264E18-6426-44A5-8B7F-C6E3E45BD916 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi James,

Thanks, some responses inline.

On = Nov 13, 2015, at 1:23 PM, James Winterbottom <a.james.winterbottom@gmail.com> wrote:

Thanks = Alissa,

Comments = inline.

Cheers
James

On 13 Nov 2015, at 6:52 am, Alissa Cooper <alissa@cooperw.in> = wrote:

I have reviewed this document and it is in good shape. I have = a few items to discuss before issuing the IETF LC and some nits that = should be resolved together with any LC comments.
=3D=3D General =3D=3D

I do not believe this = document updates RFC 6881. This document makes no recommendation about = the circumstances under which the extension it defines should be used, = so it=E2=80=99s not really specifying any kind of best current practice. = In fact, I think a reasonable question one could ask upon reading this = document is =E2=80=9Cwhen should this extension be used=E2=80=9D? But in = any event it seems incorrect to say it updates RFC = 6881.

[AJW] I am not sure that I agree with the assessment = of the not updating RFC 6881. I can see that if a request always = contains the option then it may get a PSAP URI back, if it doesn=E2=80=99t= then it can try LoST. The problem is that in cases where there is no = public LoST server, if they don=E2=80=99t ask for the routing URI then = they won=E2=80=99t be able to route. So in answer to your question, the = extension should always be sent in a request, it may not always get an = answer. Even in NENA there seem to be varying opinions on whether LoST = servers will be publicly assessable or not, so I don=E2=80=99t think = that we can assume that LoST is the public=E2=80=99s answer to all = things related to emergency = routing.

Ok. My point is that at present the document = doesn=E2=80=99t actually make the recommendation that implementations = should always send the routing request. It is silent on this. A proper = update to RFC 6881 would explain what the recommendation(s) are for = requests and responses and would use the requirements notation as it is = used in 6881 (e.g., =E2=80=9CED-, etc.). 



I will = note that I am not in the camp that believes that references to = terminology documents need to be normative. That seems particularly true = here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do.

[AJW] I don=E2=80=99t mind either way, I was really = just following what seems to be = convention.
Ok, the shepherd write-up says one of the = authors wants these to be normative.



=3D=3D Sec 4 = =3D=3D

I think = I understand why the draft describes how the LIS gets the routing URI = from a LoST server in Section 3, but given that the point of this = mechanism is to fill in a gap when there is no LoST server, I don=E2=80=99= t think it=E2=80=99s a point that should be re-emphasized. So, a = suggestion:

OLD
How the
   LIS obtains this information is left to implementation, one possible
   option is that the LIS acquires it from a LoST server, other
   possibilities are described in Section 3.

NEW
How the
   LIS obtains this information is left to implementation. Possibilities =
are described in Section 3.


[AJW] I am fine with that. I think LoST was actually = added to that sentence as a result of comments in a pervious version. I = shall remove it and replace it with = your recommendation.

Also, = if I=E2=80=99m reading this right, there are two error cases where the = LIS response would be the same: if the LIS doesn=E2=80=99t understand = the extension, and if the LIS cannot obtain routing information. Why is = it okay to have both of these errors look the same to the client making = the request? Would it not be useful for the client to know whether its = request was not understood at all, or whether the LIS just doesn=E2=80=99t= know what URI to send? And if the two cases really are meant to have = the same result, they should be described in the same way (i.e., = shouldn=E2=80=99t the second case say =E2=80=9CMUST return location as = normal=E2=80=9D if it were to match the first = case?).

=3D=3D Sec 7 = =3D=3D

There seems to be a bit lurking here that I=E2=80=99d like to = understand:

This = represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.

What is the valid use case for a = LIS to send a routing URI but no location URI? That is, how does the LIS = know how to find the PSAP if it doesn=E2=80=99t know the location? Is = this for those one-PSAP-for-the-whole-country cases? Understanding that = will help make sense of this recommendation, because on its face it = seems to call into question the third-party authorization model in RFC = 6155. That is, if a third party is appropriately authorized to make a = request on behalf of a Target, why should that party not be trusted with = a routing URI in the absence of a location = URI?

[AJW] Perhaps this could be worded better. Section = 5.2 of RFC 5985 says =E2=80=9CA successful response to a location = request MUST contain a PIDF-LO and/or Location URI(s)=E2=80=9D. So what = the sentence is really trying to say is that the LIS shouldn=E2=80=99t = return a location value and the routing information, it should only a = location URI when the routing information is = returned.

Not following your last sentence above still, = could you re-phrase?

Thanks,
Alissa



Nits:

=3D=3D Abstract =3D=3D

s/This document = specifies an extension to the HELD protocol/This document = specifies an extension to the HELD protocol, updating [RFC = 5985],/

=3D=3D = Sec 1 =3D=3D

s/Networks of forest guides have not eventuated/Networks of forest = guides have not materialized/

s/This document describes adding an = extension/This document describes an extension/
=3D=3D Sec 2 =3D=3D
Please expand the acronyms on first = use.

=3D=3D Sec 3 = =3D=3D

s/such a = HELD/such as HELD/

=3D=3D Sec 7 =3D=3D
Expand =E2=80=9CLCP=E2=80=9D = on first use.

=3D=3D Sec 10 = =3D=3D

s/Keith Drage = ofr/Keith Drage for/





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


= --Apple-Mail=_8A264E18-6426-44A5-8B7F-C6E3E45BD916-- From nobody Mon Nov 16 11: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 2A95A1A882F for ; Mon, 16 Nov 2015 11:29:59 -0800 (PST) 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 w-cABrmHWELn for ; Mon, 16 Nov 2015 11:29:56 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D4D1A887C for ; Mon, 16 Nov 2015 11:29:56 -0800 (PST) Received: by pabfh17 with SMTP id fh17so187018850pab.0 for ; Mon, 16 Nov 2015 11:29:56 -0800 (PST) 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=VWZtiZ28kwC8Y+gbxw+g1vYA9EF9KBI9xqZ0TAIq7Ik=; b=HITOgBahEMYCGq2gaktoFdfE6dZOnP4u0AY8E2OlS1JB5mdcElUn4nFiiqUhl2LeOC Rby8TayoUz/jR2fHqFBGyaknvfQP4aAyHHKxio2G8NRV9qKffde9578HVunu+Y0edL9x jl3LOCbollaJs0Z0IU1KXEwvjQpDdRdRGKySCaJ9soKoqPHBalaoXkMCEPS+3Lb6uWms FADGsmS70EVi4o8QyEJ1K4KdCgNPi+f0Giu4arAKpqlMh5blJZ2UqefFgw65eDxRNGTQ /A64yk3/aZHIwjbLXbFRaFUk/yjcICCYaGxb1g/2CXSAnh/wtKk0/gAnOpJ9iMbt9/6D Dx0A== X-Received: by 10.68.135.103 with SMTP id pr7mr30036605pbb.53.1447702195882; Mon, 16 Nov 2015 11:29:55 -0800 (PST) Received: from [192.168.1.11] (124-168-176-241.dyn.iinet.net.au. [124.168.176.241]) by smtp.gmail.com with ESMTPSA id bs3sm38053664pbd.89.2015.11.16.11.29.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Nov 2015 11:29:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_230B9756-69EE-4284-8A6B-0D1A03C9BD4E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Tue, 17 Nov 2015 06:29:53 +1100 Message-Id: <173BBCAB-F050-4BAA-B651-C7C1AF8CB92E@gmail.com> References: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 16 Nov 2015 19:29:59 -0000 --Apple-Mail=_230B9756-69EE-4284-8A6B-0D1A03C9BD4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Alissa, More inline. > On 17 Nov 2015, at 4:04 am, Alissa Cooper wrote: >=20 > Hi James, >=20 > Thanks, some responses inline. >=20 >>=20 >>=20 >>> On 13 Nov 2015, at 6:52 am, Alissa Cooper > wrote: >>>=20 >>> I have reviewed this document and it is in good shape. I have a few = items to discuss before issuing the IETF LC and some nits that should be = resolved together with any LC comments. >>>=20 >>> =3D=3D General =3D=3D >>>=20 >>> I do not believe this document updates RFC 6881. This document makes = no recommendation about the circumstances under which the extension it = defines should be used, so it=E2=80=99s not really specifying any kind = of best current practice. In fact, I think a reasonable question one = could ask upon reading this document is =E2=80=9Cwhen should this = extension be used=E2=80=9D? But in any event it seems incorrect to say = it updates RFC 6881. >>=20 >> [AJW] I am not sure that I agree with the assessment of the not = updating RFC 6881. I can see that if a request always contains the = option then it may get a PSAP URI back, if it doesn=E2=80=99t then it = can try LoST. The problem is that in cases where there is no public LoST = server, if they don=E2=80=99t ask for the routing URI then they won=E2=80=99= t be able to route. So in answer to your question, the extension should = always be sent in a request, it may not always get an answer. Even in = NENA there seem to be varying opinions on whether LoST servers will be = publicly assessable or not, so I don=E2=80=99t think that we can assume = that LoST is the public=E2=80=99s answer to all things related to = emergency routing. >=20 > Ok. My point is that at present the document doesn=E2=80=99t actually = make the recommendation that implementations should always send the = routing request. It is silent on this. A proper update to RFC 6881 would = explain what the recommendation(s) are for requests and responses and = would use the requirements notation as it is used in 6881 (e.g., =E2=80=9C= ED-, etc.).=20 [AJW] I will add these to the relevant sections. >=20 >>=20 >>>=20 >>> I will note that I am not in the camp that believes that references = to terminology documents need to be normative. That seems particularly = true here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do. >>=20 >> [AJW] I don=E2=80=99t mind either way, I was really just following = what seems to be convention. >=20 > Ok, the shepherd write-up says one of the authors wants these to be = normative. [AJW] That was probably me and I was only keeping with convention if = that isn=E2=80=99t really a convention then I can move but if no one has = a strong opinion either way then I will just leave them. >=20 >>> =E2=80=94 SNIP >>>=20 >>> There seems to be a bit lurking here that I=E2=80=99d like to = understand: >>>=20 >>> This represents additional information about the Target, >>> as a consequence it is recommended that this option only be used = when >>> a location URI is returned by the LIS. >>>=20 >>> What is the valid use case for a LIS to send a routing URI but no = location URI? That is, how does the LIS know how to find the PSAP if it = doesn=E2=80=99t know the location? Is this for those = one-PSAP-for-the-whole-country cases? Understanding that will help make = sense of this recommendation, because on its face it seems to call into = question the third-party authorization model in RFC 6155. That is, if a = third party is appropriately authorized to make a request on behalf of a = Target, why should that party not be trusted with a routing URI in the = absence of a location URI? >>=20 >> [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 = says =E2=80=9CA successful response to a location request MUST contain a = PIDF-LO and/or Location URI(s)=E2=80=9D. So what the sentence is really = trying to say is that the LIS shouldn=E2=80=99t return a location value = and the routing information, it should only a location URI when the = routing information is returned. >=20 > Not following your last sentence above still, could you re-phrase? [AJW] For a LIS to return a HELD locationResponse the response must = contain a location, that location may be a location URI or a location = value. A HELD locationResponse cannot ever contain just a routing = response. They main reason for returning a location to a third-party = that requested the information using an identity extension was that the = party wanted to route a message somewhere, and that they would first = query a LIS and then use that location to query a LoST server. Since the = extension described in this document eliminates the need for the LoST = interaction, there is also little need to return a location value, a = locationURI will do. Does that help?=20 >=20 > Thanks, > Alissa >=20 >>=20 >>>=20 >>> Nits: >>>=20 >>> =3D=3D Abstract =3D=3D >>>=20 >>> s/This document specifies an extension to the HELD protocol/This = document specifies an extension to the HELD protocol, updating [RFC = 5985],/ >>>=20 >>> =3D=3D Sec 1 =3D=3D >>>=20 >>> s/Networks of forest guides have not eventuated/Networks of forest = guides have not materialized/ >>>=20 >>> s/This document describes adding an extension/This document = describes an extension/ >>>=20 >>> =3D=3D Sec 2 =3D=3D >>>=20 >>> Please expand the acronyms on first use. >>>=20 >>> =3D=3D Sec 3 =3D=3D >>>=20 >>> s/such a HELD/such as HELD/ >>>=20 >>> =3D=3D Sec 7 =3D=3D >>>=20 >>> Expand =E2=80=9CLCP=E2=80=9D on first use. >>>=20 >>> =3D=3D Sec 10 =3D=3D >>>=20 >>> s/Keith Drage ofr/Keith Drage for/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_230B9756-69EE-4284-8A6B-0D1A03C9BD4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Alissa,

More inline.


On 17 Nov 2015, at 4:04 am, Alissa Cooper <alissa@cooperw.in> = wrote:

Hi = James,

Thanks, some responses inline.



On 13 Nov 2015, at 6:52 am, Alissa Cooper = <alissa@cooperw.in> wrote:

I have reviewed = this document and it is in good shape. I have a few items to discuss = before issuing the IETF LC and some nits that should be resolved = together with any LC comments.

=3D=3D General =3D=3D

I do not believe this = document updates RFC 6881. This document makes no recommendation about = the circumstances under which the extension it defines should be used, = so it=E2=80=99s not really specifying any kind of best current practice. = In fact, I think a reasonable question one could ask upon reading this = document is =E2=80=9Cwhen should this extension be used=E2=80=9D? But in = any event it seems incorrect to say it updates RFC = 6881.

[AJW] I am not sure that I agree with the assessment = of the not updating RFC 6881. I can see that if a request always = contains the option then it may get a PSAP URI back, if it doesn=E2=80=99t= then it can try LoST. The problem is that in cases where there is no = public LoST server, if they don=E2=80=99t ask for the routing URI then = they won=E2=80=99t be able to route. So in answer to your question, the = extension should always be sent in a request, it may not always get an = answer. Even in NENA there seem to be varying opinions on whether LoST = servers will be publicly assessable or not, so I don=E2=80=99t think = that we can assume that LoST is the public=E2=80=99s answer to all = things related to emergency = routing.

Ok. My point is that at = present the document doesn=E2=80=99t actually make the recommendation = that implementations should always send the routing request. It is = silent on this. A proper update to RFC 6881 would explain what the = recommendation(s) are for requests and responses and would use the = requirements notation as it is used in 6881 (e.g., =E2=80=9CED-, = etc.). 

[AJW] I will add these to the relevant = sections.




I will note that I am not in the camp = that believes that references to terminology documents need to be = normative. That seems particularly true here given that the terms being = defined are all entities and realistically the label an entity has on it = does not affect the entity=E2=80=99s ability to properly implement the = HELD protocol. But I will not stand in the way of the WG=E2=80=99s = decision to call out the downrefs in IETF LC and add them to the downref = registry if that=E2=80=99s what you want to = do.

[AJW] I don=E2=80=99t mind either way, I was really = just following what seems to be = convention.

Ok, the shepherd = write-up says one of the authors wants these to be = normative.

[AJW] That was probably me and I was only keeping with = convention if that isn=E2=80=99t really a convention then I can move but = if no one has a strong opinion either way then I will just leave = them.


=E2= =80=94 SNIP

There seems to be a bit lurking here that I=E2=80=99d like to = understand:

This = represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.

What is the valid use case for a = LIS to send a routing URI but no location URI? That is, how does the LIS = know how to find the PSAP if it doesn=E2=80=99t know the location? Is = this for those one-PSAP-for-the-whole-country cases? Understanding that = will help make sense of this recommendation, because on its face it = seems to call into question the third-party authorization model in RFC = 6155. That is, if a third party is appropriately authorized to make a = request on behalf of a Target, why should that party not be trusted with = a routing URI in the absence of a location = URI?

[AJW] Perhaps this could be worded better. Section = 5.2 of RFC 5985 says =E2=80=9CA successful response to a location = request MUST contain a PIDF-LO and/or Location URI(s)=E2=80=9D. So what = the sentence is really trying to say is that the LIS shouldn=E2=80=99t = return a location value and the routing information, it should only a = location URI when the routing information is = returned.

Not following your last = sentence above still, could you = re-phrase?

[AJW] For a LIS to return a = HELD locationResponse the response must contain a location, that = location may be a location URI or a location value. A HELD = locationResponse cannot ever contain just a routing response. They main = reason for returning a location to a third-party that requested the = information using an identity extension was that the party wanted to = route a message somewhere, and that they would first query a LIS and = then use that location to query a LoST server. Since the extension = described in this document eliminates the need for the LoST interaction, = there is also little need to return a location value, a locationURI will = do. Does that help? 


Thanks,
Alissa



Nits:

=3D=3D Abstract = =3D=3D

s/This document = specifies an extension to the HELD protocol/This document specifies = an extension to the HELD protocol, updating [RFC 5985],/

=3D=3D Sec 1 = =3D=3D

s/Networks of forest = guides have not eventuated/Networks of forest guides have not = materialized/

s/This document describes = adding an extension/This document describes an = extension/

=3D=3D Sec 2 = =3D=3D

Please expand the = acronyms on first use.

=3D=3D Sec 3 = =3D=3D

s/such a = HELD/such as HELD/

=3D=3D Sec 7 = =3D=3D

Expand =E2=80=9CLCP=E2=80=9D on first = use.

=3D=3D Sec 10 =3D=3D

s/Keith Drage = ofr/Keith Drage for/







_____________________________________________= __
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
= --Apple-Mail=_230B9756-69EE-4284-8A6B-0D1A03C9BD4E-- From nobody Wed Nov 18 13:30: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 652721B2F73 for ; Wed, 18 Nov 2015 13:30:55 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 Akcf_1oAk-Dg for ; Wed, 18 Nov 2015 13:30:52 -0800 (PST) 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 C1BCF1B2F72 for ; Wed, 18 Nov 2015 13:30:52 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1012720A30 for ; Wed, 18 Nov 2015 16:30:52 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 18 Nov 2015 16:30:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=WrmuS BCtL45UKIqT246Oto3Efok=; b=z57vH7VvrMFn7F7UUxIoUCKHgkYR0nGJKxgzf na6tMygi+DspcFrWevjFAFvhTICzJrLiHgg5CdDm2PO0XshEXN0FL42Gq6UCD4HG YUq8WTqRG2Fo+cZYxkY+d33JRyK6qIZwG9fueKB6u+q6L6sneTji4TDPek1i6Yzp xCLkbU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=WrmuSBCtL45UKIqT246Oto3Efok=; b=LTMhd bGOan3NeYV8dOYfbRCJzlBjNlwNrYHrbE6WH0FdLs5/mx+eoymIXayaZJgNKnFB0 uWCzDIZ3/PPsgK0FAvXkQQr6H2bpK2mM8vxyjXpLc8w0ykc/xlZF6jg8kFIeVtmD Gtkrnq5l7Iyk57LJS8N8iRsqbnxxREghhmgJ2g= X-Sasl-enc: blOxG4WRsuqHXNWBi1+FTHOGTulGxTWTXwoU2WBRh/GS 1447882251 Received: from dhcp-171-68-20-140.cisco.com (dhcp-171-68-20-140.cisco.com [171.68.20.140]) by mail.messagingengine.com (Postfix) with ESMTPA id 65228C01902; Wed, 18 Nov 2015 16:30:51 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9191311B-895F-498C-B469-0B1A34662C99" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <173BBCAB-F050-4BAA-B651-C7C1AF8CB92E@gmail.com> Date: Wed, 18 Nov 2015 13:30:50 -0800 Message-Id: <4840B933-C7FF-4E5D-B939-0645985B1087@cooperw.in> References: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> <173BBCAB-F050-4BAA-B651-C7C1AF8CB92E@gmail.com> To: James Winterbottom X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 18 Nov 2015 21:30:55 -0000 --Apple-Mail=_9191311B-895F-498C-B469-0B1A34662C99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi James, > On Nov 16, 2015, at 11:29 AM, James Winterbottom = wrote: >>=20 >>>=20 >>>>=20 >>>> I will note that I am not in the camp that believes that references = to terminology documents need to be normative. That seems particularly = true here given that the terms being defined are all entities and = realistically the label an entity has on it does not affect the = entity=E2=80=99s ability to properly implement the HELD protocol. But I = will not stand in the way of the WG=E2=80=99s decision to call out the = downrefs in IETF LC and add them to the downref registry if that=E2=80=99s= what you want to do. >>>=20 >>> [AJW] I don=E2=80=99t mind either way, I was really just following = what seems to be convention. >>=20 >> Ok, the shepherd write-up says one of the authors wants these to be = normative. >=20 > [AJW] That was probably me and I was only keeping with convention if = that isn=E2=80=99t really a convention then I can move but if no one has = a strong opinion either way then I will just leave them. I think it would be preferable for them to be informative. >=20 >>=20 >>>> =E2=80=94 SNIP >>>>=20 >>>> There seems to be a bit lurking here that I=E2=80=99d like to = understand: >>>>=20 >>>> This represents additional information about the Target, >>>> as a consequence it is recommended that this option only be used = when >>>> a location URI is returned by the LIS. >>>>=20 >>>> What is the valid use case for a LIS to send a routing URI but no = location URI? That is, how does the LIS know how to find the PSAP if it = doesn=E2=80=99t know the location? Is this for those = one-PSAP-for-the-whole-country cases? Understanding that will help make = sense of this recommendation, because on its face it seems to call into = question the third-party authorization model in RFC 6155. That is, if a = third party is appropriately authorized to make a request on behalf of a = Target, why should that party not be trusted with a routing URI in the = absence of a location URI? >>>=20 >>> [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 = says =E2=80=9CA successful response to a location request MUST contain a = PIDF-LO and/or Location URI(s)=E2=80=9D. So what the sentence is really = trying to say is that the LIS shouldn=E2=80=99t return a location value = and the routing information, it should only a location URI when the = routing information is returned. >>=20 >> Not following your last sentence above still, could you re-phrase? >=20 > [AJW] For a LIS to return a HELD locationResponse the response must = contain a location, that location may be a location URI or a location = value. A HELD locationResponse cannot ever contain just a routing = response. They main reason for returning a location to a third-party = that requested the information using an identity extension was that the = party wanted to route a message somewhere, and that they would first = query a LIS and then use that location to query a LoST server. Since the = extension described in this document eliminates the need for the LoST = interaction, there is also little need to return a location value, a = locationURI will do. Does that help?=20 Ah, sorry, I was missing that this was about value vs. URI as opposed to = returning location at all. I would suggest making a small addition to = the text to make this clear: This represents additional information about the Target, as a consequence it is recommended that this option only be used when the LIS returns a location URI, not a location value. Thanks, Alissa --Apple-Mail=_9191311B-895F-498C-B469-0B1A34662C99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi James,

On Nov 16, 2015, at 11:29 AM, = James Winterbottom <a.james.winterbottom@gmail.com> wrote:



I will note that I am not in the camp = that believes that references to terminology documents need to be = normative. That seems particularly true here given that the terms being = defined are all entities and realistically the label an entity has on it = does not affect the entity=E2=80=99s ability to properly implement the = HELD protocol. But I will not stand in the way of the WG=E2=80=99s = decision to call out the downrefs in IETF LC and add them to the downref = registry if that=E2=80=99s what you want to = do.

[AJW] I don=E2=80=99t mind either way, I was really = just following what seems to be = convention.

Ok, the shepherd = write-up says one of the authors wants these to be = normative.

[AJW] That was probably me and I was only keeping with = convention if that isn=E2=80=99t really a convention then I can move but = if no one has a strong opinion either way then I will just leave = them.

I think it would be preferable for them to be = informative.



=E2= =80=94 SNIP

There seems to be a bit lurking here that I=E2=80=99d like to = understand:

This = represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.

What is the valid use case for a = LIS to send a routing URI but no location URI? That is, how does the LIS = know how to find the PSAP if it doesn=E2=80=99t know the location? Is = this for those one-PSAP-for-the-whole-country cases? Understanding that = will help make sense of this recommendation, because on its face it = seems to call into question the third-party authorization model in RFC = 6155. That is, if a third party is appropriately authorized to make a = request on behalf of a Target, why should that party not be trusted with = a routing URI in the absence of a location = URI?

[AJW] Perhaps this could be worded better. Section = 5.2 of RFC 5985 says =E2=80=9CA successful response to a location = request MUST contain a PIDF-LO and/or Location URI(s)=E2=80=9D. So what = the sentence is really trying to say is that the LIS shouldn=E2=80=99t = return a location value and the routing information, it should only a = location URI when the routing information is = returned.

Not following your last = sentence above still, could you re-phrase?

[AJW] For a LIS to return a HELD = locationResponse the response must contain a location, that = location may be a location URI or a location value. A HELD = locationResponse cannot ever contain just a routing response. They main = reason for returning a location to a third-party that requested the = information using an identity extension was that the party wanted to = route a message somewhere, and that they would first query a LIS and = then use that location to query a LoST server. Since the extension = described in this document eliminates the need for the LoST interaction, = there is also little need to return a location value, a locationURI will = do. Does that help? 

Ah, sorry, I was missing that this was about value = vs. URI as opposed to returning location at all. I would suggest making = a small addition to the text to make this clear:

This =
represents additional information about the Target,
   as a consequence it is recommended that this option only be used when
   the LIS returns a location URI, not a location =
value.

Thanks,
Alissa

= --Apple-Mail=_9191311B-895F-498C-B469-0B1A34662C99-- From nobody Wed Nov 18 15:49: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 221791B393E for ; Wed, 18 Nov 2015 15:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 GNR_SEkQl-yR for ; Wed, 18 Nov 2015 15:49:43 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3001B3938 for ; Wed, 18 Nov 2015 15:49:43 -0800 (PST) Received: by padhx2 with SMTP id hx2so59999505pad.1 for ; Wed, 18 Nov 2015 15:49:43 -0800 (PST) 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=Sw4gaXwKseuOyWacRyUiTEchNRNaNl+1hK5cwbaWnuc=; b=Y4iG8FKV2Q2QsQ9/8vrVoTa7Bi8OM7/9F6xX4nNG3pG7I92yl8gKOr0CqlEQ3HI9cb JH0M4ygg6WnE4bpEQWEC0zxnvUpGfYaoTnhC1Ljo0COJWgyULpuS3V1t6jMtBTR0rhGU dptXIk0dpWS/Iv7hsSiquSiVtvb3/SiHtQ0N/FCZJGTch3CriZSwPBkLiI+bgprUxcNH 3muspnuCC7QL7r+UHkoh7sJl6g7jwClna4mQ/IAsJSfKiqhHPO4Lx7VGQeLLNj02ZlmG OwD1xlZory3hAsUuej5eydKqkBjbuugJQ8uyi9bwulGH4XPdwY7jzEO5O9aXAD2JvB6Y Gbpw== X-Received: by 10.66.124.165 with SMTP id mj5mr5930876pab.97.1447890583451; Wed, 18 Nov 2015 15:49:43 -0800 (PST) Received: from [10.188.20.228] ([1.144.6.52]) by smtp.gmail.com with ESMTPSA id sx1sm6334167pbc.36.2015.11.18.15.49.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Nov 2015 15:49:42 -0800 (PST) References: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> <173BBCAB-F050-4BAA-B651-C7C1AF8CB92E@gmail.com> <4840B933-C7FF-4E5D-B939-0645985B1087@cooperw.in> Mime-Version: 1.0 (1.0) In-Reply-To: <4840B933-C7FF-4E5D-B939-0645985B1087@cooperw.in> Content-Type: multipart/alternative; boundary=Apple-Mail-4BB679F8-9C9E-4357-AA7A-BC7DB8958D7D Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Thu, 19 Nov 2015 10:49:35 +1100 To: Alissa Cooper Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 18 Nov 2015 23:49:46 -0000 --Apple-Mail-4BB679F8-9C9E-4357-AA7A-BC7DB8958D7D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Alissa Sent from my iPhone > On 19 Nov 2015, at 8:30 am, Alissa Cooper wrote: >=20 > Hi James, >=20 >>> On Nov 16, 2015, at 11:29 AM, James Winterbottom wrote: >>>=20 >>>>=20 >>>>>=20 >>>>> I will note that I am not in the camp that believes that references to= terminology documents need to be normative. That seems particularly true he= re given that the terms being defined are all entities and realistically the= label an entity has on it does not affect the entity=E2=80=99s ability to p= roperly implement the HELD protocol. But I will not stand in the way of the W= G=E2=80=99s decision to call out the downrefs in IETF LC and add them to the= downref registry if that=E2=80=99s what you want to do. >>>>=20 >>>> [AJW] I don=E2=80=99t mind either way, I was really just following what= seems to be convention. >>>=20 >>> Ok, the shepherd write-up says one of the authors wants these to be norm= ative. >>=20 >> [AJW] That was probably me and I was only keeping with convention if that= isn=E2=80=99t really a convention then I can move but if no one has a stron= g opinion either way then I will just leave them. >=20 > I think it would be preferable for them to be informative. >=20 >>=20 >>>=20 >>>>> =E2=80=94 SNIP >>>>>=20 >>>>> There seems to be a bit lurking here that I=E2=80=99d like to understa= nd: >>>>>=20 >>>>> This represents additional information about the Target, >>>>> as a consequence it is recommended that this option only be used wh= en >>>>> a location URI is returned by the LIS. >>>>>=20 >>>>> What is the valid use case for a LIS to send a routing URI but no loca= tion URI? That is, how does the LIS know how to find the PSAP if it doesn=E2= =80=99t know the location? Is this for those one-PSAP-for-the-whole-country c= ases? Understanding that will help make sense of this recommendation, becaus= e on its face it seems to call into question the third-party authorization m= odel in RFC 6155. That is, if a third party is appropriately authorized to m= ake a request on behalf of a Target, why should that party not be trusted wi= th a routing URI in the absence of a location URI? >>>>=20 >>>> [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 says= =E2=80=9CA successful response to a location request MUST contain a PIDF-LO= and/or Location URI(s)=E2=80=9D. So what the sentence is really trying to s= ay is that the LIS shouldn=E2=80=99t return a location value and the routing= information, it should only a location URI when the routing information is r= eturned. >>>=20 >>> Not following your last sentence above still, could you re-phrase? >>=20 >> [AJW] For a LIS to return a HELD locationResponse the response must conta= in a location, that location may be a location URI or a location value. A HE= LD locationResponse cannot ever contain just a routing response. They main r= eason for returning a location to a third-party that requested the informati= on using an identity extension was that the party wanted to route a message s= omewhere, and that they would first query a LIS and then use that location t= o query a LoST server. Since the extension described in this document elimin= ates the need for the LoST interaction, there is also little need to return a= location value, a locationURI will do. Does that help?=20 >=20 > Ah, sorry, I was missing that this was about value vs. URI as opposed to r= eturning location at all. I would suggest making a small addition to the tex= t to make this clear: >=20 > This represents additional information about the Target, > as a consequence it is recommended that this option only be used when > the LIS returns a location URI, not a location value. >=20 > Thanks, > Alissa >=20 --Apple-Mail-4BB679F8-9C9E-4357-AA7A-BC7DB8958D7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Alissa

Sent from my iPho= ne

On 19 Nov 2015, at 8:30 am, Alissa Cooper <alissa@cooperw.in> wrote:

Hi James,

On Nov 16, 2015, at 11:29 A= M, James Winterbottom <a.james.winterbottom@gmail.com> wrote:



I will note that I am not in the camp that believes that references= to terminology documents need to be normative. That seems particularly true= here given that the terms being defined are all entities and realistically t= he label an entity has on it does not affect the entity=E2=80=99s ability to= properly implement the HELD protocol. But I will not stand in the way of th= e WG=E2=80=99s decision to call out the downrefs in IETF LC and add them to t= he downref registry if that=E2=80=99s what you want to do.
=

[AJW] I don=E2=80=99t mind e= ither way, I was really just following what seems to be convention.

Ok, the shepherd write-up says one of the authors wa= nts these to be normative.
[AJW] That was probably me and I was only keeping with convention if t= hat isn=E2=80=99t really a convention then I can move but if no one has a st= rong opinion either way then I will just leave them.
<= /div>

I think it woul= d be preferable for them to be informative.



=E2=80=94 SNIP

= There seems to be a bit lurking here that I=E2=80=99d like to understand:

This represents additional information abo=
ut the Target,
   as a consequence it is recommended that this option only be used when
   a location URI is returned by the LIS.

What is the valid use case for a LIS to send a= routing URI but no location URI? That is, how does the LIS know how to find= the PSAP if it doesn=E2=80=99t know the location? Is this for those one-PSA= P-for-the-whole-country cases? Understanding that will help make sense of th= is recommendation, because on its face it seems to call into question the th= ird-party authorization model in RFC 6155. That is, if a third party is appr= opriately authorized to make a request on behalf of a Target, why should tha= t party not be trusted with a routing URI in the absence of a location URI?<= /div>

[AJW] Perha= ps this could be worded better. Section 5.2 of RFC 5985 says =E2=80=9CA= successful response to a location request MUST contain a PIDF-LO and/or Loc= ation URI(s)=E2=80=9D. So what the sentence is really trying to say is that t= he LIS shouldn=E2=80=99t return a location value and the routing information= , it should only a location URI when the routing information is returned.

Not following your last sentence above still, c= ould you re-phrase?

<= /div>
[AJW] = For a LIS to return a HELD locationResponse the response must contain a= location, that location may be a location URI or a location value. A HELD l= ocationResponse cannot ever contain just a routing response. They main reaso= n for returning a location to a third-party that requested the information u= sing an identity extension was that the party wanted to route a message some= where, and that they would first query a LIS and then use that location to q= uery a LoST server. Since the extension described in this document eliminate= s the need for the LoST interaction, there is also little need to return a l= ocation value, a locationURI will do. Does that help? 

Ah, sorry, I was missing that t= his was about value vs. URI as opposed to returning location at all. I would= suggest making a small addition to the text to make this clear:
<= br class=3D"">
This represents additional information abou=
t the Target,
   as a consequence it is recommended that this option only be used when
   the LIS returns a location URI, not a location value.
Thanks,
Alissa

= --Apple-Mail-4BB679F8-9C9E-4357-AA7A-BC7DB8958D7D-- From nobody Fri Nov 20 09:32: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 893D21B39E1 for ; Fri, 20 Nov 2015 09:32:23 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 F88uP2ogJXJO for ; Fri, 20 Nov 2015 09:32:21 -0800 (PST) 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 3C6A51B39DD for ; Fri, 20 Nov 2015 09:32:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 75EDA209F1 for ; Fri, 20 Nov 2015 12:32:20 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 20 Nov 2015 12:32:20 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=w6Rdr DjAMsCob6kylNTPaN5RpWo=; b=dLjnxZUS5zrInJpo6NTK7O3hkWPNdJl5U00Ad hPiCzDUPIN1PJ4ZHQeKAEb32fC2hIehKe4ikg768mcWZO+CoVErpG9tvWeVvaZyi NhD1kfM9g/2Qkw2JRoTLLpthWfqZflU/W9DksmpeEumZGQRYqW3bK8d6iw1hCkQr 9UZg7M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=w6RdrDjAMsCob6kylNTPaN5RpWo=; b=CDqNN 2wvGpr9h9k5zm9LTwKx3he18VY3tNj7wnd//IRYiwbky7PZXfXRFalRab7BPLSl4 XwZnos/odygfl/oTcj4J8J5ePy3m45EDf8PFjD9MeKQbSR0CWbJ5W/Nv8s1tRurX 7ZV69Wgp6FpGQvYYTJw3wJ0VCypvtoFCRggeow= X-Sasl-enc: z9vBpXWnROnpWKS6Hd1oXwriigxIAU8KB+RONOMbkHOs 1448040739 Received: from dhcp-171-68-20-162.cisco.com (dhcp-171-68-20-162.cisco.com [171.68.20.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 86E5968015F; Fri, 20 Nov 2015 12:32:19 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_489DA846-95AD-4D8C-942A-44C93B0A2E2B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Fri, 20 Nov 2015 09:32:17 -0800 Message-Id: <6E77EB81-5195-4749-A196-CCED1EE4A604@cooperw.in> References: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> <173BBCAB-F050-4BAA-B651-C7C1AF8CB92E@gmail.com> <4840B933-C7FF-4E5D-B939-0645985B1087@cooperw.in> To: James Winterbottom X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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, 20 Nov 2015 17:32:23 -0000 --Apple-Mail=_489DA846-95AD-4D8C-942A-44C93B0A2E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will initiatie IETF LC when the rev gets posted. Thanks, Alissa > On Nov 18, 2015, at 3:49 PM, James Winterbottom = wrote: >=20 > Thanks Alissa >=20 > Sent from my iPhone >=20 > On 19 Nov 2015, at 8:30 am, Alissa Cooper > wrote: >=20 >> Hi James, >>=20 >>> On Nov 16, 2015, at 11:29 AM, James Winterbottom = > = wrote: >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I will note that I am not in the camp that believes that = references to terminology documents need to be normative. That seems = particularly true here given that the terms being defined are all = entities and realistically the label an entity has on it does not affect = the entity=E2=80=99s ability to properly implement the HELD protocol. = But I will not stand in the way of the WG=E2=80=99s decision to call out = the downrefs in IETF LC and add them to the downref registry if that=E2=80= =99s what you want to do. >>>>>=20 >>>>> [AJW] I don=E2=80=99t mind either way, I was really just following = what seems to be convention. >>>>=20 >>>> Ok, the shepherd write-up says one of the authors wants these to be = normative. >>>=20 >>> [AJW] That was probably me and I was only keeping with convention if = that isn=E2=80=99t really a convention then I can move but if no one has = a strong opinion either way then I will just leave them. >>=20 >> I think it would be preferable for them to be informative. >>=20 >>>=20 >>>>=20 >>>>>> =E2=80=94 SNIP >>>>>>=20 >>>>>> There seems to be a bit lurking here that I=E2=80=99d like to = understand: >>>>>>=20 >>>>>> This represents additional information about the Target, >>>>>> as a consequence it is recommended that this option only be = used when >>>>>> a location URI is returned by the LIS. >>>>>>=20 >>>>>> What is the valid use case for a LIS to send a routing URI but no = location URI? That is, how does the LIS know how to find the PSAP if it = doesn=E2=80=99t know the location? Is this for those = one-PSAP-for-the-whole-country cases? Understanding that will help make = sense of this recommendation, because on its face it seems to call into = question the third-party authorization model in RFC 6155. That is, if a = third party is appropriately authorized to make a request on behalf of a = Target, why should that party not be trusted with a routing URI in the = absence of a location URI? >>>>>=20 >>>>> [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 = says =E2=80=9CA successful response to a location request MUST contain a = PIDF-LO and/or Location URI(s)=E2=80=9D. So what the sentence is really = trying to say is that the LIS shouldn=E2=80=99t return a location value = and the routing information, it should only a location URI when the = routing information is returned. >>>>=20 >>>> Not following your last sentence above still, could you re-phrase? >>>=20 >>> [AJW] For a LIS to return a HELD locationResponse the response must = contain a location, that location may be a location URI or a location = value. A HELD locationResponse cannot ever contain just a routing = response. They main reason for returning a location to a third-party = that requested the information using an identity extension was that the = party wanted to route a message somewhere, and that they would first = query a LIS and then use that location to query a LoST server. Since the = extension described in this document eliminates the need for the LoST = interaction, there is also little need to return a location value, a = locationURI will do. Does that help?=20 >>=20 >> Ah, sorry, I was missing that this was about value vs. URI as opposed = to returning location at all. I would suggest making a small addition to = the text to make this clear: >>=20 >> This represents additional information about the Target, >> as a consequence it is recommended that this option only be used = when >> the LIS returns a location URI, not a location value. >>=20 >> Thanks, >> Alissa >>=20 --Apple-Mail=_489DA846-95AD-4D8C-942A-44C93B0A2E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I will initiatie IETF LC when the rev gets = posted.

Thanks,
Alissa

On = Nov 18, 2015, at 3:49 PM, James Winterbottom <a.james.winterbottom@gmail.com> wrote:

Thanks Alissa

Sent from my iPhone

On 19 Nov 2015, at 8:30 am, Alissa Cooper <alissa@cooperw.in> = wrote:

Hi = James,

On Nov 16, 2015, at 11:29 AM, James = Winterbottom <a.james.winterbottom@gmail.com> wrote:



I will note that I am not in the camp = that believes that references to terminology documents need to be = normative. That seems particularly true here given that the terms being = defined are all entities and realistically the label an entity has on it = does not affect the entity=E2=80=99s ability to properly implement the = HELD protocol. But I will not stand in the way of the WG=E2=80=99s = decision to call out the downrefs in IETF LC and add them to the downref = registry if that=E2=80=99s what you want to = do.

[AJW] I don=E2=80=99t mind either way, I was really = just following what seems to be = convention.

Ok, the shepherd = write-up says one of the authors wants these to be = normative.

[AJW] That was probably me and I was only keeping with = convention if that isn=E2=80=99t really a convention then I can move but = if no one has a strong opinion either way then I will just leave = them.

I think it would be = preferable for them to be informative.



=E2=80=94 = SNIP

There seems to be a bit lurking here that I=E2=80=99d like to = understand:

This = represents additional information about the Target, as a consequence it is recommended that this option only be used when a location URI is returned by the LIS.

What is the valid use case for a = LIS to send a routing URI but no location URI? That is, how does the LIS = know how to find the PSAP if it doesn=E2=80=99t know the location? Is = this for those one-PSAP-for-the-whole-country cases? Understanding that = will help make sense of this recommendation, because on its face it = seems to call into question the third-party authorization model in RFC = 6155. That is, if a third party is appropriately authorized to make a = request on behalf of a Target, why should that party not be trusted with = a routing URI in the absence of a location = URI?

[AJW] Perhaps this could be worded better. Section = 5.2 of RFC 5985 says =E2=80=9CA successful response to a location = request MUST contain a PIDF-LO and/or Location URI(s)=E2=80=9D. So what = the sentence is really trying to say is that the LIS shouldn=E2=80=99t = return a location value and the routing information, it should only a = location URI when the routing information is = returned.

Not following your last = sentence above still, could you re-phrase?

[AJW] For a LIS to return a HELD = locationResponse the response must contain a location, that = location may be a location URI or a location value. A HELD = locationResponse cannot ever contain just a routing response. They main = reason for returning a location to a third-party that requested the = information using an identity extension was that the party wanted to = route a message somewhere, and that they would first query a LIS and = then use that location to query a LoST server. Since the extension = described in this document eliminates the need for the LoST interaction, = there is also little need to return a location value, a locationURI will = do. Does that help? 

Ah, sorry, I was missing = that this was about value vs. URI as opposed to returning location at = all. I would suggest making a small addition to the text to make this = clear:

This =
represents additional information about the Target,
   as a consequence it is recommended that this option only be used when
   the LIS returns a location URI, not a location =
value.

Thanks,
Alissa

<= br class=3D"">= --Apple-Mail=_489DA846-95AD-4D8C-942A-44C93B0A2E2B-- From nobody Sat Nov 21 00:37: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 6F04A1B40F7 for ; Sat, 21 Nov 2015 00:37:01 -0800 (PST) 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 mkXgrEq-OGeZ for ; Sat, 21 Nov 2015 00:36:54 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 C7A681B40F5 for ; Sat, 21 Nov 2015 00:36:54 -0800 (PST) Received: by pacdm15 with SMTP id dm15so140046640pac.3 for ; Sat, 21 Nov 2015 00:36:54 -0800 (PST) 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=HTP+q1VVUQv7ofaGmz9gxUKbrAHHY9KMyN2GeX+j4EA=; b=eEwuYlvBH8UYoxKqredxqmN8b0moygodWqQzMoqi4JZ1rtv076UjQHBfxv3//nm9m5 MaK3dqiGp0BX05byD5PWQ0lKSCnUTPDQi23ascVuzIGNwK/ck+LnKOk2q/qDUoWsphEZ c7KkiwhVYc5JWPXZG+ThCwoTk4nuEZw4Xgf54L9V2rYUGY2WZt+GOcxUsskmR2msxHvF e0VkcFtz2OCOGBm0Q1a+l0/+UI2F0c6DzPrJegGTqfQY6gxkvDMpE2RsXStB4tGHbMou sLVuFm/NJwvANPes6uRk4hU5Ak4vhP8bvjhbxnceR+EHbj3ARAHMP624oyTnywg73kpW lFyg== X-Received: by 10.68.91.162 with SMTP id cf2mr24435695pbb.34.1448095014485; Sat, 21 Nov 2015 00:36:54 -0800 (PST) Received: from [192.168.1.100] ([1.129.82.254]) by smtp.gmail.com with ESMTPSA id p6sm2202726pfi.20.2015.11.21.00.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 00:36:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: <6E77EB81-5195-4749-A196-CCED1EE4A604@cooperw.in> Date: Sat, 21 Nov 2015 19:36:50 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <52FDD830-AC87-40C4-AD51-3F0CD6AC8131@gmail.com> References: <0D5FCE62-7970-4AC1-90BF-D011D2C6B955@gmail.com> <173BBCAB-F050-4BAA-B651-C7C1AF8CB92E@gmail.com> <4840B933-C7FF-4E5D-B939-0645985B1087@cooperw.in> <6E77EB81-5195-4749-A196-CCED1EE4A604@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03 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: Sat, 21 Nov 2015 08:37:01 -0000 Hi Alissa, I think the only comment of yours that I didn=E2=80=99t comment on was = the one surrounding the LIS understanding the new option but not being = able to provide routing information. When we were originally writing the document we came to this scenario = and found three options: 1) Just return location and ignore the routing request (this is = what the document currently says) 2) Pass something back, anything 3) Pass something back and say, but indicate it may not be the = droid they are looking for (LoST allows for this approach with the = defaultMappingReturned warning). The original reason for going with 1 was simplicity. If you requested = routing, got nothing you would try LoST. Similarly if you requested = routing and got a response saying, =E2=80=9Ceh, not sure, try this = one=E2=80=9D, then the requestor would probably try LoST anyway. I guess = that with 3, at least the requestor has something. If there is general agreement, then I will add an attribute to the = routingInformation element that can indicate if it is default or not, = and require the LIS to always respond with something if it understands = the extension. Cheers James >>>=20 >=20