Subject: [Sip] Comments on location-conveyance-12

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Nov 2008 16:38:17 +0000

Apologies that these comments are rather late:

Technical comments:

1. Why do we permit Geolocation in a PRACK request? Suppose the UAS
considers the location to be essential, but has some problem with it and
returns a 424 response. Where does this leave the reliable provisional
response that the PRACK request was supposed to be acknowledging? A
similar problem has been discussed with SDP in a PRACK request, and a
less-than-perfect solution has been found. However, for SDP we had to
find a solution because SDP has been permitted in a PRACK request since
RFC 3262. With Geolocation we have the opportunity to disallow it in a
PRACK request, thereby avoiding the problem.

2. In the example in 5.1:
";inserted-by="[email-masked]""
I don't think [email-masked] is a valid hostport. We could
reduce it to "atlanta.example.com", which is the same as the domain part
of the From URI, but then it would not be possible for a recipient to
distinguish whether it was inserted by the UAC or the proxy
[email-masked] proxy. Moreover, if both the UAC and the proxy
insert a location with the same inserted-by, they would not be able to
distinguish which error code relates to the location they inserted. In
this particular case LbyV is used, so location must have been inserted
by the UAC. Wouldn't it be more appropriate to use the UAC's own host
name (i.e., from its contact URI), or if it doesn't have one, its IP
address? Of course, if the IP address is behind a NAT it might not be
unique, and I suppose there is potential for conflict if the UAC is
behind two NATs. Have there been any discussions on this? It might
require more than just fixing the example - it might require more text
on UAC behaviour to address this issue.

There are other instances in the document of inappropriate inserted-by
values.

3. "If a UAC has already conveyed location in the original request of a 
   transaction, and wants to update its location information (for 
   whatever reason) after the original request is sent, or after a 
   dialog is created (regardless of how the UAC conveyed location 
   previously, as an LbyV or LbyR) - this is done by a UAC sending an 
   UPDATE request [RFC3311]"
I think we should change "transaction" to "INVITE dialog usage".
"Transaction" is certainly wrong. The question is whether we change it
to "dialog" or "INVITE dialog usage". I think  UPDATE applies only to
INVITE dialog usages.

4. "Unless stated otherwise by future standards-track publication(s), a 
   LbyR URI only has meaning within the Geolocation header field and 
   MUST NOT appear in any other SIP header field."
This is a requirement on the UAC or proxy, yet it appears in the section
on UAS behaviour.

5. "A 
   "used-for-routing" parameter MUST NOT ever be removed from a 
   locationValue in a request."
This appears in the section on UAS behaviour, yet I don't see that it is
relevant to a UAS. The UAS is the recipient, and any passing on of
location information is outside the scope of this document. Also I don't
see how it is testable. If we need to make such a statement, I think it
should be in the proxy section.

6. "Additional locationValues inserted into a request SHOULD be placed 
   the order they were generated, and not rearranged."
Again we have a normative statement on UAC/proxy behaviour in the
section dealing with UAS behaviour.

7. "Individual header parameters in any received locationValue MUST NOT 
   be modified or deleted in transit to the ultimate destination."
Again this appears in the section on UAS behaviour, and we should not
specify the transiting of location information by a UAS to elsewhere,
since that is outside the scope of this document.

8. "A UAS MUST be prepared to receive subsequent location updates from 
   the UAC, either LbyV or LbyR (regardless of how the UAS received 
   location previously from this UAC).  The UAC will convey location 
   using the UPDATE [RFC3311] method to the UAS."
See also my earlier comment about INVITE dialog usages. I think this
paragraph too is only concerned with updates within the context of an
INVITE dialog usage.

9. "This document makes it clear that if when there are more than one 
   location, each in the same PIDF-LO MUST be about the same Target 
   (identifier) and point at the same position on the earth."
I think "MUST" should be "must", because the normative requirement is
stated elsewhere. This section is concerned only with UAS behaviour, so
cannot make normative statements applicable to the UAC or a proxy.

10. "All other entities MUST 
   ignore any locationErrorValue not directed towards them."
Again, this is in the section on UAS behaviour, so we can't make
normative requirements on other entities. Change "MUST" to "must" or
"are required to".

11. "The above example says that the Location Recipient is 
   server42.example.com, and this entity believes it cannot route this 
   message without knowing the "inserter="'s location."
server42.example.com could be a UAS - there is nothing to say it is a
proxy. Since a UAS cannot route, then change "route" to "handle", which
is more general purpose.

