On 10 November 2016 at 10:31, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > On 11/10/2016 10:18 AM, Stephen John Smoogen wrote: >> On 10 November 2016 at 09:27, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: >>> >>>>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote: >> >> >> Here are the items I would like to point out: >> >> 1. The TLD name should be something that DNS considers a known unknown >> name. With the fact that IANA is allowing top level domains of all >> sorts we do not want to end up having .fedora or .foobaz end up >> causing thousands of computers saying they are in someones domain. So >> .invalid .localhost .example .local or .test . I expect that >> .localdomain might not ever be registered but who knows. >> > > RFC 2606[1] reserves several TLDs that may never be registered for public > usage. Out of those, going with > Fedora-XXXXXXXX.localhost > seems like the best bet. > > > [1] https://tools.ietf.org/html/rfc2606#page-2 > > >> 2. The XXXXXX is rather important because of two conflicting items. >> One we don't want it to be too short that collisions might occur a >> lot, but we don't want it to be too long for readability but also the >> less collisions the more likely it can be used to track people. If we >> don't care about making breadcrumbs which could be used to 'track' >> people we need to be clear about it so that people who are not wanting >> that can steer clear. [My 'I am an idiot about randomness' solution >> would be uuidgen | sum and that number is used for this. There is a >> good chance of uniqueness per small site and non-uniqueness overall. ] >> > > Again, I think that tracking issues are orthogonal to this ticket. Anyone who > sets a hostname *manually* is already unique. If that's something to be > concerned about, then it's better to solve that at whatever layers reveal this > information. That is solving it too late because there will always be leaks. Privacy is just another form of security. If you don't design it in as best you can early on, you are spending too much work later trying to patch it in. Currently hostnames and volumegroups would not be that useful to track people down. We all like to think that we have come up with that unique name for the computer.. but in general it isn't that unique and there are going to be anywhere from 10 to millions of other computers with that identifier. That actually obscures data and so makes it less likely to be used. However anything which is machine created to try and make sure there aren't easy collisions is a boon to tracking. And any identifier which may be used in multiple places because it makes it easier on a system admin or a general program.. bonus. So let us say we don't take this into consideration until much later or higher in the stack and we want to make sure that we don't have collisions. So we go with something like a Fed-<12 char [0-9a-z]> identifier. Because we now have a unique identifier it tends to get used everywhere that a confusion of names might occur.. thus vg-<12 char [0-9a-z]> etc. This makes programmers and system administrators lives easier because you can have a huge storage array with unique names... yay. However it also makes the person who has the laptop with Fed-0123456789ab vg-0123456789ab, etc etc stand out like a sore thumb as various parts of that data might get leaked out in different places. The hostname shows up in dhcp logs, the vg shows up in browser environment variables., some other tools decides that the sys-id is useful for cookie generation, etc etc. Each time you think you have gotten all the apps fixed, some programmer finds this unique id, realizes it makes their life easier for some other problem they have and uses it again. So in any case, what I am suggesting is that we make a semi-unique identifier. It is unique enough that you won't get a collision in some 'target' space, but not so unique that it stands out like a black dot on a white shirt. Make the code adjustable somewhere in the process so that if someone wants it off, it can be done and if they need it to be a bigger space it can be done so. > >> 3. case-sensitivity argument about Fedora or fedora looks to be a >> bikeshed. There are probably local business reasons where having >> caps/lowercase in names is important but in those cases they should >> put in tools to conform to their local business reason. > > Yeah, I mostly just want Fedora for the proper noun. Since it serves no > functional difference, I don't care much. After the conversation we've had so > far, I *do* think we're more or less agreed that we want the longer "Fedora" > rather than "fed" prefix though. > > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
