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

From: Ralph Droms <[email-masked]>
Date: Thu, 10 Nov 2005 14:16:08 -0500

dhc WG members: Please review and comment on draft-ietf-geopriv-dhcp-
civil-07.txt.

Back in September, I sent a message to the dhcwg mailing list asking for
WG review of draft-ietf-geopriv-dhcp-civil-07.txt (original e-mail is
appended to this message).  Shortly after I sent that message, Ted
Hardie sent e-mail to the effect that there was another outstanding
Discuss on draft-ietf-geopriv-dhcp-civil: 

On Mon, 2005-09-19 at 10:16 -0700, Ted Hardie wrote:
> Thanks to Ralph for forwarding this to the group.  There may be a further revision,
> however, as David Kessens still has an outstanding discuss which is not yet
> resolved.  David has agreed to update the discuss text to indicate more clearly
> the points of discussion but has not yet done so.  Until that is complete, it is
> not clear whether further changes to this aspect of the document will be requested.
> Your review of this draft is, of course, appreciated, but please be aware that there may
> be a second request.

Just to be clear, it is not definitely the case that a -08 revision will
be published.  dhc WG members should review the -07 revision and reply
with comments to the [email-masked] mailing list by Friday, 2005-11-18.

- Ralph

=====

Following up on the announcement of the publication of draft-ietf-
geopriv-dhcp-civil-07.txt, which John Schnizlein forwarded to the
mailing list, the -04 revision of this draft was reviewed by the dhc WG
several months ago, in a joint last call with the geopriv WG.  The draft
was then submitted to the IESG.  draft-ietf-geopriv-dhcp-civil-07.txt
includes changes in response to comments received during the IESG
review.  Because this specification involves DHCP, the dhc WG has an
opportunity for a final review of the draft.  Accordingly, if you have
any comments about the draft, please respond by 1700EDT on Thu, 9/22.  I
will forward any responses to the IESG and the geopriv WG chairs.

I prepared a diff of the -04 and -07 versions, but haven't sent it with
this announcement because it's about 200KB (using side-by-side rfcdiff
tool).  Let me know if you'd like me to send you an individual copy.

- Ralph

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 21 Nov 2005 16:45:14 -0500

I think it would be far better if the IETF told people the issues
regarding security and privacy, but did not dictate. So, MUST and MUST
NOT should not be used when referring to security or privacy issues,
IMHO.

SHOULD and SHOULD NOT are OK, because they can be "violated" if you have
good reasons. MUST and MUST NOT can not be "violated".

Per RFC 2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

- Bernie

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]] 
> Sent: Monday, November 21, 2005 4:36 PM
> To: John Schnizlein (jschnizl)
> Cc: [email-masked]; [email-masked]; Ted 
> Hardie; Bernie Volz (volz); DHCP discussion list; 
> [email-masked]; Henning Schulzrinne; Ralph Droms (rdroms)
> Subject: Re: [Geopriv] Re: [dhcwg] Re: I-D 
> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> 
> You mean, modulo security/privacy concerns.
> 
> John Schnizlein wrote:
> > 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
> > 
> ...
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 21 Nov 2005 17:41:03 -0500

So, I guess we end up with something like the client must assume the
widest possible distribution and retention for the information it
provides, but that the server should not (NOT must not!) distribute nor
retain. This is essentially what I would expect -- if I provide the
information I would hope it would be put to proper use and not misused.
However, if you're paranoid or don't trust where you're connected, don't
provide the information in the first place.

Not sure exactly how this maps to PIDF-LO's since I haven't followed the
GEOPRIV WG in general.

Does something like that make sense? Is it a useful compromise?

- Bernie

> From: Randall Gellens [mailto:[email-masked]] 
> Sent: Monday, November 21, 2005 5:11 PM
> To: Ted Hardie; Bernie Volz (volz); Henning Schulzrinne
> Cc: [email-masked]; DHCP discussion list; Ralph Droms (rdroms)
> Subject: [Geopriv] RE: [dhcwg] Re: I-D 
> At 11:49 AM -0800 11/21/05, Ted Hardie wrote:
> 
> >  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?
> 
> This does mean that a client has to make a possibly unpleasant choice 
> between not sending the information, and thus possibly making it 
> harder be located in an emergency or possibly having poorer service 
> in some other area, and sending it with no redistribution/retention 
> limits.
> 
> I'd rather have the implied policy be do not distribute / do not 
> retain, even though that raises the issue of what counts as 
> distribution.
> 
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for 
> myself only
> -------------- Randomly-selected tag: ---------------
> History is strewn thick with evidence that truth is not hard to kill,
> but a lie, well told, is immortal.
> --Mark Twain
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 21 Nov 2005 17:11:39 -0600

Hmm.. Sounds like OBO to me. ;)

I actually think that network management find this misbehaving phone has
other better options at hand than this. If the server doesn't support
LCI then I don't think that this option is going to help, and if the
server does support LCI then other options such using the lease query
mechanism proposed in
http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-09.txt to
get the LCI data or relay data from the server directly.

I still think that the potential long term mess is far worse than the
short-term gains.

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, 22 November 2005 10:03 AM
> To: Winterbottom, James
> Cc: Randall Gellens; [email-masked]; DHCP discussion list
> Subject: Re: [Geopriv] RE: [dhcwg] Re: I-D
ACTION:draft-ietf-geopriv-dhcp-
> civil-07.txt
> 
> 
> 
> Winterbottom, James wrote:
> > [AJW] I simply don't understand this statement. If the end-point has
its
> > location, how is providing that location to a DHCP server going to
> > assist with emergency call routing?
> 
> It's a bit of a stretch, but the logic would be something like:
> 
> - End point knows location, but client application doesn't know how to
> retrieve or use it (this would include all current IP telephony soft
> clients, for example);
> 
> - in an enterprise environment, the proxy server gets to ask the DHCP
> server for location information (and uses it for emergency call
routing).
> 
> I agree that this is not a deployment scenario we should make the
> preferred outcome.
> 
> The more likely case is that this is used for network management
("find
> the misbehaving PC or phone").
> 
> 
> >
> > My personal opinion is that allowing the transfer of location from
the
> > client to the server in this manner is a significant stretch of the
> > intentions laid out in RFC-3694 and quite far reaching application
and
> > security implications.
> > Cheers
> > James
------------------------------------------------------------------------
> ------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> >
------------------------------------------------------------------------
> ------------------------
> > [mf2]
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]