Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 02 July 2009 18:07 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0103A6DC3 for <sipcore@core3.amsl.com>; Thu, 2 Jul 2009 11:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+BR7pxEqWqO for <sipcore@core3.amsl.com>; Thu, 2 Jul 2009 11:07:18 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2AF853A6DB4 for <sipcore@ietf.org>; Thu, 2 Jul 2009 11:07:18 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM6008BQ2CROZ@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 02 Jul 2009 19:07:39 +0100 (BST)
Date: Thu, 02 Jul 2009 19:07:39 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-reply-to: <XFE-SJC-212tWBXDDvY00004b9c@xfe-sjc-212.amer.cisco.com>
To: "James M. Polk" <jmpolk@cisco.com>, sipcore@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218C331@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
Thread-Topic: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3
Thread-Index: Acn7OPkzw37WgkI/T+yFA/Ay04T13wABGvew
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> <XFE-SJC-212tWBXDDvY00004b9c@xfe-sjc-212.amer.cisco.com>
Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2009 18:07:19 -0000

James,

Thanks for attending to my comments. Just some remarks on the ones you
queried.

> >- "It is possible, and it fact, planned in certain
> >    circumstances to have SIP requests routed based on the 
> location of
> >    the target. This means SIP servers can be location recipients. If
> >    this is not desired by a location inserter - the act of including
> >    location into this request, then a separate indication 
> is given in
> >    the Geolocation header it this usage is allowed."
> >I am not sure what the last sentence means - a "location inserter" is
> >not an "act of including location into this request".
> 
> the inserter term does come out of the blue, so I'll clarify this, as 
> it is an important point.
[JRE] Sorry, perhaps my comment was not clear, but the way the sentence
is constructed suggests that "a location server" is "the act of
including...". I don't have a problem with the term "inserter", but with
the words that follow and the general sentence construction.

> 
> >I think what might
> >be undesirable is not the fact that SIP servers can be location
> >recipients, but the fact that they might use location information for
> >routing.
> 
> you do not like the idea of servers routing a request based on the 
> contained location?
[JRE] My comment is misunderstood. I am talking about what the inserter
does not desire. I believe the text is trying to cover the case where
the location inserter does not desire that location be used for routing.

> 
> can you clarify, please
[JRE] I hope my explanations above are clear.

> 
> if you do feel this way, then I disagree with you, as this is central 
> to emergency services and other source based routing (i.e., directing 
> the message based on where the UAC is, instead of what the 
> destination address is).
> 
> >I think the last sentence should be rewritten something like
> >this.
> >   "The location inserter is able to include a separate 
> indication in the
> >Geolocation header field to denote whether routing on the 
> basis of the
> >target's location is permitted."
> 
> regardless of hte above, this sentence is not wrong, and does make a 
> good point, so I'll look at including it.
> 
> 
> >If we do this, then the last sentence seems to follow on 
> nicely from the
> >first sentence, and the second sentence seems to get in the way, so
> >delete the second sentence. If we really need to retain the second
> >sentence, at least change "SIP servers" to "SIP proxies" 
> (since a UAS is
> >also a SIP server).
> 
> wrt proxies vs. servers -- I tried to account for there being B2BUAs 
> at the same place as proxies would be, to attempt to get them to 
> behave in nearly identical ways based on this spec.
[JRE] SIP RFCs have traditionally not specified B2BUA behaviour (whether
or not that is good, I don't wish to debate here). Also, if you do want
to include B2BUAs, you would need to make it more clear, e.g., define
server as meaning proxy or B2BUA (maybe redirect too, I guess). On the
other hand, a UAS, although it is a server, cannot route, so maybe my
point is moot.

> >- " LbyR refers to a UA
> >    including a location URI in a SIP request header field 
> which can be
> >    dereferenced by a Location Recipient to receive Alice's Location
> >    Object, in the form of a PIDF-LO."
> >The header field is not dereferenced, it is the location URI that is
> >dereferenced.
> 
> this is an artifact of the acronym "LbyR" being considered an 
> archiecture by the Geopriv WG for about a year (some still feel it 
> is), where I believe LbyR is just a location URI.  This is an attempt 
> to have the Geopriv folks understand that the Location URI, which is 
> the Geolocation header value is used to dereference the 
> Target's location.
[JRE] I agree, but my original complaint still holds, i.e., it is the
URI that is dereferenced, not the header field. The header field
contains more than just the URI.

> 
> >I would suggest (also making other parts of the sentence
> >more generic):
> >    "LbyR refers to a Location Server
> >    including in the header of a SIP request a location URI 
> that can be
> >    dereferenced by a Location Recipient to receive a Location
> >    Object, in the form of a PIDF-LO, representing the Target's
> >location."
> 
> interesting suggestion... connecting the UAC as the Target that's 
> really acting as a Location Server. While true, this might confuse 
> SIP specific folks.  Then again, maybe not - given that what you 
> state above is accurate.
[JRE] The point I was trying to make is that we also allow a proxy to be
a Location Server, i.e., to insert the location. Location Server is
therefore more accurate than UA.

> >- "or on an external server (LbyR)"
> >It is not clear what "external" is relative to. Change to:
> >   "or on a server (LbyR)"
> 
> it is meant to emphasize that LbyR is a location URI pointing towards 
> the location record that does not reside on the location target 
> itself (even if the target is an LS), it is on another entity. 
> perhaps I do not need to make this point.
[JRE] It is not clear to me, so I would indeed prefer to remove
"external".

John