Forwarded HTTP Extension
RFC 7239

Received changes through RFC Editor sync (changed abstract to 'This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.

This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.')

[Ballot comment]
It took a while, but I believe we got to some good compromisetext that helps explain the purpose of your work. Thanks for the time taken to get the polish right.

[Ballot comment]
I read the latest version draft-ietf-appsawg-http-forwarded-08
I believe that the authors introduced the justifications (even if this could always be improved).
While I understand the privacy issues, since X-forwarded is deployed and the WG wants to standardize this, I support the format specifications of this draft.

[Ballot comment]

I commented on the privacy aspects of this during IETF LC and while
the resulting text (in 8.3) is such that I can accept the outcome of
that discussion is as good as we can get, I still have to say this
isn't really something that I think we would have developed
from-scratch in a WG. With this document, we're standardising
something that is the opposite of privacy-friendly, basically just
because the existing X-Forwarded-* header fields exist and are used
already and anything we developed that was more privacy-friendly
wouldn't get deployed.

I'm also not at all clear as to who benefits from standardising
this, e.g. see my comments on 7.2 & 8.1 below. That may have been
discussed on the apps-discuss list, but I don't recall that so am
concerned that we may just be standardising this because someone had
the energy to write and process the document.

I think the document would be better if it didn't present this as
being a good (or unconditionally "needed") thing, at least without
caveats. For example, I don't think this is "needed" by users, but
rather more by others. That's mostly a writing-style thing though.

What is a "trusted path" of proxies, or a "trusted proxy"? I think
that phrase could just be deleted since there are very few cases
where anyone knows of and (equally) trusts all the proxies on a
path. I don't think the document defines that well enough for the
phrase to be kept.

Encouraging addition and modification of header fields like this
means that any future HTTP e2e integrity mechanisms will have to be
more complex than otherwise, basically about as complex as DKIM (or
the DOSETA proposal derived from that). I'm not sure if that might
or might not have a bad effect on future work with HTTP. I don't
know if that was discussed on the httpbis list or on apps-discuss.

Section 4 says proxies MUST ensure the "correct" header field is
updated but doesn't seem to say exactly how to know which header
field is the correct one.

5.4 seems to be standardising a practice that amounts to trying to
fool the user-agent into believing that TLS was used end to end when
in fact it was not. While this is so widely deployed that its
probably pointless to try even discourage, I'm not convinced that a
WG would design a standard for a server-side crypto accellerator in
this way. I think we'd be more likely to make the middlebox at least
visible to the user-agent.

7.2 doesn't seem to me to specify when to preserve the header field
and when not to do so. I don't think "direct consequence" is
something that all implementers will understand in the same way.
(If doing whatever you like is fine here, then that calls into
question the basis for standardising this in the first place.)

8.1 says this cannot be relied upon. If that's the case then why is
it being standardised? Whitelisting proxies is (as the document
admits) not a credible mitigation.

8.2 says telling the client about the proxy chain is somehow a bad
thing but doesn't justify that. Since a client could find out anyway
if they wanted to bother, that seems wrong.

8.2 says to disallow the TRACE request. Is that a change to HTTP?
If so, then where was that discussed?

Section 9 says only that the expert should ensure that the
specification "address the security and privacy implications of the
requested parameter." So if I defined a parameter that passed on the
precise location of the end-user or the most recent healthcare
related URL they've accessed then would that be ok? I think
additional instructions are needed as to the acceptable purposes to
which such parameters can be put or else perhaps IETF review would
in fact be better. Given the field of applicability I would not be
surprised if very privacy-invasive parameters were defined in
future.

The W3C have standardised the DoNotTrack header field. It
should be clear whether or not, and if so, how, this header
field interacts with that one.


5.1 says "some other kind of identifier" which seems quite loose.

5.5 says widely deployed extensions SHOULD be standardized which is
an odd use of 2119.

What does "in a sensible way" mean in 7.4? That seems underspecified.

[Ballot discuss]
NOTE: I'm entering this as a discuss and not as a comment.

I support Adrian and Stephen's points.

Not entirely sure this actionable, but think we ought to at least talk about it on the call: I'm struggling to figure out why we need to standardize this.  This feels to me like when a draft was just recently floated to standardize TLS proxies (i.e., standardized MITM) - sure we could do that but is really a good idea?

[Ballot discuss]
I plan to change my DISCUSS position to an ABSTAIN position after
the telechat. Its a DISCUSS for now in case some of the points help
to improve something in the meantime.

(Updated to add DNT point at the end. No other change)

I commented on the privacy aspects of this during IETF LC and while
the resulting text (in 8.3) is such that I can accept the outcome of
that discussion is as good as we can get, I still have to say this
isn't really something that I think we would have developed
from-scratch in a WG. With this document, we're standardising
something that is the opposite of privacy-friendly, basically just
because the existing X-Forwarded-* header fields exist and are used
already and anything we developed that was more privacy-friendly
wouldn't get deployed.

I'm also not at all clear as to who benefits from standardising
this, e.g. see my comments on 7.2 & 8.1 below. That may have been
discussed on the apps-discuss list, but I don't recall that so am
concerned that we may just be standardising this because someone had
the energy to write and process the document.

I think the document would be better if it didn't present this as
being a good (or unconditionally "needed") thing, at least without
caveats. For example, I don't think this is "needed" by users, but
rather more by others. That's mostly a writing-style thing though.

What is a "trusted path" of proxies, or a "trusted proxy"? I think
that phrase could just be deleted since there are very few cases
where anyone knows of and (equally) trusts all the proxies on a
path. I don't think the document defines that well enough for the
phrase to be kept.

Encouraging addition and modification of header fields like this
means that any future HTTP e2e integrity mechanisms will have to be
more complex than otherwise, basically about as complex as DKIM (or
the DOSETA proposal derived from that). I'm not sure if that might
or might not have a bad effect on future work with HTTP. I don't
know if that was discussed on the httpbis list or on apps-discuss.

Section 4 says proxies MUST ensure the "correct" header field is
updated but doesn't seem to say exactly how to know which header
field is the correct one.

5.4 seems to be standardising a practice that amounts to trying to
fool the user-agent into believing that TLS was used end to end when
in fact it was not. While this is so widely deployed that its
probably pointless to try even discourage, I'm not convinced that a
WG would design a standard for a server-side crypto accellerator in
this way. I think we'd be more likely to make the middlebox at least
visible to the user-agent.

7.2 doesn't seem to me to specify when to preserve the header field
and when not to do so. I don't think "direct consequence" is
something that all implementers will understand in the same way.
(If doing whatever you like is fine here, then that calls into
question the basis for standardising this in the first place.)

8.1 says this cannot be relied upon. If that's the case then why is
it being standardised? Whitelisting proxies is (as the document
admits) not a credible mitigation.

8.2 says telling the client about the proxy chain is somehow a bad
thing but doesn't justify that. Since a client could find out anyway
if they wanted to bother, that seems wrong.

8.2 says to disallow the TRACE request. Is that a change to HTTP?
If so, then where was that discussed?

Section 9 says only that the expert should ensure that the
specification "address the security and privacy implications of the
requested parameter." So if I defined a parameter that passed on the
precise location of the end-user or the most recent healthcare
related URL they've accessed then would that be ok? I think
additional instructions are needed as to the acceptable purposes to
which such parameters can be put or else perhaps IETF review would
in fact be better. Given the field of applicability I would not be
surprised if very privacy-invasive parameters were defined in
future.

The W3C have standardised the DoNotTrack header field. It
should be clear whether or not, and if so, how, this header
field interacts with that one.

[Ballot comment]
5.1 says "some other kind of identifier" which seems quite loose.

5.5 says widely deployed extensions SHOULD be standardized which is
an odd use of 2119.

What does "in a sensible way" mean in 7.4? That seems underspecified.

[Ballot comment]
There have been questions about whether anyone really discussed the value of standardizing this, as opposed to just jumping in and working out the details.  Here's a brief citation of some of the related discussion on the httpbis mailing list from April 2011, when Andreas started the discussion of the predecessor document, http://tools.ietf.org/html/draft-petersson-forwarded-for

------------
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0035.html
Karl Dubost:
---
Are there other products/companies using X-Forwarded-For?
What are the products emitting the header?
What are the products parsing the header? (libraries, etc)
What are the usual mistakes, errors, etc we might have to face when parsing this header?

------------
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0036.html
Matt Domsch:
---
> Are there other products/companies using X-Forwarded-For?
> What are the products emitting the header?

Apache mod_proxy emits the header, at least when used as a reverse proxy (front end for web applications).

------------
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0038.html
Willy Tarreau:
---
I know quite a number of companies using it for logging purposes.

> What are the products emitting the header?

At least apache , haproxy and squid immediately come to mind.
Haproxy already emits it for IPv4 and IPv6 addresses and uses
no brackets, it emits it as returned by inet_ntop().

> What are the products parsing the header? (libraries, etc)

haproxy is able to use it for various purposes (IP-based ACL
filtering, transparent binding, etc...). Right now it only
parses it for IPv4 addresses, so adding support for both
brackets and non-brackets forms is not a problem.

------------
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0039.html
Martin Thompson:
---
Some form of standardization of this would be useful for us.  We plan to use this for more than just logging.  Of course, we'll cope without a formal definition.

I'll note that adding a new header is nice, but it actually means more work - we still have to process X-Forwarded-For to support all the existing stuff.  Is the "X-" so offensive?  Is there a reason not to simply specify what everyone does.

------------
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0048.html
Mark Nottingham:
---
It's not so much that; it's that there's no interop on the contents of X-Forwarded-For for IPv6 headers (AFAIK), so we should take the opportunity to define a new header that specifies it well.

While we're at it, I'd like to see extensibility points added; there are a bunch of bits of per-hop metadata that would be nice to allow in here, instead of defining separate headers. For example, in some use cases it'd be good to identify the receiving address, as well as the sending one.

------------
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0071.html
Brian Pane:
---
> There is no current uses of "Forwarded-For", backwards compatibility
> therefore does not prevent us from doing it right.

I look at it a bit differently: there are many current uses of
Forwarded-For.  Every web proxy I've seen in the past decade uses it,
every web server has an option to log it, and every nontrivial web
analytics system parses it.  They all do expect the "X-" in front,
though.  The rollout of a naming change will be difficult; I
anticipate that proxy servers will end up sending both X-Forwarded-For
and Forwarded-For for many years.  That might be inevitable, but it
brings to mind two concerns:
- People who plan to log Forwarded-For data for forensic purposes will
need to keep logging X-Forwarded-For as well.
- X-F-F values can get somewhat large, and sending the value twice
(once as X-F-F and once as F-F) will help push more requests past 1MSS
in size, resulting in an extra round-trip delay in cases where the
proxy does not already have an established connection to the
destination.

I don't think either of those points is a show-stopper for
Forwarded-For, but they're nontrivial implementation challenges.

------------

[Ballot comment]
The long threads on apps-discuss and ietf-general focused early on syntax details and privacy implications. Perhaps there were in-meeting conversations that discussed why standardizing this would help that weren't captured on list? It would be good to capture in this document a clear statement of why the IETF believes this is a good behavior to standardize (and be sure we have consensus behind it). This would fall out from the resolution of Adrian's discuss, which I support.

[Ballot discuss]
I think it is unfortunate that this document does not give any
explanation of why it is desirable to expose the information that is
lost during proxying and which the proposed extensions make available.

It is normal for work in the IETF to be presented along with some
motivations based on utility. While it is quite clear that the proposed
mechanism would work to provide the function described, it is a
mystery why any proxy would implement it or consider the extension
valuable.

Given that lack of explanation, I don't understand why the IETF would
pursue this work on the Standards Track.

This Discuss could be resolved by adding some explanation to the
document. Barry sent a recent email containing some explanation of why
a standard approach to this function would be beneficial - that text
would address half of my concern. But the benefits of a standard way of
doing something are not the whole answer: I also need to know why *any*
way of doing this needs to be documented.

[Ballot comment]
I believe that some of the concerns expressed about privacy would be
aliviated if more emphasis was placed on the fact that this extension
*allows* the disclosure of information, but doesn't require it. This
is presumably information that would have been visible had the proxy
not been used.

Since one possible reason for using the proxy is to obscure this
information, it would make sense for the use of this extension by the
proxy to be negotiable by the originating component.

---

Abstract
I would prefer you to s/standardizes/defines/

[Ballot discuss]
I agree with Stephen's concern, and will also be Abstaining.

I addition to the privacy concern I am also concerned that this may defeat one of the purposes of proxies, which is to defeat geopriv. I therefore think that the least that needs to happen is that the feature MUST be off by default, and that there should be an element of the protocol that allows the user to (silently) specify that the proxy must not apply this feature.

[Ballot comment]
Section 4:

  A proxy server that wants to add a new "Forwarded" header field value
  can either append it to the last existing "Forwarded" header field
  after a comma separator or add a new field at the end of the header
  block.
 
So, let's say that I have:

Forwarded: FOO
Via: BAR

that appear in that order. Is it still OK for me to append if I am not on the lookout for Via?

Forwarded: FOO,BAZ
Via: BAR

Will that screw things up semantically because now I don't know which order the events happened in?

If that's not a problem, it seems to me that:

Forwarded: FOO
Forwarded: BAR

is semantically equivalent to:

Forwarded: FOO, BAR

If that is true, I think you should explicitly say that at the end of section 4. Would I be allowed to collect together multiple Forwarded fields and make them one big Forwarded field?

Section 5: I find the first sentence in each of sections 5.1 and 5.2 very confusing.

5.1: "The 'by' parameter is used to disclose the interface where the request came in to the proxy server." If I understand this correctly, you are saying "The 'by' parameter identifies the interface on the proxy server creating the Forwarded information on which the request came in." If that's right, it's not clear from sentence.

5.2 "The 'for' parameter is used to disclose information about the client that initiated the request and following proxies in a chain of proxies." I think I get the first part of the sentence: "The 'for' parameter identifies the client that connected to the proxy server creating the Forwarded information." I can't figure out what the second part of the sentence means.

[Ballot discuss]

I plan to change my DISCUSS position to an ABSTAIN position after
the telechat. Its a DISCUSS for now in case some of the points help
to improve something in the meantime.

I commented on the privacy aspects of this during IETF LC and while
the resulting text (in 8.3) is such that I can accept the outcome of
that discussion is as good as we can get, I still have to say this
isn't really something that I think we would have developed
from-scratch in a WG. With this document, we're standardising
something that is the opposite of privacy-friendly, basically just
because the existing X-Forwarded-* header fields exist and are used
already and anything we developed that was more privacy-friendly
wouldn't get deployed.

I'm also not at all clear as to who benefits from standardising
this, e.g. see my comments on 7.2 & 8.1 below. That may have been
discussed on the apps-discuss list, but I don't recall that so am
concerned that we may just be standardising this because someone had
the energy to write and process the document.

I think the document would be better if it didn't present this as
being a good (or unconditionally "needed") thing, at least without
caveats. For example, I don't think this is "needed" by users, but
rather more by others. That's mostly a writing-style thing though.

What is a "trusted path" of proxies, or a "trusted proxy"? I think
that phrase could just be deleted since there are very few cases
where anyone knows of and (equally) trusts all the proxies on a
path. I don't think the document defines that well enough for the
phrase to be kept.

Encouraging addition and modification of header fields like this
means that any future HTTP e2e integrity mechanisms will have to be
more complex than otherwise, basically about as complex as DKIM (or
the DOSETA proposal derived from that). I'm not sure if that might
or might not have a bad effect on future work with HTTP. I don't
know if that was discussed on the httpbis list or on apps-discuss.

Section 4 says proxies MUST ensure the "correct" header field is
updated but doesn't seem to say exactly how to know which header
field is the correct one.

5.4 seems to be standardising a practice that amounts to trying to
fool the user-agent into believing that TLS was used end to end when
in fact it was not. While this is so widely deployed that its
probably pointless to try even discourage, I'm not convinced that a
WG would design a standard for a server-side crypto accellerator in
this way. I think we'd be more likely to make the middlebox at least
visible to the user-agent.

7.2 doesn't seem to me to specify when to preserve the header field
and when not to do so. I don't think "direct consequence" is
something that all implementers will understand in the same way.
(If doing whatever you like is fine here, then that calls into
question the basis for standardising this in the first place.)

8.1 says this cannot be relied upon. If that's the case then why is
it being standardised? Whitelisting proxies is (as the document
admits) not a credible mitigation.

8.2 says telling the client about the proxy chain is somehow a bad
thing but doesn't justify that. Since a client could find out anyway
if they wanted to bother, that seems wrong.

8.2 says to disallow the TRACE request. Is that a change to HTTP?
If so, then where was that discussed?

Section 9 says only that the expert should ensure that the
specification "address the security and privacy implications of the
requested parameter." So if I defined a parameter that passed on the
precise location of the end-user or the most recent healthcare
related URL they've accessed then would that be ok? I think
additional instructions are needed as to the acceptable purposes to
which such parameters can be put or else perhaps IETF review would
in fact be better. Given the field of applicability I would not be
surprised if very privacy-invasive parameters were defined in
future.

[Ballot comment]

5.1 says "some other kind of identifier" which seems quite loose.

5.5 says widely deployed extensions SHOULD be standardized which is
an odd use of 2119.

What does "in a sensible way" mean in 7.4? That seems underspecified.

[Ballot comment]
I have no objection to publish the draft, but one question/suggestion:
The forwarded header is defined in such a way that it can only carry complete IP addresses, but not IP prefixes.

Extending the header to carry IP prefixes would allow to make a tradeoff between user privacy and interest of the other end in learning about from where the request came.
Such a prefix could, for instance, say 192.168.178.0/24 instead of giving the full IP address of 192.168.178.22.

Would this make sense?

OTOH browser finger printing can potentially anyhow allow to figure who what user is doing the request.

[Ballot comment]
I have no objection to publish the draft, but one question:
The forwarded header is defined in such a way that it can only carry complete IP addresses, but not IP prefixes.

Extending the header to carry IP prefixes would allow to make a tradeoff between user privacy and interest of the other end in learning about from where the request came.
Such a prefix could, for instance, say 192.168.178.0/24 instead of giving the full IP address of 192.168.178.22.

OTOH browser finger printing can potentially anyhow allow to figure who what user is doing the request.

IANA has reviewed draft-ietf-appsawg-http-forwarded-06 and has the following comments:

IANA understands that, upon approval of this document, there are two actions
which IANA must complete.

First, in the Permanent Message Header Field Names registry located at:

www.iana.org/assignments/message-headers/perm-headers.html

a new permanent message header will be registered as follows:

Header Field Name: Forwarded
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Second, IANA is to create a new registry, called the "HTTP Forwarded parameters"
registry. This registry will be maintained through Specification Required as
defined by RFC 5226.

There are initial assignments for this new registry as follows:

+-------------+---------------------------------------+-------------+
| Parameter  | Description                          | Reference  |
| name        |                                      |            |
+-------------+---------------------------------------+-------------+
| by          | IP-address of incoming interface of a |[ RFC-to-be ]|
|            | proxy                                |            |
| for        | IP-address of client making a request |[ RFC-to-be ]|
|            | through a proxy                      |            |
| host        | Host header field of the incoming    |[ RFC-to-be ]|
|            | request                              |            |
| proto      | Application protocol used for        |[ RFC-to-be ]|
|            | incoming request                      |            |
+-------------+---------------------------------------+-------------+

IANA understands that these two actions are the only ones required to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Forwarded HTTP Extension) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Forwarded HTTP Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document standardizes an HTTP extension header field that allows
  proxy components to disclose information lost in the proxying
  process, for example, the originating IP address of a request or IP
  address of the proxy on the user-agent-facing interface.  Given a
  trusted path of proxying components, this makes it possible to
  arrange it so that each subsequent component will have access to, for
  example, all IP addresses used in the chain of proxied HTTP requests.

  This document also specifies guidelines for a proxy administrator to
  anonymize the origin of a request.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/


