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

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/
>
>