Advice

=09Pa= ges=09=09: 11

=09Date= =09=09: 2007-2-13

=09=

The pur= pose of this document is to define a new, straightforward

=A0=A0 Dynamic Delega= tion Discovery Service (DDDS) application to allow

= =A0=A0 mapping of domain nam= es to URIs for particular application services

=A0=A0 and protocols.=A0 Although defined as a new DDDS appl= ication, dubbed

=A0=A0 U-NAPTR, this is effectively an extension of the Straigh= tforward

=A0=A0= NAPTR (S-NAPTR) DDDS application.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-daigle-una= ptr-02.txt

To remove yourself from the I-D Announcement list, send a messag= e to=A0

i-d-announce-request@i= etf.org with the word unsubscribe in the body of=A0

the message.=A0

You can also = visit htt= ps://www1.ietf.org/mailman/listinfo/I-D-announce=A0

to change your subscrip= tion settings.

Internet-Drafts are also available by anonymous FTP. Login with = the=A0

username "anonymous" and a password of your e-mail address. After=A0

logging i= n, type "cd internet-drafts" and then=A0

"get draft-daigle-unaptr-02.txt".

A list of = Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html<= SPAN class=3D"Apple-converted-space">=A0

or = ftp://ftp.ietf.org/= ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a mes= sage to:

=09mailserv@ie= tf.org.

In the body type:

=09"FILE= /internet-drafts/draft-daigle-unaptr-02.txt".

=09

NOTE:=09The mail server at ietf.org can return the documen= t in

=09MIME-encoded form by using the "mpack" utility.=A0 To use this

=09fe= ature, insert the command "ENCODING mime" before the "FILE"

=09command.=A0 To decode the= response(s), you will need "munpack" or

=09a MIME-compliant= mail reader.=A0 Different M= IME-compliant mail readers

=09exhibit different behavior, es= pecially when dealing with

=09"multipart" MIME messages (i.e= . documents which have been split

=09up into multiple messag= es), so check your local documentation on

=09how to manipula= te these messages.

Below is the data which will enable a MIME compliant mail re= ader

implementation to automatically retrieve the A= SCII version of the

Internet-Draft.

Content-Type: text/plain

Content-ID: <2007-2-13140826.I-D@ietf.org= >

= I-D-Announce mailing list

I-D-Announce@ietf.org

https://www1.ietf.o= rg/mailman/listinfo/i-d-announce