No IPR declarations have been submitted directly on this I-D.

====================================
A specific point for Last Call discussion, please:
During AD Evaluation, the registration policy for the new "HTTP
Forwarded parameters" registry (see Section 9) was changed to
"Specification Required" from "RFC Required".  This needs further
review during Last Call, for two reasons:

1. While RFC Required forces new registrations through the IETF RFC
process, and might discourage registrations from individuals or
organizations that are unfamiliar with or averse to that process,
Specification Required necessitates the appointment of a Designated
Expert to review the requests and associated specifications.  Each of
these policies comes with baggage, and we have to make sure we're
weighing it down with the *right* baggage.

2. If we stay with Specification Required we should include a short
paragraph with rough guidelines for the Designated Expert: what to
consider when approving registration requests.  If we want the DE to
approve most requests, just checking the associated specifications for
sanity, we need to say that.  If we want the DE to put some judgment
into deciding whether the requested parameters make sense and fit into
the usage model, or whatever, we should say something about that.
Comments and proposed text for this are encouraged.
====================================

Document shepherd writeup:

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?  Why
> is this the proper type of RFC?  Is this type of RFC indicated in the
> title page header?

This document provides definition of a new HTTP header field, which is
targeted at replacing many similar but non standard HTTP header fields.
This is targeted at becoming a Proposed Standard, which is appropriate,
and which is indicated in the document header.

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.

