Re: Eric Rescorla's Discuss on draft-ietf-httpbis-cdn-loop-01: (with DISCUSS and COMMENT)

On Mon, Jan 28, 2019 at 6:18 PM Mark Nottingham <mnot@mnot.net> wrote:

> Adam seemed to be OK with the current text in <
> https://www.w3.org/mid/00331e00-e1a5-e12a-6462-826033dcad6b@nostrum.com>,
> so I think it's just you.
>

1. I'd like to hear Adam comment after reading my note below.
2. I'm not sure how this changes the points I'm making.

-Ekr


>
> > On 29 Jan 2019, at 11:13 am, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > I feel like we're talking past each other a bit.
> >
> > The original text just has some opaque string and then assumes there
> will be no collisions, but doesn't provide any mechanism for preventing
> them. Saying that people should use DNS-based names is a mechanism of
> preventing them, but if you also allow opaque strings then there's still no
> mechanism for preventing them from colliding. So, either we believe that
> arbitrarily chosen opaque names have a nontrivial chance of collision (in
> which case we need to provide a mechanism about how to not have that
> happen) or we believe they don't, in which case no text is needed. It seems
> to me that Adam and I think there is a nontrivial chance, and Mark doesn't,
> but that's the point to resolve.
> >
> > -Ekr
> >
> >
> > On Sun, Jan 27, 2019 at 4:51 PM Mark Nottingham <mnot@mnot.net> wrote:
> > Some advisory text to guide using them?
> >
> >
> > > On 28 Jan 2019, at 9:45 am, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > Well, this argument has some force, but my point is that this isn't
> substantively different from the initial version of the draft in this
> respect.
> > >
> > > -Ekr
> > >
> > >
> > > On Sun, Jan 27, 2019 at 2:10 PM Mark Nottingham <mnot@mnot.net> wrote:
> > > HTTP has used similar constructs for 20+ years and collisions have not
> been an issue:
> > >
> > > https://httpwg.org/specs/rfc7230.html#header.via
> > > https://httpwg.org/specs/rfc7231.html#header.user-agent
> > > https://httpwg.org/specs/rfc7231.html#header.server
> > >
> > > All of them address the issue of pseudonym collision by recognising
> that implementers have an interest in distinguishing their implementations
> from others if they want to rely upon a field for debugging (as all of
> these are, effectively). None of them addresses the case of an active,
> *intentional* collision (as we see sometimes with User-Agent), because
> doing so would require far too much infrastructure, compared to any benefit
> seen.
> > >
> > > Notably, doing something like rooting product tokens in the DNS name
> space would have done *nothing* to prevent the issues we're seeing with
> User-Agent. Doing so would have also brought about the usual questions
> around whether something needs to listen at that hostname, whether it needs
> to resolve, and what happens when a name changes hands.
> > >
> > > The failure case of a collision is also pretty straightforward; if I
> run a CDN and another CDN usurps my value, they're only shooting themselves
> in the foot, because it'll look like they're in a loop if I'm configured to
> forward traffic to them, and they'll start refusing requests -- thereby
> screwing their customers. Their natural incentive is to avoid this
> situation.
> > >
> > > So, the properties you're looking for are already naturally emergent
> from the documented protocol. While we could require a hostname, I think
> doing so is effectively cargo-cult protocol design; it won't actually
> improve collision avoidance in practice.
> > >
> > >
> > >
> > > > On 28 Jan 2019, at 6:44 am, Eric Rescorla <ekr@rtfm.com> wrote:
> > > >
> > > > Unless I am misreading this text, it seems to not provide any
> guidance at all about how the pseudonyms are constructed, so I don't really
> see how it addresses the issue of pseudonym collision
> > > >
> > > > On Thu, Dec 20, 2018 at 9:04 PM Mark Nottingham <mnot@mnot.net>
> wrote:
> > > > See:
> > > >   https://github.com/httpwg/http-extensions/commit/59505dbd1883
> > > >
> > > >
> > > > > On 21 Dec 2018, at 3:34 pm, Adam Roach <adam@nostrum.com> wrote:
> > > > >
> > > > > On 12/20/18 7:19 PM, Mark Nottingham wrote:
> > > > >> On 21 Dec 2018, at 11:40 am, Adam Roach <adam@nostrum.com> wrote:
> > > > >>> I agree with EKR here. The more I think about the situation --
> and Mark's responses in particular ("There are relatively few CDNs, and
> they're pretty aware of each other") -- the more I'm convinced that, while
> the proposed solution *probably* works in 2018, it may well fail in 2028,
> depending on how the CDN market evolves. If history is any guide, engineers
> are pretty terrible futurists. The best we can do is plan for scaling
> beyond that which we can presently imagine (cf. IPv4).
> > > > >>>
> > > > >>> I think some means of collision avoidance here is required prior
> to document publication.
> > > > >> I agree engineers are terrible futurists; however (and perhaps as
> a result), we're really really good at over-engineering things for
> anticipated problems that don't eventuate. My viewpoint here is informed by
> observing how many Web-related registries operate (or fail to).
> > > > >
> > > > >
> > > > > No one here is asking for a registry.
> > > > >
> > > > >
> > > > >> The current specification allows us to insert more stringent
> requirements in the future if necessary. Personally, I think that's
> sufficient.
> > > > >>
> > > > >> However, if you insist, I think the lowest-impact way to address
> this is to adopt a structure similar to that used in Via, (hostname under
> control of the CDN or pseudonym) and encourage (but not require) use of a
> hostname.
> > > > >
> > > > >
> > > > > It's probably enough to say that it has to end in a domain name
> under control of the CDN, but your proposal works as well.
> > > > >
> > > > >
> > > > >> If we do that, we might want to revisit the example, since its
> use of 'host' might be confusing to readers.
> > > > >
> > > > >
> > > > > I always assume that spec changes that impact examples imply
> changes in the corresponding examples, so yes. Thanks.
> > > > >
> > > > >
> > > > > /a
> > > > >
> > > > >
> > > >
> > > > --
> > > > Mark Nottingham   https://www.mnot.net/
> > > >
> > >
> > > --
> > > Mark Nottingham   https://www.mnot.net/
> > >
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>