12. "o  there MUST NOT be more than one locationErrorValue to the same 
      "inserter=" in the request."
and then later:
"The 
   error codes destined for the same inserter MUST NOT contradict the 
   meaning of the problem the Location Recipient had with a particular 
   locationValue."
I found these two statements contradictory. The first seems to say only
one locationErrorValue per inserter, and the second seems to suggest
that you can have more than one.

13. "It is allowed, but NOT RECOMMENDED, for more than one SIP element
to
   insert location into a request along its path."
and later:
"However, if location is already in a SIP request, a SIP server 
   SHOULD NOT add another LbyR that identifies the same target in the 
   PIDF-LO (in the <tuple-id> element) to the same request."
Isn't one of these statements redundant? In fact the first statement is
broader than the second statement, so I guess the second statement is
redundant. In other words, if it is not recommended that more than one
SIP element can insert location, then it follows that a second SIP
element should not add a second location identifying the same target.

14. "However, if 
   the Geolocation header parameter "routing-allowed" is present and 
   set to "no", or is not present (knowing the default behavior is "no"
   if not present, with or without a Geolocation header), SIP servers 
   MUST NOT view the contents of the LbyV message body."
Anything that receives a request is a SIP server, including a UAS. I
think "proxies" is intended here, or perhaps B2BUAs too. This is only
one example of "SIP server" or "SIP servers" throughout the document,
all of which need checking to see whether they are really intended to
include UASs. 

15. It is not clear to me that "MUST NOT view" is a testable
requirement. "MUST NOT route on" would be more appropriate.

16. "No type of SIP server can delete a "Routing-allowed" header 
   parameter,"
Should this be a MUST NOT statement?

17. "but if one is not yet present, any SIP server MAY add a 
   "Routing-allowed" header parameter with the value set to "no" only."
This seems a rather pointless thing to do. Why can't it be set to "yes"
if there was no location there previously (and therefore upstream
entities had not already used location for routing)?

18. "If there are any errors during dereferencing, or in
   the PIDF-LO itself, the proxy will error the original request to the
   UAC with a locationErrorValue indicating what the proxy concluded 
   was wrong with the location."
What does "will error" mean here? Does it mean return a 4xx/5xx/6xx
response code, or does it mean wait for a downstream entity to return a
response code and insert a Geolocation-Error?

Nits
19. "The cid-url is defined in [RFC2392] to locate message body 
   parts.  This URI type MUST be present in a SIP request if location 
   is transmitted LbyV only."
I think "only" should be deleted.

20. In 4.3.5 on the subject of error 500:
"Action(s) to be taken by Geolocation-Error receiver to a 1XX:"
Change 1XX to 5XX.

21. In the example in 5.1:
"Contact: <sips:[email-masked]>"
This is Alice's AOR (identical to what is in From) - it should be
different, i.e., a contact URI.

22. "understanding 
   that there are no IETF police"
Is this really an appropriate statement for an RFC? Delete.

John

_______________________________________________
Sip mailing list  https://www.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: Wed, 26 Nov 2008 12:58:58 -0600

John

Thanks for the excellent review. I have comments in-line below

At 10:38 AM 11/26/2008, Elwell, John wrote:
>1. Why do we permit Geolocation in a PRACK request?

because I couldn't come up with a good enough reason to prohibit it 
in any Method except ACK and CANCEL.  My preference is to not allow 
it in a BYE either, but I've received more than one comment that this 
shouldn't be prevented - as there may be a use down the road that we 
cannot foresee now.

>Suppose the UAS
>response that the PRACK request was supposed to be acknowledging?

The thinking is that any 424 rejection, where Location is mandated 
(i.e., essential), overrides subsequent requests (i.e., transactions) 
within the same Call-ID until the problem about the Location (it's 
bad, it's invalid, it's not present, it can't be parsed, it can't be 
dereferenced, etc) is resolved.

Is this something you do not agree with.

Removing PRACK from being allowed to carry a Geolocation header is 
easy, I just need a good enough reason to do it.

>A
>I don't think [email-masked] is a valid hostport.

I coped this from what's allowed in a Via header, therefore I believe 
it should be.

>We could
>[email-masked] proxy.

Exactly the problem with not identifying the exact host who inserted 
the location in the first place. This is an identifier to a 
particular host that inserted a particular location to inform the 
location recipient that determined the location was bad in order to 
target the return e2e message at a particular host in the signaling 
path that their location was considered bad and understand that host 
(and no other host) need pay attention to the error code in the 
locationErrorValue.

