On Thu, Dec 23, 2021 at 12:31 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Hi PHB, I have read through the thread.
You have also been in discussions on FB etc. Your comments are very helpful, thanks.
I don't think that we can really give out 7B short callsigns though.
I have many nick names that are used in a variety of contexts, some of which
are loose pseudonym (i.e. many people in some communities know me by the nick
only, and we don't necessarily go out of our way to connect our muggle
names). The number of callsigns needed is more like 30B, if we all have 3-4
nicknames. Add to that nicknames like "mom" and "dad"...
Plus my pets will need nicknames too.
I totally agree. But the 7B figure is merely the value I have been using as the minimum value that has to be supported for capacity planning purposes. If this takes off, and the price is $0.10/callsign I expect the number of names to get into the trillions. But I didn't want to start off with that.
For example, I am not going to bind my IoT devices in my house to my callsign @phb because I might want to sell the house. So I am going to have @lawnswood_chester, @dalek_hq_boston, @minons_truro, etc. That way I can easily grant authorization to everyone living in the house. Now everyone can control the HVAC, they don't need to wake me up to do it. This goes even more so for rental properties.
I think there does need to be a little friction in the system or everyone is going to be run ragged. It doesn't cost much to register a name but there is a cost. And there is a much higher overhead from people attacking the system at layer 8. So there has to be enough revenue to insure the operations, etc.
I'm very much into the idea that:
_No renewal fees. Names are sold freehold, not rented_
The importance of not rented is much more than the cost of renting names. Much more than half of the cost in the DNS system comes from the need to service renewal fees. And that creates costs all the way up the stack.
I can't use a DNS name as a surrogate for an ISBN or a DOI, I can use a callsign though. I am not going to pay $10/yr to keep the web page of a book that is out of print but if I can register the callsign @dotcrime_manifesto for $0.10, I will call the publisher, exercise my returned rights clause and plonk it out on a Web service somewhere.
Back in the mists of time Google spent a lot of time/effort collecting digital copies of every book in creation. I am sure they would be more than happy to serve up the text if it was easy for them to do.
So yes, very very large numbers of callsigns, at least one per person, residence, book, etc. etc. This is also getting us towards content routing type schemes.
The reason I picked $0.10 is that I know I can scale a system so that the cost of registration is much less than $0.01 per KB. Every maintenance and registration task for the registry and the responder is trivially parallel. So I can easily support the system with a heartbeat of a minute or so at very, very large scale.
I come back to: all (nick)names are relative/local:
https://datatracker.ietf.org/doc/html/rfc2693#section-2.6
The actual cryptography and formats in RFC2693 we can replace with CBOR/COSE,
and/or your mathmesh formats.
I prefer JSON for assertions, human readability is a plus. But serialization formats are easy.
The way that I would suggest we do this is via allocating IPv6 prefixes to
people. Do people need an entire /64 each? Maybe.
A /32 allocation gives us 4B /64s, which is probably enough to start with,
if we can ask for additional /32s. Or we could ask for a single IPv6/24
giving us 281T or something.
Glad you asked, I wasn't going to bring it up (yet) but I am also planning to assign an IPv6 ULA with each callsign.
Since I have a registry scheme, I can assign addresses incrementally, no need to rely on random allocation. So I will be proposing to allocate into fd00::/8 in /64 chunks. So I will probably be asking for a /32 sized chunk in fd00::/8 which would give me an IPv4 sized space to start with and ask for more iff needed. If it fails, the next experiment in registered ULA space just picks a different prefix.
Since the ULA IP addresses are non-routable, the size really doesn't matter very much. There is no need for sub-nets and if you think you need one, just grab another callsign.
The way these would be used is Alice Plutocrat has houses in Boston and Cape Cod. She has fixed devices in each location that would like to be able to interact regardless of which ISP she is using for the purpose. Her NAT boxes on each end perform ARP like routing across the Internet mapping the ULA address to a routable address and back. The net is a Virtual Public Network, it has the bridging functions of IPSEC without any of the crypto which we are doing at transport layer and above.
We need this really allocated, because then it fits immediately into ip6.arpa.
Yeah, it's long hard to remember prefix. We already have a variety of ways
to put 128-bit AAAA in forward places. We might need some new RR types so that we
can do relative naming, or we could just use AAAA records.
So "Michael's IETF-Friend-PHB" would be implemented by having
"IETF-Friend-PHB IN AAAA" contain your AAAA value in my tree.
Oh nice, now I get it...
Populating the reverse DNS would provide some really interesting properties.
What do we *do* with these IPv6? Probably not route them globally.
I expect use of L3 overlays, such as LISP, but also L7 overlays through web
browsers too. Maybe /128 routes via RPL(RFC6550) within the home. Maybe.
That is the sort of thing I am thinking of as well. But with access controls
Alice Plutocrat probably doesn't want everyone knowing where the bits go. The public delegation can get people to an authoritative but they will need authorization to get any response out of it.
The win for IETF here is that if I get traction at the million user level, my expansion strategy will be 'Mesh ready' (was going to be 'Web/4.0 ready' till team Ponzi decided to start talking about Web/3 like TimBL hadn't already done Web/3.0 a decade ago). What will it mean for an ISP to be 'Mesh ready'?
1) Offer (not require use of) a Mesh Service with at least 10GB of storage and a decent SLA
2) Offer (not require use of) a Callsign Resolver with a decent SLA
3) Provide registration of 10 callsigns per account
4) Support IPv6
5) Support a DNS forwarding service of a fixed DNS address that tracks the DHCP delegation of the user.
6) Anything else that makes sense and futhers IETF goals
*Note that providing a Mesh service will eventually entail providing at least some form of DPRIV like DNS resolution and various other security related protocol enhancements.
