Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt

Matthew Ford <ford@isoc.org> Fri, 11 February 2011 11:05 UTC

Return-Path: <ford@isoc.org>
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 7B5553A696B for <int-area@core3.amsl.com>; Fri, 11 Feb 2011 03:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.932
X-Spam-Level:
X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 R9ZxsqeSd-sX for <int-area@core3.amsl.com>; Fri, 11 Feb 2011 03:05:18 -0800 (PST)
Received: from smtp151.iad.emailsrvr.com (smtp151.iad.emailsrvr.com [207.97.245.151]) by core3.amsl.com (Postfix) with ESMTP id A45433A6892 for <int-area@ietf.org>; Fri, 11 Feb 2011 03:05:18 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp55.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1E4232E0272; Fri, 11 Feb 2011 06:05:33 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp55.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 132512E0959; Fri, 11 Feb 2011 06:05:31 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Matthew Ford <ford@isoc.org>
In-Reply-To: <D2DB65CB-C48E-48E3-AAEB-7277837BCBFB@juniper.net>
Date: Fri, 11 Feb 2011 12:05:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6EBCAC5-A602-4329-8B32-2086DD70D360@isoc.org>
References: <20110119183002.30410.51185.idtracker@localhost> <98A16B2D00B5724F81E80EF1927A029703FC95@nasanexd01e.na.qualcomm.com> <31963_1297088150_4D4FFE96_31963_99436_1_94C682931C08B048B7A8645303FDC9F33C44015A86@PUEXCB1B.nanterre.francetelecom.fr> <D2DB65CB-C48E-48E3-AAEB-7277837BCBFB@juniper.net>
To: Alain Durand <adurand@juniper.net>
X-Mailer: Apple Mail (2.1082)
Cc: Julien Laganier <julienl@qualcomm.com>, "int-area@ietf.org" <int-area@ietf.org>, "draft-ietf-intarea-server-logging-recommendations@tools.ietf.org" <draft-ietf-intarea-server-logging-recommendations@tools.ietf.org>, Vogt <christian.vogt@ericsson.com>, Christian@core3.amsl.com
Subject: Re: [Int-area] I-D Action:draft-ietf-intarea-server-logging-recommendations-02.txt
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, 11 Feb 2011 11:05:19 -0000

On 10 Feb 2011, at 10:48, Alain Durand wrote:

> 
> On Feb 7, 2011, at 9:15 AM, <mohamed.boucadair@orange-ftgroup.com> <mohamed.boucadair@orange-ftgroup.com> wrote:
> 
>> Dear authors, all,
>> 
>> I read this I-D and have the following comments:
>> 
>> * In its current state, this I-D does not add more content compared to what is stated in http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-02#section-12. I understand this document aims to make a recommendation but IMHO it would be useful if the I-D discusses other aspects which are not covered so far such as the behaviour of the server when some headers such XFF are used. Storing the content of such headers would be useful in some scenarios (the port binding is not logged in the address sharing side) which prefer to expose an identifier to the destination server instead of maintaining a binding. 
> 
> 
> Med:
> 
> draft-ietf-intarea-shared-addressing-issues was about describing issues, not making recommendations.
> 

I agree. The shared-addressing-issues document was always intended to be a catalogue of issues, and not to get into a large amount of detail regarding any particular issue, and certainly not to make any specific recommendations about how issues can be addressed. So in that light, I think the server-logging-recommendations document is a helpful addition.

Mat