Re: Comments on location-conveyance-12

John

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

At 10:38 AM 11/26/2008, Elwell, John wrote:
>Apologies that these comments are rather late:
>
>Technical comments:
>
>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
>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?

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
>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 protected]""
>I don't think [email protected] is a valid hostport.

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

>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 protected] 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
>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)

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
>unique, and I suppose there is potential for conflict if the UAC is
>behind two NATs.

yes - this is a concern

>Have there been any discussions on this?

yes

>It might
>require more than just fixing the example - it might require more text
>on UAC behaviour to address this issue.

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
>values.

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


>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.

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


>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.

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).


>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.

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
>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.

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>.


>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.

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


>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.

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


>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.

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
>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".

good suggestion


>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.

good suggestion


>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.

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
>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?

yep

>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.

correct


>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.

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?


>15. It is not clear to me that "MUST NOT view" is a testable
>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...?


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

fair point, I'll change the text


>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.

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"
>if there was no location there previously (and therefore upstream
>entities had not already used location for routing)?

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)?


>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

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
>response code and insert a Geolocation-Error?

no, it does not mean this.


>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.

fair


>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.

good catch, thanks


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

thanks, I'll change it


>22. "understanding
>    that there are no IETF police"
>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?


>John

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