Re: [apps-discuss] Last Call: <draft-ietf-appsawg-http-forwarded-06.txt> (Forwarded HTTP Extension) to Proposed Standard

SM <sm@resistor.net> Mon, 09 July 2012 21:22 UTC

Return-Path: <sm@resistor.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A411E8173; Mon, 9 Jul 2012 14:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level:
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJXwMGFq2ulp; Mon, 9 Jul 2012 14:21:57 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BCA11E80E4; Mon, 9 Jul 2012 14:21:57 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q69LLx7m017297; Mon, 9 Jul 2012 14:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341868925; bh=sQcyKrJ7hAmWjwTfm63Thdab5jqyPxDj7kbudVysXB8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Tokl53q1VxLDXSsTzhsNZwPJ4Nlp9jVwFdxuWWnauSs/RXKIYmeVWI2FHKYgk38y6 4GGp+xSwfls4CbOVJoFubTV646b+W/UJfy6HEyHPnBePU0xuEdcK8ZUC6FXxb4CasZ hchDhXNHycJYUfVCiEGvItnXhf8lQxTTkSzv2SdM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341868925; i=@resistor.net; bh=sQcyKrJ7hAmWjwTfm63Thdab5jqyPxDj7kbudVysXB8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nGacxioge+UP4ZG5j5QRjkTzcBshZcNwxrqIBcO+7R/hXbs8dkw7op7x/ND+u1Jwo 8Doy5nyuolYxLBzL6gFcy8cIG10rSNN/Fxy6pn5QJnSMKLaSQ5HVkRdcvc6V7jmDn/ 51IBZvmDDsXVngdLAGmL+SOsfzID0NGFgyXQ5+Wk=
Message-Id: <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 09 Jul 2012 13:59:43 -0700
To: IETF Discussion Mailing List <ietf@ietf.org>
From: SM <sm@resistor.net>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-http-forwarded-06.txt> (Forwarded HTTP Extension) to Proposed Standard
In-Reply-To: <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org>
References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: apps-discuss@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 21:22:01 -0000

At 11:27 09-07-2012, Alissa Cooper wrote:
>Is it possible to recommend that generated tokens have limited 
>lifetimes (per-request or otherwise), and make the static case the 
>exception? The first statement above gets at this, but it seems to 
>me that the middle ground between random generation per request and 
>permanent unique token is worth emphasizing if there will be proxies 
>that want to keep per-client identifiers around for some limited 
>amount of time that isn't forever.

Yes.

>It's also worth noting that the second statement above is equally 
>true for statically provisioned client IP addresses.
>
>Also, this statement in 8.3 is not really true and probably better left out:
>
>"Proxies using this extension will preserve the information of a
>    direct connection, which has an end-user privacy impact, if the end-
>    user or deployer does not know or expect that this is the case."

I suggest removing that statement.  The wording is not entirely 
clear.  I read it as diluting end-user privacy impact.

In Section 6.3:

   'To distinguish the obfuscated identifier from other identifiers,
    it MUST have a leading underscore "_".'

I suggest removing the requirement and using "can".  The implementer 
can decide what to put in that field.

Regards,
-sm