= --=_zeke.ecotroph.net-32530-1171417980-0001-2-- --===============0491834897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0491834897==-- From ecrit-bounces@ietf.org Tue Feb 13 21:09:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH9aQ-00056M-0h; Tue, 13 Feb 2007 21:09:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH9aP-00056H-4E for ecrit@ietf.org; Tue, 13 Feb 2007 21:09:33 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH9aN-0007Mv-6K for ecrit@ietf.org; Tue, 13 Feb 2007 21:09:33 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HH9a6-0007Df-RG; Tue, 13 Feb 2007 20:09:15 -0600 From: "Brian Rosen" To: "'Jonathan Rosenberg'" Subject: RE: [Ecrit] comments on LoST Date: Tue, 13 Feb 2007 21:09:23 -0500 Message-ID: <02b301c74fdd$292c3c00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdPvkTMJzwpLfkOR2SRqjQgph2k1QAHjOiw In-Reply-To: <45D23B87.7050203@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, there are two ways to do this. One is to keep the data for both, a real polygon for the geo, and appropriate values in fields of the civic. The other way is to use geocoding to convert civic to geo and use the polygons in all cases. Conversion in this case is acceptable, both because you don't forward the converted value, and because the database used can be precisely the database used for other routing purposes. Which you use depends on what you have available. With respect to the emergency case, PSAPs dealing with geo pretty much have to have an accurate geocode database to be able to dispatch responders appropriately when location arrives as geo. Once you have the database, it's much easier and better to always use the polygon boundaries. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, February 13, 2007 5:28 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] comments on LoST > > So you are saying its not hard for a server to convert a boundary > definition that is in civic format to one in geodesic format? Seems near > impossible to me. The server would more or less have to havve all > boundary objects in both formats, I would think. > > -Jonathan R. > > Brian Rosen wrote: > > > Comment on the "Thirdly": I don't think it's a big problem to have both > > civic and geo boundaries. There are a couple of ways to do it, and most > > functions need to be able to handle geo and civic interchangeably. It's > > possible for one server to refer to another, but in practice, I don't > think > > that will be needed. > > > > Brian > > > > > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>Sent: Tuesday, February 13, 2007 11:18 AM > >>To: ECRIT > >>Subject: [Ecrit] comments on LoST > >> > >>Here are my comments on the latest version of LoST from SVN > >>(http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit- > >>lost-04.txt). > >> > >> > >>I have several high level comments. > >> > >>Firstly, the specification is somewhat confused about whether it is > >>specifying a data object (like a presence document), in which case the > >>semantics of the fields are critical, or whether it is specifying a > >>protocol, in which case state machines, transactions, timers, failures, > >>element behaviors, and so on, are relevant. I believe LoST is the latter > >>not the former, yet the spec is mostly written as if it was the former > >>and not the latter. > >> > >>Secondly, I think the binding to http and https is not well specified, > >>and many important details (minimum baseline mandatory requirements, > >>timer considerations, usage of security techniques, pipelining, etc.) > >>are not discussed at all. > >> > >>Thirdly, I have some concerns over the requirement for servers to > >>support both geodesic-2d and civic for all queries. IN particular, I > >>fear that it will be common for boundary objects to exist in only one > >>form or the other, and I don't see how conversion can easily be done > >>between the two. > >> > >>More specific comments below: > >> > >> > >> > >> > >>>This document describes an XML-based protocol for mapping service > >>> identifiers and geodetic or civic location information to service > >>> contact URIs. In particular, it can be used to determine the > >>> location-appropriate PSAP for emergency services. > >> > >>expand PSAP acronym > >> > >> > >>>This document describes a protocol for mapping a service identifier > >>> [10] and location information compatible with PIDF-LO [7], namely > >>> revised civic location information [11] and GML [13]) > >> > >>missing open paren > >> > >> > >> > >>>While the initial focus is on providing mapping > >>> functions for emergency services, it is likely that the protocol is > >>> applicable to any service URN. > >> > >>the first sentence mentions service identifiers but doesn't actually say > >>service URN. Suggest that you add in the first sentence: > >> > >>"..for mapping a service identifier (in the form of a service URN > [10]).." > >> > >> > >>>Example service URL schemes include sip [14], xmpp > >>> [15], and tel [16]. > >> > >>I'm gonna be a nit-picker and point out that these are actually URI and > >>not URL. That error occurs in many places in the document. > >> > >> > >>> For example, in the United States, > >>> the "2-1-1" and "3-1-1" service numbers follow a similar location- > to- > >>> service behavior as emergency services. > >> > >>might be good to mention what these are > >> > >> > >> > >>>This document names this protocol "LoST", for Location-to-Service > >>> Translation. LoST Satisfies the requirements [18] for mapping > >> > >>satisfies > >> > >>THe last paragraph in the introduction repeats most of which is said > >>already above. I'll note it does so more clearly than the rest of the > >>intro. I suggest moving it up towards the front of the introduction. > >> > >>Also, the introduction is missing an important point that is obvious for > >>us in this field but probably non-obvious for newbies. I'd suggesting > >>adding the following text in the intro: > >> > >>"Numerous techniques have been specified for the discovery of servers > >>for a particular service, including NAPTR records, SVRLOC and similar > >>protocols. However, there are an important class of services where the > >>specific service instance that is to be connected to depends on the > >>identity of the service and the location of the entity that needs to > >>reach it. An example of this is emergency telecommunications services, > >>where the service instance is a Public Safety Answering Point (PSAP) > >>that has jurisdiction over the location of the user making the call. > >>Here, the desired PSAP isn't necessarily the one that is topologically > >>or even line-of-sight closest to the caller; rather, it is the one that > >>serves the callers location based on geopolitical boundaries. For this > >>reason, the selected service instance is a function of location and the > >>desired service." > >> > >> > >> > >>Section 3 isn't really an overview of operation at all. It mainly > >>addresses the question of WHEN a user invokes LoST. I was expecting > >>first an architecture picture that shows a client, a server, and some > >>backend stuff (other servers). LosT is show as between client and > >>server. The section would talk about clients issuing requests and > >>servers answering them. It would mention HTTP and indicate what is > >>contained in a request, whats in an answer. Mention caching and the use > >>of regions as a technique to avoid repeated queries on the server. It > >>would mention the primary primitives provided by lost. > >> > >> > >>>4. LoST servers and Their Resolution > >> > >>LoST Servers and their Resolution > >> > >> > >>I wonder if there should be a separate port number for LoST. See RFC > 3205. > >> > >> > >>>A receiver can replace a mapping with another one having > >>> the same 'source' and 'sourceId' and a higher version number. > >> > >>You have not used the term receiver before. Client you mean? > >> > >> > >>> The 'version' attribute is a positive integer that is incremented for > >>> each change in the mapping. The XML data type does not specify an > >>> upper bound for this attribute and thus, the value MUST NOT wrap > >>> around. Thus, a higher version number refers to a more recent > >>> mapping. A mapping maintains its sourceId value as long as it > >>> remains logically the same, e.g., represents the same service > >>> boundary or replaces an earlier service boundary. > >> > >>Do these have to increase by 1 for each update, or just increase? SHould > >>be clear. > >> > >> > >>>The contents of this attribute is a > >>> timezoned XML type dateTime, in canonical representation. See > >> > >>contents are > >> > >> > >>> The 'expires' attribute is REQUIRED to be included in the > >>> element. > >> > >>Is there a way to use LoST without caching? To specify that this result > >>is valid only for the purposes of satisfying this one query? Or to say > >>that the results never expire? > >> > >> > >>>On occasion, a server may be forced to return an expired mapping if > >>> it cannot reach the authoritative server or the server fails to > >>> return a usable answer. Clients and servers MAY cache the mapping > so > >>> that they have at least some information available. Caching servers > >>> that have such stale information SHOULD re-attempt the query each > >>> time a client requests a mapping. > >> > >>A meta-issue here, is whether the LoST protocol is meant to just be a > >>client-server protocol, or whether we are specifying rules for the > >>entire system. This SHOULD here is a rule for a server to follow when > >>contacting other servers and thus would not be present in a > >>client-server protocol spec. > >> > >>As another issue, this section (section 5) is a mix of behaviors that > >>define rules around construction of objects and for behaviors of > >>servers. WHich is it? > >> > >> > >>> Zero or more elements describe the service with a > >>> string that is suitable for display to human users, each annotated > >>> with the 'xml:lang' attribute that contains a language tag to aid in > >>> the rendering of text. > >> > >>Presumably the presence of more than one is to allow responses to convey > >>multiple languages. Might want to state that. > >> > >> > >>>The element is optional but may also be required if the > >>> mapping is to be digitally signed. > >> > >>seems like a normative statement is needed here - The element > >>MUST be present if the mapping is to be digitally signed. > >> > >> > >>> A response MAY indicate the region for which the service URL returned > >>> would be the same as in the actual query, the so-called _service > >>> region_. > >> > >>I don't understand this definition. I thought it would be something > >>like: The service region is a set of locations, such that if a client > >>generates a new query with the same service URN and a location within > >>the set, the server would return the same service URI in its response. > >> > >> > >>>The service region is described by value > >>> in one or more elements, each formatted according > >>> to a different location profile, identified by the 'profile' > atribute > >>> (see Section 11). > >> > >>and: > >> > >> > >>> A response MAY contain more than one element with > >>> profile 'civic'. > >> > >>appear to contradict each other. Which is it? > >> > >> > >>>The identifier is a random token with at least 128 bits of entropy > >>> and can be assumed to be globally unique. It uniquely references a > >>> particular boundary. If the boundary changes, a new identifier MUST > >>> be chosen. Because of these properties, a client receiving a > mapping > >>> response can simply check if it already has a copy of the boundary > >>> with that identifier. If so, it can skip checking with the server > >>> whether the boundary has been updated. Since service boundaries are > >>> likely to remain unchanged for extended periods of time, possibly > >>> exceeding the normal lifetime of the service URL, this approach > >>> avoids unnecessarily refreshing the boundary information just > because > >>> the the remainder of the mapping has become invalid. > >> > >>Any guidelines about when a server is supposed to send a service > >>boundary reference as opposed to the actual service boundary in a > >>response? > >> > >> > >>>The Service Number Element > >>> > >>> The service number is returned in the optional > >>> element. It contains a string of digits, * and # that a user on a > >>> device with a 12-key dial pad could use to reach that particular > >>> > >>> > >>> > >>>Hardie, et al. Expires August 13, 2007 [Page > 11] > >>> > >> > >> > >>>Internet-Draft LoST February > 2007 > >>> > >>> > >>> service. > >> > >>This is not true. > >> > >>So if I'm in an enterprise which requires '9' for an outside line, > >>wouldn't I have to dial 9 first before this sequence? I think these > >>service numbers represent numbers that are part of the local *numbering > >>plan*, and are accessed based on the *dial plan* configured into the > >>device. > >> > >> > >>>7.3.3. Recursion > >>> > >>> LoST and queries can be > >>> recursive, as indicated by the 'recursive' attribute. A value of > >> > >>You haven't mentioned the listServicesByLocation query yet. > >> > >> > >>>The example in Figure 6 demonstrates address > >>> validation, omitting the standard response elements. > >> > >>but figure 6 is a request, not a response. So how can it omit response > >>elements? Maybe you mean figure 7? > >> > >> > >>>true. Each element contains a list of tokens separated by white > >>> space, enumerating the civic location lables used in child elements > >> > >>labels > >> > >> > >>> Note that the same address can yield different responses if parts of > >>> the civic address contradict each other. For example, if the postal > >>> code does not match the city, local server policy determines whether > >>> the postal code or the city is considered valid. The mapping > >>> naturally corresponds to the valid elements. > >> > >>I think you need a bit more guidance on how to construct the validation > >>responses. In particular, I think that you would want to indicate that > >>the most specific address component that is in conflict is the one > >>listed as in error. For example, if a street address is 65 Main St. and > >>there is no number 65 on Main St., you would indicate that "65" is in > >>error, not Main St. > >> > >> > >>> > >>> >>> xmlns="urn:ietf:params:xml:ns:lost1"> > >>> urn:service:sos > >>> > >>> > >>> Figure 12: Example of query > >> > >>The text in section 9 doesnt mention that the query can contain a > >>service. Presumably this is a request for the server to indicate which > >>services it supports beneath this root? And that, if absent, its a > >>request for all services? > >> > >>There is an assumption that the server knows all of the services it > >>supports. What about a LoST server that front ends a large number of > >>back-end servers, forwarding requests to a particular back-end server > >>based on location? THis front end server doesn't really know what > >>services it supports. > >> > >> > >>> define the manner in which location information is transmitted. It > >>> possible to standardize other profiles in the future. The two > >>> baseline profiles are: > >> > >>It is > >> > >> > >>> 4. The declaration of whether geodetic-2d or civic is to be used as > >>> the baseline profile. It is necessary to explicitly declare the > >>> baseline profile as future profiles may be combinations of > >>> geodetic and civic location information. > >> > >>This doesn't make sense to me; I thought this spec defined both > >>geodetic-2d and civic as baseline mandatory-to-implement. > >> > >> > >>>Requests and responses containing or > >>> elements MUST contain location information in exactly one of the two > >>> baseline profiles, in addition to zero or more additional profiles. > >>> The ordering of location information indicates a preference on the > >>> part of the sender. > >> > >>THis seems odd. Why can't you include location in both of the location > >>profiles if you have it? It might allow the server to figure out which > >>is more accurate and use that one. > >> > >> > >>> 1. A client MUST be capable of understanding the response for the > >>> baseline profiles it used in the request. > >> > >>The word 'profiles' (plural) makes me think you can in fact have > >>multiple baseline profiles in the request, though the words above forbid > >>it. > >> > >> > >>> 4. Servers MUST implement the geodetic-2d and civic profiles. > >> > >>What does this mean? Does it mean that it must be able to process > >>requests with objects in either format? Does it mean it needs > >>to be able to represent a boundary in either of the two formats? Thats > >>actually a tall order; I would tend to think that boundaries in > >>particular would typically exist in only one format and that conversion > >>is not going to be easy or possible in many cases. > >> > >> > >>> 6. If a server receives a request that only contains location > >>> information using profiles it does not understand, the server > >>> responds with a (Section 12.1). > >> > >>based on your rules this should never happen. > >> > >> > >>> 7. The element MUST use the same location profile > >>> that was used to retrieve the answer and indicates which profile > >>> has been used with the 'profile' attribute. > >> > >>'used to retrieve the answer' - what does that mean? What if the server > >>converts the input format internally prior to looking up the answer in a > >>backend store? > >> > >>Also these rules do not place any requirements on clients. Do they need > >>to support both geodesic-2d and civic? Should be clear either way. > >> > >> > >>> These rules enable the use of location profiles not yet specified, > >>> while ensuring baseline interoperability. Take, for example, this > >>> scenario. Client X has had its firmware upgraded to support the > >>> uber-complex-3D location profile. Client X sends location > >> > >>You are talking about figures 16 and 17 though you don't reference them. > >> > >> > >>> Servers use this profile by placing a GML [13] element > >>> within the element. This is defined by the > >>> 'polygon' pattern in the LoST schema (see Section 14). > >> > >>Well, servers 'use this profile' by processing requests and > >>constructing serviceBoundary objects in responses. I think you mean to > >>say that objects are constructed using and > >>serviceBoundary elemenets by elements. > >> > >>Same comment on 11.3. > >> > >> > >>>A LoST server can respond indicating that the querier should redirect > >>> the query to another server, using the element. The > >>> element includes a 'target' attribute indicating the LoST > application > >>> unique string (see Section 4) that the client SHOULD be contacting > >>> next, as well as the 'source' attribute indicating the server that > >>> generated the redirect response and a 'message' attribute explaining > >>> the reason for the redirect response. > >> > >>Is there support for multiple languages at once here, as is the case > >>with warnings and errors? > >> > >> > >>>13. LoST Transport > >> > >>You might want to include some discussion on timers. LoST layers a > >>transaction protocol ontop of HTTP. How long should a client wait for a > >>response? > >> > >>Do LoST servers need to support pipelining? Do they have to provide both > >>http and https support? Do clients need to support both? > >> > >>What about authentication? Can digest be used? What about mutual TLS? > >> > >>I think this section is a bit underspecified. > >> > >> > >> > >>>16.5. LoST Location Profile Registry > >>> > >>> This document seeks to create a registry of location profile names > >>> for the LoST protocol. Profile names are XML tokens. This registry > >>> will operate in accordance with RFC 2434 [2], Standards Action. > >> > >>I'd suggest you actually include the table that IANA is supposed to > >>create. I think you want it to look like this: > >> > >> > >>LoST Location Profiles > >> > >>Profile Name Specification > >>-------------------------------------- > >>geodetic-2d RFCXXXX > >>civic RFCXXXX > >> > >> > >> > >>>Generally, authentication and authorization is not required for > >>> mapping queries. If it is, authentication mechanism of the > >>> underlying transport mechanism, such as HTTP basic and digest > >>> authentication, MAY be used. (Basic authentication SHOULD only be > >>> used in combination with TLS.) > >> > >>I this this last SHOULD has to be a MUST. > >> > >> > >>>17. Security Considerations > >> > >>Text in the body of the specification discusses body signatures, but > >>there is no treatment on how this is done. > >> > >> > >>>In protocols that support > >>> content type indication, LoST uses the media type application/ > >>> lost+xml. > >> > >>What does this mean? That when used with HTTP, LoST objects use this > >>content-type? > >> > >> > >> > >>Thanks, > >>JOnathan R. > >> > >> > >> > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Cisco Fellow Parsippany, NJ 07054-2711 > >>Cisco Systems > >>jdrosen@cisco.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.cisco.com > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 08:31:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKDt-0006Dv-6v; Wed, 14 Feb 2007 08:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKDr-0006Cr-E5 for ecrit@ietf.org; Wed, 14 Feb 2007 08:30:59 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHKDq-0005kv-0Q for ecrit@ietf.org; Wed, 14 Feb 2007 08:30:59 -0500 Received: (qmail invoked by alias); 14 Feb 2007 13:30:56 -0000 X-Provags-ID: V01U2FsdGVkX18dc0p9L44dX8BRPjt2aAI4oe3cJNIoHrUEgZogfT C25w== Message-ID: <45D30F0C.3080307@gmx.net> Date: Wed, 14 Feb 2007 15:30:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] LoST-04 and Security Considerations Section References: <4.3.2.7.2.20070213192956.029f3f18@email.cisco.com> In-Reply-To: <4.3.2.7.2.20070213192956.029f3f18@email.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, I am not aware of any restrictions regarding the usage of RFC 2119 language in the security section. Btw, your draft does this as well :-) http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-07.txt Ciao Hannes James M. Polk wrote: > Authors > > A quick thought/observation: > > There is normative text in the Security Considerations section, and I > don't believe this is appropriate or even allowed. I think it should > be moved regardless into the main text body. > > James > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 11:16:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMnv-00075d-2h; Wed, 14 Feb 2007 11:16:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMnt-00074e-E4 for ecrit@ietf.org; Wed, 14 Feb 2007 11:16:21 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHMns-0000Z6-3q for ecrit@ietf.org; Wed, 14 Feb 2007 11:16:21 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2007 08:16:19 -0800 X-IronPort-AV: i="4.14,169,1170662400"; d="scan'208"; a="360904640:sNHT45288608" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1EGGJ59031465; Wed, 14 Feb 2007 08:16:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1EGGJnL027786; Wed, 14 Feb 2007 08:16:19 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:16:07 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:16:06 -0800 Message-ID: <45D335C4.7070209@cisco.com> Date: Wed, 14 Feb 2007 11:16:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] comments on LoST References: <02b301c74fdd$292c3c00$640fa8c0@cis.neustar.com> In-Reply-To: <02b301c74fdd$292c3c00$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2007 16:16:06.0951 (UTC) FILETIME=[6E7C8370:01C75053] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1205; t=1171469779; x=1172333779; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Ecrit]=20comments=20on=20LoST |Sender:=20; bh=J6VBGCuPxqYPNF5a1RM4yx22EPeerRdB1H31f3zpiHY=; b=N7eZ8B1BWrX+HKzpR/i76luL1EuDTDVx/yK9Jwa6uOLcSpwrzZ29bhl5/UnN+33nz7NCEs6U jyNMhE/3AvfIleqjKK6XKBfc5bIyYuX4aofrDE2C9BOev/5BLQzuGm9D; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > Well, there are two ways to do this. One is to keep the data for both, a > real polygon for the geo, and appropriate values in fields of the civic. > > The other way is to use geocoding to convert civic to geo and use the > polygons in all cases. Conversion in this case is acceptable, both because > you don't forward the converted value, and because the database used can be > precisely the database used for other routing purposes. So here is my concern. The client sends its query using a object in civic form. The server has all its information in geodesic. So, it converts the civic to geodesic and does its work. But now, it has to return the boundary information in civic format. But, in this case, it doesn't have it - you only have it in polygon format. So how does this work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 11:20:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMsJ-0001LP-8f; Wed, 14 Feb 2007 11:20:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMsI-0001L8-2e for ecrit@ietf.org; Wed, 14 Feb 2007 11:20:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHMsF-0001Ag-Jm for ecrit@ietf.org; Wed, 14 Feb 2007 11:20:54 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2007 08:20:51 -0800 X-IronPort-AV: i="4.14,169,1170662400"; d="scan'208"; a="39457986:sNHT50376366" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1EGKowT028865; Wed, 14 Feb 2007 08:20:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1EGKWHA013847; Wed, 14 Feb 2007 08:20:50 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:20:46 -0800 Received: from [10.32.241.151] ([10.32.241.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:20:45 -0800 Message-ID: <45D336DC.4080308@cisco.com> Date: Wed, 14 Feb 2007 11:20:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on LoST References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> In-Reply-To: <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2007 16:20:46.0056 (UTC) FILETIME=[14D88E80:01C75054] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4138; t=1171470051; x=1172334051; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Ecrit]=20comments=20on=20LoST |Sender:=20; bh=w73mcvgiXxqB2af/GSlWY09SWUOee5viz3sH+qIxsXk=; b=GLVB2fQ9E07U3QyahC5K5Eh59m2dVWH+CWGWw9S4BF1KZSX161/QTiFMkBE/1p+er8RcMfJ0 8lPotgHlw0g+RDvMSacq9h63/jadVvfVLRnB4K7W21GFUg4cgcz/cAnA; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org inline. Andrew Newton wrote: > > On Feb 13, 2007, at 5:49 PM, Jonathan Rosenberg wrote: > >> Right. SO what if a server has boundary information in civic format >> and a client makes a query in geodesic format. > > > An error occurs, like . Or the server redirects to a geo > forrest guide. But the two resolution paths are different. There is > no reason to believe that the same authoritative server MUST have both > sets of information. Then I am misunderstanding the spec. I thought it required servers to support both location profiles. What does it mean to 'support'? > >> Even if you use NAPTR/SRV you can still have default port numbers; >> SIP does this (port 5060 default). People seem to still find comfort >> in default port numbers for firewall configuration. Trust me, I'm >> well aware of its practical limits.... > > > Agreed, but what would they be? 80 and 443? Since it isn't essential > to specify, I don't see a need to do so. You'd go do an iana allocation request and include them in the spec. >>>> Any guidelines about when a server is supposed to send a service >>>> boundary reference as opposed to the actual service boundary in a >>>> response? >>> >>> Hmmm... good question. I would think that all authoritative >>> servers would always send service boundary values so that caching >>> resolvers may actually cache them. As for the resolvers, they >>> probably know best what to do based on their configuration. >> >> >> So, then why bother even supporting explicit inclusion of a service >> boundary? Less options in a protocol is better. > > > Because the client may have a good reason for not wanting the value, > such as it is on a bandwidth limited link. The client can request > this, but what is sent is up to the server. Err, I'm confused. I was suggesting that it might be easier to ONLY have a service boundary reference in the findServiceResponse. That is, to drop support for including the actual service boundary in a find service response. Rather, the client always has to fetch it separately. I was asking what the use case was for EVER including the actual service boundary (as opposed to the reference) in a findServiceResponse. If there is none, we can drop it. >>>> You might want to include some discussion on timers. LoST layers a >>>> transaction protocol ontop of HTTP. How long should a client wait >>>> for a response? >>> >>> I'm not falling into that tarpit. For a discussion on timers, see TCP. >> >> >> It may be a tarpit, but I dont think you can just skirt the issue >> entirely. Its not really a tcp issue at all. If a server needs to go >> to other servers to get an answer, and THOSe servers are delayed or >> down, what happens? Should the client retry right away? How does the >> client know that the server is trying (in which case a retry on a >> different server is useless) vs. unresponsive (in which case a retry >> is useful)? >> >> This is one of the dangers of running on http as a substrate. LoST is >> NOT like HTTP in its use of multi-hop resolution. That brings up all >> kinds of new failure modes that you need to consider. > > > The problem is that I am being told, over another draft, that SIP is a > bad protocol to model this type of stuff after. Quite frankly, the > guidance in this area is less than helpful. My experience so far is, > "Use TCP. If you do anything else, don't do bad things... but we can > enumerate what those bad things are." The real issue here is, will we see interop problems because servers timeout before clients do? Seems like there are real things here needing specification. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 11:30:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN1O-0005yy-Vp; Wed, 14 Feb 2007 11:30:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN1N-0005xC-UC for ecrit@ietf.org; Wed, 14 Feb 2007 11:30:17 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHN1M-0002v2-Kb for ecrit@ietf.org; Wed, 14 Feb 2007 11:30:17 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HHN1D-0002Sq-9t; Wed, 14 Feb 2007 10:30:07 -0600 From: "Brian Rosen" To: "'Jonathan Rosenberg'" Subject: RE: [Ecrit] comments on LoST Date: Wed, 14 Feb 2007 11:30:10 -0500 Message-ID: <002601c75055$687a5b80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45D335C4.7070209@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdQU3IX9KNITF+4SzCG2zbGqX0a9gAAaw8g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You have the polygons for "city" "county" "state" etc. You intersect them with the service boundary polygon. You take the smallest, totally enclosed area. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, February 14, 2007 11:16 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] comments on LoST > > > > Brian Rosen wrote: > > > Well, there are two ways to do this. One is to keep the data for both, > a > > real polygon for the geo, and appropriate values in fields of the civic. > > > > The other way is to use geocoding to convert civic to geo and use the > > polygons in all cases. Conversion in this case is acceptable, both > because > > you don't forward the converted value, and because the database used can > be > > precisely the database used for other routing purposes. > > So here is my concern. The client sends its query using a > object in civic form. The server has all its information in geodesic. > So, it converts the civic to geodesic and does its work. But > now, it has to return the boundary information in civic format. But, in > this case, it doesn't have it - you only have it in polygon format. > > So how does this work. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 11:36:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN7Q-0001ZS-Sr; Wed, 14 Feb 2007 11:36:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHN7O-0001ZF-DI for ecrit@ietf.org; Wed, 14 Feb 2007 11:36:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHN7N-00045h-2O for ecrit@ietf.org; Wed, 14 Feb 2007 11:36:30 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2007 08:36:28 -0800 X-IronPort-AV: i="4.14,169,1170662400"; d="scan'208"; a="464488776:sNHT45316516" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1EGaSSO016525; Wed, 14 Feb 2007 08:36:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1EGaGE4001239; Wed, 14 Feb 2007 08:36:28 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:36:22 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.228.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 08:36:21 -0800 Message-Id: <4.3.2.7.2.20070214103403.0196fa48@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Feb 2007 10:36:23 -0600 To: Hannes Tschofenig From: "James M. Polk" Subject: Re: [Ecrit] LoST-04 and Security Considerations Section In-Reply-To: <45D30F0C.3080307@gmx.net> References: <4.3.2.7.2.20070213192956.029f3f18@email.cisco.com> <4.3.2.7.2.20070213192956.029f3f18@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Feb 2007 16:36:21.0978 (UTC) FILETIME=[42B2EBA0:01C75056] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1049; t=1171470988; x=1172334988; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20LoST-04=20and=20Security=20Considerations=2 0Section |Sender:=20; bh=FdmwO9UAlZx1GPx9EnSi9iSXmnUIJsCjIHjfqGy4UjI=; b=JRpTDVDa5aHZ+Q70yJBAz7xhJuiGVlgK+cQzqaeDtaFhC04PTFlW43uoxO7FeSGPvOjIENcl aKjxJqKZms5+BCkNAtPMsaSsE7M4UrQ1QE/b4VoyGf8OlfhytBiv8Dio; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 03:30 PM 2/14/2007 +0200, Hannes Tschofenig wrote: >Hi James, > >I am not aware of any restrictions regarding the usage of RFC 2119 >language in the security section. This email was a reaction as much as anything to guidance from ADs in the past telling me to remove such language before they moved a particular doc to move forward (which has happened more than once in the last few years) >Btw, your draft does this as well :-) >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-07.txt yep, I'm embarrassed to admit the second paragraph does have this. >Ciao >Hannes > >James M. Polk wrote: >>Authors >> >>A quick thought/observation: >> >>There is normative text in the Security Considerations section, and I >>don't believe this is appropriate or even allowed. I think it should be >>moved regardless into the main text body. >> >>James >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 11:41:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNBu-0003eb-DT; Wed, 14 Feb 2007 11:41:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNBt-0003bL-75 for ecrit@ietf.org; Wed, 14 Feb 2007 11:41:09 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHNBq-0004jO-MW for ecrit@ietf.org; Wed, 14 Feb 2007 11:41:09 -0500 Received: from [160.39.247.135] (dyn-160-39-247-135.dyn.columbia.edu [160.39.247.135]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l1EGf2qD002635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Feb 2007 11:41:02 -0500 (EST) In-Reply-To: <4.3.2.7.2.20070214103403.0196fa48@email.cisco.com> References: <4.3.2.7.2.20070213192956.029f3f18@email.cisco.com> <4.3.2.7.2.20070213192956.029f3f18@email.cisco.com> <4.3.2.7.2.20070214103403.0196fa48@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST-04 and Security Considerations Section Date: Wed, 14 Feb 2007 11:41:01 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "'ecrit@ietf.org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Whether allowed or not, I think the main body of the spec, outside the various "Considerations", should be sufficient to build an interoperable implementations. Thus, a 2119 term isn't bad if it merely restates what has been said before, but it shouldn't be the only or first time the concept or protocol feature is explained. On Feb 14, 2007, at 11:36 AM, James M. Polk wrote: > At 03:30 PM 2/14/2007 +0200, Hannes Tschofenig wrote: >> Hi James, >> >> I am not aware of any restrictions regarding the usage of RFC 2119 >> language in the security section. > > This email was a reaction as much as anything to guidance from ADs > in the past telling me to remove such language before they moved a > particular doc to move forward (which has happened more than once > in the last few years) > > >> Btw, your draft does this as well :-) >> http://www.ietf.org/internet-drafts/draft-ietf-sip-location- >> conveyance-07.txt > > yep, I'm embarrassed to admit the second paragraph does have this. > > >> Ciao >> Hannes >> >> James M. Polk wrote: >>> Authors >>> >>> A quick thought/observation: >>> >>> There is normative text in the Security Considerations section, >>> and I don't believe this is appropriate or even allowed. I think >>> it should be moved regardless into the main text body. >>> >>> James >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 12:44:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOB2-0004KP-SQ; Wed, 14 Feb 2007 12:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOB1-0004JN-NG for ecrit@ietf.org; Wed, 14 Feb 2007 12:44:19 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOAz-0004rN-Fc for ecrit@ietf.org; Wed, 14 Feb 2007 12:44:19 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 14 Feb 2007 12:43:32 -0500 id 0158843F.45D34A44.00006735 In-Reply-To: <45D336DC.4080308@cisco.com> References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on LoST Date: Wed, 14 Feb 2007 12:44:15 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Feb 14, 2007, at 11:20 AM, Jonathan Rosenberg wrote: >> On Feb 13, 2007, at 5:49 PM, Jonathan Rosenberg wrote: >>> Right. SO what if a server has boundary information in civic >>> format and a client makes a query in geodesic format. >> An error occurs, like . Or the server redirects to a >> geo forrest guide. But the two resolution paths are different. >> There is no reason to believe that the same authoritative server >> MUST have both sets of information. > > Then I am misunderstanding the spec. I thought it required servers > to support both location profiles. What does it mean to 'support'? A server cannot return an error indicating it did not recognize one of those profiles. >>> Even if you use NAPTR/SRV you can still have default port >>> numbers; SIP does this (port 5060 default). People seem to still >>> find comfort in default port numbers for firewall configuration. >>> Trust me, I'm well aware of its practical limits.... >> Agreed, but what would they be? 80 and 443? Since it isn't >> essential to specify, I don't see a need to do so. > > You'd go do an iana allocation request and include them in the spec. That is an answer for "how". I asked about "what". > Err, I'm confused. I was suggesting that it might be easier to ONLY > have a service boundary reference in the findServiceResponse. That > is, to drop support for including the actual service boundary in a > find service response. Rather, the client always has to fetch it > separately. I was asking what the use case was for EVER including > the actual service boundary (as opposed to the reference) in a > findServiceResponse. If there is none, we can drop it. Well, it prevents another round trip in cases where the value is needed. But I see your point. > The real issue here is, will we see interop problems because > servers timeout before clients do? Seems like there are real things > here needing specification. That's a good point. Suggestions are welcome. But I'll also point out that DNS has not such timer specifications. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 15:57:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRBK-0003LL-Bd; Wed, 14 Feb 2007 15:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHRBI-0003LF-Nm for ecrit@ietf.org; Wed, 14 Feb 2007 15:56:48 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHRBH-0001y6-Fs for ecrit@ietf.org; Wed, 14 Feb 2007 15:56:48 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l1EKucBW008972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Feb 2007 15:56:38 -0500 (EST) In-Reply-To: <45D336DC.4080308@cisco.com> References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B962B08-1D99-47A7-834E-190C3999653A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] comments on LoST Date: Wed, 14 Feb 2007 15:57:27 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > >>> Even if you use NAPTR/SRV you can still have default port >>> numbers; SIP does this (port 5060 default). People seem to still >>> find comfort in default port numbers for firewall configuration. >>> Trust me, I'm well aware of its practical limits.... >> Agreed, but what would they be? 80 and 443? Since it isn't >> essential to specify, I don't see a need to do so. > > You'd go do an iana allocation request and include them in the spec. I see no reason for LoST to use anything beyond port 80 or 443 as long as it uses HTTP/S. LoST is very much in the same spirit as XML- RPC or SOAP, both of which use port 80/443. > > Err, I'm confused. I was suggesting that it might be easier to ONLY > have a service boundary reference in the findServiceResponse. That > is, to drop support for including the actual service boundary in a > find service response. Rather, the client always has to fetch it > separately. I was asking what the use case was for EVER including > the actual service boundary (as opposed to the reference) in a > findServiceResponse. If there is none, we can drop it. > I've made that argument in the past. The one argument that was offered in favor of retaining by-value inclusion of boundaries is that civic boundaries are likely to be small in size, so the overhead of retrieving the boundary separately is far larger than including it, due to the need to issue a separate query for the by-reference case. Personally, I still think that simplicity would be a good thing here. > > The real issue here is, will we see interop problems because > servers timeout before clients do? Seems like there are real things > here needing specification. The case that can occur is that the seeker asks the resolver and the resolver asks the authoritative server (or similar variations). If the seeker timeout is shorter than the resolver timeout, nothing bad happens - the resolver caches the answer it eventually got for the next querier, possibly a re-attempt by the same seeker. If the converse occurs (seeker timeout > resolver timeout), the seeker gets a failure indication from the resolver. Thus, I don't see a need to specify an explicit timeout. In many practical cases, the timeouts will be driven by the TCP or HTTP library, so they may not be configurable in any event. Any such choice would likely be completely arbitrary. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 17:26:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSZh-0005Xd-RQ; Wed, 14 Feb 2007 17:26:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSZg-0005VG-Q7 for ecrit@ietf.org; Wed, 14 Feb 2007 17:26:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSZe-0005Zv-Ee for ecrit@ietf.org; Wed, 14 Feb 2007 17:26:04 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2007 14:26:03 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="389162666:sNHT227037484" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1EMQ1tj029412 for ; Wed, 14 Feb 2007 14:26:01 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1EMPfVK002590 for ; Wed, 14 Feb 2007 14:26:01 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 14:26:00 -0800 Received: from mlinsnerwxp ([171.70.228.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 14:26:00 -0800 From: "Marc Linsner" To: Date: Wed, 14 Feb 2007 17:26:00 -0500 Message-ID: <00d301c75087$1b2adf30$80e446ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdQhv6gmBqG2mfKTrOO1NZTZo8fyw== X-OriginalArrivalTime: 14 Feb 2007 22:26:00.0532 (UTC) FILETIME=[1AE43940:01C75087] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=519; t=1171491961; x=1172355961; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20WGLC=20-=20=20A=20Dynamic=20Host=20Configuration=20Protocol=2 0(DHCP)=20based=20Location-to-Service=20Translation=20Protocol=20(LoST)=20 Discovery=20Procedure |Sender:=20; bh=090yvK1Rorkix+Ld1Lht82weJy9idJC4Z8/NgiNkOQs=; b=N+10vERvbkxMrNlN9NOFeCCfYb0OcWpK6/pWDl8bO5SYrJE701oVIB3lukWGPAnjmSBh+NkN xFItEPiyKn4uDDV/HbxTFL5BeVbJlplOGBha3qeiVGkBtAO9XdyjHmDq; Authentication-Results: sj-dkim-8; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] WGLC - A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org All, This message marks the issuance of a working group last call (WGLC) on ECRIT's Internet Draft entitled "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure" (draft-ietf-ecrit-dhc-lost-discovery-00.txt). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.t xt. Please post comments and questions to this mailing list no later than 2 March 2007. -Marc Linsner- ECRIT co-chair _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 17:26:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSZg-0005V3-Le; Wed, 14 Feb 2007 17:26:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSZf-0005Uu-Mo for ecrit@ietf.org; Wed, 14 Feb 2007 17:26:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSZe-0005Zu-BZ for ecrit@ietf.org; Wed, 14 Feb 2007 17:26:03 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2007 14:26:01 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="39556474:sNHT253230264" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1EMQ1xB029932 for ; Wed, 14 Feb 2007 14:26:01 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1EMPfVI002590 for ; Wed, 14 Feb 2007 14:26:01 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 14:26:00 -0800 Received: from mlinsnerwxp ([171.70.228.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 14:26:00 -0800 From: "Marc Linsner" To: Date: Wed, 14 Feb 2007 17:26:00 -0500 Message-ID: <00d201c75087$1afffea0$80e446ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdQhwOOb5ajdQEqRWSFLAqUmRUcow== X-OriginalArrivalTime: 14 Feb 2007 22:26:00.0251 (UTC) FILETIME=[1AB958B0:01C75087] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=417; t=1171491961; x=1172355961; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20WGLC=20-=20LoST=3A=20A=20Location-to-Service=20Translation=20 Protocol |Sender:=20; bh=GmriEZzBL49V5+psKIQpbydAVE/a7QxGOkATb96iFQ8=; b=QqR/A0dRNRUnqbCV3xgY52n5bI/iuDg4BnJMkHxtN5ePrUFhESOAJLWHEf9TiuuTAc5VW/Ml EayBCOhsM6K/8OmxyPqBA1/CrWkx/N5Shq+9JAZbGxbyWzUzIK5xCOKz; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] WGLC - LoST: A Location-to-Service Translation Protocol X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org All, This message marks the issuance of a working group last call (WGLC) on ECRIT's Internet Draft entitled "LoST: A Location-to-Service Translation Protocol" (draft-ietf-ecrit-lost-04.txt). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-04.txt. Please post comments and questions to this mailing list no later than 2 March 2007. -Marc Linsner- ECRIT co-chair _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 19:06:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHU8l-0005ev-7A; Wed, 14 Feb 2007 19:06:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHU8k-0005eT-1q for ecrit@ietf.org; Wed, 14 Feb 2007 19:06:22 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHU8i-0003rk-OE for ecrit@ietf.org; Wed, 14 Feb 2007 19:06:22 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l1F0683q027186; Wed, 14 Feb 2007 17:06:09 -0700 Message-ID: <45D3A3F3.1080704@ntt-at.com> Date: Wed, 14 Feb 2007 16:06:11 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on LoST References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> In-Reply-To: <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andrew; My comments inline. Andrew Newton wrote: > > On Feb 14, 2007, at 11:20 AM, Jonathan Rosenberg wrote: >>> On Feb 13, 2007, at 5:49 PM, Jonathan Rosenberg wrote: >>>> Right. SO what if a server has boundary information in civic format >>>> and a client makes a query in geodesic format. >>> An error occurs, like . Or the server redirects to a geo >>> forrest guide. But the two resolution paths are different. There is >>> no reason to believe that the same authoritative server MUST have >>> both sets of information. >> >> Then I am misunderstanding the spec. I thought it required servers to >> support both location profiles. What does it mean to 'support'? > > A server cannot return an error indicating it did not recognize one of > those profiles. So are you saying that server may only support 1 of the mandatory profile, and if it was queried with the profile that it doesn't support it can't return an error? If that's the case the text needs to be clarified. Also, with recursion being false as a default, if the server in question doesn't support the profile asked, what is it supposed to do? Is there a case where service resolution to "urn:service:A" is provided for profile 1 while not provided for profile 2? If there is needs more information to provide the client with knowledge that some service resolutions are provided only for a certain profile. Also what is a geo forrest guide? This is a term I have never heard before? I didn't think there was a distinction in forrest guide based on the location profile.. My understanding was the same as Jonathan that LoST server had to provide resolution to 2 mandatory profiles. Regards Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 14 21:30:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHWOL-0007MA-68; Wed, 14 Feb 2007 21:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHWOK-0007Jz-16 for ecrit@ietf.org; Wed, 14 Feb 2007 21:30:36 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHWOI-0007k0-Qt for ecrit@ietf.org; Wed, 14 Feb 2007 21:30:36 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 14 Feb 2007 21:29:50 -0500 id 01588458.45D3C59E.00006E25 In-Reply-To: <45D3A3F3.1080704@ntt-at.com> References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> <45D3A3F3.1080704@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on LoST Date: Wed, 14 Feb 2007 21:30:33 -0500 To: shida@ntt-at.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Feb 14, 2007, at 7:06 PM, Shida Schubert wrote: > So are you saying that server may only support 1 of the mandatory > profile, and if it was queried with > the profile that it doesn't support it can't return an error? If > that's > the case the text needs to be > clarified. What do you mean by "support"? Because it cannot return a location profile error for either of the two base profiles. As to what data it MUST have, the answer is ZERO. No server is required to have data for either profile unless it has data for a profile derived from a base profile. > Also, with recursion being false as a default, if the server > in question doesn't support the > profile asked, what is it supposed to do? Again, what do you mean by "support"? A server can always return for anything you pass to it. That's not very useful, but is allowable. > Is there a case where service > resolution to "urn:service:A" > is provided for profile 1 while not provided for profile 2? Probably, but my crystal ball isn't that good. > If there is > > needs more information to provide the client with knowledge that some > service resolutions are provided > only for a certain profile. That's not a bad idea, but is also unnecessary. > Also what is a geo forrest guide? This is a term I have never heard > before? > I didn't think there was a distinction in forrest guide based on the > location profile.. My understanding > was the same as Jonathan that LoST server had to provide resolution > to 2 > mandatory profiles. I simply meant a forrest guide populated with the geo data. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 15 01:00:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZfa-0002AD-PL; Thu, 15 Feb 2007 01:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZfZ-00029P-NE for ecrit@ietf.org; Thu, 15 Feb 2007 01:00:37 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHZfY-0007Mb-8O for ecrit@ietf.org; Thu, 15 Feb 2007 01:00:37 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l1F60WGd019342; Wed, 14 Feb 2007 23:00:33 -0700 Message-ID: <45D3F702.5060406@ntt-at.com> Date: Wed, 14 Feb 2007 22:00:34 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on LoST References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> <45D3A3F3.1080704@ntt-at.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy; Let me try again. My comments inline.. Andrew Newton wrote: > > On Feb 14, 2007, at 7:06 PM, Shida Schubert wrote: >> So are you saying that server may only support 1 of the mandatory >> profile, and if it was queried with >> the profile that it doesn't support it can't return an error? If that's >> the case the text needs to be >> clarified. > > What do you mean by "support"? Because it cannot return a location > profile error for either of the two base profiles. As to what data it > MUST have, the answer is ZERO. No server is required to have data for > either profile unless it has data for a profile derived from a base > profile. I somehow understood that support for both profiles meant. " If the server was able to provide resolution for service B in region A, then the service MUST be able to provide resolution for region A in both civic/geo location profiles." Now, obviously that's not what "support" means. It merely means that LoST server is able to understand the profile(schema). So if support simply implies that server understands the profile is really useless and some additional information should be provided to aid the client in making an intelligent decision. If it can't return an error, some sort of warning that provides the seeker with a hint implying which profile is needed for the resolution may be desirable. Further, it would be useful to have the ability to express the "profile type supported"/service in as well as . If the seeker(client) checks to see what service, resolver supports and it sees that it supports the service it is interested in, how would it know that the resolution is only provided for profile A? It can't... If the seeker is smart enough it might attempt the query with civic, and if fails try again with geo. But what if the resolution is only provided for one of the optional profile(call it geo-x) that client doesn't support? Current text doesn't prevent this from happening does it? If its mandatory to provide mapping for one of the base profile, client will simply try the other base profile if one fails. But reading your comment I just don't see that is how it works. I am assuming from your comment that if the mapping for service:pizza is provided only for optional location profile X? The "service:pizza" will be listed in the as supported service. Client interested in the resolution of "service:pizza" may try the query with every profile it understands only to find out that none of the profile the client supports can be used for resolution... This can be avoided by simply returning which profile the resolution is available for. > >> Also, with recursion being false as a default, if the server >> in question doesn't support the >> profile asked, what is it supposed to do? > > Again, what do you mean by "support"? A server can always return > for anything you pass to it. That's not very useful, but > is allowable. According to my understanding can be returned under various cases as follows. The example illustrated assumes that query was composed using geo. 1. If the server doesn't provide resolution for the region in query and recursive was set to "false" or not declared. 2. If the server doesn't have the geo data for the service:pizza and recursive was set to "false" or not declared. > Would be nice to provide with information of why it failed and possibly the profile which can be used to obtain the mapping. 3. If the server is aware of another authoritative server that can provide resolution for the geo but recursive is either not declared or set to "false" > Would be nice to provide information that resolution can be provided by server X or redirect. 4. recursive was set to true, but no authoritative server owned data for the service:pizza in geo. > Again would be nice to provide which profile would succeed. After I wrote this I looked at the schema and saw that defaultValue for recursive is "true" but section 7.3.3 says it's default value is "false". I am a bit confused is the default "false" or "true"? -- Text from section 7.3.3 -- "A value of "true" indicates a recursive query, with the default being "false" when the attribute is omitted. ----------------------------- 3 of the cases above can be avoided by setting recursive="true". Anyhow, I do believe that normative behavior of client and server for any services in general should be declared somewhere and should be added as a milestone of this WG. Ideally general behavior of client/server is included in this document but I understand that there is an extraneous pressure for this work to be completed. Furthermore I understand that phone-bcp is covering the normative behavior for emergency case but what's debated above is not limited to emergency case.. I think... Regards Shida > >> Is there a case where service >> resolution to "urn:service:A" >> is provided for profile 1 while not provided for profile 2? > > Probably, but my crystal ball isn't that good. > >> If there is >> >> needs more information to provide the client with knowledge that some >> service resolutions are provided >> only for a certain profile. > > That's not a bad idea, but is also unnecessary. Sure may be not necessary but I believe it's useful. > >> Also what is a geo forrest guide? This is a term I have never heard >> before? >> I didn't think there was a distinction in forrest guide based on the >> location profile.. My understanding >> was the same as Jonathan that LoST server had to provide resolution to 2 >> mandatory profiles. > > I simply meant a forrest guide populated with the geo data. Okay thanks. > > -andy > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 15 09:58:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHi3b-0000Yh-Vo; Thu, 15 Feb 2007 09:57:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHi3a-0000YO-D2 for ecrit@ietf.org; Thu, 15 Feb 2007 09:57:58 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHi3X-0002gC-32 for ecrit@ietf.org; Thu, 15 Feb 2007 09:57:58 -0500 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 15 Feb 2007 09:57:02 -0500 id 01588135.45D474BE.000023B0 In-Reply-To: <45D3F702.5060406@ntt-at.com> References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> <45D3A3F3.1080704@ntt-at.com> <45D3F702.5060406@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80DB9D35-04C9-4624-9AC5-5AC03402FAB5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on LoST Date: Thu, 15 Feb 2007 09:57:45 -0500 To: shida@ntt-at.com X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Feb 15, 2007, at 1:00 AM, Shida Schubert wrote: > So if support simply implies that server understands the profile > is really > useless and some additional information should be provided to aid > the client in making > an intelligent decision. > If it can't return an error, some sort of warning that provides the > seeker with a hint > implying which profile is needed for the resolution may be desirable. This implies that the client making the query in geo also has the same location in civic and vice versa. That's a pretty big assumption. We have discussed this issue in great detail on this list, and the consensus was that if a client has location in both geo and civic and wishes to get an answer for both, the client will simply make two separate queries -- one for geo and one for civic. A for one query will not prevent it from getting the information for the other. > Further, it would be useful to have the ability to express the > "profile type supported"/service > in as well as . I'm indifferent to this idea. If others support it, we could add it in. > After I wrote this I looked at the schema and saw that defaultValue > for > recursive is "true" but section 7.3.3 says it's default value is > "false". I am > a bit confused is the default "false" or "true"? > > -- Text from section 7.3.3 -- > "A value of "true" indicates a recursive query, with the default being > "false" when the attribute is omitted. > ----------------------------- That'll have to get fixed. I'm inclined to have it default to true. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 15 12:26:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHkNQ-0005cc-MZ; Thu, 15 Feb 2007 12:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHkNQ-0005cF-2f for ecrit@ietf.org; Thu, 15 Feb 2007 12:26:36 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHkNF-00011p-Tq for ecrit@ietf.org; Thu, 15 Feb 2007 12:26:36 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l1FHQMVI011236; Thu, 15 Feb 2007 10:26:23 -0700 Message-ID: <45D497C1.7020907@ntt-at.com> Date: Thu, 15 Feb 2007 09:26:25 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on LoST References: <45D1E4BE.9020205@cisco.com> <5BF48ED9-3131-4790-B9EA-1DB2C483F16E@hxr.us> <45D24077.7080400@cisco.com> <0A3A22C0-8316-473B-9F63-88FA3C901365@hxr.us> <45D336DC.4080308@cisco.com> <687C4574-5C43-4C7E-B803-8E298C79556A@hxr.us> <45D3A3F3.1080704@ntt-at.com> <45D3F702.5060406@ntt-at.com> <80DB9D35-04C9-4624-9AC5-5AC03402FAB5@hxr.us> In-Reply-To: <80DB9D35-04C9-4624-9AC5-5AC03402FAB5@hxr.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > > On Feb 15, 2007, at 1:00 AM, Shida Schubert wrote: >> So if support simply implies that server understands the profile >> is really >> useless and some additional information should be provided to aid the >> client in making >> an intelligent decision. >> If it can't return an error, some sort of warning that provides the >> seeker with a hint >> implying which profile is needed for the resolution may be desirable. > > This implies that the client making the query in geo also has the same > location in civic and vice versa. That's a pretty big assumption. We > have discussed this issue in great detail on this list, and the > consensus was that if a client has location in both geo and civic and > wishes to get an answer for both, the client will simply make two > separate queries -- one for geo and one for civic. A for > one query will not prevent it from getting the information for the other. No! Client may not have the same location in civic and geo, the location that these two profiles may overlap but probably has different accuracy. My geo location that I get from my GPS may be very accurate to a point and because of its accuracy would be the preferred location to be used when my UA sends a LoST query. According to your comment, there is a possibility that geo may not resolve to any URI even when recursive="true", because none of the authoritative servers responsible for the region may hold the resolution data for geo. If I obtain an error but I know from that resolution for the service I want is provided, I may want to re-try query with inaccurate civic location information I obtain through DHCP. If resolution for civic is available, at least I get some URI to contact the service I am interested in, accurate location information can be provided then. * I really hope that for an emergency case(service:sos), there will be a text in phone-bcp mandating the administrator of LoST to maintain mapping data for both geo/civic within the region so client only supporting geo or vice versa will at least get some kind of resolution. Furthermore, to increase the chance of obtaining the mapping data, I would also recommend recursive=true at all time. One question was unanswered.. If resolution is provided only for non mandatory-to-implement profile, would it still be listed in the as service supported? If so I do think that's problematic. Although I am aware that it is out of scope of protocol definition, but if there is no indication of which profile is supported(data available)/service, some text imposing /recommending the server to provide resolution in at least one of the base profile should exist for the protocol to be useful... > >> Further, it would be useful to have the ability to express the >> "profile type supported"/service >> in as well as . > > I'm indifferent to this idea. If others support it, we could add it in. > >> After I wrote this I looked at the schema and saw that defaultValue for >> recursive is "true" but section 7.3.3 says it's default value is >> "false". I am >> a bit confused is the default "false" or "true"? >> >> -- Text from section 7.3.3 -- >> "A value of "true" indicates a recursive query, with the default being >> "false" when the attribute is omitted. >> ----------------------------- > > That'll have to get fixed. I'm inclined to have it default to true. I am inclined to have it default to true as well. Regards Shida > > > -andy > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 16 00:05:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHvHv-0004nt-MS; Fri, 16 Feb 2007 00:05:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHvHt-0004mE-Ju for ecrit@ietf.org; Fri, 16 Feb 2007 00:05:37 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHvHp-0003YB-Co for ecrit@ietf.org; Fri, 16 Feb 2007 00:05:37 -0500 X-SEF-Processed: 5_0_0_910__2007_02_15_23_11_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 15 Feb 2007 23:11:01 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 23:05:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Feb 2007 23:05:28 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Namespaces in LoST Thread-Index: AcdRiBNkoipW5tRTTJClSj0ofShO6Q== From: "Thomson, Martin" To: "ECRIT" X-OriginalArrivalTime: 16 Feb 2007 05:05:30.0016 (UTC) FILETIME=[143AFA00:01C75188] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] Namespaces in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2146133556==" Errors-To: ecrit-bounces@ietf.org --===============2146133556== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd291bGQgYXBwZWFyIHRoYXQgdGhlIFBvbHlnb24gYW5kIFBvaW50IGVsZW1lbnRzIGRlc2Ny aWJlZCBpbiB0aGUgY29tcGFjdCBzeW50YXggc2NoZW1hIGFyZSBkZWZpbmVkIGluIHRoZSBMb1NU IG5hbWVzcGFjZS4gIEhvd2V2ZXIsIHRoZSBleGFtcGxlcyBzaG93IHRoZW0gdG8gYmUgaW4gdGhl ICdodHRwOi8vd3d3Lm9wZW5naXMubmV0L2dtbCcgbmFtZXNwYWNlICh3ZWxsLCBleGNlcHQgZm9y IGZpZ3VyZSAxNywgd2hpY2ggaGFzIGFuIGluY29ycmVjdCBuYW1lc3BhY2UgVVJOKS4NCg0KSXMg dGhlcmUgc29tZSB3YXkgdG8gcmVmZXIgdG8gdGhlIGF1dGhvcml0YXRpdmUgR01MIHNjaGVtYSBy YXRoZXIgdGhhbiByZWRlZmluZSB0aGUgZWxlbWVudHM/DQoNCg0KT25lIG90aGVyIG5pdDoNCiAt IHRoZSAidWJlci1jb21wbGV4LTNEIiBleGFtcGxlIGlzIHZlcnkgdHdvIGRpbWVuc2lvbmFsLg0K DQpDaGVlcnMsDQpNYXJ0aW4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBh bmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJp dmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2lu YWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============2146133556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2146133556==-- From ecrit-bounces@ietf.org Fri Feb 16 09:16:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3sP-0000Si-6t; Fri, 16 Feb 2007 09:15:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3sO-0000Sd-2a for ecrit@ietf.org; Fri, 16 Feb 2007 09:15:52 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3sD-00088G-UO for ecrit@ietf.org; Fri, 16 Feb 2007 09:15:52 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l1GEFdW06982 for ; Fri, 16 Feb 2007 09:15:39 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007021609160101594 for ; Fri, 16 Feb 2007 09:16:01 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 09:16:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Feb 2007 09:16:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on lost-04 Thread-Index: AcdR1NCn1zXH10ejQqeO0XfrwUsHig== From: "Reese, Theresa E" To: "ECRIT" X-OriginalArrivalTime: 16 Feb 2007 14:16:02.0003 (UTC) FILETIME=[FCD43230:01C751D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Ecrit] Comments on lost-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Having reviewed draft-ietf-ecrit-lost-04, I have the following comments: 1. Section 5.3 of lost-04 states, "On occasion, a server may be forced to return an expired mapping if it cannot reach the authoritative server or the server fails to return a usable answer. Clients and servers MAY cache the mapping so that they have at least some information available. Caching servers that have such stale information SHOULD re-attempt the query each time a client requests a mapping." =20 Since, based on prior feedback received in response to my comments on lost-03, there will be no warning included in a response that contains expired data, please add a statement that says that the client is expected to check 'expires' attribute associated with mapping data returned in a LoST response. There is already a statement in this paragraph that describes client behavior (i.e., that the client may cache the mapping data). I would like to see this expanded to clarify this additional client behavior. 2. The first sentence of Section 5.6 states, " A response MAY indicate the region for which the service URL returned would be the same as in the actual query, the so-called _service region_." Later on in the paragraph, there is a statement that states, "The response MUST contain at least one service boundary using the same profile as the request." =20 Since it is optional to include a in a response, it is suggested that the text in the latter sentence of the paragraph be modified as follows, "If included in a response, the element MUST contain at least one service boundary that uses the same profile as the request."=20 Also in a response to my comments on lost-03, it was stated, "A serviceBoundary needs to be requested by the client (using a serviceBoundary=3D"value" attribute) or is included by the server if = local policy indicates it." I do not see any text in lost-04 that describes the latter condition under which a element will be included in a response. 3. Section 7.3 of lost-04 states the following: "The request includes attributes that govern whether the request is handled iteratively or recursively, whether location validation is performed and which elements must be contained in the response." =20 Please change the text to read "....which elements MAY be contained in the response." Based on a previous e-mail exchange, the LoST server may or may not return the explicitly requested elements identified above, as well as others that are implicitly requested (i.e., URI, displayName, serviceNumber) depending on whether it supports them or not. As indicated in previous e-mails, my preference would be to include a warning if requested data cannot be provided in the response. However, if lost-04 addresses this situation by just omitting the unavailable information from the response (without treating it as an abnormal condition), then the text in Section 7.3 should not use the word "must". 4. In my comments on lost-03, I requested that additional text be added to Section 7.3.3 to clarify the iterative case. The response that Hannes provided to my comments on lost-03 provided a number of helpful clarifications, but I do not see any additional clarifications included in lost-04. 5. Section 7.4.2 of lost-04 states, "A server can indicate in its response which civic address elements it has recognized as valid, which ones it has ignored and which ones it has checked and found to be invalid. The server MUST include this information if the 'validateLocation' attribute in the request was true." The continued use of the word MUST in the last sentence is inconsistent with the e-mails received in response to my comments on lost-03. If a LoST server receives an iterative request for validation information, but does not support validation, either it will return an error message or it will just omit the information from the response. In my opinion, only the first option applies if the text in Section 7.4.2 continues to use the word "MUST", and Hannes described an error message that would be appropriate for this case. Henning was of the opinion that the response message should instead just omit the validation information (without any type of error/warning provided). As indicated previously, my preference is for an appropriate error/warning to be returned. If this approach is not to be supported by LoST, then the text in Section 7.4.2 should only use the word "MAY". It should be further noted that, if Henning's approach is used, changes will need to be made to Section 12 of the document which states that a warning should be provided if the server is only capable of returning part of the requested information, and an error of "not found" if the server cannot find an answer to the query. Again, my preference is to use the errors/warnings defined in Section 12 for such scenarios. 6. Section 12.2 of lost-04 states the following: "This version of the specification does not define any warning elements." =20 This statement is inconsistent with the text in Section 12 which states, " It returns a element as part of another response element if it was able to respond in part, but the response may not be quite what the client had desired" and "Unless otherwise noted, all elements below can be either an error or a warning, depending on whether a default response, such as a mapping, is included." =20 To reiterate, consistent with Hannes' response to my previous comments on lost-03, I support the use of warnings when only partial information is available. =20 Thank you for your consideration of my comments. Terry Reese=20 =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 16 09:34:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4Ap-0003lc-8H; Fri, 16 Feb 2007 09:34:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4Ao-0003lH-5u for ecrit@ietf.org; Fri, 16 Feb 2007 09:34:54 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4Am-00052Z-Vn for ecrit@ietf.org; Fri, 16 Feb 2007 09:34:54 -0500 Received: from [172.16.10.228] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 16 Feb 2007 09:34:08 -0500 id 01588477.45D5C0E0.00007AC3 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Namespaces in LoST Date: Fri, 16 Feb 2007 09:34:51 -0500 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Feb 16, 2007, at 12:05 AM, Thomson, Martin wrote: > It would appear that the Polygon and Point elements described in > the compact syntax schema are defined in the LoST namespace. > However, the examples show them to be in the 'http:// > www.opengis.net/gml' namespace (well, except for figure 17, which > has an incorrect namespace URN). > > Is there some way to refer to the authoritative GML schema rather > than redefine the elements? Yes, and we are planning to do just that. -05 will have that pattern ripped out and the text will be replaced with a reference to the OGC document. > One other nit: > - the "uber-complex-3D" example is very two dimensional. Suggestions welcome. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 19 08:54:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ8xr-0000bs-MD; Mon, 19 Feb 2007 08:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ8xq-0000Vl-6Z for ecrit@ietf.org; Mon, 19 Feb 2007 08:53:58 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJ8xk-0006hJ-KA for ecrit@ietf.org; Mon, 19 Feb 2007 08:53:58 -0500 Received: (qmail invoked by alias); 19 Feb 2007 13:53:50 -0000 X-Provags-ID: V01U2FsdGVkX19js0ACJX9j12Kzpytz/bUiSub61c6w4wVnWAkCnI +4nA== Message-ID: <45D9ABEA.6090102@gmx.net> Date: Mon, 19 Feb 2007 15:53:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ecrit] Security for Emergency Services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, together with Henning, Andy and Raj we have written a paper on "Protecting First-Level Responder Resources in an IP-based Emergency Services Architecture". We have submitted it to the NetCri workshop (see http://www.cs.umd.edu/~sharno/NetCri07/) and with the permission of the workshop program chairs we are allowed to distribute it already before the workshop (which will be April 13th, 2007). Please find the camera ready version of the paper here: http://www.ietf-ecrit.org/TEMP/Emergency-Service-Security.pdf The purpose of the paper is to give an overview of currently discussed solution proposals in order to stimulate a discussion about potential follow-up work that may need to be done in this area. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 19 18:30:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHx3-0008NH-EY; Mon, 19 Feb 2007 18:29:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHx1-0008Mw-LC for ecrit@ietf.org; Mon, 19 Feb 2007 18:29:44 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJHx0-0001kz-D2 for ecrit@ietf.org; Mon, 19 Feb 2007 18:29:43 -0500 Received: from [192.168.0.105] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 19 Feb 2007 18:29:26 -0500 id 0158811A.45DA32D6.00000FF1 Message-ID: <45DA32DC.10303@thinkingcat.com> Date: Mon, 19 Feb 2007 18:29:32 -0500 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ECRIT Subject: Re. [Ecrit] WGLC - A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, Having a look at the document, there's (only!) one thing that I'm unclear about: > RFC 1035 [RFC1035] encoding was chosen to accommodate future > internationalized domain name mechanisms. Sorry to quack like a goose, but: huh? I went through the mailing list archive (as I'm not a subscriber) and couldn't find traces of the discussion about this point, so my apologies for the lack of context. But what is this trying to say? Either the DHCP option supports IDNs natively (i.e., in Unicode), in which case: . this option is not (just) supporting domain names, it is also supporting IDNs, and . RFC 1035 conventions will not help, because they constrain the content of the octets beyond what is needed for Unicode. Or, the DHCP option is supporting encoded IDNs (IDNA), in which case they are identical to every other domain name, so it's not clear why that's a motivation for a specific encoding. Or, this group is anticipating some other developments not even on the horizon for IDN encodings, which makes the engineering hard. Would it be reasonable to just drop the paragraph altogether? Leslie. > To: > Subject: [Ecrit] WGLC - A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure > From: "Marc Linsner" > Date: Wed, 14 Feb 2007 17:26:00 -0500 > > All, > > This message marks the issuance of a working group last call (WGLC) on > ECRIT's Internet Draft entitled "A Dynamic Host Configuration Protocol > (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery > Procedure" (draft-ietf-ecrit-dhc-lost-discovery-00.txt). You may view this > document at > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.t > xt. > > Please post comments and questions to this mailing list no later than 2 > March 2007. > > -Marc Linsner- > ECRIT co-chair > > _______________________________________________ > Ecrit mailing list > Ecrit at ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 19 20:58:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJKGg-00052E-C9; Mon, 19 Feb 2007 20:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJKGe-000529-V4 for ecrit@ietf.org; Mon, 19 Feb 2007 20:58:08 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJKGd-0007IY-MC for ecrit@ietf.org; Mon, 19 Feb 2007 20:58:08 -0500 Received: from [192.168.0.41] (pool-141-153-194-152.mad.east.verizon.net [141.153.194.152]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l1K1vqV5024827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Feb 2007 20:57:53 -0500 (EST) In-Reply-To: <45DA32DC.10303@thinkingcat.com> References: <45DA32DC.10303@thinkingcat.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A455632-6ACE-4BDC-99DE-5D598BB1E763@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: Re. [Ecrit] WGLC - A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Date: Mon, 19 Feb 2007 20:57:50 -0500 To: Leslie Daigle X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm happy to drop the reference; I think this was copied from somewhere else and may or may not have made sense back then. The idea is to use IDNA, based on DHCP-WG advice received (and SIP DHCP option precedent). On Feb 19, 2007, at 6:29 PM, Leslie Daigle wrote: > Hi, > > Having a look at the document, there's (only!) one thing that > I'm unclear about: > >> RFC 1035 [RFC1035] encoding was chosen to accommodate future >> internationalized domain name mechanisms. > > > Sorry to quack like a goose, but: huh? > > I went through the mailing list archive (as I'm not a subscriber) > and couldn't find traces of the discussion about this point, so my > apologies for the lack of context. > > But what is this trying to say? > > Either the DHCP option supports IDNs natively (i.e., in Unicode), > in which case: > . this option is not (just) supporting domain names, > it is also supporting IDNs, and > . RFC 1035 conventions will not help, because they > constrain the content of the octets beyond what is needed > for Unicode. > > Or, the DHCP option is supporting encoded IDNs (IDNA), in which > case they are identical to every other domain name, so it's not > clear why that's a motivation for a specific encoding. > > Or, this group is anticipating some other developments not even > on the horizon for IDN encodings, which makes the engineering > hard. > > Would it be reasonable to just drop the paragraph altogether? > > Leslie. > >> To: >> Subject: [Ecrit] WGLC - A Dynamic Host Configuration Protocol >> (DHCP) based Location-to-Service Translation Protocol (LoST) >> Discovery Procedure >> From: "Marc Linsner" >> Date: Wed, 14 Feb 2007 17:26:00 -0500 >> All, >> This message marks the issuance of a working group last call >> (WGLC) on >> ECRIT's Internet Draft entitled "A Dynamic Host Configuration >> Protocol >> (DHCP) based Location-to-Service Translation Protocol (LoST) >> Discovery >> Procedure" (draft-ietf-ecrit-dhc-lost-discovery-00.txt). You may >> view this >> document at >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost- >> discovery-00.t >> xt. >> Please post comments and questions to this mailing list no later >> than 2 >> March 2007. >> -Marc Linsner- >> ECRIT co-chair >> _______________________________________________ >> Ecrit mailing list >> Ecrit at ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 21 14:00:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwhj-0007rC-U6; Wed, 21 Feb 2007 14:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwhj-0007mc-Bk for ecrit@ietf.org; Wed, 21 Feb 2007 14:00:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJwhh-0004cv-RS for ecrit@ietf.org; Wed, 21 Feb 2007 14:00:39 -0500 Received: (qmail invoked by alias); 21 Feb 2007 19:00:36 -0000 X-Provags-ID: V01U2FsdGVkX19C5JANw3tCsBp8drYVEYqAFLDgYNFEFIcnrxP/c7 RNBw== Message-ID: <45DC96CF.4080606@gmx.net> Date: Wed, 21 Feb 2007 20:00:31 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: Re. [Ecrit] WGLC - A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure References: <45DA32DC.10303@thinkingcat.com> <2A455632-6ACE-4BDC-99DE-5D598BB1E763@cs.columbia.edu> In-Reply-To: <2A455632-6ACE-4BDC-99DE-5D598BB1E763@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Leslie Daigle , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Leslie, Here is the updated draft: http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-ietf-ecrit-dhc-lost-discovery-01.txt I have removed the sentence you pointed to. It was a copy-and-paste bug. Ciao Hannes Henning Schulzrinne wrote: > I'm happy to drop the reference; I think this was copied from > somewhere else and may or may not have made sense back then. The idea > is to use IDNA, based on DHCP-WG advice received (and SIP DHCP option > precedent). > > On Feb 19, 2007, at 6:29 PM, Leslie Daigle wrote: > >> Hi, >> >> Having a look at the document, there's (only!) one thing that >> I'm unclear about: >> >>> RFC 1035 [RFC1035] encoding was chosen to accommodate future >>> internationalized domain name mechanisms. >> >> >> Sorry to quack like a goose, but: huh? >> >> I went through the mailing list archive (as I'm not a subscriber) >> and couldn't find traces of the discussion about this point, so my >> apologies for the lack of context. >> >> But what is this trying to say? >> >> Either the DHCP option supports IDNs natively (i.e., in Unicode), >> in which case: >> . this option is not (just) supporting domain names, >> it is also supporting IDNs, and >> . RFC 1035 conventions will not help, because they >> constrain the content of the octets beyond what is needed >> for Unicode. >> >> Or, the DHCP option is supporting encoded IDNs (IDNA), in which >> case they are identical to every other domain name, so it's not >> clear why that's a motivation for a specific encoding. >> >> Or, this group is anticipating some other developments not even >> on the horizon for IDN encodings, which makes the engineering >> hard. >> >> Would it be reasonable to just drop the paragraph altogether? >> >> Leslie. >> >>> To: >>> Subject: [Ecrit] WGLC - A Dynamic Host Configuration Protocol (DHCP) >>> based Location-to-Service Translation Protocol (LoST) Discovery >>> Procedure >>> From: "Marc Linsner" >>> Date: Wed, 14 Feb 2007 17:26:00 -0500 >>> All, >>> This message marks the issuance of a working group last call (WGLC) on >>> ECRIT's Internet Draft entitled "A Dynamic Host Configuration Protocol >>> (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery >>> Procedure" (draft-ietf-ecrit-dhc-lost-discovery-00.txt). You may >>> view this >>> document at >>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-00.t >>> >>> xt. >>> Please post comments and questions to this mailing list no later than 2 >>> March 2007. >>> -Marc Linsner- >>> ECRIT co-chair >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit at ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 22 13:59:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJA6-00011D-4V; Thu, 22 Feb 2007 13:59:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKJA4-0000yu-U1 for ecrit@ietf.org; Thu, 22 Feb 2007 13:59:24 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKJA3-0002fR-Gk for ecrit@ietf.org; Thu, 22 Feb 2007 13:59:24 -0500 Received: (qmail invoked by alias); 22 Feb 2007 18:59:20 -0000 X-Provags-ID: V01U2FsdGVkX183F+olhxU3Tw29lDQo1ftjnJpUAuU0vWCxtHvpQH GNcA== Message-ID: <45DDE806.2050600@gmx.net> Date: Thu, 22 Feb 2007 19:59:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: iesg-secretary@ietf.org, "Peterson, Jon" , "Cullen Jennings (fluffy)" , Marc Linsner References: <459FD34A.6070508@gmx.net> In-Reply-To: <459FD34A.6070508@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT Subject: [Ecrit] ECRIT Milestone Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Dear IESG Secretary, Hi Jon, Hi Cullen, although we work at full speed it seems that a milestone update for the ECRIT working group is needed: DONE Informational RFC containing terminology definitions and the requirements DONE An Informational document describing the threats and security considerations DONE A Standards Track RFC describing how to identify a session set-up request is to an emergency response center April 2007 A Standards Track RFC describing how to route an emergency call based on location information April 2007 An Informational document describing the Mapping Protocol Architecture April 2007 An Informational document describing the ECRIT Framework May 2007 A BCP document describing the emergency call support for devices Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 22 15:05:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKC8-0006O1-4V; Thu, 22 Feb 2007 15:05:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKC6-0006Nr-JO for ecrit@ietf.org; Thu, 22 Feb 2007 15:05:34 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKKC5-0004Q6-4H for ecrit@ietf.org; Thu, 22 Feb 2007 15:05:34 -0500 Received: (qmail invoked by alias); 22 Feb 2007 20:05:31 -0000 X-Provags-ID: V01U2FsdGVkX1+dGQsXJkGdbSYz2ocLo+xkw9k+WTLxUvVccKOuHu v4Yg== Message-ID: <45DDF789.1000306@gmx.net> Date: Thu, 22 Feb 2007 21:05:29 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Ecrit] Review of LoST-04, part 1 References: <45D2252C.1090401@nortel.com> In-Reply-To: <45D2252C.1090401@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Tom, thanks for your review and your text proposals. Please find my response below: Tom-PT Taylor wrote: > I've hardly started to put out comments, but given the contentious > nature of definitions, I figured this should hit the list now. I'm not > wedded to the proposed definitions, but I think they capture the usage > within LoST-04. > > 1. Organization of the document > ------------------------------- > > I find that the presentation in lost-03 has a few things out of place: > > -- Section 3 is specific to usage of the message, so it > really belongs in the introduction to section 7. You are right. I, however, think that we should extend Section 3 by including the other message exchanges to give an overview what will be described later. > > -- Section 5 is specific to the message, so it > belongs in section 7.4, immediately after section 7.4.1. A high-level > understanding of the intent of is all that is needed up to > that point. > That's certainly possible. When we decided to move the element section we thought that it would be useful since it is one of the core building blocks. > Bearing these comments in mind, please note that subsequent comments > use the existing section numbering in LoST-04. In the case of proposed > text, that numbering may have to be changed if these comments are > accepted. This possibility is flagged by enclosing section numbers in > proposed text in quotes. > > Section 1 > --------- > > para 3: LoST doesn't cache -- it supports caching. > Fixed. > ", para 4: Delete "The relationship between", so that the sentence > starts "Other functions ...". Not sure I'd call architecture a > function, but I can't think of another word at the moment. > Fixed. > Section 2 > --------- > > Little terminology from [18] is really used in this document. For > instance, "mapping" is more general in this document than in [18], and > should likely be defined explicitly here. Here is a stab at some text: > > > > Mapping > > Mapping is a process that takes a location and a service identifier as > inputs and returns one or more URIs that point to a host providing > that service or acting as an intermediary to establish communication > with the serving entity. This definition is a generalization of the > term "mapping" as used in [18], because of the potential for LoST to > be used for non-emergency services. > > Mapping is performed in LoST through exchange of the and > messages as defined in section "7". > > LoST Client and Server > > "LoST client" is the role played by a host that sends LoST query > messages and receives LoST response messages. "LoST server" is the > role played by a host that receives LoST query messages and sends LoST > response messages. In recursive operation, the same host may play both > roles. This document also uses the term "authoritative server" to > designate a host that acts in the LoST server role only and > successfully resolves the input location and service identifier to a > URI or set of URIs. > > Service Boundary > > A service boundary is the boundary or set of boundaries of a > geographic region, respectively set of geographic regions, within > which all locations will map to the same URI or set of URIs for a > given service. > > In LoST, service boundaries are expressed using ... > > Validation > > The term "validation" as used in this document is a concrete > realization of the term "location validation" as defined in section > 3.5 of [18]. > > Thanks for the text. Looks good to me (with some minor modifications). By including these terms into the LoST draft we have a bit of repetition but it could improve the readability of the draft. Ciao Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 23 04:24:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKWfM-0003Bc-8K; Fri, 23 Feb 2007 04:24:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKWfL-0003BX-P3 for ecrit@ietf.org; Fri, 23 Feb 2007 04:24:35 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKWfK-0005bb-5C for ecrit@ietf.org; Fri, 23 Feb 2007 04:24:35 -0500 Received: (qmail invoked by alias); 23 Feb 2007 09:24:28 -0000 X-Provags-ID: V01U2FsdGVkX19iakMBG2Ji5jtWk0fiaqbNeA6yCcJQoKIhVvKKvS zsow== Message-ID: <45DEB2CC.7010805@gmx.net> Date: Fri, 23 Feb 2007 10:24:28 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] Meeting Agenda -- Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, I have uploaded a new version of the agenda. It is still incomplete. Please help me to complete the agenda. Here is the current version: http://www3.ietf.org/proceedings/07mar/agenda/ecrit.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 23 05:36:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKXmV-0004Ir-Gd; Fri, 23 Feb 2007 05:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKXmU-0004Ig-9v for ecrit@ietf.org; Fri, 23 Feb 2007 05:36:02 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKXmT-0008Nd-1s for ecrit@ietf.org; Fri, 23 Feb 2007 05:36:02 -0500 Received: (qmail invoked by alias); 23 Feb 2007 10:35:59 -0000 X-Provags-ID: V01U2FsdGVkX1/0cZFw+m/0oSLcjUff35xvUFJDc1tmfPcVRA/n1I JOfg== Message-ID: <45DEC38F.2060607@gmx.net> Date: Fri, 23 Feb 2007 11:35:59 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] ECRIT Meeting Agenda -- Important Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, based on a request by Cullen we had to remove our second meeting slot. This was the 1 hour slot for the discussion with the IEEE regarding their emergency services architecture. This was necessary due to overall scheduling problems. Cullen suggested to still have our meeting with the IEEE but todo it during lunch time or any other day. I will send a separate mail to solicit feedback from the group. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 23 07:14:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKZIt-0006WO-9r; Fri, 23 Feb 2007 07:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKZIs-0006WI-5X for ecrit@ietf.org; Fri, 23 Feb 2007 07:13:34 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKZIq-0005vS-Qz for ecrit@ietf.org; Fri, 23 Feb 2007 07:13:34 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l1NC5Pr03893; Fri, 23 Feb 2007 07:05:25 -0500 (EST) Received: from [47.130.17.10] ([47.130.17.10] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 07:13:30 -0500 Message-ID: <45DEDA53.1020906@nortel.com> Date: Fri, 23 Feb 2007 07:13:07 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Review of LoST-04, part 1 References: <45D2252C.1090401@nortel.com> <45DDF789.1000306@gmx.net> In-Reply-To: <45DDF789.1000306@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 12:13:30.0138 (UTC) FILETIME=[07AADFA0:01C75744] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi. One remark. Hannes Tschofenig wrote: > Hi Tom, > > thanks for your review and your text proposals. Please find my response > below: > > Tom-PT Taylor wrote: >> I've hardly started to put out comments, but given the contentious >> nature of definitions, I figured this should hit the list now. I'm not >> wedded to the proposed definitions, but I think they capture the usage >> within LoST-04. >> >> 1. Organization of the document >> ------------------------------- >> >> I find that the presentation in lost-03 has a few things out of place: >> >> -- Section 3 is specific to usage of the message, so it >> really belongs in the introduction to section 7. > > You are right. > > I, however, think that we should extend Section 3 by including the other > message exchanges to give an overview what will be described later. > >> -- Section 5 is specific to the message, so it >> belongs in section 7.4, immediately after section 7.4.1. A high-level >> understanding of the intent of is all that is needed up to >> that point. >> > That's certainly possible. When we decided to move the element > section we thought that it would be useful since it is one of the core > building blocks. [PTT] This goes to the heart of one of Jonathan's remarks. You are thinking of data structures, where I assumed LoST-04 was documentation of a protocol. Viewed in that latter light, no matter how much effort went into the definition of , it is just one information element of just one of the messages in the protocol, and (I think) should be documented in its proper place relative to that protocol description. ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 23 07:41:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKZjt-0001mJ-9h; Fri, 23 Feb 2007 07:41:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKZjs-0001ly-1S for ecrit@ietf.org; Fri, 23 Feb 2007 07:41:28 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKZjq-00073U-70 for ecrit@ietf.org; Fri, 23 Feb 2007 07:41:28 -0500 Received: (qmail invoked by alias); 23 Feb 2007 12:41:24 -0000 X-Provags-ID: V01U2FsdGVkX1/wBYgSY2TwkXLe3wilryRQDuv7jdLUMt5IuQRSO2 cuqQ== Message-ID: <45DEE0EE.3080305@gmx.net> Date: Fri, 23 Feb 2007 13:41:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Dorothy Stanley , Bernard Aboba , Djohnston@nextwave.com, "Wijnen, Bert $Bert$" , Dorothy Stanley Subject: [Ecrit] IEEE - IETF ECRIT Emergency Services Meeting (IETF#68, Prague) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, some time back we arranged a meeting with IEEE members to have a discussion about their emergency services architecture and the alignment with the IETF ECRIT work. Everything was fine and I requested an additional 1 hour slot for ECRIT to have enough time for discussions. Now, we had to change our plans and we don't have this one hour slot anymore. We therefore need to find a date for a meeting. Please let me know what time and date is convenient for you or add the information to the following Wiki page yourself: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/PragueEmergencyServices Username: EcritGroup Passwd: ietf-ecrit Sorry for the complications. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 23 11:01:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKcqi-0007nX-Bq; Fri, 23 Feb 2007 11:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKcqh-0007nO-0n; Fri, 23 Feb 2007 11:00:43 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKcqc-0005yI-Le; Fri, 23 Feb 2007 11:00:43 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 6F61D20102; Fri, 23 Feb 2007 11:00:33 -0500 (EST) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02011-08-6; Fri, 23 Feb 2007 11:00:31 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 67C462010A; Fri, 23 Feb 2007 11:00:31 -0500 (EST) In-Reply-To: <45DEE0EE.3080305@gmx.net> To: Hannes Tschofenig MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Fri, 23 Feb 2007 11:00:28 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 02/23/2007 11:00:30 AM, Serialize complete at 02/23/2007 11:00:30 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: GEOPRIV , Dorothy Stanley , Bernard Aboba , Djohnston@nextwave.com, "Wijnen, Bert $Bert$" , Dorothy Stanley , ECRIT Subject: [Ecrit] Re: IEEE - IETF ECRIT Emergency Services Meeting (IETF#68, Prague) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0686794531==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0686794531== Content-Type: multipart/alternative; boundary="=_alternative 0057F0C38525728B_=" This is a multipart message in MIME format. --=_alternative 0057F0C38525728B_= Content-Type: text/plain; charset="US-ASCII" Hello Hannes,. I added my info to the Wiki however think we should try hard to make it within the main meeting week so that highest attendance can be achieved, even on ad-hoc. In a pinch I am available any of those slots -- would prefer earlier, say Mon or Tues. -- Peter Blatherwick Hannes Tschofenig 23.02.07 07:41 To: ECRIT , GEOPRIV cc: Bernard Aboba , OPS ADs , Djohnston@nextwave.com, Dorothy Stanley , Dorothy Stanley , "Wijnen, Bert (Bert)" , peter_blatherwick@mitel.com Subject: IEEE - IETF ECRIT Emergency Services Meeting (IETF#68, Prague) Hi all, some time back we arranged a meeting with IEEE members to have a discussion about their emergency services architecture and the alignment with the IETF ECRIT work. Everything was fine and I requested an additional 1 hour slot for ECRIT to have enough time for discussions. Now, we had to change our plans and we don't have this one hour slot anymore. We therefore need to find a date for a meeting. Please let me know what time and date is convenient for you or add the information to the following Wiki page yourself: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/PragueEmergencyServices Username: EcritGroup Passwd: ietf-ecrit Sorry for the complications. Ciao Hannes --=_alternative 0057F0C38525728B_= Content-Type: text/html; charset="US-ASCII"
Hello Hannes,.
I added my info to the Wiki however think we should try hard to make it within the main meeting week so that highest attendance can be achieved, even on ad-hoc. In a pinch I am available any of those slots -- would prefer earlier, say Mon or Tues.
-- Peter Blatherwick

Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

23.02.07 07:41

To: ECRIT <ecrit@ietf.org>, GEOPRIV <geopriv@ietf.org>
cc: Bernard Aboba <aboba@internaut.com>, OPS ADs <dromasca@avaya.com>, Djohnston@nextwave.com, Dorothy Stanley <dstanley1389@gmail.com>, Dorothy Stanley <DStanley@arubanetworks.com>, "Wijnen, Bert (Bert)" <bwijnen@alcatel-lucent.com>, peter_blatherwick@mitel.com
Subject: IEEE - IETF ECRIT Emergency Services Meeting (IETF#68, Prague)

Hi all, some time back we arranged a meeting with IEEE members to have a discussion about their emergency services architecture and the alignment with the IETF ECRIT work. Everything was fine and I requested an additional 1 hour slot for ECRIT to have enough time for discussions. Now, we had to change our plans and we don't have this one hour slot anymore. We therefore need to find a date for a meeting. Please let me know what time and date is convenient for you or add the information to the following Wiki page yourself: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/PragueEmergencyServices Username: EcritGroup Passwd: ietf-ecrit Sorry for the complications. Ciao Hannes
--=_alternative 0057F0C38525728B_=-- --===============0686794531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0686794531==-- From ecrit-bounces@ietf.org Fri Feb 23 11:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKd5x-0000Mx-17; Fri, 23 Feb 2007 11:16:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKd5v-0000KT-Ar for ecrit@ietf.org; Fri, 23 Feb 2007 11:16:27 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKd5s-0008WK-TU for ecrit@ietf.org; Fri, 23 Feb 2007 11:16:27 -0500 Received: (qmail invoked by alias); 23 Feb 2007 16:16:23 -0000 X-Provags-ID: V01U2FsdGVkX19rLZRCYrhr0eExYP3dDDB1MbSDGldvxkG78aPmrA na5A== Message-ID: <45DF1352.7050400@gmx.net> Date: Fri, 23 Feb 2007 17:16:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: peter_blatherwick@mitel.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: GEOPRIV , Dorothy Stanley , Bernard Aboba , Djohnston@nextwave.com, "Wijnen, Bert $Bert$" , Dorothy Stanley , ECRIT Subject: [Ecrit] Re: IEEE - IETF ECRIT Emergency Services Meeting (IETF#68, Prague) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Peter, peter_blatherwick@mitel.com wrote: > Hello Hannes,. > I added my info to the Wiki however think we should try hard to make it > within the main meeting week so that highest attendance can be achieved, > even on ad-hoc. I fully agree with you. > In a pinch I am available any of those slots -- would > prefer earlier, say Mon or Tues. > -- Peter Blatherwick > > The same is true for me. We once had a meeting with the 3GPP. That meeting was on Sunday. Ciao Hannes > > > > Hannes Tschofenig > 23.02.07 07:41 > > To: ECRIT , GEOPRIV > cc: Bernard Aboba , OPS ADs > , Djohnston@nextwave.com, Dorothy Stanley > , Dorothy Stanley , > "Wijnen, Bert (Bert)"