[e2e] a means to an end

[David P. Reed]

In this context, I re-read RFC3924.    (An informational RFC, I should 
note, not a standard).  Indeed, Fred was an author of the document, 
perhaps not of the design.  The second quote suggests that government 
intrusion into information being sent to registries of location 
information (i.e. RADIUS servers) is both desired and is actually 
recommended by Cisco, at least in countries, such as my own, that have 
policies that support surveillance without court supervision.

I would also note that there is no specific protection of the 
information thus made available to non-governmental sources described in 
the document.  Marketers, for example, such as NebuAd and Phorm, should 
feel free to track location of individuals by their network footprints, 
perhaps giving another use for this architectural feature.
> IESG Note
>
>    This RFC is not a candidate for any level of Internet Standard.  The
>    IETF disclaims any knowledge of the fitness of this RFC for any
>    purpose, and in particular notes that the decision to publish is not
>    based on IETF review for such things as security, congestion control
>    or inappropriate interaction with deployed protocols.  The RFC Editor
>    has chosen to publish this document at its discretion.  Readers of
>    this document should exercise caution in evaluating its value for
>    implementation and deployment.
>
> Abstract
>
>    For the purposes of this document, lawful intercept is the lawfully
>    authorized interception and monitoring of communications.  Service
>    providers are being asked to meet legal and regulatory requirements
>    for the interception of voice as well as data communications in IP
>    networks in a variety of countries worldwide.  Although requirements
>    vary from country to country, some requirements remain common even
>    though details such as delivery formats may differ.  This document
>    describes Cisco's Architecture for supporting lawful intercept in IP
>    networks.  It provides a general solution that has a minimum set of
>    common interfaces.  This document does not attempt to address any of
>    the specific legal requirements or obligations that may exist in a
>    particular country.
>   


> 4.2.  Data Services
>
>    The same model (Figure 1) can also be used for data services.  In
>    this case the IRI IAP could be a server that acts as registration,
>    authentication and authorization point for the data service (e.g., a
>    RADIUS server).  If a potential IRI IAP does not have the available
>    interfaces (c) and (e), the MD may have to do a content tap on
>    registration signaling in order to obtain the IRI.
>
>    The IRI in the case of a data service could include:
>
>    *  The time that the user registered or de-registered for the
>       service.
>    *  Addressing information (i.e., given the user identity, what IP
>       address or other information is available that could be used in
>       interface (d) to do the content tap).
>
>    Once suitable addressing information is available in order to do
>    content tapping the MD can invoke the tap via interface (d).
>
>    Clearly the IRI interfaces (c, e, g) are different for data than they
>    are for voice services.  However, the content IAP is typically the
>    same (an edge router).  Interfaces (d, f, and h) may also be the
>    same.
>   


Lloyd Wood wrote:
> Fred, you did write RFC3924.
>
> On 8 Nov 2008, at 01:07, Fred Baker wrote:
>> AFAIK, IP addresses are not assigned to people.
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>
>
>
>
>
>
>