Subject: Re: Last Call: <draft-ietf-httpbis-cdn-loop-01.txt> (CDN Loop Prevention) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Sun, 2 Dec 2018 15:51:03 +0100

Hi there,

here's my feedback, mainly editorial:

> 1.  Introduction
> ...
>    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.

Please use "header field" consistently.

> 1.1.  Relationship to Via
> 
>    HTTP defines the Via header field in [RFC7230], Section 5.7.1 for

s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/

>    "tracking message forwards, avoiding request loops, and identifying
>    the protocol capabilities of senders along the request/response
>    chain."
> 
>    In theory, Via could be used to identify these loops.  However, in
>    practice it is not used in this fashion, because some HTTP servers
>    use Via for other purposes - in particular, some implementations
>    disable some HTTP/1.1 features when the Via header is present.

It would be nice if this came with pointers to related bug reports so 
the reader could have a glance.

> 2.  The CDN-Loop Request Header Field
> 
>    CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn"
>    CDN-Loop: baz-cdn; abc="123"; def="456", anotherCDN
> 
>    Note that the token syntax does not allow whitespace, DQUOTE or any
>    of the characters "(),/:;<=>?@[]{}".  See [RFC7230], Section 3.2.6.

s/.  See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./

>    Likewise, note the rules for when parameter values need to be quoted
>    in [RFC7231], Section 3.1.1.

s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/

> 5.2.  Informative References
> 
>    [loop-attack]
>               Chen, J., Jiang, J., Zheng, X., Duan, H., Liang, J., Li,
>               K., Wan, T., and V. Paxson, "Forwarding-Loop Attacks in
>               Content Delivery Networks", ISBN 1-891562-41-X,
>               DOI 10.14722/ndss.2016.23442, February 2016,
>               <http://www.icir.org/vern/papers/cdn-loops.NDSS16.pdf>.

The thing being cited is not the same thing as ISBN 1-891562-41-X (which 
appears to be the publication in which the paper appears). I believe it 
would be best to drop the ISBN number.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Dec 2018 09:21:03 +1100

Hi Julian,

> On 3 Dec 2018, at 1:51 am, Julian Reschke <[email-masked]> wrote:
> 
> It would be nice if this came with pointers to related bug reports so the reader could have a glance.
> 

Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 04 Dec 2018 14:25:08 -0800

> On Dec 4, 2018, at 2:21 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Julian,
> 

In fact, RFC 7322 actually includes both styles of section reference:

Status of This Memo

  ...  see Section 2 of RFC 5741.

4.8.4.  Internationalization Considerations Section

   ... see "IETF Policy on Character Sets
   and Languages" [BCP18], Section 6, for more information.

—Tommy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 5 Dec 2018 06:44:16 +0100

> Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.

In this case it was a personal preference, but note that just because 
multiple forms are blessed, they work equally well everywhere...

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 5 Dec 2018 11:04:05 +0000

>     and Languages" [BCP18], Section 6, for more information.
I suggest we leave this document as-as and let RFC Editor to sort this 
out. They are quite good at this.