Subject: [Geopriv] Comments on introductory text in draft-ietf-geopriv-lbyr-requirements-01

From: Richard Barnes <[email-masked]>
Date: Thu, 06 Dec 2007 16:00:47 -0800

Part 1 in a three-part series.
1. Comments on introductory text
2. Comments on requirements
3. Comments on security considerations

Section 1. First paragraph.
SIP is not the only mechanism for carrying LbyV.  Email, for example,
works as well, or XMPP, etc.  Revise to say "While there are already
direct mechanisms for providingn location directly (e.g., as part of the
SIP signaling protocol),..."

Section 1. Second paragraph.
I would re-frame this as follows.  There are four-high-level operations
that you want to do with an LbyR.
1. Creation / allocation	(target - server)
2. Configuration 		(target - server)
3. Dereference			(deref. client - deref. server)
4. Destruction / cancellation	(target - server)
Given the pattern of communications, it makes sense to group these
functions into two protocols.  Functions 1,2, and 4 belong to a
management or configuration protocol, while function 3 belongs to a
dereference protocol.  (LCPs are a special case of the management
protocol; for example, HELD implicitly creates and configures a
reference)  I suggest the term "Location URI Management Protocol", or "LUMP.

Section 1. Last paragraph.
I don't understand what this paragraph means.  What are you ruling out?

Section 2.
Why is there all this white space?

Section 3.1.
This section should be merged into Section 3.  As mentioned above, I
would replace the definition of "Location Configuration Protocol" with
something like "Location URI Management Protocol (LUMP)".

Section 4.
I would re-title this as "Overview of Location by Reference".

Section 4. First paragraph.
It's not just in mobile networks that polling's not efficient!

Section 4. Figure 1
Change the LCP->LUMP

Section 4. "The following list ..."
This should be describing Figure 1, with three points.  In brief:
1. Target requests reference from server; server creates, delivers
2. Target conveys reference to recipient (OUT OF SCOPE)
3. Recipient dereferences reference, either by request/response (HTTP)
or by pub/sub (SIP SUBSCRIBE)

Section 4. "Note that the Target ..."
1. Need to remove pub/sub language from the first sentence to make it
general.
"subscribe to its own location information"
--> "dereference the location URI to obtain its own location information"
2. I would rephrase the example as follows:
For example, the Target might obtains a subscription URI (e.g., a SIP
URI) from the HELD, the Geopriv layer 7 location configuration protocol.
  The target can then subscribe to the URI in order to be periodically
notified of its current location.  The endpoint can also express a
geospatial boundary (using [ref:geopriv-policy]), so that it will not be
notified of location until it leaves that boundary.

Section 4. "For LbyR..."
Remove the word "randomized".

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv