Skip to main content

Loop Detection in Content Delivery Networks (CDNs)
RFC 8586

Revision differences

Document history

Date Rev. By Action
2022-11-10
02 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2019-08-19
02 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2019-08-19
02 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Tim Wicinski was marked no-response
2019-04-25
02 (System) Received changes through RFC Editor sync (added Errata tag)
2019-04-24
02 (System)
Received changes through RFC Editor sync (created alias RFC 8586, changed title to 'Loop Detection in Content Delivery Networks (CDNs)', changed abstract to 'This …
Received changes through RFC Editor sync (created alias RFC 8586, changed title to 'Loop Detection in Content Delivery Networks (CDNs)', changed abstract to 'This document defines the CDN-Loop request header field for HTTP.  CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop.  The new header field can be used to identify the error and terminate the loop.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-04-24, changed IESG state to RFC Published)
2019-04-24
02 (System) RFC published
2019-04-23
02 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-04-17
02 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-04-01
02 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-02-14
02 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-02-11
02 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-02-08
02 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-02-05
02 (System) RFC Editor state changed to EDIT
2019-02-05
02 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-02-05
02 (System) Announcement was received by RFC Editor
2019-02-05
02 (System) IANA Action state changed to In Progress
2019-02-05
02 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-02-05
02 Amy Vezza IESG has approved the document
2019-02-05
02 Amy Vezza Closed "Approve" ballot
2019-02-05
02 Amy Vezza Ballot approval text was generated
2019-02-05
02 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-02-03
02 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-03
02 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-02-03
02 Mark Nottingham New version available: draft-ietf-httpbis-cdn-loop-02.txt
2019-02-03
02 (System) New version approved
2019-02-03
02 (System) Request for posting confirmation emailed to previous authors: Stephen Ludin , Mark Nottingham , Nick Sullivan
2019-02-03
02 Mark Nottingham Uploaded new revision
2019-02-03
01 Eric Rescorla [Ballot comment]
Mark provided new text and I'll trust the AD to follow up with getting it in the doc.
2019-02-03
01 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss
2018-12-20
01 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-12-20
01 Benjamin Kaduk
[Ballot comment]
I support Ekr's Discuss (and note that "unlikely" is not really a
quantifiable criterion).

Section 1

  This specification defines the CDN-Loop request …
[Ballot comment]
I support Ekr's Discuss (and note that "unlikely" is not really a
quantifiable criterion).

Section 1

  This specification defines the CDN-Loop request header field for HTTP
  to enable secure interoperability of forwarding CDNs.  Having a
  header that is guaranteed not to be modified by other CDNs that are
  used by a shared customer helps give each CDN additional confidence
  that any purpose (debugging, data gathering, enforcement) that they
  use this header for is free from tampering due to how that customer
  configured the other CDNs.

Per some of the other discussions on this document, I don't think that
"guaranteed" is the best description here; the property that we are hoping
to get is more that we have a well-known place to store loop-prevention
state, and it is documented as being a header field that should not be
removed by cooperating implementations.  There is no "guarantee" so long as
implementations that do not support CDN-Loop are in play, but the field of
play should improve over time as CDN-Loop support increases.

(Ben's comment about the "MUST NOT remove this header field" apparently
applying to even intermediaries that do not implement this spec is also
relevant.)

I see that this Section 2 text is already slated for edits, but I might
make a bigger change than just s/MUST NOT/must not/, maybe something like:

The effectiveness of this mechanism relies on all intermediaries preserving
the header field, since removing (or allowing it to be removed, e.g., by
customer configuration) would prevent downstream CDNs from using it to
detect looping.  In general, unknown header fields are not removed by
intermediaries, but there may be need to add CDN-Loop to an
implementation's list of header fields that are not to be removed under any
circumstances.

Section 3

If we're going to talk about the potential for signing the header field's
contents (nit: the new text just talks about "the header" with no "field"),
do we need to say how the signature validation would be affected by another
intermediary adding to the CDN-Loop header field's value?
2018-12-20
01 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-12-20
01 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12072


This seems like can be easily fixed, but I do think it needs to be
fixed. …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12072


This seems like can be easily fixed, but I do think it needs to be
fixed.

DETAIL
S 2.
>      header if necessary).

>      The token identifies the CDN as a whole.  Chosen token values SHOULD
>      be unique enough that a collision with other CDNs is unlikely.
>      Optionally, the token can have semicolon-separated key/value
>      parameters, to accommodate additional information for the CDN's use.

