Subject: [Geopriv] Re: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Nov 2005 14:55:09 -0500

I'm fine with that approach. Certainly simpler to describe...

Before I draft text, anybody objecting to this?

Bernie Volz (volz) wrote:
> Ted:
> 
> Excellent solution!
> 
> - Bernie 
> 
> 
>>-----Original Message-----
>>From: Ted Hardie [mailto:[email-masked]] 
>>Sent: Monday, November 21, 2005 2:49 PM
>>To: Bernie Volz (volz); Henning Schulzrinne
>>Cc: Ralph Droms (rdroms); DHCP discussion list; [email-masked]
>>Subject: RE: [dhcwg] Re: I-D 
>>ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
>>
>>At 9:12 AM -0500 11/21/05, Bernie Volz \(volz\) wrote:
>>
>>>If you want to keep this information private, DON'T SEND IT via DHCP.
>>>Period. End of story! That's why clients shouldn't be sending this
>>>unless configured to.
>>>
>>
>>This suggests that we might get past this by reversing 
>>Henning's original
>>proposal.  Do not make this a protocol error, but state in 
>>the document
>>that sending it from client to server is equivalent to 
>>sending a pidf-lo
>>with unlimited distribution and retention permitted.   Make 
>>it a SHOULD NOT,
>>obviously, but note that if you do send it that is the effect.
>>
>>My reasoning here is that it is nigh impossible to determine what
>>administrative domain means in many deployments, and the agreement
>>to share among servers in a single administrative domains translates
>>into "you don't know where this is going".  If we state in 
>>the document
>>that it is SHOULD NOT unless the client is willing to set the 
>>ravish-me bits,
>>that is at least clear on what the consequences are.
>>
>>How would that work for folks?
>>				Ted
>>

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

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 21 Nov 2005 16:08:23 -0500

I can live with the 'SHOULD NOT', but please don't compare this to 'sending
a pidf-lo with unlimited distribution and retention permitted'.  One major
difference between LCI carried in DHCP and a pidf-lo is the lack of user
identity.  I do agree that one should be cautious of everything, including
their DHC provider, but in this case the same amount of information that
goes downstream, goes upstream.

Operationally, I would surmise:

1) If the client requests LCI option(s) and receives none, there would be no
reason to send LCI upstream.  Assume the DHCP server does not support LCI.

2) If the client requests LCI option(s) and receives location information
deemed to be less accurate than locally-known/self-measured, one *could*
send the LCI upstream as a maintenance procedure to correct the wiremap
database.  (Obviously under admin control.)

3) If the client receives unsolicited LCI option(s) due to
locally-known/self-measured location is the mode of operation, no reason to
send anything upstream, ignore the LCI options and continue with life.

Hence, sending upstream only in special circumstances works for me.

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Schulzrinne
> Sent: Monday, November 21, 2005 2:55 PM
> To: Bernie Volz (volz)
> Cc: Ted Hardie; DHCP discussion list; [email-masked]; Ralph 
> Droms (rdroms)
> Subject: Re: [dhcwg] Re: I-D 
> >>This suggests that we might get past this by reversing Henning's 
> >>original proposal.  Do not make this a protocol error, but state in 
> >>the document that sending it from client to server is equivalent to 
> >>sending a pidf-lo
> >>administrative domain means in many deployments, and the 
> agreement to 
> >>share among servers in a single administrative domains 
> translates into 
> >>"you don't know where this is going".  If we state in the document 
> >>ravish-me bits, that is at least clear on what the consequences are.
> >>
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg