Also don't fall into the trap of just assigning random serial numbers to servers. I later worked somewhere that did this and it makes it difficult to communicate about the servers in the middle of outages. I've had communication issues where I've been talking to another engineer and I was using the first hex digits of the server name and they were using the last as shortcuts and we thought we were logged into different servers and it was the same one. You hardly ever want humans dealing with your server names, but when humans do need to use your server names it is one of the times that really matter because shit is on fire.
Group them by single purpose of what the cluster does with some kind of incrementing number. The idea to use theme names and not "project" names is also deeply 100% wrong. When you have 100,000s of servers you run out of theme names and you'll fail to remember the name schemes in the middle of an outage. Name them after what the servers do, and keep them more or less reflecting their purpose. Consider carefully some kind of numbering scheme to keep the short names unique across datacenters so you don't have a dozen foo-101 servers. You may want to use incrementing serial numbers for both datacenters and cluster members or something so "foo-1-101" and number your datacenters (or logical cluster number if you're really big and stamp them out 30,000 at a time or something).
Oh right this is the RFC from 1990. Yeah, shit has changed, this RFC needs to evolve.
Back in 1990 when this was written a single system admin hand managing 20-30 servers was a lot. Web didn't exist. I can't recall any kind of load balancing or much clustering. You might have SunOS boxes running RIP doing routing across internal subnets that were 10baseT. NAT and firewalls weren't used much at all and servers would just sit on public IPs. This RFC is prehistoric.