[apps-discuss] APPSDIR review of draft-ietf-appsawg-http-forwarded-02

Salvatore Loreto <salvatore.loreto@ericsson.com> Mon, 14 May 2012 13:40 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9CA21F8759 for <apps-discuss@ietfa.amsl.com>; Mon, 14 May 2012 06:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.053
X-Spam-Level:
X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, 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 HqSduB07Z0bK for <apps-discuss@ietfa.amsl.com>; Mon, 14 May 2012 06:40:34 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF521F8755 for <apps-discuss@ietf.org>; Mon, 14 May 2012 06:40:33 -0700 (PDT)
X-AuditID: c1b4fb30-b7c05ae000003df9-4a-4fb10b50dc14
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8A.CE.15865.05B01BF4; Mon, 14 May 2012 15:40:33 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 14 May 2012 15:40:33 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9DF622326; Mon, 14 May 2012 16:40:32 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8F1B252FA9; Mon, 14 May 2012 16:40:32 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3B9A252E12; Mon, 14 May 2012 16:40:32 +0300 (EEST)
Message-ID: <4FB10B4F.80906@ericsson.com>
Date: Mon, 14 May 2012 16:40:31 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, draft-ietf-appsawg-http-forwarded@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------040207010809050508070206"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [apps-discuss] APPSDIR review of draft-ietf-appsawg-http-forwarded-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2012 13:40:35 -0000



I have been selected as the Applications Area Directorate reviewer for 
this draft
(for background on appsdir, please see  
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive.
Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.


Document: draft-ietf-appsawg-http-forwarded-02

Title: Forwarded HTTP Extensions
Reviewer: Salvatore Loreto
Review Date: 2012-05-14
IESG Telechat Date:


Summary:
I have read and reviewed this draft.
The draft is really clear on describing the issues and the proposed 
solution,
it is almost ready for publication  however there are some issues that need
to be addressed before publication.



Major Issues:
-----------
Section 4

the "token" syntax is currently defined to be aligned to the HTTP 
parameter syntax as defined in
draft-ietf-httpbis-p1-messaging-19#section-3.2.4
however this syntax does not allow to insert an IPv4address with the 
optional port
or an IPv6address with or without port.


Minor Issues:
-----------
-Section 4

last paragraph states

    Given that a proxy wishes to add a Forwarded header field to the
    outgoing request, if the incoming request has no such header field,
    the proxy simply adds the header with the list of parameters desired.
    If, on the other hand, the incoming request has such a header field,
    the proxy adds a comma and the list of parameters.


It should also list the possibility to simply add another Forwaded: instance
to the list of headers (as the header field uses HTTP list syntax).


-Section 5.2

    The "for" parameter is used to disclose information about the user
    agent that initiated the request.


s/user agent/client
The sentence is supposed to give a general description of the parameter,
using the term user agent seems to suggest that the parameter is only for
user agents.

    Typically the value of this
    parameter is an IP address, but it MAY also be some other kind of
    identifier.


The normative MAY is not necessary since it is only an informative 
example of usage.


-Section 5.3

    This MAY be used for example by the origin
    server if a reverse proxy is rewriting the "Host" header field to
    some internal host name


The normative MAY is not necessary since it is only an informative 
example of usage.


- Section 5.5

    IANA MUST in such cases be notified, and parameters
    should be registered according to [RFC3864].

it would be better to rephrase it in something like:
"It is possible to register additional parameters using the IANA 
registration policy
described in [RFC3864]"

- Section 6.3

It is not clear to me how  a randomly generate value in Forwarded header 
field
can be used for tracing and debugging, and especially why it would be 
necessary this
header for debugging.
Moreover I agree that in case you do not want to disclose information it 
would be better
don't add the "Forwarded: for" header field at all as a random 
identifier would end up
to provide extra information anyway.


- Section 8.1

It should be clarified that the header is not supposed at all to be 
inserted in an answer
as it would reveal the full proxy chain to the client.
Also it usage with a TRACE request should be clarified.



Nits:
----

- Section 4

    Example:

        Forwarded: For=192.0.2.43,"for=[2001:db8:cafe::17]:47011"

it should be

	Forwarded: For=192.0.2.43,for="[2001:db8:cafe::17]:47011"



- Section 6.1

in the last sentence "an IPv6 adress" ' -> "an IPv6 address"


- Section 7

IPv6 addresses must be transmitted as quoted-string

i.e. for=[2001:db8:cafe::17]  should be for="[2001:db8:cafe::17]"



best regards
/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com