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

["James M. Polk" <[e-mail]>]

At 04:50 AM 7/2/2009, Elwell, John wrote:
>I focused on sections 1 to 3, since they have been subject to
>substantial changes. I think the changes on the whole are an
>improvement, but I still have some minor comments and nits.

John -- thanks for the review.


>Minor comments:
>- "Location Information Server (LIS) - a logical server that stores
>       geolocation records of Targets, which correspond to LbyR URIs."

I agree this term definition is fuzzy, and planned on doing more with 
it when I rev the doc before the -01 deadline.

>Several problems with this definition:
>a) What are "geolocation records"? Elsewhere in the document we talk
>about just "location" or "location information" - I doubt the need to
>introduce yet another term "geolocation record", which does not seem to
>be used elsewhere.
>b) What exactly "correspond" to LbyR URIs. Targets certainly do not
>"correspond" to LbyR URIs. Also I don't think geolocation records
>"correspond" to LbyR URIs. Is it trying to say something like "these
>records being identified by LbyR URIs"?

I'll change the wording.

>c) I don't think this definition of the term LIS is in line with usage
>within GEOPRIV documents, e.g., lis-discovery or HELD. In HELD, a LIS
>provides either a location by value or a reference. A URI provided as a
>reference will result in a recipient contacting a server to provide the
>location value, but that server is not necessarily a LIS, I believe.

I think it is, but will verify.

>At
>least I don't believe it acts as a LIS in this circumstance,

I think this is the exact circumstance in which this acts this way, 
but could be wrong, and will verify with Mary Barnes (author of 
HELD). I didn't look to the HELD docs - that have to describe this 
same thing - for a way of stating/defining all this, and I should have.

>even if the
>same physical server can also be a LIS. I think where we use the term
>LIS in location-conveyance, we should perhaps consider using something
>like "dereferencing server" instead.

that works for me, but within geopriv-speak, they use the term LIS 
for this (or I can't tell when this isn't applied in this way). I'll verify.


>- "This document describes how Location can be "conveyed" from one SIP
>    entity unsolicited to another entity using SIP [RFC3261]."
>I think it would be worth mentioning that it applies only to SIP
>requests:
>    "This document describes how Location can be "conveyed" in a SIP [RFC
>3261] request from one SIP entity unsolicited to another SIP entity."

this is a good suggestion - and I'll easily do this.


>- Later in the same paragraph: "The phrase "location conveyance"
>    describes scenarios in which a SIP user agent client (UAC) is
>    informing a user agent server (UAS) or intermediate SIP server
>    without being previously asked where the UAC is."
>This is more restrictive than the sentence in the preceding comment (in
>that conveyance is constrained to start at the UAC, rather than at a
>proxy). The sentence does not seem to add any value and can be dropped.

it is basically repeating, so I'll drop it.


>- "Location Conveyance is different from a UAC, Alice, seeking the
>    location the UAS, Bob.  Location conveyance, using SIP, never asks
>    for another entity's location be in a response.  Asking for someone
>    else's location is not discussed in this document."
>This is redundant, since the sentence two comments back already says
>"unsolicited". If we really need to say anything, we can much more
>simply say:
>    "Requesting an entity to convey its location via SIP is outside the
>scope of this document."

I had a sentence saying this, but took it out. I guess I shouldn't have.


>- "This document describes the
>    extension to SIP for how it complies with the Using Protocol
>    requirements, "
>I think this would be better worded as:
>   "This document specifies an extension to SIP to allow it to be a Using
>Protocol in compliance with the requirements of [RFC 3693]."

good suggestion


>- "Common terms are in Section 1. Section 3 provides an overview of SIP
>    location conveyance.  Section 4 details the modifications necessary
>    to accomplish location conveyance.  Section 5 gives decode examples
>    of geolocation within SIP requests, both LbyV and LbyR.  Section 6
>    articulates the SIP element type behaviors for location conveyance.
>    Section 7 discusses Geopriv privacy considerations.  Section 8
>    discusses security considerations.  Section 9 IANA registers the
>    modifications made to SIP by this document from section 4."
>This duplicates the table of contents (well, it hardly adds anything) -
>delete.

many many docs have a paragraph like this, and have a TOC, so I kept 
it here because of that practice.

I can easily drop it - because you're right, if someone had read the 
TOC, nothing here is new.


>- "Section 4 gets into guidance and limitations of this behavior."
>Section 4 seems to specify normative behaviour, so I would hardly call
>it guidance. I would delete this sentence. If we really need to retain
>such a sentence, we should use more precise wording than "gets into".

fair


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

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

can you clarify, please

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.


>- "There is no mechanism by which the veracity of these parameters can
>    be verified."
>It is not clear what "these parameters" refers to, because the term
>"parameter" has not been used in the preceding text. It would be best to
>enumerate the particular fields that this refers to.

fair comment


>- "They are hints to downstream entities on how the
>    location information in the message was originated, intended and
>    used."
>The words "was ... used" do not make sense - the information has not yet
>been used - merely conveyed. I am not sure what is intended here.

I'll make this clearer


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

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



>Nits:
>
>- In the abstract, "where SIP servers
>    make routing decisions based on the location of the user agent
>    clients"
>Change "clients" to "client", since a SIP request can have only one UAC.

fair


>- "directly or indirectly from transmitting SIP
>    entity"
>Change to
>   "directly or indirectly from a transmitting SIP
>    entity"

good catch


>- "In
>    other works"
>Change to
>   "In
>    other words"

thanks!


>- "a new SIP header"
>Change to:
>   "a new SIP header field"
>(and likewise for "a new header" later. Also other places in the
>document where "header" is used rather than "header field", even though
>we are referring to only a part of the SIP header.)

fair, in fact, I did this sweep before, but obviously didn't catch 
all of the replacements.


>- "that points to the where the
>    location is"
>Change to:
>   "that points to where the
>    location is"

thanks


>- "either in the SIP request itself "
>I think it would be more accurate to say:
>   "either in the body of the SIP request"

fair


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


>- "Transport Layer Security is expected when a request contains
>    a target's location.  Some implementations will choose to have
>    S/MIME to encrypt message bodies from source to destination."
>Shouldn't we have a paragraph break before this?

we could... and I will  ;-)

Thanks

James



>John
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore