Erik Kline <[email protected]> wrote:
>> Here is my proposed text, in case you haven't used the link above yet:
...
> If this is the recommendation that has consensus then I think this
> definitely explains the intention more clearly, thank you.
I guess I need to wait a few days to hear back from the WG and other reviewers.
I should repost to [email protected], which I'll do in a second.
> That said, it seems to me to be akin to saying "don't use a CDN", or at
> least don't use them the way most CDN services are configured. I'm not
> sure how this will be received by folks who should be reading and
> considering these things.
> Still, including it as RECOMMENDED seems fine to me. It tells the
> reader "here be dragons" and sets out the rationale.
Yes, the goal is to have some BCP that sets out some things that work better.
I did run this document by a few CDN people and they seemed okay.
Of course, things could get better, and we could revise the document.
Use a CDN if you need to, I think that there are some reasonable ways to do
configure things for it.
If this document helps CDNs and users of CDN align their offerings better,
than that's a good thing. In this case having an A/AAAA record that just
always has *all* the possible geolocation/tailored-response answers would
work really well. Like:
all.upgrades.example.com -- all possible names (put into MUD file)
upgrades.examples.com -- tailored response name (put into firmware)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
