Subject: Call For HTTPbis adoption: cdn-loop-prevention

From: Patrick McManus <[email-masked]>
Date: Thu, 26 Jul 2018 17:11:09 -0400

Hi All,

When we met in Montreal there was strong interest in the room in adopting
the presented cdn-loop-prevention draft, with no dissenting hum on the
topic. This message opens that call for adoption discussion on the list.

Specifically, if you didn't have a chance to participate in that discussion
please reply to this email with your opinion and reasons for or against
adoption of the loop prevention draft (
https://tools.ietf.org/html/draft-cdn-loop-prevention-00) as a proposed
standards track document. Discussion on any points raised relevant to the
draft is also welcome here.

As discussed, the document deals specifically with loop prevention at the
scope of a CDN and we're accepting that its an intrinsic part of the
document if we take it on (of course adopting it does not obligate the
group to eventually publish it, but changing the scope of the loop
detection would be out of scope for changes to it.)

I'll hold the CFA open until August 9th.

Thanks
-Patrick

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jul 2018 16:27:15 +1200

On 27/07/18 09:11, Patrick McManus wrote:
> Hi All,
> 
> When we met in Montreal there was strong interest in the room in
> adopting the presented cdn-loop-prevention draft, with no dissenting hum
> on the topic. This message opens that call for adoption discussion on
> the list.
> 
> Specifically, if you didn't have a chance to participate in that
> discussion please reply to this email with your opinion and reasons for
> or against adoption of the loop prevention draft
> (https://tools.ietf.org/html/draft-cdn-loop-prevention-00) as a proposed
> standards track document. Discussion on any points raised relevant to
> the draft is also welcome here.
> 
> As discussed, the document deals specifically with loop prevention at
> the scope of a CDN and we're accepting that its an intrinsic part of the

I still don't see the utility of adding yet another mechanism here - it
just looks like more complexity for those of us implementing them. Which
the implementations attempting to be worked around will block/break the
same way they break the existing mechanisms.

That said, I'm not going to vote against adoption if thats what the rest
of the WG want.

Amos