I don't know how to understand "unique enough" as a conformance
requirement. I think you need to specify something specific here, like
"globally unique" or some other scope. I don't insist that you provide
a construction algorithm, though obviously that would be good.
2018-12-20
01 Eric Rescorla
[Ballot comment]
S 1.
>      in a "loop" accidentally; because routing is achieved through a
>      combination of DNS and forwarding …
[Ballot comment]
S 1.
>      in a "loop" accidentally; because routing is achieved through a
>      combination of DNS and forwarding rules, and site configurations are
>      sometimes complex and managed by several parties.

>      When this happens, it is difficult to debug.  Additionally, it
>      sometimes isn't accidental; loops between multiple CDNs be used as an

can be used


S 2.
>      CDN-Loop = #cdn-id
>      cdn-id  = token *( OWS ";" OWS parameter )

>      Conforming Content Delivery Networks SHOULD add a value to this
>      header field to all requests they generate or forward (creating the
>      header if necessary).

Can this header only go in a request?


S 3.
>      through configuration) and servers (including intermediaries) SHOULD
>      NOT use it for other purposes.

>  3.  Security Considerations

>      The threat model that the CDN-Loop header field addresses is a

As Alissa points out, this also potentially leaks the CDN you use,
even if that would otherwise be hidden. For instance, suppose that a
request goes A -> B -> C but B is hidden (doesn't add anything to the
headers). If you know B's token, then you can tell if this is the case
or not., by injecting it yourself and seeing if you get service. Seems
like you should document this.
2018-12-20
01 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2018-12-19
01 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-12-19
01 Ben Campbell
[Ballot comment]
*** Substantive Comments ***

I agree with Alissa's comments, and Adam's comments about configurations that intentionally cross a CDN more than once.

- …
[Ballot comment]
*** Substantive Comments ***

I agree with Alissa's comments, and Adam's comments about configurations that intentionally cross a CDN more than once.

- abstract: The abstract could use some more meat. What does the new header accomplish?

§2:
-- first paragraph: Seems like this header helps "detect" loops, rather than "prevent" them.
-- last paragraph: "To be effective, intermediaries - including Content Delivery Networks
- MUST NOT remove this header field,"

Does that put normative requirements on things that do not implement the spec?

§3, first paragraph: How can CDNs stop their customer from modifying the header?

** Editorial Comments ***

§1,
-- 4th paragraph: "loops between multiple CDNs be used as an
attack vector" Missing word(s) around "CDNs be"?
-- last paragraph: The last sentence os convoluted. Can it be broken into simpler sentences?
2018-12-19
01 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-12-19
01 Warren Kumari
[Ballot comment]
I have only a small nit:
"The threat model that the CDN-Loop header field addresses is a customer who is attempting to attack …
[Ballot comment]
I have only a small nit:
"The threat model that the CDN-Loop header field addresses is a customer who is attempting to attack a service provider by configuring a forwarding loop by accident or malice. "

The "attempting to attack ... by accident" reads oddly to me. It feel to me that "attempting" implies intent, and I don't see how you can accidentally intend to attack.
Perhaps "The threat model that the CDN-Loop header field addresses is a customer who is attacking a service provider by configuring a forwarding loop by accident or malice. " (or "causing an attack" or "negative impact").

Anyway, this is just a minor point, perhaps try address it if you are editing anyway...
2018-12-19
01 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-12-18
01 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-12-18
01 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2018-12-18
01 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-12-17
01 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-12-17
01 Adam Roach
[Ballot comment]
Thanks to everyone who worked on this document. In general it looks good,
although I have a handful of suggestions that the authors …
[Ballot comment]
Thanks to everyone who worked on this document. In general it looks good,
although I have a handful of suggestions that the authors may wish to
consider.

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

General:

SIP has a similar (albeit more rigorously-defined) loop detection model, which
carefully distinguishes between unwanted loops and what SIP terms "spirals,"
which are requests that (for valid operational reasons) traverse the same
entity more than once. Is it possible that CDNs might have similarly
intentional configurations that cause a request to traverse their network more
than once? If so, it's probably worth discussing this somewhere in this
document, so as to increase the chances that implementations have the
functionality needed by CDN operators.

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

General:

