<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2020 at 5:56 AM Karl Reuss <<a href="mailto:reuss@umd.edu">reuss@umd.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/29/20 8:33 PM, Paul Vixie wrote:<br>
> we have dispensed with 'site' and 'location' as relationships which would<br>
> define a 'portion of' as a 'root server instance', and that's good (says me).<br>
<br>
Personally, I'm not ready to give up on location/site as part of the RSSAC definition for instance.  When we're at an RSSAC meeting discussing instances, location is the primary way we identify them. I really liked the plain language Wes used in his recent definitions and i'm concerned your more technically accurate definition will confuse much of our RSSAC audience.<br><br></blockquote><div><br></div><div>I don't think the instance description or methodology needs to be uniform.</div><div><br></div><div>After all, an instance is only ever an instance of a <i>single</i> root-server's anycast footprint.</div><div><br></div><div>E.g. you can say "instance X of <a href="http://b.root-servers.net">b.root-servers.net</a>", but not "instances at location X", since those are apples to oranges comparisons.</div><div><br></div><div>The naming scheme used by any particular root server operator's instances should be left up the the operator.</div><div><br></div><div>The only real requirement is that for any particular operator, their instances should be named uniquely, but I think everyone will agree that is only sensible.</div><div><br></div><div>Insisting on a uniform naming is only going to cause problems, and IMHO doing so (uniform naming) accomplishes nothing particularly useful. </div><div><br></div><div>Brian</div></div></div>