Subject: Re: [Sip] WGLC on draft-ietf-sip-location-conveyance

From: [email-masked]
Date: Mon, 2 Apr 2007 09:43:35 +0530

Some comments/questions on the draft. 

1) Multiple Locations:
- Section 5.3.1
A server/proxy can add gelocation value to the existing geolocation 
header provided by UAC. In that case the messsage would look like this:

Geolocation: <cid:[email-masked]>; inserted-by=endpoint,
             <sips:[email-masked]>; 
             inserted-by=server; 

=>How the location recipient will decide which location is to 
be referred to? Either the one provided in the Sip message (CID URI) 
or he has to subscribe to the location provided in SIPS URI?

2) Location by reference overhead:
Look at the following scenario (P - is also a location recipient):

             LIS                                LIS 
            ^  |                                ^  | 
SUBSCRIBE |  | NOTIFY     SUBSCRIBE |  |NOTIFY
            |  |                                |  |
UA ------->  P1 ------------------>  P2  ----------->
   INIVITE           INVITE                INVITE

In order to take action based on "retransmission-allowed" or not, 
P1 has to subscribe to the LIS (Location Information Server), 
obtain the location and then take the action. The same has to be 
done by all the intermediate proxies. So is this not a overhead?

3) "retransmission-allowed"
Even if "retransmission-allowed" value is set to "no", can the 
proxy remove the PIDF location object from the message? RFC 3261 
does not allow any proxy to add or delete the message body. So what 
is the use of "retransmission-allowed" with value "yes" or "no"?

4) What is the behavior in following case:

Retransmission-allowed Routing-query-allowed Transmission for Query
---------------------- --------------------- ----------------------
        "no"                  not present           ?????

5) "message-routed-on-this-uri" tells the downstream entity that 
is was routed based on location once. In section  5.3.1 it is 
mentioned that in case multiple times if routing is done based on 
location still only one latest entry of "message-routed-on-this-uri" 
is sufficient. 

Why downstrem entity need to know that only one routing has 
happened (if at all it needs to know)? Why it need not find out 
multiple location based routing was done?

6) Section 3.2: Use of the header in BYE, INFO and REFER 
Methods are allowed, although no purpose is known.  Conveying 
location in a CANCEL, BYE, ACK or PRACK is not defined. 

Conveying location in "BYE" is defined or not?

7) <sips: [email-masked]> or <sips:server.com/username> 
are these same? Is the second form a valid SIP URI?

8) Why only PIDF format is selected.
 
9) Assume the case that UAC has sent his identity in the first INVITE. 
Callee would have subscribed to that identity and would get the 
caller's location. Now if caller's identity is changed and caller 
sent a new RE-INVITE message. Should callee then stop subscription 
with first location and should subscribe to the new location? 
There is no behaviour with respect to this is mentioned in UAS scope?

regards
Rishu

"Drage, Keith \(Keith\)" <[email-masked]> 
03/05/2007 01:05 AM

To
<[email-masked]>
cc
[email-masked], [email-masked], [email-masked]
Subject
[Sip] WGLC on draft-ietf-sip-location-conveyance

(As WG chair)

This is to announce a working group last call of 

http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-07.txt

Due to the presence of IETF#68 in Prague, this is an extended last call 
(for four weeks), and comments should be provided by start of business on 
Monday 2nd April 2007.

However if you think there are significant technical issues that should be 
raised in IETF#68, please review the document well before that time to 
make your comment to the list, so that such discussion in the IETF meeting 
can occur.

Please provide all comments to the SIP mailing list, and also to the 
document authors listed (and mailing addresses) listed at the end of the 
document. For each comment, it is ideal to provide the copy the specific 
part of the text the comment is against, in order to provide context of 
the comment, as well as identifying the section/page and the comment 
itself. 

Please also clearly indicate whether the comment is editorial/technical, 
and if technical the degree of the comment, e.g. minor, major flaw, wrong 
solution, or whatever. This helps in assessing the order in which comments 
get addressed when they are reviewed.

In parallel with WGLC, a review team has also been set up to review the 
document, and this review team will review at least the significant 
comments for implementation. I will be addressing them in a separate mail.

As the document is a location supporting protocol, the document will also 
be reviewed by the GEOPRIV group. However it is appropriate for all 
readers to review the document against the GEOPRIV requirements for such 
protocols, which may be found in RFC 3963.

The above document however does not cover location by reference. There is 
a preliminary set or requirements in 

http://www.ietf.org/internet-drafts/draft-marshall-geopriv-lbyr-requirements-00.txt

For which we would like to align with whatever that document develops 
into. Therefore it is appropriate to review against this document, and 
identify differences. These could either be taken as comments against the 
draft-ietf-sip-location-conveyance, or against the location by reference 
requirements.

Regards

