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

From: "Roger Marshall" <[email-masked]>
Date: Sun, 24 Feb 2008 14:54:47 -0800

Part 1 - Editor Responses to Richard Barnes' suggested changes to:
draft-ietf-geopriv-lbyr-requirements-01 back in Dec.

Richard:
With apologies for taking so long, please find my editor responses to
your long-waiting comments/questions, below.

My goal is to at least get these early edits folded into an -02 by the
deadline.

These edits don't fully take into account all the latest nuances
recently discussed on the list, such as the form of Figure 1. itself, so
will be sequential, always with deference to wg list acceptance (or
not).

-roger marshall.

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 4:01 PM
> To: 'GEOPRIV'; Roger Marshall
> Subject: Comments on introductory text in 
> draft-ietf-geopriv-lbyr-requirements-01
> 
> 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),..."

RSM - Agree, have changed text in -02

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

RSM - Partly agree, 1 & 4, the creation/allocation and
destruction/cancellation is an action that is performed by the server,
based on either target's request to do so, or some other trigger (e.g.,
timer value to destroy, "watcher" request for location URI, etc.  I've
modified the -02 text to take this into account.

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

RSM, Partly agree, not opposed to thinking of two protocol types, mgmt &
dereference, but this draft may not be the right place to specifically
talk about, even name, one of them - a so-called "LUMP" protocol.  So,
I've left the term LUMP out.  It seems to me that a definition for LUMP
might belong in a different draft (e.g., its own).

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

RSM - Originally, this text was here to represent that the discussion of
location URI had to do with "location" of the subscriber, not linked
with the "identity" of the subscriber.  To me, this paragraph seems to
add nothing useful, so I've deleted it on the this next iteration.

> 
> Section 2.
> Why is there all this white space?

RSM - White space gone.

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

RSM - Okay with merging the structure - will be done in -02 version.  No
LUMP term though - for that, I'd like to get more wg/list feedback as to
whether it fits this draft, or not.

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

RSM - Okay. This makes sense.

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

RSM - no contest. text modified.

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

RSM - This is good approach.  Existing text replaced w/above.

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

RSM - removed "randomized" - section rewritten based on suggestion
above.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

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