>Moreover, if both the UAC and the proxy
>insert a location with the same inserted-by

this would not happen, if this spec is followed. Each inserter= would 
be different. Pragmatically, if they are not, then each will have to 
act according to the error code.

>, they would not be able to
>distinguish which error code relates to the location they inserted.

yep, but that's their problem. Each host needs to identify themselves 
uniquely for this reason, otherwise they suffer not knowing which 
host this error is for, but will have to act as if it were both hosts.

>In
>name (i.e., from its contact URI)

I mentioned this is copied from the Via header, so this ought to be 
good enough. Let me know if it is not.

>, or if it doesn't have one, its IP
>address?

IP addresses will be overwritten by SBCs, pragmatically, so I'm not 
sure this is enough of an identifier, do you?

>  Of course, if the IP address is behind a NAT it might not be
>behind two NATs.

yes - this is a concern

>Have there been any discussions on this?

yes

>It might

given what you and I have said above, what merger of text would you suggest?

>There are other instances in the document of inappropriate inserted-by

I believe, though, that they are all consistent now. Any change will 
be global also.

>to "dialog" or "INVITE dialog usage". I think  UPDATE applies only to

I'll accept your correction, and change the text to "INVITE dialog 
usage" to be completely clear here.

>This is a requirement on the UAC or proxy, yet it appears in the section

yes - to guide the UAS to not pay attention to a LbyR URI anywhere 
else than a Geolocation header. The point here is to disallow usage 
of a Location URI in any header except the Geolocation header (i.e., 
not stuffed into another header).

>relevant to a UAS.

this provides the UAS with strong guidance that a locationValue has 
been used to make a routing decision. Since more than one 
locationValue can be in a request, having this indication inside each 
locationValue that was used for routing decisions gives the UAS an 
indication - call it a history - of the path of the request towards the UAS.

 From a historical point of view, this provides an after-the-fact 
account of how each routing entity made its decision to route the 
request. This was requested specifically from the emergency calling 
folks so they can figure out if a particular routing entity made a 
bad decision - optimistically believing they can modify routing 
decisions for future/similar locations in requests.

>The UAS is the recipient, and any passing on of

this is specific to the answer in bullet #5, to give the UAS a path 
of entities the request passed through, in order, so the UAS can 
learn which location the request was routed to first, then which was 
second <and so on>.

>since that is outside the scope of this document.

but this is a *hint* at those nasty things called B2BUAs and SBCs...

>paragraph too is only concerned with updates within the context of an

I'll make the same correction to "INVITE dialog usages"

>stated elsewhere.

ok

I'll also correct the "...that if when there..." part of the 
sentence, given that it doesn't make much sense (oops).

>This section is concerned only with UAS behaviour, so

good suggestion

>proxy. Since a UAS cannot route, then change "route" to "handle", which

good suggestion

>I found these two statements contradictory.

yeah - thanks for catching this.

This is an artifact from the old way I proposed doing the location 
error messages to the newer (and simpler) way of doing location error 
messages. The former text is true, and the latter needs to be 
modified or deleted.

>The first seems to say only
>Isn't one of these statements redundant?

yep

>In fact the first statement is

correct

>all of which need checking to see whether they are really intended to

yes, if any location recipient intermediary wants to view a location, 
it *must* first look to see *if* it has permission to do so, and that 
permission is in the "routing-allowed" header parameter. Is this not 
clear? Does it need to be reworded to get this meaning across?

>requirement. "MUST NOT route on" would be more appropriate.

Geopriv wants this to mean "MUST NOT view" fully knowing their are no 
IETF police.  The aim is to prevent viewing and then the potential 
for storing and sending to a non-signaling path 3rd party would be 
prevented (if the intermediary obeyed this spec).

Perhaps this is testable by demonstrating that if 
"routing-allowed=no", that the message's location is immediately 
removed from the intermediary's cache...?

>Should this be a MUST NOT statement?

fair point, I'll change the text

>This seems a rather pointless thing to do.

the intent from the Geopriv ID is to mandate the default behavior at 
each intermediary (that follows this spec) to consider the policy 
imposed by the originator of the request to be "no" unless the flag 
is set to yes.

>Why can't it be set to "yes"

This indication is meant to dissuade any location inserted by any 
intermediary (meaning the UAC did not insert location in the first 
place) from using its own policy to inform downstream entities of the 
UAC's location. In other words, this text is meant to allow a UAC to 
tell everyone downstream that "I don't want my location used for 
routing, even if I did not include my location in this request - but 
someone else did".