Keith

Keith Drage
+44 1793 776249
[email-masked]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 24 Apr 2007 14:43:19 -0500

See comments in-line

>or he has to subscribe to the location provided in SIPS URI?

This is a local policy decision - when there is more than one 
location (either by-value or by-reference or one or more of both) in 
a SIP message.  This is the complication of allowing more than one 
location in a SIP message.

>done by all the intermediate proxies. So is this not a overhead?

this is location conveyed indirectly.  If location is not *in* the 
message, it MAY have to be retrieved from an external source.

We have concluded that LbyR (Location-by-Reference) does not violate 
the retransmission flag in an LbyR dereference.

BTW - both P1 and P2 will likely SUB/NOT to the same LIS for the same 
location-by-reference.

>proxy remove the PIDF location object from the message?

no, per 3261 (as you state)

>RFC 3261

I believe this is discussing whether or not the proxy can copy the 
location and send it somewhere else (i.e. not in this transaction).

>Retransmission-allowed Routing-query-allowed Transmission for Query

Transmission for Query is "not allowed"

>location still only one latest entry of "message-routed-on-this-uri"

This will be corrected to keep the "message-routed-on-this-uri" for 
each location URI the message was routed on, in times where more than 
one proxy routed the message from different URIs (locations in the message).

>happened (if at all it needs to know)?

The goal of this is to give routing information to the PSAP for their 
consumption, and after the call forensics (if the call was misrouted 
or something went wrong). PSAPs want to have the ability to go to 
where the problem was and request a correction so it doesn't happen again.

>Why it need not find out

again, this will be corrected. And, hopefully, if there is routing 
done more than once, any subsequent routing would correct any error done.

>Conveying location in "BYE" is defined or not?

this is an error, and Location is should not be in a BYE (unless 
someone has a use case indicating a reason for it to be?)

>are these same? Is the second form a valid SIP URI?

I believe so. My co-author put this in.  Because you're questioning 
this, we will check.  Thanks!

>8) Why only PIDF format is selected.

because the IETF and the emergency services community (to date) has 
requested the least amount of errors possible, and limiting Location 
to be only in one format (which the IETF is pushing into IEEE, ATIS, 
TIA and other SDOs) means there is hopefully no information lost in 
any translation when converting location formats.

>9) Assume the case that UAC has sent his identity in the first INVITE.

this is likely

>caller's location.

right now, one UA(1) Subscribing to another UA(2) for UA2's location 
is a pull mechanism and is not defined in this document.  That's 
being left for a future ID.

>Now if caller's identity is changed and caller

correct, see just above to read that this is out-of-scope for the 
Location Conveyance ID.

Thanks for the detailed review, and sorry for the late response.

>Due to the presence of IETF#68 in Prague, this is an extended last 
>call (for four weeks), and comments should be provided by start of 
>business on Monday 2nd April 2007.
>
>However if you think there are significant technical issues that 
>should be raised in IETF#68, please review the document well before 
>that time to make your comment to the list, so that such discussion 
>in the IETF meeting can occur.
>
>document authors listed (and mailing addresses) listed at the end of 
>the document. For each comment, it is ideal to provide the copy the 
>specific part of the text the comment is against, in order to 
>provide context of the comment, as well as identifying the 
>section/page and the comment itself.
>
>Please also clearly indicate whether the comment is 
>editorial/technical, and if technical the degree of the comment, 
>e.g. minor, major flaw, wrong solution, or whatever. This helps in 
>assessing the order in which comments get addressed when they are reviewed.
>
>In parallel with WGLC, a review team has also been set up to review 
>the document, and this review team will review at least the 
>significant comments for implementation. I will be addressing them 
>in a separate mail.
>
>As the document is a location supporting protocol, the document will 
>also be reviewed by the GEOPRIV group. However it is appropriate for 
>all readers to review the document against the GEOPRIV requirements 
>for such protocols, which may be found in RFC 3963.
>
>The above document however does not cover location by reference. 
>There is a preliminary set or requirements in
>
>For which we would like to align with whatever that document 
>develops into. Therefore it is appropriate to review against this 
>document, and identify differences. These could either be taken as 
>comments against the draft-ietf-sip-location-conveyance, or against 
>the location by reference requirements.
>
>
>Regards
>
>Keith
>
>Keith Drage
>+44 1793 776249
>[email-masked]
>
>the individual to whom it is addressed. It may contain privileged or 
>confidential information and should not be
>circulated or used for any purpose other than for what it is 
>intended. If you have received this message in error,
>please notify the originator immediately. If you are not the 
>intended recipient, you are notified that you are strictly
>prohibited from using, copying, altering, or disclosing the contents 
>of this message. Aricent accepts no responsibility for
>loss or damage arising from the use of the information transmitted 
>by this email including damage from virus."