This document standardizes an HTTP extension header field that allows
proxy components to disclose information lost in the proxying
process, such as the originating IP address of a request and the IP address
of the proxy on the user-agent-facing interface.  Given a trusted
path of proxying components, this makes it possible to arrange it so
that each subsequent component will have access to, for example, all IP
addresses used in the chain of proxied HTTP requests.

This document is meant to replace several ad-hoc solutions already
deployed today.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

Nothing worth noting.

> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

There are several implementations of similar header fields already in use.

> Personnel
>
>  Who is the Document Shepherd? Who is the Responsible Area
>  Director?

Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD.

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I've read the whole document and tried to spot inconsistencies between
different parts or with documents being referenced. I've also reviewed ABNF
and IANA considerations in details. The latter was changed based on my
review.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

The document got lots of review in HTTPBIS WG and APPSAWG.
No concern about depth and breadth of the reviews.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

The document already got reviews regarding Privacy Considerations.
I can't think of another review that needs doing (apart from Directorate
reviews that would happen anyway).

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosures have been filed on this document.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?

The document has solid WG consensus.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

idnits 2.12.13 reports no errors/warnings.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

Expert Review for the Forwarded HTTP header field was requested
and the Designated Expert (Graham Klyne) confirmed that the registration
is Ok.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

The document references Normatively 2 drafts in the HTTPBis WG. The two
referenced drafts are believed to be near completion.
All other references are to RFCs.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

There are no DownRefs.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document.

The document registers a new HTTP header field ("Forwarded") and also
creates a new subregistry for Forwarded header field parameters. This is
consistent with the body of the document.

> Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.

Yes.

> Confirm that any referenced IANA registries have been clearly
> identified.

Yes.

> Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

Yes.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

The new registry created by the document specifies an RFC Required policy
and doesn't require Expert Review.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

The ABNF verifies with BAP (after expanding of the list production
defined in HTTPBIS documents).