From wwwrun@rfc-editor.org Wed Jan 4 14:56:38 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8711E80B6; Wed, 4 Jan 2012 14:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9FHiA4J8DPt; Wed, 4 Jan 2012 14:56:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6851E11E80C5; Wed, 4 Jan 2012 14:56:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E123972E004; Wed, 4 Jan 2012 14:54:23 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120104225423.E123972E004@rfc-editor.org> Date: Wed, 4 Jan 2012 14:54:23 -0800 (PST) Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 6444 on Location Hiding: Problem Statement and Requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:56:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6444 Title: Location Hiding: Problem Statement and Requirements Author: H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett Status: Informational Stream: IETF Date: January 2012 Mailbox: hgs+ecrit@cs.columbia.edu, L.Liess@telekom.de, Hannes.Tschofenig@gmx.net, barbara.stark@att.com, andres.kytt@skype.net Pages: 9 Characters: 18495 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-location-hiding-req-04.txt URL: http://www.rfc-editor.org/rfc/rfc6444.txt The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Wed Jan 11 01:28:46 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035A921F870A; Wed, 11 Jan 2012 01:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 336X2AQEdX+e; Wed, 11 Jan 2012 01:28:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74821F86A9; Wed, 11 Jan 2012 01:28:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111092844.10069.96756.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 01:28:44 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 09:28:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Pro= tocol based Service Boundaries and Mapping Elements Author(s) : Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-lost-sync-14.txt Pages : 29 Date : 2012-01-11 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-14.txt From hannes.tschofenig@gmx.net Wed Jan 11 01:30:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495C121F879F for ; Wed, 11 Jan 2012 01:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNLTQlr1LDFw for ; Wed, 11 Jan 2012 01:30:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A89DE21F8783 for ; Wed, 11 Jan 2012 01:30:08 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2012 09:30:06 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp013) with SMTP; 11 Jan 2012 10:30:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180rmlUlW00omKbRon9DqzorC5H4IvWFLVm8QTCIR dCdg2C/mOhtSKk Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Wed, 11 Jan 2012 11:30:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <831E75A2-96FD-44AF-84F2-206D7D0040A5@gmx.net> References: To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Org , ietf-types@ietf.org Subject: Re: [Ecrit] [ietf-types] Request for review of Media Type 'application/lostsync+xml' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 09:30:10 -0000 Hi Bjoern,=20 thank you for your review. I have updated the draft based on your = comments.=20 Here is the new draft: = http://www.ietf.org/id/draft-ietf-ecrit-lost-sync-14.txt Ciao Hannes On Sep 18, 2011, at 10:29 PM, Bjoern Hoehrmann wrote: > * Hannes Tschofenig wrote: >> MIME media type name: application >>=20 >>=20 >> MIME subtype name: lostsync+xml >=20 > This is based on an outdated version of the template, the current one = is > in RFC 4288; some of the fields are named and organized differently. >=20 >> Optional parameters: charset >>=20 >> Indicates the character encoding of enclosed XML. >>=20 >>=20 >> Encoding considerations: Uses XML, which can employ 8-bit >> characters, depending on the character encoding used. See RFC >> 3023 [RFC3023], Section 3.2. >=20 > RFC 3023 should be referenced as specified in RFC 3023 section 7.1. >=20 >> Additional information: >>=20 >> Magic Number: None >>=20 >>=20 >> File Extension: .lostsyncxml >>=20 >>=20 >> Macintosh file type code: 'TEXT' >>=20 >>=20 >> Personal and email address for further information: Hannes >> Tschofenig, Hannes.Tschofenig@nsn.com >=20 > (The rendering "Name " is more often used for this.) > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 From internet-drafts@ietf.org Wed Jan 11 10:16:11 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C733B11E80B2; Wed, 11 Jan 2012 10:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeUNWL3bKCPg; Wed, 11 Jan 2012 10:16:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7411E80DC; Wed, 11 Jan 2012 10:16:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111181610.21629.44919.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 10:16:10 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:16:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Pro= tocol based Service Boundaries and Mapping Elements Author(s) : Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-lost-sync-15.txt Pages : 29 Date : 2012-01-11 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-15.txt From hannes.tschofenig@gmx.net Wed Jan 11 11:20:45 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F175421F85F7 for ; Wed, 11 Jan 2012 11:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpBS2DaFL9DQ for ; Wed, 11 Jan 2012 11:20:44 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0C94221F85DA for ; Wed, 11 Jan 2012 11:20:43 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2012 19:20:39 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 11 Jan 2012 20:20:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+AZTle0mWAHY+yyvbtAkS61eoKHEpDiBgRzenyjr HRJlmbTlsIRhXQ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 21:20:37 +0200 Message-Id: <1C42DF3A-B965-48E4-8E8B-BBF101486EF0@gmx.net> To: "Julian F. F. Reschke" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Org Subject: [Ecrit] draft-ietf-ecrit-lost-sync-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:20:45 -0000 Hey Julian,=20 as discussed in our call today I have updated the document. I submitted = version -15 and put the ECRIT WG on CC to let everyone know about the = proposed changes.=20 As a background for others on the list, Julian reviewed the document a = while ago and I made changes but Robert noticed that I had missed a few = issues. Here is his review:=20 http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01798.html There are two interesting issues:=20 1) HTTP POST is used by LoST Sync When Henning and I worked on the LoST Sync specification we just = followed the design of many of our other HTTP protocol designs (like = LoST, HELD, etc.).=20 Julian had some concerns that the tunneling of XML over HTTP could lead = to undesired behavior when the protocol is run over proxies (rather than = in an isolated environment) if we do not precisely specify what these = devices do with the LoST Sync protocol. There are various ways to deal = with that problem and, for example, using a different port number (as = suggested in BCP 56) is one option. Another option is to always use TLS.=20= I have now changed the draft in such a way that it mandates the usage of = TLS. I believe that this is quite appropriate for a protocol that is so = security sensitive.=20 I believe that this addresses the concerns. 2) LoST Sync Relax NG Schema Registration RFC 3688 defines the "The IETF XML Registry" and the abstract says: This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. Note that the document does not talk about Relax NG schemas. We have, = for example, with LoST and other specifications uses this XML registry = to register our Relax NG schemas. That's not quite what the registry was = designed for.=20 Julian has a token now to investigate this issue.=20 Ciao Hannes From hannes.tschofenig@gmx.net Fri Jan 13 01:17:41 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0306721F85B9 for ; Fri, 13 Jan 2012 01:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwmwqLklEGuz for ; Fri, 13 Jan 2012 01:17:40 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A554421F85C4 for ; Fri, 13 Jan 2012 01:17:39 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 09:17:30 -0000 Received: from unknown (EHLO [10.255.128.92]) [192.100.123.77] by mail.gmx.net (mp028) with SMTP; 13 Jan 2012 10:17:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX190ew0HEWZ0t2g0hWnQB2bZXxaP3u+vcMNZGcO8f9 SsMA3fncun3A7m Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <4E7B207E.6020903@it.aoyama.ac.jp> Date: Fri, 13 Jan 2012 11:17:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> References: <4E7B207E.6020903@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org, "apps-review@ietf.org" , Henning Schulzrinne Subject: Re: [Ecrit] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:17:41 -0000 Hi Martin,=20 thanks for your review.=20 On Sep 22, 2011, at 2:48 PM, Martin J. D=FCrst wrote: > I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please see = http://www.apps.ietf.org/content/applications-area-review-team). >=20 > Document: draft-ietf-ecrit-lost-sync-12 > Reviewer: Martin D=FCrst > Review Date: September 22, 2011 >=20 > Review Summary: >=20 > This draft should be clarified in various places before being = published. > There is also a deeper design issue that I will mention upfront and = that hopefully will be taken to heart for future work. >=20 > Document Summary: >=20 > The document defines a 'protocol' (actually a number of XML messages, = under a common Media type, carried over http(s)) for synchronizing = Location-to-Service Translation (LoST) service boundaries and mapping = elements. >=20 >=20 > Design Issue: >=20 > It seems still in fashion to define a 'protocol' independent of = underlying transport. This is preferable if there is a truely expected = need for multiple transports, and if there is a large abstraction gap = between the newly defined 'protocol' and the potential underlying = transport mechanism. However, in the case at hand, only one transport = (HTTP, including its secured equivalent HTTPS) is used, and the = abstraction gap is extremely low. >=20 > Once one has understood REST, it's very easy to see a set of mappings = as a resource, a as a simple HTTP GET and a = as a PUT. A with = element would require some thought, although there = are several possible solutions. >=20 >=20 I certainly agree with you we could have designed the protocol = differently. A design based on REST would have been one possible option. = I don't think it would have made any difference to the result but it is = certainly more fashionable these days.=20 > Major Issues (necessary clarifications): >=20 > Independence of LoST: The Introduction says: > In any case, this document can also be > used without the LoST protocol even though the format of the > element is re-used from the LoST specification. > What does "can be used without the LoST protocol" mean? If it said = something like "this specification is independent of the LoST protocol = specification except in that it reuses the element (and some = error elements) from that specification", that would be easier to = understand. Good question.=20 What I wanted to express in this rather complicated way is the = following: There is the LoST protocol, which the group had developed a few years = ago. It runs between a LoST client and a LoST server.=20 Then, there is an architecture document that has to be understood in the = context of the IETF emergency services architecture. This architecture = document in a nutshell says: Here is an architecture similar to DNS. Use = LoST as a protocol between the nodes and a synchronization protocol = between the top-level servers. This document is this synchronization = protocol.=20 The synchronization protocol is not LoST but a new protocol. There is, = however, a component (namely these mappings) that is defined in LoST = that can (and is) reused in this protocol. For a definition:=20 mapping: A mapping is a short-hand for 'mapping from a location object to either another mapping server or the desired service URLs'. Any idea how I could phrase this a bit better to get my message across.=20= (One option is obviously to avoid mentioning the fact that the mapping = element is re-used from LoST; an implementer will figure it out anyway.) >=20 > Namespaces: It is overkill to define new namespaces for each spec. = It's a well-known secret in the XML community that it's easily possible = to add a number of new elements to an existing namespace. This would be = very appropriate in this case, because the number of reused elements and = attributes is quite large, and the number of new elements is low. This = would simplify most of the examples. I guess you refer to the namespace registration in the IANA = consideration section, namely urn:ietf:params:xml:ns:lostsync1 In the RAI area we have (to my knowledge) always created new namespaces = for new schemas. But I am pleased to hear that this is not needed.=20 Could you explain what we should be doing instead?=20 >=20 > 4.2 Behavior of the LoST Sync Destination: This needs various = clarifications. >=20 > The first paragraph uses 'replace', the next one after the conditions = uses 'update'. Is this the same? Then use the same word. Also, it says: > If the received mapping M' does not update any existing mapping M > then it MUST be added to the local cache as an independent mapping. > If I apply this to a mapping with conditions 1. and 2. being true, but = condition 3. being false, then this means that older mappings of the = same source and sourceID MUST be added to the local cache. Surely this = must be wrong. Good catch. I updated the text. > Also, it says that an emply element means that a = "corresponding" mapping has to be determined based on source, sourceID, = and lastUpdated. The "lastUpdated" here is ambiguous and could lead to = differing implementations. Does lastUpdated have to match with equality? = Does it have to be (the same or?) newer than the one being cached? I have changed that sentence so that only source and sourceID have to = match. It may indeed the possible that someone understands the sentence = in a way that the indicated mapping is removed from the cache but then = the previously received one is now active. That was, however, not my = intention to implement a sort of "rollback".=20 >=20 > Also, all the examples (Figs. 10/12) also contain an 'expires' = attribute. Is that necessary? Does it have to be the same as the = lastUpdated attribute? Please specify. A mapping element must contain an expires attributes and it contains the = absolute time at which the mapping becomes invalid. It has nothing to do with the lastUpdated attribute. >=20 > Further, we have: "The element MAY carry a = element": What kind of message element? If this is from RFC 5222, then = please say so. In Fig. 12, there is a 'message' attribute, is that what = is meant? If yes, then please fix the prose (element-> attribute). If = no, then point out the difference. I added a note that this is a message that provides information for = debugging purposes. This element is not from RFC 5222.=20 The 'message' is an attribute. Corrected.=20 =20 >=20 > Fig. 12: This uses an attribute value for human-readable text. This is = considered bad practice, because it forecloses the use of further markup = in case this is considered necessary (can often become the case for = internationalization reasons). While this is human readable text I now state that it is only used for = debugging purposes. What would you use instead?=20 >=20 > in Transport, it says: > The HTTP request MUST use the > Cache-Control response directive "no-cache" to (*) HTTP-level = caching > At (*), a verb such as 'suppress' or 'avoid' or some such seems to be = missing. Please clarify. I changed that section based on Julian Reschke's review.=20 >=20 > In Operational Considerations, the use of XML Digital Signatures is = mentioned. With just the text that is there, it seems impossible to = guess what actually should be done. For example, how is authorization = verified? Also, why only sign the first time? Wouldn't it be easier/more = straightforward to just sign every time? > This looks like either an afterthought (in which case the MUST isn't = appropriate, because it doesn't have anything to do with the protocol = per se) or some missing context (e.g. from LoST itself) in which case = there should be some reference or so to clarify the context. >=20 I added text to clarify the issues you raised.=20 > Security Considerations: In particular the last two sentences read = like security considerations not for synchronization, but for the = underlying PSAP data and LoST itself. Probably similar considerations = have already been given in RFC 5222 or elsewhere, in which case they = should be included by reference. >=20 Changed the wording.=20 > 9.1: "8-bit characters": This term is highly inappropriate, because = it's actually 8-bit bytes, not characters. Please just point to RFC = 3023. >=20 Changed it.=20 > 9.1, security considerations: Replace the current text with a pointer = to the security considerations in the spec (text similar to the = "Published Specification" item) >=20 Done.=20 > p. 25: The namespace document has the namespace as > urn:ietf:params:xml:ns:lost1:sync, while in the examples it is > urn:ietf:params:xml:ns:lostsync1. Please fix and check carefully. >=20 Thanks.=20 >=20 > Minor Issues (mainly editorial): >=20 > Abstract and Introduction: add a comma at end of clause > The main data structure, the element, used for > encapsulating information about service boundaries*,* is defined... >=20 Done.=20 > p.4: "we call them Austria and Finland": "we call them" makes sense = with fictive country names, but in this case "for example Austria and = Finland" makes more sense. OK.=20 >=20 > p. 8: "Node B issuing the first request and plays" > -> "Node B is issuing the first request and plays" Ok. >=20 > p. 12: There should be a short explanation of the = element in the prose. >=20 Added text.=20 > 4.3: The first two example given with bullet points add a linebreak = after the first attribute, it would be easier if they also added a = linebreak after the second one. >=20 Done.=20 > 6. Relax: Please add some introductory text. >=20 What text are you thinking about? > 7. Operational Considerations: > When B obtained this new mapping it would find out that it has to > distribute it to its peer C. C would also want to distribute the > mapping to B (and vice versa). > Either remove the 'vice versa' or the sentence before it. Ok >=20 > "If the originally mapping" -> > "If the original mapping" >=20 Thanks.=20 > Security Considerations: Split the long paragraph into shorter pieces = for easier readability. >=20 OK.=20 > 9.1, Additional Information: Please add "None" >=20 Done.=20 > 10. In earlier times, the shepherd was called the PROTO shepherd. But = these days, PROTO isn't used anymore as far as I know. Please remove. Done.=20 Ciao Hannes >=20 >=20 > Regards, Martin. From internet-drafts@ietf.org Fri Jan 13 01:25:39 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803921F84A1; Fri, 13 Jan 2012 01:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL0nwa+UyLfm; Fri, 13 Jan 2012 01:25:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6BF21F8449; Fri, 13 Jan 2012 01:25:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120113092539.1471.33362.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 01:25:39 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:25:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Pro= tocol based Service Boundaries and Mapping Elements Author(s) : Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-lost-sync-16.txt Pages : 29 Date : 2012-01-13 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-16.txt From hannes.tschofenig@gmx.net Fri Jan 13 01:33:32 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B347F21F84F5 for ; Fri, 13 Jan 2012 01:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMgSWMQr15lG for ; Fri, 13 Jan 2012 01:33:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CE90C21F851A for ; Fri, 13 Jan 2012 01:33:31 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 09:33:30 -0000 Received: from unknown (EHLO [10.255.128.92]) [192.100.123.77] by mail.gmx.net (mp069) with SMTP; 13 Jan 2012 10:33:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/4hmQB0Qz4jkNLtEWuBqhW3Rtv7AdJ0tITvCgTrt 2O6d/rMyB98O0t From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2012 11:33:26 +0200 Message-Id: <2C770BAA-04A9-440C-90DB-367BC448F706@gmx.net> To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Subject: [Ecrit] draft-ietf-ecrit-lost-sync-16 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:33:32 -0000 Based on Martin's review I have updated the LoST Sync draft.=20 Please find the most recent version here:=20 http://tools.ietf.org/html/draft-ietf-ecrit-lost-sync-16 Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-lost-sync-16 I will wait for Martin to take a look at the proposed changes to see = whether further refinements are needed.=20 Ciao Hannes From hannes.tschofenig@gmx.net Sun Jan 15 11:18:20 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9233621F8468 for ; Sun, 15 Jan 2012 11:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77E6D9BeuDR9 for ; Sun, 15 Jan 2012 11:18:20 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A824D21F8467 for ; Sun, 15 Jan 2012 11:18:19 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 19:11:37 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp021) with SMTP; 15 Jan 2012 20:11:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19tcLFZnFxtJAZi6+BjBgJdvuQYXosKwaL+Doip6n lRpIw7dkh0bn13 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4F12FA22.6040805@gmx.de> Date: Sun, 15 Jan 2012 21:11:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C42DF3A-B965-48E4-8E8B-BBF101486EF0@gmx.net> <4F12FA22.6040805@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Org Subject: Re: [Ecrit] draft-ietf-ecrit-lost-sync-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 19:18:20 -0000 Hi Julian,=20 On Jan 15, 2012, at 6:09 PM, Julian Reschke wrote: >> There are two interesting issues: >>=20 >> 1) HTTP POST is used by LoST Sync >>=20 >> When Henning and I worked on the LoST Sync specification we just = followed the design of many of our other HTTP protocol designs (like = LoST, HELD, etc.). >=20 > Yep. >=20 > The protocols mentioned above essentially use HTTP as a tunnel. I = would NOT recommend them as an example of protocol design unless you are = sure that you can control senders, receivers, and intermediates. Also = keep in mind that one of the advantages of using HTTP is that you can = reuse existing components (like libraries and server frameworks), in = which case using HTTP the wrong way can lead to later pain. But didn't we add directives that control the behavior of the HTTP = protocol to, for example, control caching?=20 Isn't this enough or the wrong approach?=20 Ciao Hannes