This mechanism implies a means for detecting loops, but gives no guidance for a
uniform way of indicating that such a loop has occurred. I would have expected
the document to either point to an existing 400- or 500-class response code, or
define a new 400- or 500-class response code to indicate a loop-induced failure.
(Compare with SIP's 482 response code).

Consider adding such guidance and/or a new code.

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

Abstract:

>  This specification defines the CDN-Loop request header field for
>  HTTP.

This description is too sparse to be a useful abstract. The technical summary
from the document shepherd write-up would seem to be a reasonable bit of text
to replace it with:

>  This simple document defines a new request header field for HTTP:
>  CDN-Loop. CDN-Loop addresses an operational need that occurs when an
>  HTTP request is intentionally forwarded between CDNs but then is
>  accidentally re-routed back into the original CDN causing a non
>  terminating loop. The new header field is used to identify the error
>  and terminate the loop.

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

§2:

>  header field to all requests they generate or forward (creating the
>  header if necessary).

Nit: "...creating the header field..."

>  As with all HTTP headers defined using the "#" rule, the CDN-Loop
>  header can be added to by comma-separating values, or by creating a

Nit: "...HTTP header fields..."

Nit: " ...CDN-Loop header field..."

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

§2:

>  CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn"

While the "cdn" TLD is not yet allocated by ICANN, it remains available for a
registry to apply for an be granted. Please use a hostname from a TLD or
second-level domain allocated by RFC 2606.
2018-12-17
01 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-12-17
01 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-12-17
01 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-12-17
01 Alissa Cooper
[Ballot comment]
Is it possible that a chain of these headers might reveal something proprietary (or otherwise non-public) that an involved CDN or site might …
[Ballot comment]
Is it possible that a chain of these headers might reveal something proprietary (or otherwise non-public) that an involved CDN or site might not want to have revealed to any entity with access to the request? Also, it seems possible for these headers to exacerbate fingerprinting of clients, say if something distinguishing two requests ends up being the chain of CDN-loop headers, or if the cdn-id is made more granular than it needs to be for the specified purpose. It might be good to discuss each of these issues a bit in Section 3.

Please respond to the Gen-ART review.
2018-12-17
01 Alissa Cooper Ballot comment text updated for Alissa Cooper
2018-12-17
01 Alissa Cooper
[Ballot comment]
Is it possible that a chain of these headers might reveal something proprietary (or otherwise non-public) that an involved CDN or site might …
[Ballot comment]
Is it possible that a chain of these headers might reveal something proprietary (or otherwise non-public) that an involved CDN or site might not want to have revealed to any entity with access to the request? Also, it seems possible for these headers to exacerbate fingerprinting of clients, say if something distinguishing two requests ends up being the chain of CDN-loop headers, or if the cdn-id is made more granular than it needs to be for the specified purpose. It might be good to discuss each of these issues a bit in Section 3.
2018-12-17
01 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-12-14
01 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-12-14
01 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-12-13
01 Amy Vezza Placed on agenda for telechat - 2018-12-20
2018-12-13
01 Alexey Melnikov Ballot has been issued
2018-12-13
01 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-12-13
01 Alexey Melnikov Created "Approve" ballot
2018-12-13
01 Alexey Melnikov Ballot writeup was changed
2018-12-13
01 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake.
2018-12-11
01 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-12-10
01 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-12-10
01 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-cdn-loop-01. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-cdn-loop-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new registration is to be made as follows:

Header Field Name: CDN-Loop
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review registry (see RFC 8126), we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that this is the only action 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. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-12-06
01 Colin Perkins Request for Last Call review by TSVART Completed: Ready. Reviewer: Colin Perkins. Sent review to list.
2018-12-03
01 Joel Halpern Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list.
2018-12-03
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2018-12-03
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2018-12-03
01 Magnus Westerlund Request for Last Call review by TSVART is assigned to Colin Perkins
2018-12-03
01 Magnus Westerlund Request for Last Call review by TSVART is assigned to Colin Perkins
2018-11-29
01 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-11-29
01 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-11-29
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2018-11-29
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2018-11-27
01 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-11-27
01 Amy Vezza
The following Last Call announcement was sent out (ends 2018-12-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, alexey.melnikov@isode.com, Tommy …
The following Last Call announcement was sent out (ends 2018-12-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, alexey.melnikov@isode.com, Tommy Pauly , tpauly@apple.com, Patrick McManus
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDN Loop Prevention) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'CDN Loop Prevention'
  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 2018-12-11. 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 specification defines the CDN-Loop request header field for
  HTTP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/ballot/


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




2018-11-27
01 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-11-27
01 Alexey Melnikov Last call was requested
2018-11-27
01 Alexey Melnikov Last call announcement was generated
2018-11-27
01 Alexey Melnikov Ballot approval text was generated
2018-11-27
01 Alexey Melnikov Ballot writeup was generated
2018-11-27
01 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2018-11-26
01 Tommy Pauly
Technical Summary

This simple document defines a new request header field for HTTP:
CDN-Loop. CDN-Loop addresses an operational need that occurs when an
HTTP request …
Technical Summary

This simple document defines a new request header field for HTTP:
CDN-Loop. CDN-Loop addresses an operational need that occurs when an
HTTP request is intentionally forwarded between CDNs but then is
accidentally re-routed back into the original CDN causing a non
terminating loop. The new header field is used to identify the error
and terminate the loop.

The document was co-authored by employees of three different large CDNs.

Working Group Summary

The group was largely in agreement that this was a sensible solution
and consensus was quickly reached. About 35 emails were exchanged on
the document. A majority of the comments dealt with the relationship
between CDN-Loop and the existing Via header field. Consensus was
reached that Via was essentially 'burned' at this point and not
operationally suitable for that purpose.

Document Quality

Participation in the document's review and development was sufficient
given the tight scope of the document. In addition to the 3
primary authors, 9 other individuals weighed in with comments and
reviews. This represented contributors from both clients, servers, and
intermediaries

The Working Group Last Call requested information on any plans to
implement. In addition to the author's CDNs one other CDN stepped
forward at that time with interest. There has been at least one
pre-release deployment already.

Personnel

Tommy Pauly is the document shepherd; Alexey Melnikov is the
responsible Area Director.
 
2018-11-26
01 Tommy Pauly Notification list changed to Patrick McManus <mcmanus@ducksong.com>, Tommy Pauly <tpauly@apple.com> from Patrick McManus <mcmanus@ducksong.com>
2018-11-26
01 Tommy Pauly Document shepherd changed to Tommy Pauly
2018-11-26
01 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2018-11-20
01 Patrick McManus
Technical Summary

This simple document defines a new request header field for HTTP:
CDN-Loop. CDN-Loop addresses an operational need that occurs when an
HTTP request …
Technical Summary

This simple document defines a new request header field for HTTP:
CDN-Loop. CDN-Loop addresses an operational need that occurs when an
HTTP request is intentionally forwarded between CDNs but then is
accidentally re-routed back into the original CDN causing a non
terminating loop. The new header field is used to identify the error
and terminate the loop.

The document was co-authored by employees of three different large CDNs.

Working Group Summary

The group was largely in agreement that this was a sensible solution
and consensus was quickly reached. About 35 emails were exchanged on
the document. A majority of the comments dealt with the relationship
between CDN-Loop and the existing Via header field. Consensus was
reached that Via was essentially 'burned' at this point and not
operationally suitable for that purpose.

Document Quality

Participation in the document's review and development was sufficient
given the tight scope of the document. In addition to the 3
primary authors, 9 other individuals weighed in with comments and
reviews. This represented contributors from both clients, servers, and
intermediaries

The Working Group Last Call requested information on any plans to
implement. In addition to the author's CDNs one other CDN stepped
forward at that time with interest. There has been at least one
pre-release deployment already.

Personnel

Patrick McManus is the document shepherd; Alexey Melnikov is the
responsible Area Director.
 
2018-11-20
01 Patrick McManus Responsible AD changed to Alexey Melnikov
2018-11-20
01 Patrick McManus IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-11-20
01 Patrick McManus IESG state changed to Publication Requested
2018-11-20
01 Patrick McManus IESG process started in state Publication Requested
2018-11-20
01 Patrick McManus Changed consensus to Yes from Unknown
2018-11-20
01 Patrick McManus Intended Status changed to Proposed Standard from None
2018-11-20
01 Patrick McManus Notification list changed to Patrick McManus <mcmanus@ducksong.com>
2018-11-20
01 Patrick McManus Document shepherd changed to Patrick McManus
2018-11-20
01 Patrick McManus Changed document writeup
2018-11-20
01 Patrick McManus IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-10-27
01 Patrick McManus IETF WG state changed to In WG Last Call from WG Document
2018-10-23
01 Mark Nottingham New version available: draft-ietf-httpbis-cdn-loop-01.txt
2018-10-23
01 (System) New version approved
2018-10-23
01 (System) Request for posting confirmation emailed to previous authors: Stephen Ludin , Mark Nottingham , Nick Sullivan
2018-10-23
01 Mark Nottingham Uploaded new revision
2018-08-16
00 Patrick McManus This document now replaces draft-cdn-loop-prevention instead of None
2018-08-16
00 Mark Nottingham New version available: draft-ietf-httpbis-cdn-loop-00.txt
2018-08-16
00 (System) WG -00 approved
2018-08-15
00 Mark Nottingham Set submitter to "Mark Nottingham ", replaces to draft-cdn-loop-prevention and sent approval email to group chairs: httpbis-chairs@ietf.org
2018-08-15
00 Mark Nottingham Uploaded new revision