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

From: [email-masked]
Date: Mon, 21 Nov 2005 15:22:02 -0500

Makes sense to me. 

Only thing I might ask to add is some description on under what conditions 
it might be useful to send location client --> server (otherwise it would 
be a MUST NOT, right?).  To me that good reason is to set up the mapping 
of L2 chassis id / port number to physical location, to build up the 
location database in the first place (or verify it after the fact).  The 
device itself would not be remembered, only the mapping to location.  That 
was described somewhere in this loooooong thread recently.  (I'm OK with 
not providing that guidance too, if it becomes an issue for any reason.) 

(Silently watching ... and hoping this will settle sometime soon, so it 
can get to RFC.)

-- Peter Blatherwick 

Henning Schulzrinne <[email-masked]>
Sent by: [email-masked]
21.11.05 14:55

        To:     "Bernie Volz (volz)" <[email-masked]>
        cc:     Ted Hardie <[email-masked]>, DHCP discussion list <[email-masked]>, 
[email-masked], "Ralph Droms \(rdroms\)" <[email-masked]>
        Subject:        Re: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

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

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

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

---

From: John Schnizlein <[email-masked]>
Date: Mon, 21 Nov 2005 16:18:16 -0500

It is not reasonable to say MUST NOT because conditions where the 
protocol would be used are not specified.  That might be the tradition 
in some other community, but Internet tradition is to prohibit (MUST 
NOT) only those behaviors that interfere with correct protocol 
function.

John

On Nov 21, 2005, at 3:22 PM, [email-masked] wrote:
>
> Makes sense to me.    
>
> Only thing I might ask to add is some description on under what 
> conditions it might be useful to send location client --> server 
> (otherwise it would be a MUST NOT, right?).  To me that good reason is 
> to set up the mapping of L2 chassis id / port number to physical 
> location, to build up the location database in the first place (or 
> verify it after the fact).  The device itself would not be remembered, 
> only the mapping to location.  That was described somewhere in this 
> loooooong thread recently.  (I'm OK with not providing that guidance 
> too, if it becomes an issue for any reason.)  
>
> (Silently watching ... and hoping this will settle sometime soon, so 
> it can get to RFC.)
>
>         cc:        Ted Hardie <[email-masked]>, DHCP discussion 
> list <[email-masked]>, [email-masked], "Ralph Droms \(rdroms\)" 
> <[email-masked]>
>         Subject:        Re: [dhcwg] Re: I-D

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Nov 2005 16:35:38 -0500

You mean, modulo security/privacy concerns.

John Schnizlein wrote:
> NOT) only those behaviors that interfere with correct protocol function.
> 
> John
> 
...