Does this make sense?

Does the text need to be changed to reflect this meaning (if the 
existing text doesn't make this clear)?

>response code

a 424 only, but with a LocationErrorValue that's in section 4.3 of 
the existing version.

>, or does it mean wait for a downstream entity to return a

no, it does not mean this.

>I think "only" should be deleted.

fair

>"Action(s) to be taken by Geolocation-Error receiver to a 1XX:"

good catch, thanks

>different, i.e., a contact URI.

thanks, I'll change it

>Is this really an appropriate statement for an RFC? Delete.

<mumble> .... but I want to make a point here that this is what's going on....

Do you have an alternate text suggestion that conveys this meaning, 
but isn't so blatant?

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 28 Nov 2008 13:43:21 +0000

James,

Thanks for your responses. Please see my further remarks below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of James M. Polk
> Sent: 26 November 2008 18:59
> To: Elwell, John
> Cc: SIP List
> Subject: Re: [Sip] Comments on location-conveyance-12
> 
> John
> 
[JRE] My feeling is that we should either remove PRACK or add some
explanation of how a UAC should behave if it receives a 424 to a PRACK
request (taking into account that there is an unacknowledged reliable
18x outstanding). I will go with the majority as to which of these two
options we take.

> I coped this from what's allowed in a Via header, therefore I believe 
[JRE] From my understanding of the ABNF for hostport, it cannot contain
"@". I don't know why you think this is allowed in a Via header - I
could not find any evidence.

> (and no other host) need pay attention to the error code in the 
[JRE] Depends on resolution of the previous comment.

> act according to the error code.
[JRE] Depends on resolution of the earlier comment.

> good enough. Let me know if it is not.
[JRE] See above.

> given what you and I have said above, what merger of text 
[JRE] I need agreement on what can go in the inserted-by field before I
can make any specific proposals.

> I believe, though, that they are all consistent now. Any change will 
[JRE] Yes, I know they are consistent, but I think they are wrong.

> not stuffed into another header).
[JRE] If we are making a normative statement about what a UAC or proxy
can insert in other header fields, that should appear in the section
dealing with UAC or proxy behaviour respectively. If we are just
reminding the reader that other header fields cannot carry a LbyR URI,
we should not use RFC 2119 language. For the latter case, just changing
"MUST NOT" to "should not" would suffice.

> indication - call it a history - of the path of the request 
[JRE] If we are trying to assist the UAS implementer, we should not use
RFC 2119 language. We should rephrase something like "A
"used-for-routing" parameter, once inserted by an entity, should not be
removed by any downstream entity and should reach the UAS".

> decisions for future/similar locations in requests.
[JRE] Yes, I understand the reason for it - it just needs to be
reworded.

> learn which location the request was routed to first, then which was 
[JRE] So again, RFC 2119 language should not be used. We should say
something like "Multiple locationValues received in a request will
appear in the order in which they were inserted by upstream entities."

> but this is a *hint* at those nasty things called B2BUAs and SBCs...
[JRE] This might not be clear to the reader. Elsewhere we have a
statement "In the spirit of informing implementers of B2BUAs and SBCs,
each 
   server type really should adhere to the above proxy guidance with 
   respect to the "Routing-allowed" header parameter"
If we had similar statements about other aspects of proxy behaviour that
B2BUAs should adhere to, I think that would be better. Then the sentence
on which I commented could be deleted.

> messages. The former text is true, and the latter needs to be 
[JRE] Good.

> clear? Does it need to be reworded to get this meaning across?
[JRE] This is the section on proxy behaviour. A UAS implementer will not
necessarily look at this section, so we should not make normative
statements about UAS in this section. The term "SIP servers" includes
UASs, and therefore I have a problem with it.
 
> removed from the intermediary's cache...?
[JRE] I find this rather obscure, but I won't press the point if
everyone else is happy.

> existing text doesn't make this clear)?
[JRE] I can live with it as it is.

> no, it does not mean this.
[JRE] So make it clear what is meant, rather than just saying "will
error".

> Do you have an alternate text suggestion that conveys this meaning, 
[JRE] Well, there are no IETF police to ensure that a proxy conforms to
proxy requirements, and no IETF police to ensure that a UA conforms to
UA requirements, but we don't bother to remind the reader. So why remind
the reader in this case? I would prefer just to delete the phrase.

John