>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_001_01CA37E6.8B58EBD7"
>
>The paragraph in question comes directly from
>RFC 4776. I figured that if it was good enough
>there, then it is good enough here.Â
>
>However, I tend to agree with James. It
>doesn’t really say what needs to be said.
>
>So…what do we need to say with respect to policy?<
>
>From: geopriv-bounces@ietf.org
>[mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
>Sent: Friday, 18 September 2009 1:59 AM
>To: jmpolk@cisco.com
>Cc: geopriv@ietf.org
>Subject: Re: [Geopriv] [geopriv] #22: Resolution
>does not define Geographic Privacy policy ?
>
> > This paragraph is also missing the point recently raised that the
> > security properties of LI delivery of an LCP is based on the protocol
> > itself, not a function of the server needing to do anything (i.e.,
> > there is no authorization step or encryption necessary).
>
>Should this be the central point made with respect to privacy policy?
I'm thinking so wrt LCPs, but probably only wrt LCPs.
Much of time, DHCP servers will push -
unsolicited - Options 123 and/or 99 towards
clients. Meaning there is no RFC 3118 preshared
key exchange, or anything else to verify who is
asking for the information; mostly because no one
asked for anything, yet it was still sent.
If this sounds horrible, it is - were this 10
years ago where Ethernet hubs were still in use
(outside of 4 port residential homes). Nearly all
Ethernet connections are today are dedicated,
with dot1x and such already running, therefore
this is really not a concern (as far as
eavesdropping or overhearing is
concerned). Cable systems send this information
in the clear - as far as IP is concerned - but
all Cable systems use 56bit DES encryption within
the Cable plant, therefore no one hears anything
(unless someone is stupid enough to have a dot11
AP attached to the CM that is available to anyone
who wants to listen). We can't help the clueless sometimes... ;-)
>Or is there something else to say with respect to resolution/uncertainty
>as well?
One of the main concerns I have is that we'll get
through all this work and someone will put this
Arch doc against the DHCP RFCs and say "hey,
these RFCs seem to be inconsistent (or violate) what the Arch doc says".
I do not believe that is a goal, but we need to
reverse engineer Arch to the point that 3825 (and
its bis) and 4776 end up matching what the Arch
doc says - so implementers and ID writers in the
future aren't totally confused.
>------------------------------------------------------------------------------------------------
>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
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
