Re: [Int-area] Revving draft-intarea-shared-addressing-issues

<pierre.levis@orange-ftgroup.com> Fri, 25 June 2010 08:05 UTC

Return-Path: <pierre.levis@orange-ftgroup.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EA03A68A9 for <int-area@core3.amsl.com>; Fri, 25 Jun 2010 01:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level:
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfGLb08q91Xi for <int-area@core3.amsl.com>; Fri, 25 Jun 2010 01:05:38 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 1495128C0D0 for <int-area@ietf.org>; Fri, 25 Jun 2010 01:05:38 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D91628B8010; Fri, 25 Jun 2010 10:06:06 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D053E8B800D; Fri, 25 Jun 2010 10:06:06 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jun 2010 10:05:35 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Jun 2010 10:05:34 +0200
Message-ID: <F1A741D65FFEF6489D607B26ABA0ED5702434144@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <D03111CE-0D82-4CE3-AC82-2B2954116CFE@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Int-area] Revving draft-intarea-shared-addressing-issues
Thread-Index: AcsT9GiNTgcbIcuESkmqVHbynT7dmgARwogw
References: <1339FDB5-B518-4210-9D7E-6711E4E10DB0@isoc.org> <D03111CE-0D82-4CE3-AC82-2B2954116CFE@ericsson.com>
From: pierre.levis@orange-ftgroup.com
To: christian.vogt@ericsson.com, ford@isoc.org, draft-ford-shared-addressing-issues@tools.ietf.org
X-OriginalArrivalTime: 25 Jun 2010 08:05:35.0865 (UTC) FILETIME=[310C6E90:01CB143D]
Cc: int-area@ietf.org
Subject: Re: [Int-area] Revving draft-intarea-shared-addressing-issues
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2010 08:05:40 -0000

Yes I agree the smallest element needed is one timestamp

So it is more accurate to write [IP address - Port - Protocol - Timestamp]

And this does not preclude that a real legal request can bear other pieces of information


Pierre 

-----Message d'origine-----
De : Christian Vogt [mailto:christian.vogt@ericsson.com] 
Envoyé : vendredi 25 juin 2010 01:26
À : Matthew Ford; draft-ford-shared-addressing-issues@tools.ietf.org
Cc : Internet Area Mailing List
Objet : Re: [Int-area] Revving draft-intarea-shared-addressing-issues

On Jun 10, 2010, Matthew Ford wrote:

> o Revise the first portion of §10 as follows:
> 
> "In many jurisdictions, service providers are legally obliged to provide
> the identity of a subscriber upon request to the appropriate
> authorities.  [...]  The legal request should include the information:
> [IP address - Port - Protocol- Begin_Timestamp - End_Timestamp]...

Shouldn't the legal request include only one timestamp, as opposed to a
time interval as your text is suggesting?  The time interval should be
a logging requirement, not a requirement for requests.

- Christian