Subject: [Geopriv] a review of draft-linsner-geopriv-lcp-00

From: Andrew Newton <[email-masked]>
Date: Fri, 17 Feb 2006 08:14:41 -0500

<co-chair hat="off"/>

After reading draft-linsner-geopriv-lcp-00, I come away with two  
conclusions: 1) I'm fairly certain I understand the purpose and  
motivation behind this specification, but 2) I couldn't implement it.

1) I like the fact that the draft clearly states that LCP is a  
sighting protocol.  This stops me from guessing about use cases and  
client interactions.  I also appreciate a lot of the other text  
explaining why TCP is the transport under consideration, etc...  In  
general, the problem being solved is clearly stated.

2) However, this specification does not list any data formats or  
protocol operations.  I suppose that there may be no need for this on  
the client side as the mere client connection to the server provides  
the IP address of the client to the server.  However, this is not  
stated.  Nor is it stated what information and format is handed back  
to the client.

The big question I had when I finished reading this draft was  
"Doesn't HELD do this?"  HELD runs over TCP (and TLS).  HELD uses  
source IP addresses as the database location key.  And HELD can be  
used as a sighting protocol.

-andy

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

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 20 Feb 2006 12:05:55 -0500

> general, the problem being solved is clearly stated.

Thanks!

> stated.

Our current thinking is that a client-to-server message may be required in
order to notify the LIS application of a TCP connection (assuming the
application doesn't poll the stack for connection data).  We believe this
message should be as simple as a single character.

  Nor is it stated what 
> information and format is handed back to the client.

The intention is to use the same objects that are defined in RFC3825 and
civil-09.  We obviously need to clarify this better in the text.

> 
> The big question I had when I finished reading this draft was "Doesn't 
> HELD do this?"  HELD runs over TCP (and TLS).  HELD uses source IP 
> addresses as the database location key.  And HELD can be used as a 
> sighting protocol.

The advantage of LCP over HELD is that it is much simpler.

LCP uses a port of it's own, not "tunneled" through http.  This allows for
broadcast discovery of the LIS, all under control of the L2/L3 provider.
This would be a large benefit to the current practice of deploying
residential ATAs within the home gateway/router.   Also included in this
mechanism is the transparent ability to cooperate with NATs/PATs if the LCP
client is "inside" the home network.  Since there is no network information
in the protocol data, normal NAT/PAT operation of address/port substitution
will work without the need for STUN/TURN/ICE/etc.

-Marc-