Subject: Proposal, open up .arpa

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2021 13:28:40 -0500

TL;DR; I have two ways of achieving my desired end. One of which people are
not going to like, the other of which they are totally going to hate. I do
not actually require IETF permission for either, nor am I the only person
thinking along these lines, I am merely the person whose approach is least
likely to result in collateral damage, consider responses in those terms.

I have been following various naming proposals in the PonziCoin world for
some time. There are many companies who for a mere $10-200/year will
register a shortname for your ethereum wallet so people can give you money.
And of course, the cost of ethereum gas for making the payments only makes
the cost even stupider. But don't worry, there will be a technical fix for
that the minute they find themselves a virgin and a unicorn.

OK, so those proposals are obvious nonsense but the notion of using a
Certificate Transparency type log to issue names for life on a first come
first served basis is not. Hence my callsign proposal:

https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsign-01.html

[A very similar proposal has been made to ITU by the Chinese delegation
under their 'New Internet' scheme though I only became aware of the details
of that after I wrote my own. It is my belief that the primary motivation
behind the ITU proposal is to prevent the abuse of DNS as a control point
in the Internet infrastructure.]

Running infrastructure costs real money but I see no reason for the cost of
running the infrastructure proposed to be more than a one-time $0.10 per
name. No renewal fees. Names are sold freehold, not rented.

The objective here is to give Internet users a name they can use for life.
And yes, I realize that it is impossible to collect $0.10 fees so I plan to
sell names in packs of 50 or so. So for the price of a pint of beer you can
buy a permanent callsign for yourself and pass out the means to grab one to
your friends.

There are of course many social issues to be considered, not least of which
where does the surplus go. My proposal being that the whole show to be run
by a not-for-profit and the surplus go to fund open source development of
secure Internet software, specifications and standards.

But that is not the part I want to talk about right now. What I do want to
talk about is how a new naming scheme interfaces to the DNS so that it can
be used to connect to legacy applications. Legacy in this context meaning
'the stuff that is working'.

So Alice registers the callsign @alice and can use that in messaging
applications that understand the callsign scheme. Which is not hard, just
hook up to a callsign resolver and send over a query. As with blockchain,
the resolver maintains a complete copy of the log. Queries go to a
resolver, not the registry. This means far greater robustness than DNS and
offloads almost all the cost from the registry.

But what about that doorbell, that WiFi camera, etc. that Alice has? To
talk to them she needs to use her browser and that runs HTTP.

The obvious solution for this is to put a statement in the delegation
assertion for @alice to specify an authoritative DNS resolver for the DNS
addresses *.alice.mesh. The callsign resolver then delegates to the
authoritatives. The net result is that all Alice needs to do to resolve
these names is to use a DNS resolver that redirects requests in .mesh to
one of the callsign resolvers.

The net result is a protocol that respects the DNS data model at the lower
levels while modernizing the root level.

OK so nobody expects me to pay to register .mesh. I am not even going to
lift a finger to make a proposal to ICANN.

But I am not the only person making a proposal in this area and while a
single pirate TLD designed by someone who knows something of what they are
doing is likely to be amusing, a hundred or more is likely to be less so.

Which has me looking at .ARPA instead.

Having Alice type http://coffee.alice.mesh.arpa/ instead of
https://coffee.alice.mesh/ is not as nice but she will live with it. or if
open callsigns win the naming game, the anybox in her browser will probably
let her type coffee@alice and route to the place she expects to go.

Problem here is that RFC 3172 was written in a different era when people
were still frightened about the loss of control. The notion that registries
are not control points had not yet been understood.

So which would people prefer for the pseudo-delegation?

alice.mesh or alice.mesh.arpa?

This would be a reservation in .arpa, not a delegation.

PHB

(Oh and yes, I do have a browser implementation thanks to the heroes who
developed WebView2 at Microsoft. It's Windows only at the moment but should
be fixed with MAUI.)

(Oh and yes, I do understand how complex naming gets, I watched it all
happening in real time.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Dec 2021 19:39:17 +0100

On Mon, Dec 20, 2021 at 01:28:40PM -0500,
 Phillip Hallam-Baker <[email-masked]> wrote 

> first served basis is not. Hence my callsign proposal:

To be sure I understand: it looks a lot like Namecoin (which is more
than ten years old) except that it uses an append-only log and not a
blockchain? Am I correct?

> The objective here is to give Internet users a name they can use for

What if they lose the private key? And similar questions, as seen in
the years of experience with Namecoin.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2021 14:38:49 -0500

> blockchain? Am I correct?

The fact something has been tried before is not evidence of its worth. MIT
built a social media system for Al Gore's open meeting back in 1994 that
anticipated much of what only became widespread with Web 2.0, Facebook,
Twitter and such.

Namecoin was probably ahead of its time and as you point out, they did not
have a solution for managing the private key.

Ted Nelson's Xanadu preceded the Web by ten years. The main reason the Web
succeeded where Xanadu failed was that the Web jettisoned much of the
ideological baggage Nelson was fixated on. I suspect the number one reason
Namecoin failed was that it had too much blockchain  ideology attached.

Namecoin does provide ample prior art to defend the concepts from trolls
though.

The big technical difference between my work and blockchain stuff is that I
do not use any form of proof of waste, nor do I pretend to be turning lead
into gold or creating 'money'.

> the years of experience with Namecoin.

I have a private key infrastructure, that is why I have spent the past
three years inventing and implementing Threshold Key Infrastructure. Public
Key Infrastructure has failed in practice because it was only focused on
managing public keys. Management of the private key was dumped on the user.

If you are using the Mesh, you are managing private keys without having any
idea you are managing private keys. It is all completely seamless.

PHB

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 20 Dec 2021 20:18:16 +0000

> Which has me looking at .ARPA instead.

.arpa is more interesting than another tld because ...?

A dedicated tld might be a better practical choice, no?  In the scale of 
things, the registration cost isn't that high for having your own 
unambiguous name space with its own policy cone.

Nick

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2021 15:55:15 -0500

> .arpa is more interesting than another tld because ...?

If it is just one proposed personal name space then .mesh is the obvious
choice. If we have dozens it becomes harder, if we have hundreds, well it's
going to be one collision after another.

> unambiguous name space with its own policy cone.

The registration cost will be $0 in either case. I can promise you that.

ICANN was never chartered to collect a tax on innovation or to be a
gatekeeper. Nor are they likely to be granting any sort of registration to
a scheme that is going to compete with them.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2021 17:02:23 -0500

Just to be clear, I was stating that the amount paid to register a TLD or
ARPA domain is going to be $0, I am not going to be paying the $250,000 or
whatever ICANN charges for yacht polishing these days.

I do understand that a registry attempting to run at global scale will have
costs. As some of you might remember, I have been involved in running such
systems.

There is no need for any more of you to send me personal emails pointing
this out.

My model is that for the price of a pint of beer you can buy a pack of 50
coupons so you can always have one to give out if you want to have
end-to-end secure communications with someone.

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Dec 2021 18:15:30 -0500

Hi.

Aside from the more substantive content of the suggestion,
including whether this could actually be done and all costs
covered for one time charges of USD 0.10, I see three major
concerns / questions that you should probably address:

(1) Why .ARPA?  In addition to the concern Nick raised, my
recollection of the agreement between IETF and ICANN is that the
TLD is supposed to be used for _network_ infrastructure, not as
a cheap substitute for a gTLD.  Granted that boundary has been
pushed a bit in the past, but what you are talking about sounds
like personal identifiers and definitely not network
infrastructure.

(2) Assuming the IETF went along with this (and ICANN did not
have a fit about their perception of the agreement), what would
be the acceptance or rejection criterion for whenever the next
such request came along?  In other words, when someone proposed
a different scheme for, say, "hsem.arpa." or "tangle.arpa."
rather than "mesh.arpa.", what criteria would the IETF use to
accept or reject it?   Equally important, when a fight breaks
out as to who is the real Alice, or, as in the mistakes that
were made in the delegation of the NAME TLD illustrate, who gets
to administer the *.alice.mesh.arpa" subtree?  Given that, at
least in the absence of some complex administrative adjudication
procedure (like ICANN's UDRP), debates about "who is the real
Alice" tend to attract lawyers, some of whom find our theories
about DNS delegations and delegated authority inconvenient, how
would you propose to protect the IETF (or the IETF LLC) from
becoming enmeshed in such disputes?   If nothing else, that set
of issues might be a strong argument for "mesh" second level
domains underneath ccTLDs: countries are, if they choose to get
involved, good at determining the legitimate owners of a name
and associated attributes and can immunize themselves from
disputes about those questions in ways in which the IETF or your
hypothetical non-profit probably cannot.

(3) The DNS was not designed for, and has never been good at,
handling very large zones (independent of the level of the tree
at which they occur).  In the last couple of decades, throwing
some database technology and a great deal of computer horsepower
at the DNS has increased the plausible maximum zone size by
several orders of magnitude over what I believe were the
expectations in 1987 or even 1994, but the fundamental problem
remains.  Perhaps I don't understand your explanation and
example, but if the subnodes of mesh.arpa are going to be
callsigns bound to people and this model is successful, then you
are talking about a zone with four or five billion nodes in it
today (and growing).   I can think of some plausible ways around
that, perhaps including your idea about separating the resolver
function from that of a registry, but they fall well short of
"respects the DNS data model" and the computationally intensive
versions would, at scale, causes Alice's coffee to get rather
cold before she could drink it.

best,
   john

--On Monday, December 20, 2021 13:28 -0500 Phillip Hallam-Baker
<[email-masked]> wrote:

> TL;DR; I have two ways of achieving my desired end. One of
> which people are not going to like, the other of which they
> are totally going to hate. I do not actually require IETF
> permission for either, nor am I the only person thinking along
> these lines, I am merely the person whose approach is least
> I have been following various naming proposals in the
> PonziCoin world for some time. There are many companies who
> for a mere $10-200/year will register a shortname for your
> ethereum wallet so people can give you money. And of course,
> the cost of ethereum gas for making the payments only makes
> the cost even stupider. But don't worry, there will be a
> technical fix for that the minute they find themselves a
> virgin and a unicorn.
> 
> OK, so those proposals are obvious nonsense but the notion of
> using a Certificate Transparency type log to issue names for
> life on a first come first served basis is not. Hence my
> callsign proposal:
> 
> [A very similar proposal has been made to ITU by the Chinese
> delegation under their 'New Internet' scheme though I only
> became aware of the details of that after I wrote my own. It
> is my belief that the primary motivation behind the ITU
> proposal is to prevent the abuse of DNS as a control point in
> the Internet infrastructure.]
> 
> Running infrastructure costs real money but I see no reason
> for the cost of running the infrastructure proposed to be more
> than a one-time $0.10 per name. No renewal fees. Names are
> sold freehold, not rented.
> 
> The objective here is to give Internet users a name they can
> use for life. And yes, I realize that it is impossible to
> collect $0.10 fees so I plan to sell names in packs of 50 or
> so. So for the price of a pint of beer you can buy a permanent
> callsign for yourself and pass out the means to grab one to
> your friends.
> 
> There are of course many social issues to be considered, not
> least of which where does the surplus go. My proposal being
> that the whole show to be run by a not-for-profit and the
> surplus go to fund open source development of secure Internet
> software, specifications and standards.
> 
> 
> But that is not the part I want to talk about right now. What
> I do want to talk about is how a new naming scheme interfaces
> to the DNS so that it can be used to connect to legacy
> applications. Legacy in this context meaning 'the stuff that
> is working'.
> 
> So Alice registers the callsign @alice and can use that in
> messaging applications that understand the callsign scheme.
> Which is not hard, just hook up to a callsign resolver and
> send over a query. As with blockchain, the resolver maintains
> a complete copy of the log. Queries go to a resolver, not the
> registry. This means far greater robustness than DNS and
> But what about that doorbell, that WiFi camera, etc. that
> Alice has? To talk to them she needs to use her browser and
> that runs HTTP.
> 
> The obvious solution for this is to put a statement in the
> delegation assertion for @alice to specify an authoritative
> DNS resolver for the DNS addresses *.alice.mesh. The callsign
> resolver then delegates to the authoritatives. The net result
> is that all Alice needs to do to resolve these names is to use
> a DNS resolver that redirects requests in .mesh to one of the
> callsign resolvers.
> 
> The net result is a protocol that respects the DNS data model
> at the lower levels while modernizing the root level.
> 
> 
> OK so nobody expects me to pay to register .mesh. I am not
> even going to lift a finger to make a proposal to ICANN.
> 
> But I am not the only person making a proposal in this area
> and while a single pirate TLD designed by someone who knows
> something of what they are doing is likely to be amusing, a
> hundred or more is likely to be less so.
> 
> https://coffee.alice.mesh/ is not as nice but she will live
> with it. or if open callsigns win the naming game, the anybox
> in her browser will probably let her type coffee@alice and
> route to the place she expects to go.
> 
> 
> Problem here is that RFC 3172 was written in a different era
> when people were still frightened about the loss of control.
> The notion that registries are not control points had not yet
> been understood.
> 
> (Oh and yes, I do have a browser implementation thanks to the
> heroes who developed WebView2 at Microsoft. It's Windows only
> at the moment but should be fixed with MAUI.)
> 
> (Oh and yes, I do understand how complex naming gets, I
> watched it all happening in real time.)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Dec 2021 19:45:40 -0500

> like personal identifiers and definitely not network

Because it is the TLD that has been traditionally used for permanent
delegations.

When I was originally thinking of this scheme, my expectation was that ISOC
would divest itself of the .NET registry and the massive conflict of
interest that creates for IETF.

As far as my approach goes, mesh.arpa is a lot costlier to me (an RFC at
least) than .mesh (free as in beer).

> hypothetical non-profit probably cannot.

There are really two separate sets of issues there.

First there is the 'how does a registry shift the cost of the inevitable
disputes onto the parties with the complaint'. I am very familiar with that
whole process, it was a major concern for us long before VRSN bought
network solutions. I was also heavily involved in the 'how does VRSN
operate a PKI and not get sued into pieces' which Michael Baum spent a lot
of time working on.

The short answer is that obviously @microsoft has to resolve to Microsoft
Inc or really bad things start happening besides the IP issues. And so you
have to have a process, you can't just ignore it (one reason most proposals
are non starters). But once you have a process and you tell the courts that
you will abide by their decision, there are ways to control/contain the
liability.

But it doesn't eliminate the issue and there is the risk of the liability
leaking up the chain as you observe. So that probably seems to rule out
.mesh.arpa.

Fine, I will use .mesh

> cold before she could drink it.

I have always regarded the DNS hierarchy as a blunder. All that dividing
the root zone has meant is that instead of there being one place to reserve
a name, there were first three and then a hundred and now thousands and
they are all primarily rent seekers.

The registry log will grow by less than 1K per entry. So a billion
callsigns is only 1TB. I have built very big iron but this is really not
that demanding. The registry can run on a regular PC, I have run
simulations with millions of add operations an hour using magnetic disks
and would definitely use SSD in production.

Resolvers can run incrementally. They can process the log and map out to a
lookup table mapped out on SSD. Haven't written one yet but it's really not
much of a concern. Updating the mapping table can be parallelized and
resolution can be parallelized if needed.

Unlike in the DNS system, the resolver service is not provided by the
registry. That immediately brings robustness. Taking out VeriSign's ATLAS
brinds down DNS for the whole Internet. If Verizon, Comcast and such all
ran their own resolvers that did not depend on connection to the registry,
the incentive to abuse the DNS root and TLDs would be very much reduced.
Further, the providers can limit external access or shut it down completely
if they come under attack. They have much more ability to control abuse
coming from the inside.

Taking out the registry will be challenging. The attackers would have to
find it first.

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 20 Dec 2021 23:28:57 -0400

Hello,

   After reading the draft and the follow up emails I got interested in 
this idea, I mean, to have a name for life sounds like a cool concept, 
not sure if that's necessary but I guess it's better to have it that not 
have it. I think I would like to see something around this. Regarding 
the .arpa, I do not agree, I believe another tld should be used.

Thanks,

On 20/12/21 2:28 PM, Phillip Hallam-Baker wrote:
> TL;DR; I have two ways of achieving my desired end. One of which 
> people are not going to like, the other of which they are totally 
> going to hate. I do not actually require IETF permission for either, 
> nor am I the only person thinking along these lines, I am merely the 
> person whose approach is least likely to result in collateral damage, 
> consider responses in those terms.
>
> I have been following various naming proposals in the PonziCoin world 
> for some time. There are many companies who for a mere $10-200/year 
> will register a shortname for your ethereum wallet so people can give 
> you money. And of course, the cost of ethereum gas for making the 
> payments only makes the cost even stupider. But don't worry, there 
> will be a technical fix for that the minute they find themselves a 
> virgin and a unicorn.
>
> Certificate Transparency type log to issue names for life on a first 
> come first served basis is not. Hence my callsign proposal:
>
> delegation under their 'New Internet' scheme though I only became 
> aware of the details of that after I wrote my own. It is my belief 
> that the primary motivation behind the ITU proposal is to prevent the 
> abuse of DNS as a control point in the Internet infrastructure.]
>
> Running infrastructure costs real money but I see no reason for the 
> cost of running the infrastructure proposed to be more than a one-time 
> $0.10 per name. No renewal fees. Names are sold freehold, not rented.
>
> The objective here is to give Internet users a name they can use for 
> life. And yes, I realize that it is impossible to collect $0.10 fees 
> so I plan to sell names in packs of 50 or so. So for the price of a 
> pint of beer you can buy a permanent callsign for yourself and pass 
> out the means to grab one to your friends.
>
> There are of course many social issues to be considered, not least of 
> which where does the surplus go. My proposal being that the whole show 
> to be run by a not-for-profit and the surplus go to fund open source 
> development of secure Internet software, specifications and standards.
>
>
> But that is not the part I want to talk about right now. What I do 
> want to talk about is how a new naming scheme interfaces to the DNS so 
> that it can be used to connect to legacy applications. Legacy in this 
> context meaning 'the stuff that is working'.
>
> applications that understand the callsign scheme. Which is not hard, 
> just hook up to a callsign resolver and send over a query. As with 
> blockchain, the resolver maintains a complete copy of the log. Queries 
> go to a resolver, not the registry. This means far greater robustness 
> than DNS and offloads almost all the cost from the registry.
>
>
> But what about that doorbell, that WiFi camera, etc. that Alice has? 
> To talk to them she needs to use her browser and that runs HTTP.
>
> assertion for @alice to specify an authoritative DNS resolver for the 
> DNS addresses *.alice.mesh. The callsign resolver then delegates to 
> the authoritatives. The net result is that all Alice needs to do to 
> resolve these names is to use a DNS resolver that redirects requests 
> in .mesh to one of the callsign resolvers.
>
> The net result is a protocol that respects the DNS data model at the 
> lower levels while modernizing the root level.
>
>
> OK so nobody expects me to pay to register .mesh. I am not even going 
> to lift a finger to make a proposal to ICANN.
>
> But I am not the only person making a proposal in this area and while 
> a single pirate TLD designed by someone who knows something of what 
> they are doing is likely to be amusing, a hundred or more is likely to 
> be less so.
>
> https://coffee.alice.mesh/ is not as nice but she will live with it. 
> or if open callsigns win the naming game, the anybox in her browser 
> will probably let her type coffee@alice and route to the place she 
> expects to go.
>
>
> Problem here is that RFC 3172 was written in a different era when 
> people were still frightened about the loss of control. The notion 
> that registries are not control points had not yet been understood.
>
> (Oh and yes, I do have a browser implementation thanks to the heroes 
> who developed WebView2 at Microsoft. It's Windows only at the moment 
> but should be fixed with MAUI.)
>

---

From: Benson Muite <[email-masked]>
Date: Tue, 21 Dec 2021 11:40:10 +0300

>> abuse of DNS as a control point in the Internet infrastructure.]
Not sure if this is the appropriate document:
https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Documents/Internet_2030%20.pdf

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Dec 2021 09:59:03 +0100 (CET)

> Il 20/12/2021 19:28 Phillip Hallam-Baker <[email-masked]> ha scritto:
> 
While I am interested in potential future alternatives to the DNS, your plan involves selling domain names in your own TLD, even if they are just gateways to paid names in your own alt namespace. If you want to sell domain names in your own TLD, you go to ICANN and apply and pay for it just like everyone else has been doing: I see no reason why the IETF should cooperate so that you can bypass the existing rules, and doing so would enrage basically everyone else in the Internet governance sphere.

Alternatively, you set this up as an alt TLD, and if people see value in it they will install browser plugins or configure their resolvers so that it works for them. I wouldn't see anything bad in this.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]  mailto:[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Dec 2021 18:20:59 -0500

On Tue, Dec 21, 2021 at 3:59 AM Vittorio Bertola <
[email-masked]> wrote:

> While I am interested in potential future alternatives to the DNS, your
> plan involves selling domain names in your own TLD, even if they are just
> gateways to paid names in your own alt namespace.
>

The callsign proposal has the following objectives:

1) To provide permanent names to Internet users (not organizations)

2) To establish user-centric PKI by a binding of names to public keys by
definition

3) To eliminate the elements of the DNS architecture that lead to the
greatest costs.

The fact that the names can map to names in a DNS space is secondary except
to the extent that it fixes some real holes in the DNSSEC trust morel.

I spent decades trying to work out how to validate email addresses like
[email-masked]. There is no way to make it work well unless Alice owns
example.com. Then I started working of the problem of how to transfer
Alice's mesh account service from example.com to example.net.

Every Mesh user has a personal root of trust which is a fingerprint of a
public key they control and is threshold shared across their devices. So
Alice's root of trust fingerprint might
be MCM4-ZJWE-RSWW-D6VX-KZDN-J5PU-5GHA.

All I needed to do to allow Alice to transfer her account from
[email-masked] to [email-masked] was for Alice to sign an assertion
to that effect under MCMA-... and upload it to some MIT Key Server like
infrastructure.

And then as I speced out that system and started ordering hardware, I
realized I can go one better, assigning callsigns on a first come first
served basis adds nothing to the technical cost (huge legal etc. but
technical unchanged). And if it is the act of registering hey key
fingerprint that causes the name binding, the registry entries are
validated by definition. All I need to do is apply Certificate
Transparency/BlockChain ideas to prevent defection by the registry.

The cross notarization structures used by the registry means that if Alice
is looking up the registration for @bob, the ultimate root of trust that
trust chain Alice will rely on will be MCM4-..., i.e. Alice herself. Every
Mesh user is their own ultimate root of trust.

So the DNS names are really a side show here. Except that they share the
same trust structure and they don't expire. Which makes it much easier for
Alice to use IETF protocols to manage her IoT devices because they bind to
names that do not expire.

> If you want to sell domain names in your own TLD, you go to ICANN and
> apply and pay for it just like everyone else has been doing: I see no
> reason why the IETF should cooperate so that you can bypass the existing
> rules, and doing so would enrage basically everyone else in the Internet
> governance sphere.
>

That is not how I would put it. A lot of people were extremely upset when
we built the Web. And before that the telcos were even more upset about the
Internet and packet data. If you aren't upsetting anyone, it's because you
aren't doing anything useful.

It is not the function of IETF to support ICANN or its business model. The
only constituency the IETF should answer to is its users.

> Alternatively, you set this up as an alt TLD, and if people see value in
> it they will install browser plugins or configure their resolvers so that
> it works for them. I wouldn't see anything bad in this.
>

Or they will switch to a browser that comes with the capability bundled.

---

From: Dick Franks <[email-masked]>
Date: Wed, 22 Dec 2021 09:46:15 +0000

On Mon, 20 Dec 2021 at 23:16, John C Klensin <[email-masked]> wrote:
>8
> handling very large zones ...

>  ...  Perhaps I don't understand your explanation and
> today (and growing).

... and integrating w.r.t. time,  this inevitably becomes an
unsustainable proposition.

What is being proposed here is not just a unique identifier for life,
it is also the user's digital tombstone!

The prevailing "rental" model will at least ensure that "jck.com" will
be recycled a decent interval after JCK is himself recycled and unable
to shell out his $15.99

--rwf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2021 11:28:49 -0500

> unsustainable proposition.

There are plenty of names, short names will be in demand and so short names
will have to have an associated premium. For the Latin character set, I
propose increasing the price by an order of magnitude for each character
less than 9. For Han characters, there would need to be a fair equivalent.

There is no shortage of ten to fifteen character names. 5e12 of 9 character
names.

The machine I worked on for my graduate thesis processed 6TB of data a
second and LEP does much more. The data volumes are completely feasible.

> it is also the user's digital tombstone!

Yes. That is the intention.

> be recycled a decent interval after JCK is himself recycled and unable

But for many people, $15.99 is a week's wage. It is an utterly
unconscionable rent to demand. But in my scheme @jck would cost $100,000
(which is why the scheme has to be public goods). But he can be
@John_Klensin for $0.10.

Use of callsigns will be visible to others, unlike the ridiculous NFT
scheme where for $2.3 million you can buy a URL that might or might not
show a crudely drawn picture of an ape which took all of 5 minutes to draw
and says 'I am a borderline psychopath who wants everyone to know I used to
be rich before I bought this hoping to find a greater fool'.

If the money is going to the cause of building secure software to stop the
Internet collapsing and making it available for free, using a short
callsign might well have prestige same as buying a ticket to the Met Gala
does. But the money has to go to something that is widely recognized as a
good cause or the whole scheme is bound to collapse.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Dec 2021 12:31:41 -0500

Hi PHB, I have read through the thread.

I would very much like to have short callsigns that can be used to
unambiguously identify all my (and my friends, and my friends' friends)
devices.

I agree that it needs to be almost free, but not actually free.
Because land grabs, because need to have a small surplus to support the
software ecosystem, and the like.
[I would also find it interesting if we can bring the Chinese-ITU delegation
back into the tent.  I am reading Carl Malamud's 1991 Exploring the Internet]

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'm very much into the idea that:
    _No renewal fees. Names are sold freehold, not rented_

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.

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.

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.

I think that we can do all the append-only, distributed ledger stuff if
desired, but we'd probably do it within a /64.  Threshold cryptography for
the win.
The communities of pseudonymonity could allocate their own /64, and people
would allocate their community specific callsign somehow.

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.

The above requires no IETF action, just making nice with a RIR.
It does require some upfront investment in software and marketing.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Dec 2021 13:25:08 -0500

> Hi PHB, I have read through the thread.

You have also been in discussions on FB etc. Your comments are very
helpful, thanks.

> 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.

>     _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.

> and/or your mathmesh formats.

I prefer JSON for assertions, human readability is a plus. But
serialization formats are easy.

> 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.

Oh nice, now I get it...

Populating the reverse DNS would provide some really interesting properties.

> 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.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Dec 2021 10:24:33 -0500

Phillip Hallam-Baker <[email-masked]> wrote:
    mcr> I don't think that we can really give out 7B short callsigns though.

I want to repeat this: I don't think that there everyone can have a short callsign.
At 5-bits per (english) glyph (because ALICE == Alice == alice), we need 8
glyphs to get 2^40 callsigns.  And that assumes that we hand out meaningless
strings.
While a couple of billion people would prefer non-english callsigns,  I don't
think that helps us much since random sequences of Mandarin or Kanji probably
don't help.
Yeah, a series of pooh emoji will be a sought after callsign, I just don't
think we want to repeat twitter/facebook/etc. handle land grab.

    > @lawnswood_chester, @dalek_hq_boston, @minons_truro, etc. That way I

You just built some hierarchy into your handles.
(Why are minions in Truro? I dunno)

    > happy to serve up the text if it was easy for them to do.

I can't really see a connection here.

    > Oh nice, now I get it...

One would put "fd01:1234::abcd me" into the virtual equivalent of /etc/hosts
Then, when I write "IETF-Friend-PHB" (which is implicitely, "me's
IETF-Friend-PHB"), it would lookup:
   IETF-Friend-PHB.0.0.0.0.0.0.0.0.4.3.2.1.1.0.d.f.ip6.arpa
   (which I hope is reverse of fd01:1234::/64)

and, finding a AAAA record, would then know where your tree is.
There is an issue of public vs private vs limited group results to deal with.
NSEC3

    > authorization to get any response out of it.

+1

We really don't need any IETF Action.

We don't have to run this in ULA-Central.  Any /32 to /56 allocation will
work to start with.  Once successful (ly debugged!) DNAME will let us move
everyone to another prefix if necessary.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 Dec 2021 10:02:17 -1000

On 12/24/2021 5:24 AM, Michael Richardson wrote:

> Phillip Hallam-Baker<[email-masked]>  wrote:

Kim Cameron, Josh Belanoh and I worked on Call Signs at Microsoft many 
years ago, with the idea of using call signs as a place holder for a 
public key. (See: https://uspto.report/patent/grant/7,929,689.) We 
considered the call sign as a short alphanumeric string that could be 
translated to a short binary string, matching the first bits of the hash 
of the public key. We also assumed that another set of bits of the hash 
would be set to zeroes. The size constraints in that design are obvious:

* the sum of length of the call-sign bit string plus number of zeroes 
must be sufficient to prevent forgeries

* the length of the call-sign bit string must be sufficient to prevent 
collisions

The collision risk itself depends on the population size. If call signs 
are used as "pet names", they are only expected to be unique in the 
small scope of "pets". But if thy are expected to be unique worldwide 
and forever, then they have pretty much the same design constraints as 
IPv6 addresses. They can probably be a little shorter because there is 
no expectation of routability, but I would be surprised if this required 
fewer than 80 bits -- I would probably go for 96 bits.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Dec 2021 09:43:07 +1300

On 25-Dec-21 09:02, Christian Huitema wrote:
...
> The collision risk itself depends on the population size. If call signs are used as "pet names", they are only expected to be unique in the small scope of "pets". But if thy are expected to be unique worldwide and forever, then they have pretty much the same design constraints as IPv6 addresses. They can probably be a little shorter because there is no expectation of routability, but I would be surprised if this required fewer than 80 bits -- I would probably go for 96 bits.

Why define a length? Using something like HDLC bit stuffing, they could be any length you like. Or use an indefinite length CBOR string [RFC8949 section 3.2.3].

    Brian

---

From: Michael StJohns <[email-masked]>
Date: Fri, 24 Dec 2021 18:04:16 -0500

On 12/24/2021 3:02 PM, Christian Huitema wrote:
> The collision risk itself depends on the population size. If call 
> signs are used as "pet names", they are only expected to be unique in 
> the small scope of "pets". But if thy are expected to be unique 
> worldwide and forever, then they have pretty much the same design 
> constraints as IPv6 addresses. They can probably be a little shorter 
> because there is no expectation of routability, but I would be 
> surprised if this required fewer than 80 bits -- I would probably go 
> for 96 bits.

If you're looking for statistical uniqueness, this is the birthday 
collision problem.

If you set the desired chance of collision in the random space at less 
than 1 in 100,000,000 ,    8 octets covers about 600K identities, 10 
octets about 155 million and 11 octets about 2.5 billion.    Varying the 
acceptable collision risk up or down assuming everyone is using good 
quality RNGs with negligible bias changes the number of bits you need to 
generate to cover an expected space.

https://en.wikipedia.org/wiki/Birthday_problem

n = sqrt (2*d * ln(1/1-p))  where n is the number of expected picks, d 
is the size the space (e.g. unique identities), and p is the probability 
of a collision.  E.g. p = 10^-8, d = 2^64 gives ~600K for the 8 octets.

(I calculated the above numbers a while back for certificate issuance 
given random serial numbers).

That's a long winded way to say that 10 octets (96 bits) is probably not 
enough for a space of trillions as PHB proposes.

Mike

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 Dec 2021 15:14:26 -1000

On 12/24/2021 1:04 PM, Michael StJohns wrote:
> octets about 155 million and 11 octets about 2.5 billion.    Varying 
> the acceptable collision risk up or down assuming everyone is using 
> good quality RNGs with negligible bias changes the number of bits you 
> need to generate to cover an expected space.
>
> is the size the space (e.g. unique identities), and p is the 
> probability of a collision.  E.g. p = 10^-8, d = 2^64 gives ~600K for 
> the 8 octets.
>
> That's a long winded way to say that 10 octets (96 bits) is probably 
> not enough for a space of trillions as PHB proposes. 

PHB is also proposing to record assignments in a ledger, so it is 
possible to use the ledger to help mitigate collisions. Pick a name, 
check against the ledger, pick a different one if the first name is 
already taken. In that case, the desired scope of uniqueness is "all 
users trying to get a new identity at the same time", which ought to be 
a much smaller number than trillions.

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Dec 2021 20:45:21 -0500

> glyphs to get 2^40 callsigns.  And that assumes that we hand out

OK, got it. We have different understandings of short. People seem to be ok
typing in [email-masked] which is 15 chars. And there are plenty of 15
char names.

Short as in 'really short', sure, those are going to be in demand and that
is where I think we divert some willing cash into funding Internet
infrastructure for all. Names of 9 characters or more at cost, shorter
names at exponentially higher prices according to how short.

Out of respect for Flemming's character and to prevent a hijacking by a
malign cult, I propose reserving @q for the Quartermaster.

While a couple of billion people would prefer non-english callsigns,  I
> don't

The only reason I am not dealing with non-Latin names at this point is they
have to be done right.

> think we want to repeat twitter/facebook/etc. handle land grab.

Or the DNS name squatter phenomenon. I think it has to be understood that
anyone registering a name just to hold it for ransom is not going to profit
from it. On the other hand, challenges could be dealt with in a far fairer
fashion than the ICANN process.

> (Why are minions in Truro? I dunno)

Each user is likely to create their own hierarchy just to keep things
straight. Chester is easy because it's the name the house was given when it
was built. I probably don't want to put my actual home address in the name.
I like daleks and I like minions, so...

>     >> to put 128-bit AAAA in forward places.  We might need some new RR
> types so
>     >> that we

Oh I get it... Very clever.

I wasn't counting on any... My expectation being that if I build something
and it gets used, we will find a venue.

Permissionless innovations...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Dec 2021 20:50:24 -0500

On Fri, Dec 24, 2021 at 3:03 PM Christian Huitema <[email-masked]>
wrote:

> Phillip Hallam-Baker <[email-masked]> <[email-masked]> wrote:
> years ago, with the idea of using call signs as a place holder for a public
> key. (See: https://uspto.report/patent/grant/7,929,689.) We considered
> the call sign as a short alphanumeric string that could be translated to a
> short binary string, matching the first bits of the hash of the public key.
> We also assumed that another set of bits of the hash would be set to
> zeroes. The size constraints in that design are obvious:
>
> * the sum of length of the call-sign bit string plus number of zeroes must
> be sufficient to prevent forgeries
>
> are used as "pet names", they are only expected to be unique in the small
> scope of "pets". But if thy are expected to be unique worldwide and
> forever, then they have pretty much the same design constraints as IPv6
> addresses. They can probably be a little shorter because there is no
> expectation of routability, but I would be surprised if this required fewer
> than 80 bits -- I would probably go for 96 bits
>

The recent loss of Kim is very sad.

We discussed this a while back, I had stumbled on something similar. It's a
neat scheme. But I am kind of down on anything looking like Proof of Work
at the moment.

A registry allows for human readable identifiers.

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Dec 2021 12:19:21 -0500

--On Friday, December 24, 2021 15:14 -1000 Christian Huitema
<[email-masked]> wrote:

> PHB is also proposing to record assignments in a ledger, so it
> is possible to use the ledger to help mitigate collisions.
> Pick a name, check against the ledger, pick a different one if
> the first name is already taken. In that case, the desired
> scope of uniqueness is "all users trying to get a new identity
> at the same time", which ought to be a much smaller number
> than trillions.

But that also assumes that FCFS (with the ledger acting as
arbiter of "first") works.  That is probably true as long as no
one cares strongly what they are called as long as it is unique,
and preferably if the system operates in a world without
lawyers.   As we have seen in the real world, even if PHB's
"charge a lot for short names" solves that problem (at least
until someone comes along and points out that the system should
not be giving extra privileges to rich people with easy access
to hard currencies), it will be only a matter of time before
there is a dispute over who gets to be the real
@AliceMcNastyExample, especially if the identifiers don't expire
with people.

There are clearly ways to mitigate that problem, including the
traditional ones of using relatively deep hierarchy and/or
tagging the main part of names with differentiating attributes,
but I think that either the issue must be taken seriously or
someone will need to convince the large population of people
named Alice (or Bob, or, for that matter, Christian, John, or
Michael) in the world that, e.g., 

AliceqrfQ9h595S5Rg*uv!BsVSP2!QY8sSx^pQ@ar8AjytEdGbK^FG3#nMkVYrA4D4S9B 
is an appropriate and easily remembered name.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 25 Dec 2021 15:00:11 -0500

It appears that Phillip Hallam-Baker <[email-masked]> said:
>> than 80 bits -- I would probably go for 96 bits ...

>A registry allows for human readable identifiers.

Human readable is quite different from human memorable.

This problem sounds a lot like the one of picking a Gmail username,
where you tell it the name you want, and it offers one with a bunch of
digits added to make it unique. Anyone who joined gmail long enough
ago that we got the name without digits can tell you that people
remember the name they asked for, but not the extra part. 

I get an endless stream of mail intended for people with names similar
to mine who imagine that my address is their address. I don't see why
the situation here would be any different.

Venmo has the same problem, which they have tried to fix by letting people upload
a picture, and use the last four digits of the recipient's phone number as a
check code the first time you send someone money.  But those are hacks and are
unlikely to scale to billions of names.

R's,
John

---

From: Randy Presuhn <[email-masked]>
Date: Sat, 25 Dec 2021 12:21:01 -0800

Hi -

On 2021-12-25 12:00 PM, John Levine wrote:
...
> the situation here would be any different.

Indeed, even in the case of someone fortunate to have a relatively
uncommon family name, like me.  It turns out there is even another
Randy Presuhn, roughly the same age as me, my second cousin in Iowa.
For my husband, with the exceedingly common family name of Nguyen,
there appear to be countless collisions just within the context of
our city, much less world-wide.  The considerations keep pushing
in the general direction of X.500, but we know how well that has
worked out so far...

Randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Dec 2021 10:28:36 +1300

I know someone living in NZ who overnight received a "one hour from now" reminder of a COVID test for someone in the UK who occasionally mistypes their own gmail address. (A test booked on Christmas day???)

The consequences of a typing error in a call sign are potentially serious. In this case, we can only hope that the person didn't miss their test.

Regards
    Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Dec 2021 16:44:53 -0500

--On Saturday, December 25, 2021 12:21 -0800 Randy Presuhn
<[email-masked]> wrote:

>> I get an endless stream of mail intended for people with
>> names similar to mine who imagine that my address is their
>> address. I don't see why the situation here would be any
>> different.
> 
> Indeed, even in the case of someone fortunate to have a
> relatively uncommon family name, like me.  It turns out there
> is even another Randy Presuhn, roughly the same age as me, my
> second cousin in Iowa. For my husband, with the exceedingly
> common family name of Nguyen, there appear to be countless
> collisions just within the context of our city, much less
> world-wide.  The considerations keep pushing in the general
> direction of X.500, but we know how well that has worked out
> so far...

I've been trying to resist the temptation to make that analogy
:-(

Maybe worth remembering that, if one goes back several centuries
and in relatively small communities, the reason for inventing
what because surnames, often starting from patronymics,
matronymics, village or country names, occupations, or other
attributes, all appear to have originated from a need to solve
the same problem at a much less challenging scale.

And, since this discussion started with an example starting with
"@Alice", I note that a conversation that includes both John
Levine and myself requires extra qualification and energy (in
spite of my having a family name that is probably less common
than Randy's and the protection of a tradition that forbids
having two living people in the same family branch with the same
first name).

   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Dec 2021 16:51:23 -0500

On Sat, Dec 25, 2021 at 4:29 PM Brian E Carpenter <
[email-masked]> wrote:

> I know someone living in NZ who overnight received a "one hour from now"
> reminder of a COVID test for someone in the UK who occasionally mistypes
> their own gmail address. (A test booked on Christmas day???)
>
> The consequences of a typing error in a call sign are potentially serious.
> In this case, we can only hope that the person didn't miss their test.
>
> Regards
>     Brian
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Dec 2021 17:08:16 -0500

> In this case, we can only hope that the person didn't miss their test.

That is a security issue. And not one I can solve for legacy SMTP email etc.

The starting point for the Mesh was 'what would the Internet look like if
we started over'. Kind of line Internet/2 but without the constraints that
come from academic funding bodies. My stuff does not need to be original
research. I will use 30 year old ideas if they are the right ones.

In this case, access control. The only protocols that use Mesh callsigns
are Mesh messaging protocols. And every message is subject to access
control at the sending service and the receiving service.

Right now, there are only two Mesh messaging applications, contact exchange
and the confirmation protocol which is an improvement over 2FA.

So The way Alice would use the Mesh today is:

Alice creates her Mesh profile
Alice binds her profile to the service example.com as [email-masked]
Alice registers the callsign @alice.

At this point the only use for the callsign would be so that @alice can
exchange contact information via @bob. Alice and Bob probably accept
contact requests from anyone but @madonna probably would not).

So if @carol gets confused and tries to send a message to @alice instead
of @alice42, it is not going to be accepted via the Mesh messaging protocol
because @carol has not been granted message sending privs by @alice.

And the applications know all this and can react intelligently.

Since I have hallam@gmail, I get a lot of mail from confused bunnies. I
know that problem and have thought through a fairly good mitigation. As
with everything else I do, it is not perfect but it is a lot better than
what we have today.

And no, I am not setting out to 'replace SMTP''. I have built a secure
messaging infrastructure because I need it for management of contacts and
devices and for 2FA-plus that can also be applied to any other
communication modality.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Dec 2021 17:26:45 -0500

> having two living people in the same family branch with the same

I don't have all the answers, but I think I can provide an improvement on
the status quo.

One side effect of the use of patronyms was that they reinforce patriarchy
in ways that has significant impact even today.

I have little difficulty making contact with my male professional and
social contacts from 30 years ago but I have lost contact with many of my
female contacts because they have changed their names after getting
married. Sometimes more than once.

If people had a name that they could use for life, that would answer that
problem (or remove that advantage).

If we are using human readable names, there is going to be some idiot who
really wants to be @thanos and a Disney lawyer telling them they can't.

But even if that has to happen, the old binding of @thanos will still the
visible for those who want to contact the original holder. So the
considerations are not the same as for DNS names. There can be multiple
bindings to the same name but only one can be the active binding at a given
time.

There are no perfect solutions but there can be better than what we have
today which is Alice has no power, only the domain name owner has power and
domain names are very expensive to buy and to use. They are not designed
for identifying people, they are designed for identifying organizations who
own and operate computers.

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Dec 2021 17:35:06 -0500

--On Sunday, December 26, 2021 10:28 +1300 Brian E Carpenter
<[email-masked]> wrote:

> I know someone living in NZ who overnight received a "one hour
> from now" reminder of a COVID test for someone in the UK who
> occasionally mistypes their own gmail address. (A test booked
> on Christmas day???)
> 
> The consequences of a typing error in a call sign are
> potentially serious. In this case, we can only hope that the
> person didn't miss their test.

And, since the DNS was mentioned in this regard, that type of
error, especially when only a single mistyped character is
involved, was the key reason Postel pushed back against
single-letter TLDs and one or two character labels at the second
level.  Three characters is not nearly enough to guarantee that
a single-character error will produce an error rather than a
false positive on a different name, but the thinking was at
least there.

But PHB is quite correct here: if the callsign mechanism
requires that someone have prearranged permission to send a
message or retrieve anything, many problems are solved.  The
analogy is poor, but I have a mailbox (which the IETF has never
seen) that, through many generation of technology, has never
received an unsolicited message from a stranger.  Why?  Because
any incoming message is rejected by the delivery MTA if it does
not contain current-generation authentication of the sender --
for the last decade or so that has meant that the message body
is signed and that I already have the relevant public key on
file.  Of course, how those permissions are requested and
granted requires a separate mechanism.

   john

   john

---

From: Larry Masinter <[email-masked]>
Date: Sat, 25 Dec 2021 20:43:15 -0800

> There are clearly ways to mitigate that problem, including the traditional
ones
> of using relatively deep hierarchy and/or tagging the main part of names
with
> differentiating attributes, but I think that either the issue must be
taken
> seriously or someone will need to convince the large population of people
> AliceqrfQ9h595S5Rg*uv!BsVSP2!QY8sSx^pQ@ar8AjytEdGbK^FG3#nMkVYrA

People remember names they use. And usually years and memorable dates.

The URL namespace provides global uniqueness; combine a URL with a year (or
date or date/time) and you have permanent IDs.
There's a simpler way to generate short understandable and permanent names.
You don't have to tag any other parts of names with other differentiating
attributes.

https://www.ietf.org/archive/id/draft-masinter-dated-uri-08.html explains
the idea in more detail.
Yes, the initial "tdb:" might be implied by the context.
You can use as the base URL any scheme registered in IANA.

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Dec 2021 23:56:50 -0500

--On Saturday, December 25, 2021 17:26 -0500 Phillip
Hallam-Baker <[email-masked]> wrote:

>> Maybe worth remembering that, if one goes back several
>> centuries and in relatively small communities, the reason for
>> inventing what because surnames, often starting from
>> patronymics, matronymics, village or country names,
>> occupations, or other attributes, all appear to have
>> originated from a need to solve the same problem at a much
>> less challenging scale.
>> 
>> And, since this discussion started with an example starting
>> with "@Alice", I note that a conversation that includes both
>> John Levine and myself requires extra qualification and
>> energy (in spite of my having a family name that is probably
>> less common than Randy's and the protection of a tradition
>> that forbids having two living people in the same family
>> branch with the same first name).

> I don't have all the answers, but I think I can provide an
> improvement on the status quo.

It seem to me that "better than the status quo" is rather easy,
but whether it is workable and would get traction is another
question.  As you know, the status quo, however lousy, has a
good deal of associated inertia.

> One side effect of the use of patronyms was that they
> reinforce patriarchy in ways that has significant impact even
> today.

Of course, and that is why I say "and matronymics".  I was not
suggesting that system (or any "traditional" one) was desirable,
only that these issues are not new with the Internet.  Nor was I
suggesting that patronyms, if used at all, be used as names as
you seem to have inferred.  As attributes for disambiguation,
they may still be useful because it is rare for either your
birth mother's or your birth father's name to change during your
lifetime (although there are many situations that makes their
use impractical or impossible)  In particular...

> I have little difficulty making contact with my male
> professional and social contacts from 30 years ago but I have
> lost contact with many of my female contacts because they have
> changed their names after getting married. Sometimes more than
> once.

But that, while obviously true, has little to do with the
problem except in societies where women have no choice other
than changing their names on marriage -- a custom that, as you
point out, carries its own problems.  I have encountered many
women who picked a stable name, usually a pre-marriage one, and
retained it at least for professional purposes because searching
for, e.g., articles by that person is problematic if the name
changes.  I assume you have had similar experiences and
connections.  What they do, and the names they go by, in their
personal lives might be different, but I don't think that is any
different from the examples you have given about why one might
need more than one callsign.

> If people had a name that they could use for life, that would
> answer that problem (or remove that advantage).

Again, except for societies that require women to get married
and to change their names when they do so, that is relatively
easy today.  The uniqueness problem is a separate issue: easier
for me than for Randy or John Levine, easier for Randy than for
many others, very hard for the proverbial (and actual examples
of) "Joe Smith".  But in none of those cases is the problem
inability to maintain a name for life; it is ownership and/or
disambiguation vis-a-vis others with reasonable claims to the
same name.

> If we are using human readable names, there is going to be
> some idiot who really wants to be @thanos and a Disney lawyer
> telling them they can't.

Indeed.  But, as Randy indirectly pointed out, if the names are
not human readable (and probably human memorable) I think the
system will inevitably need a dictionary or directory that maps
their usual names to the unique machine readable ones, even if
it uses some serial refinement model for disambiguation.  Our
history with implementing and deploying such directories at
Internet scale has been fairly poor.

> But even if that has to happen, the old binding of @thanos
> will still the visible for those who want to contact the
> original holder.

True unless said Disney lawyer can convince you or appropriate
authorities that the initial use of the name was invalid and
violated their rights to a sufficient degree that the name
and/or binding should be removed from the database... and can
figure out a way to enforce that conclusion.

> So the considerations are not the same as for
> DNS names. There can be multiple bindings to the same name but
> only one can be the active binding at a given time.
 
Understood.  That is an important consideration but I don't
think it is the one John L., Randy, Christian, and I are poking
at from somewhat different directions.  Put differently, if I
correctly understand what you are trying to do (and I may still
not), much of what we have been talking about may be external to
the problem you are trying to solve and your proposals for
solving it.  That doesn't make the concerns irrelevant because
they may be key to whether you can get practical acceptance and
uptake outside a very narrow community, but that, again, does
not mean your ideas themselves are unworkable.
 
> There are no perfect solutions but there can be better than
> what we have today which is Alice has no power, only the
> domain name owner has power and domain names are very
> expensive to buy and to use. They are not designed for
> identifying people, they are designed for identifying
> organizations who own and operate computers.

Here I think you are confusing several different issues.  Looked
at from my perspective in the 1980s, you are not talking about
intrinsic properties of the DNS. That was a long time ago but
the assumptions then included both the idea that charges for
names higher than cost recovery were unnecessary and probably
undesirable and that the DNS would be used with deep hierarchy
with zones near the root operated in the public interest.  The
question of what the tipping point was that made were we are
today inevitable is interesting but probably not useful.  But
neither the power relationships nor the costs are necessary
properties of the DNS.  In that context, the problem with
identifying people is a design issue only because one would need
to use sufficiently deep hierarchy --think, or example, about
birth country, subdivisions as appropriate (perhaps down to
geolocation), family name at birth, and then personal name at
birth and a birth datetime somewhere -- to require that
directory function.  But is isn't a technical or, in principle,
administrative problem with the DNS.  Any country that felt like
setting up such a system for its residents in their ccTLD and
that did not consider the first priority of the DNS to be a
revenue source could deploy such a system this month.  Now,
personally, I don't like strict hierarchies for systems like
that and think it would be easy to do better.  I feel even more
strongly about plans that use the DNS because it is handy even
though it is not a particularly good match for the problem being
addressed.    But, again, there is no inherent problem with the
DNS that justifies what you are suggesting even though there may
be multiple practical problems in the current DNS operational
and management environment.

 best,
   john

---

From: tom petch <[email-masked]>
Date: Sun, 26 Dec 2021 10:51:11 +0000

> their own gmail address. (A test booked on Christmas day???)

Of course.  The UK cannot spell omicron but can panic over it. 
Vaccination stations and testing stations were widely open on December 
25th.  Whether they will attract millions of customers or only hundreds 
thousands I do not know - one day last week saw 968,000 vaccinations - 
but with Scotland, Wales and Northern Ireland now in lockdown, the UK PM 
is desperate not to have to impose such on England; the history of 12 
months ago is a case study in how not to run a country:-(

Tom Petch

>
> The consequences of a typing error in a call sign are potentially
> serious. In this case, we can only hope that the person didn't miss
> their test.
>
> Regards
>     Brian
>
> .

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Dec 2021 19:12:09 -0500

On Sat, Dec 25, 2021 at 11:57 PM John C Klensin <[email-masked]> wrote:

> ... But, again, there is no inherent problem with the

My design method has three steps.

1) Identify the problem to be addressed
2) Address that problem ignoring all legacy infrastructure
3) Decide if deployment is best served by adapting existing infrastructure
or building new

Code re-use is massively overrated. If there is a chance to erase 40 year
old mistakes with new infrastructure I will always take it. Absolutely the
only reason to build on antiques is that they make deployment easier
because they are already deployed.

The telephone infrastructure is dying. Junk calls that wake people up in
the night are much more serious than email spam. Email is dying. And right
now, the only alternatives on the table are proprietary schemes created by
over-promoted middle managers who imagine the powers that run this world
are going to allow a proprietary private interest to establish a monopoly
on communications.
DNS is not a viable discovery service to replace telephone numbers. So
someone must build something that is. Only an open service can be viable in
the long run.

DNS wouldn't have survived this long if the flaws had been easy to spot.
The ones I see are

1) Faux hierarchy
2) Registries provide the query service
3) Security is an afterthought
*Faux hierarchy*

As far as the hierarchy thing goes, I see only negative value in the
partition of the root. com/net/org was a mistake CC domains a blunder and
new TLDs a rent seeking racket.

The only purpose of the new TLDs is to extract rents from owners of major
brands. From a technical point of view, the DNS would work just fine if
every TLD apart from .com was dropped out of the root. VRSN has more than
enough capacity. (And no, I do not hold any VRSN stock, I liquidated all my
holdings last year(

There are only O(10^10) people in the world. The Latin alphabet has 26
characters (and there are roughly a dozen widely used alphabets). There is
really no need for registered names to be more than a dozen letters long to
be unique even with O(10^12) names.

All hierarchy does is introduce gatekeepers and require people to register
in each branch of the tree.

*Registries provide the query service*

DNS registries are not public so the only party that is able to offer query
service is the registry itself. This makes the registry a big fat target
for anyone wanting to 'bring down the net'. And the vast majority of the
cost of running a DNS registry comes from dealing with DDoS.

The registry cannot restrict the community it serves to mitigate DDoS
attack. Moving query service to the Mesh Service providers offloads all the
maintenance costs off the registry making nakes-for-life possible. It also
allows the service provider to deal with abusive customers by
ignoring/rate-limiting their queries.

The key to stopping Internet crime is to increase the cost to the attacker
and/or reduce the payoff. Moving the registry service does both.

*Security is an afterthought*

The primary function of the callsign service is that it is a PKI. The fact
that every name is bound to the controlling root of trust *by definition*
is what allows it to operate without trusted third parties.

I spent 25 years trying to make the CA based model work for people. It
doesn't work for a very simple reason: Corporations exist by government
fiat, humans are not. There might be a way to make the CA model work but I
am not the only person tried and nobody else made it work either. I am not
aware of anyone else even trying.

Binding names a-priori just works. But only if you begin allocating names
a-priori from the very start. It is not possible to retrofit this approach
to either telephone numbers or DNS.

The Mesh code is now running outside the development environment and the
documentation is nearly ready. The only things missing at this point for
the phase 0 release is to make the demonstration reel. This only uses DNS
discovery, the callsign system won't be deployed for a while yet.

hallambaker/Mathematical-Mesh: The Mesh is an infrastructure that makes the
Internet easier to use by making it more secure. (github.com)
<https://github.com/hallambaker/Mathematical-Mesh>

I do have running code to secure data at rest. I am not aware of anyone
else even attempting to address that problem.

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Dec 2021 16:51:41 -0500

On 12/25/21 12:19 PM, John C Klensin wrote:

> it will be only a matter of time before

The only way to keep people from fighting over names is to make them 
utterly meaningless.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Tue, 28 Dec 2021 22:54:58 +0100

On 2021-12-28 22:51, Keith Moore wrote:
> The only way to keep people from fighting over names is to make them utterly meaningless.
> 
> Keith
> 
> 

Also the way to make them irrelevant. The world is filled with HAM-radio operators after all...

	Cheers Leif

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Dec 2021 13:44:41 -0500

> Also the way to make them irrelevant. The world is filled with HAM-radio operators after all...

Not sure what  you mean about HAM radio operators.   But I do have the 
sense that people keep trying to make something that is fundamentally 
unworkable - globally unique names that scale to the world's population 
that people actually want to use.

Keith

---

From: Andy Ringsmuth <[email-masked]>
Date: Wed, 29 Dec 2021 13:05:53 -0600

> On Dec 29, 2021, at 12:44 PM, Keith Moore <[email-masked]> wrote:
> 
> Not sure what  you mean about HAM radio operators.   But I do have the sense that people keep trying to make something that is fundamentally unworkable - globally unique names that scale to the world's population that people actually want to use.
> 
> Keith

Absolutely agree.

Have we all forgotten that many of us, particularly those with a brain, DON’T want to be tracked/found/stalked/followed/badgered by ads/etc.?

I don’t want a for-life online contact method. Hell freaking no.

----
Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2021 15:24:24 -0500

>that people actually want to use.

Well, we do have phone numbers which are unique, largely meaningless,
and we all at least used to be able to remember a fair number of them.

I'm not sure they're all that useful as a model, though.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Dec 2021 20:37:53 +0000

*   But I do have the sense that people keep trying to make something that is fundamentally unworkable - globally unique names that scale to the world's population that people actually want to use.

Yeah, like X.500 without any hierarchy or organization. :)

On the other hand, I’m not gonna sign up for it, and I don’t see any reason not to let others try this thing.

---

From: Tim Bray <[email-masked]>
Date: Wed, 29 Dec 2021 12:45:23 -0800

I dunno, I'm in the Twitter @bluesky conversation, and the more I see the
alternative proposals for scalable global-human-population identity
schemes, the more I think telephone numbers aren't a terrible model.
Adequately memorable, easy to scribble on a cocktail napkin, satisfactory
as a unique key in your own personal contacts application whatever it may
be, and sufficiently boring as to not provoke a land-grab rush.  Yes, some
numbers are cooler than others, but it's less intense an issue than having
to be timb4857292@ rather than timbray@ because you arrived later on the
scene.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 29 Dec 2021 22:41:49 +0100

On 2021-12-29 19:44, Keith Moore wrote:
> Not sure what  you mean about HAM radio operators.   But I do have the sense that people keep trying to make something that is fundamentally unworkable - globally unique names that scale to the
> world's population that people actually want to use.
> 
> Keith
> 
> 

I mean that names that don't mean anything will be meaningless and therefore largely useless.

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Dec 2021 21:29:56 -0500

> to be timb4857292@ rather than timbray@ because you arrived later on the

If we were to redo telephone numbers, we would not do exchanges or area
codes. They are no longer necessary and to the extent they still have
meaning, it is privacy violating meaning.

We would probably use Base32 instead of just numbers. That gets us to some
fairly impressive compact identifiers. 5 bits per character, an 8 character
sequence is sufficient for a trillion identifiers.

Sure, from a technical point of view, @KXJL-M4AA is acceptable as an
identifier. It is more usable than
@MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y which gives us 112 bits of work factor.

I still think that for Alice, @alice is going to be the
ideal, @the_famous_alice a close approximation and so on. Sure that leads
to more hassle for the registry than random assignment but the cost is much
less memorable callsigns.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 30 Dec 2021 10:50:11 +0100 (CET)

> Il 30/12/2021 03:29 Phillip Hallam-Baker <[email-masked]> ha scritto:
> 
> If we were to redo telephone numbers, we would not do exchanges or area codes. They are no longer necessary and to the extent they still have meaning, it is privacy violating meaning.
> 
There would be reasons to keep country codes, though. Both organizational (they naturally federate the namespace and define jurisdictional spaces) and functional (at least you know the part of the world where the person is from, and the languages that are likely to work when communicating).

For the same reasons, some big / federal / multinational countries might want to keep area codes as well. Indeed, even in a mid-sized monolingual country like Italy it is very useful to know at a glance whether a fixed number is from Sicily or from Venice. You could make this optional and subject to user consent, but in many cases it would make sense to get a geolocated number.

> We would probably use Base32 instead of just numbers. That gets us to some fairly impressive compact identifiers. 5 bits per character, an 8 character sequence is sufficient for a trillion identifiers. 
> 
> Sure, from a technical point of view, @KXJL-M4AA is acceptable as an identifier. It is more usable than 
I didn't look up the science that possibly exists on this, but I suspect that strings made only of numbers or only of letters, even if slightly longer, are easier to remember than mixed strings, especially if there is not a rigid pattern on where the letters and the numbers are. Number-only strings also have the advantage that they are universal, while half of the planet is not native in the Latin script.

It's also true that memorability just for the sake of it - not associated to any vanity value in the string - might be a secondary requirement, now that we have contact books etc. However, it's still useful when you need to add a contact in a non-digital way, i.e. with someone spelling their identifier or writing it down for you.

--

---

From: "Gorman, Pierce" <[email-masked]>
Date: Thu, 30 Dec 2021 14:59:09 +0000

Richard Shockey once observed that telephone numbers as a namespace are a form of global language.  The entire planet knows how to use them and they do not rely on international character sets.  Whether telephone numbers, or any sequence(s) of integers, I always thought his observation was profound.

Pierce Gorman
Principal Engineer Sys Arch

Direct 913.439.4368 |  [email-masked]<mailto:[email-masked]>
t-mobile.com<http://www.t-mobile.com/>  | Follow T-Mobile on Twitter<https://twitter.com/tmobile>, Facebook<https://www.facebook.com/TMobile> and Instagram<http://instagram.com/tmobile>
[A close up of a logo  Description automatically generated]

From: ietf <[email-masked]> On Behalf Of Vittorio Bertola
Sent: Thursday, December 30, 2021 3:50 AM
To: Phillip Hallam-Baker <[email-masked]>
Cc: IETF-Discussion Discussion <[email-masked]>
Subject: Re: Proposal, open up .arpa

[External]

Il 30/12/2021 03:29 Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> ha scritto:

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]<mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: tom petch <[email-masked]>
Date: Thu, 30 Dec 2021 17:08:43 +0000

On 30/12/2021 14:59, Gorman, Pierce wrote:
> Richard Shockey once observed that telephone numbers as a namespace
are a form of global language.  The entire planet knows how to
use them and they do not rely on international character sets.

<tp>
Well sort of.  Working for an international company I got in the habit 
of writing
+(44)
in front of the rest of the number which is the recommende format, by 
the ITU-T I recall.

When numbers became eleven digits, my local phone company recommended 
breaking them up 5 6 or 4 3 4 but did not specify a separator.  Some use 
space, others other characters such as hyphen-minus (do the French use 
comma?) and hyphen-minus has more than one encoding in Unicode (as I 
discover when I read the minutes of IETF meetings).  I note that your 
footing uses period which I think can also be encoded in more than one way.

Most web pages I have used do not understand space or plus or brackets 
or anything but sero to nine.

Tom Petch

Whether telephone numbers, or any sequence(s) of integers, I always thought
his observation was profound.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Dec 2021 17:36:10 +0000

*   Richard Shockey once observed that telephone numbers as a namespace are a form of global language.

Please make sure that any system works so that an abused person can become unavailable (contact, tracking, etc) to their abuser(s), For example, allowing people to have more than one “name,” and not requiring proof of possession of the old one when getting the new one.

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 30 Dec 2021 11:07:20 -0800

Hi -

On 2021-12-30 1:50 AM, Vittorio Bertola wrote:
>> If we were to redo telephone numbers, we would not do exchanges or 
>> area codes. They are no longer necessary and to the extent they still 
>> have meaning, it is privacy violating meaning.
> There would be reasons to keep country codes, though. Both 
> organizational (they naturally federate the namespace and define 
> jurisdictional spaces) and functional (at least you know the part of the 
> world where the person is from,

Not really, depending on what you mean by "from," and whether you
expect the numbers to be stable over a person's lifetime.
For example, here in San Jose, California, approximately 38% of
the population is foreign-born.

> and the languages that are likely to 
> work when communicating).

Hardly.  There's good reason signs on buses here in San Jose are in
Vietnamese and Spanish as well as English, while in other cities other
languages will be used, e.g. in Minneapolis one might see English,
Spanish, Somali, and Hmong.

If one really cares about getting the right language(s), then
BCP 47 is a good start.

> For the same reasons, some big / federal / multinational countries might 
> want to keep area codes as well. Indeed, even in a mid-sized monolingual 
> country like Italy it is very useful to know at a glance whether a fixed 
> number is from Sicily or from Venice. You could make this optional and 
> subject to user consent, but in many cases it would make sense to get a 
> geolocated number.

Again, if these numbers are stable, they really won't tell where the
user is.  For example, here in San Jose, California, approximately 38%
of the population is foreign-born.  Even within the country, does it
help for me to be attributed a location roughly three thousand
kilometers from where I have lived for decades?

Overloading an identifier with mutable attributes (languages understood,
nationality, location, legal jurisdiction) seems fundamentally
unworkable to me.

Randy

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 Dec 2021 10:09:54 -0500

--On Thursday, December 30, 2021 10:50 +0100 Vittorio Bertola
<vittorio.bertola=[email-masked]> wrote:

>> If we were to redo telephone numbers, we would not do
>> exchanges or area codes. They are no longer necessary and to
>> the extent they still have meaning, it is privacy violating
>> meaning.
>> 
> organizational (they naturally federate the namespace and
> define jurisdictional spaces) and functional (at least you
> know the part of the world where the person is from, and the
> languages that are likely to work when communicating).
> 
> For the same reasons, some big / federal / multinational
> countries might want to keep area codes as well. Indeed, even
> in a mid-sized monolingual country like Italy it is very
> useful to know at a glance whether a fixed number is from
> Sicily or from Venice. You could make this optional and
> subject to user consent, but in many cases it would make sense
> to get a geolocated number.

I would only observe the similarities between the hierarchy
implied by telephone numbers (especially before number
portability in many countries, which has improved them as
identifiers and created other problem), and the X.500 identifier
and certificate plan.  I think the bottom line is that one
either hands these problems over to governments and their
designees (another hierarchy but potentially a rather flat one)
or treats them as private (whether intended to e for-profit or
not) activities/enterprises.  Either lends itself to abuse.
Perhaps one of the better ways to evaluate any such system is to
consider how it could be abused or attacked and then pick the
sort of actual or potential abuses one prefers.

   john

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Dec 2021 11:27:35 -0500

> <tp>
    > Well sort of.  Working for an international company I got in the habit of
    > writing
    > +(44)
    > in front of the rest of the number which is the recommende format, by the
    > ITU-T I recall.

Yup, and which 90% of Canadian and US built web sites refuse :-( :-(

Not just that you have a non +1 country code, but that even that you write
the +1.   (Were I in the need to hire some US based accountants or lawyers,
if they didn't put +1 on their business card, then I'd pass them by...)

So, I'm afraid that this global language is alas, actually not really global.
And the numbers are not always absolute: I have 311, 511, 611, 711 and 911
in my area.... which are essentially pet names.

And it's 999 or 119 in places, except, I'm told, for small parts of London,
where it's 0118 999 881 99 9119 7253.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Dec 2021 11:33:41 -0500

> Please make sure that any system works so that an abused person can
    > become unavailable (contact, tracking, etc) to their abuser(s), For
    > example, allowing people to have more than one “name,” and not
    > requiring proof of possession of the old one when getting the new one.

It's a really difficult requirement I think.  Mostly because it's very hard,
I think to clearly state the requirement.  There are a whole long list of "buts"

But, I really agree with your thoughts; but I think that what we really want is a
way to refuse connections from authenticated entities, and therefore, to
refuse connections from designated entities.

I think that our current (societal and individual) approaches to (cyber and
physical) stalking have been entirely inadequate.   What are better
approaches is unclear to me.  It's an HRPC issue that we need to think about
within many of our protocols.

If you haven't gone through the https://www.ihollaback.org/ training, I would
urge you do.  And consider how we can apply some of these things online.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 31 Dec 2021 16:46:56 +0000

I know a few people who would be willing to provide information about this should there be interest.

---

From: tom petch <[email-masked]>
Date: Fri, 31 Dec 2021 17:30:35 +0000

> where it's 0118 999 881 99 9119 7253.

I am familiar with 0118 but not the rest while 999 is the UK emergency 
number for emergency services and 119 has leapt to prominence in the 
past year as the place to go for anything Covid-19 related except 
lateral flow tests which are out-of-stock after the Government told 
everyone to take a test before heading out for New Year's Eve 
celebrations.  Gosh, is that the date?  Quick, I must test and be off out.

Tom Petch

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 Dec 2021 16:55:19 -0500

On Thu, Dec 30, 2021 at 4:50 AM Vittorio Bertola <
[email-masked]> wrote:

> There would be reasons to keep country codes, though. Both organizational
> (they naturally federate the namespace and define jurisdictional spaces)
> and functional (at least you know the part of the world where the person is
> from, and the languages that are likely to work when communicating).
>

There are effects, effects are not reasons unless measured by objectives.

If someone wants to reveal their nationality, fine. The technology should
not force anyone to. What part of privacy preserving end-to-end secure
communications are you not getting.

> subject to user consent, but in many cases it would make sense to get a

Neither countries nor machines have desires, only people do. If people want
to reveal information, they will. If not, not.

I have no interest in the type of federation you describe because my goal
is to return control to the individual. If the politicians have a problem
with that, they can give me my citizenship back first and then we can talk.

Unlike the anarchists/libertarians and their crypto-currency schemes, I do
believe in government. But I also observe that there are a heck of a lot of
really terrible ones out there and I am not in the least inclined to give
them more power.

---

From: Dick Franks <[email-masked]>
Date: Fri, 31 Dec 2021 22:05:08 +0000

> celebrations.  Gosh, is that the date?  Quick, I must test and be off out.

London area numbers are 020...
0118... numbers are in or around Reading, 42 miles from central London.
The prefix can be dropped when calling numbers with the same prefix.
When I lived in Ealing the (local) numbers began 998 which is clearly
had scope for an accidental emergency call.

HNY

--rwf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 Dec 2021 17:09:37 -0500

On Thu, Dec 30, 2021 at 12:36 PM Salz, Rich <[email-masked]> wrote:

>
>    - Richard Shockey once observed that telephone numbers as a namespace
>    are a form of global language.
>
> Please make sure that any system works so that an abused person can become
> unavailable (contact, tracking, etc) to their abuser(s), For example,
> allowing people to have more than one “name,” and not requiring proof of
> possession of the old one when getting the new one
>

It is not in the callsign system itself, but once there is a directory that
maps @alice onto a public key fingerprint plus a service from which a
contact assertion signed under that key can be obtained, we can
bootstrap to new messaging protocols that give us any desired communication
properties very easily.

The reason SMTP email is so sticky is that all Bob has is the address
[email-masked]. So Alice is limited to the set of protocols supported by
example.com in the case of Alice and the least common denominator in the
general case which is SMTP. There is no way to negotiate a service upgrade
to OpenPGP over SMTP.

In my scheme, Alice can decide she is only going to accept calls from @bob
and @carol. She can put @stalker on a blocklist that prevents him from
retrieving her contact assertion, posting messages, placing calls, etc. etc.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 31 Dec 2021 12:59:04 -1000

> sort of actual or potential abuses one prefers.

The telephone number hierarchy predates X.500 by a couple decades. 
Remember when the ITU ruled networking? The default situation was to 
have exactly one telecommunication provider per country, very often 
ruled by the government of that country. International calls were routed 
to the closest international telephone exchange, and from there to 
whatever provider was servicing the country code, until it reached the 
entry switch for the designated country. And then, the next digits were 
used to find the first level telephone exchange, etc., all the way to 
the subscriber. The telephone network had more-or-less a hierarchical 
topology, and the telephone numbers represented that hierarchy. The 
fancy improvements like 800 numbers or number portability came later.

X.500, and also X.400, date from a time when the ITU still believed they 
ruled networking, when the Internet was barely starting to develop. The 
names were hierarchical, rooted in a country code. There was a 
concession to the deregulation happening in some country, so X.400 
addresses included an "operator identifier" in the hierarchy, just below 
the country code. But these were name, not numbers, and they described 
the properties of the named object, not to the topology of the network.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 Dec 2021 18:04:26 -0500

--On Friday, December 31, 2021 17:09 -0500 Phillip Hallam-Baker
<[email-masked]> wrote:

>...
> It is not in the callsign system itself, but once there is a
> directory that maps @alice onto a public key fingerprint plus
> a service from which a contact assertion signed under that key
> can be obtained, we can bootstrap to new messaging protocols
> that give us any desired communication properties very easily.
> 
> The reason SMTP email is so sticky is that all Bob has is the
> address [email-masked]. So Alice is limited to the set of
> protocols supported by example.com in the case of Alice and
> the least common denominator in the general case which is
> SMTP. There is no way to negotiate a service upgrade to
> OpenPGP over SMTP.

Sorry but, having spent much of the last several days working on
rfc5321bis, I don't understand that at all.  

First of all, at least in principle, absolutely nothing prevents
Alice from creating [email-masked] (or, preferably,
something much more obscure) and then discarding or rejecting
anything that does not come from Bob, using whatever
authentication mechanism the two of them can work out.  If there
were one reasonable, network-wide authentication mechanism
(which might or might not involve a key server), they would not
need to negotiate.

Second, I'm not sure what you mean by "OpenPGP over SMTP" but
cannot think of anything that would prevent defining an SMTP
extension that asserted that no message was welcome unless the
content was in OpenPGP (signed, encrypted, or both).
Alternately, it would be fairly easy to write an extension,
probably cloning and modifying STARTTLS, that would use OpenPGP
to hide most of the envelope or, indeed, use OpenPGP as an
alternative to all elements of TLS except the tunnel itself.
Some versions of the latter would have the same problem that
using TLS with SMTP does, naming having to have keys scattered
around and get the envelope (and maybe the message) at least
partially into cleartext at each relay.  But, unless one says
"no relays", one has to be satisfied with either encrypting
content (maybe including message headers) but not envelopes or
having things in clear on the relay almost no matter what one
does.   

> In my scheme, Alice can decide she is only going to accept
> calls from @bob and @carol. She can put @stalker on a
> blocklist that prevents him from retrieving her contact
> assertion, posting messages, placing calls, etc. etc.

For accepting calls and running blocklists all of that can be
done with SMTP.  Whether it can be done with SMTP as provided by
a particular mail service provider is another question, but that
just implies either finding a different provider or supplying
the current provider enough incentive to offer it.  As to
blocking access to contact information and the like, as far as
Internet mail is concerned in the absence of a directory
service, that is more or less the default... and advertising
mail address to a list like list one (on putting it in an RFC)
are matters of choice with other choices available if one can
maintain multiple addresses for different purposes (and that
seems no different from having different callsigns).

john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 Dec 2021 19:03:21 -0500

On Fri, Dec 31, 2021 at 6:04 PM John C Klensin <[email-masked]> wrote:

> authentication mechanism the two of them can work out.

My goal is to allow Madonna to use @madonna as her callsign for
personal and business use. Only the callers she authorizes get access to
her personal inbox, everyone else gets her PA or her fan club secretary.

A naming system where Alice has to create a new name for every set of
people she wants to communicate with isn't really a naming scheme. And you
still don't do anything to address the issue of SMTP spam. Oh and please
don't suggest that because an anti-spam solution has a very small chance of
allowing a few pieces of unwanted messages through that it is no
improvement on SMTP.

> If there

The whole point of tying the naming system to the key service is to effect
that scheme.

> content was in OpenPGP (signed, encrypted, or both).

The fact that the user's application never talks to the recipient's inbound
mail server in the SMTP model as deployed makes that unworkable. And you
can't change that either because there are multiple layers of services
between that inbound email server and the user's inbox.

> having things in clear on the relay almost no matter what one

By the time you have made those changes, you have a sufficiently different
protocol to need a signaling mechanism to advise the existence of an
upgrade option. That is how I got to building the Mesh in the first place.

The Mesh does make using S/MIME and OpenPGP email pretty easy. But the
messaging infrastructure it uses to make SMTP palatable can be applied to
build a mail system vastly superior to and more capable than SMTP.

My system is designed from the ground up as the basis for a workflow
system. Alice sends a task to Bob or Carol, Bob accepts it first, completes
it creating a task for Doug. Meanwhile Alice can view the whole process
flow in real time and see what is happening. Sure, I could try to make that
work with SMTP, OpenPGP and a cargo container full of duct tape. But it
would suck because messages would be dropped all the time by all the other
ad hoc in the system.

> the current provider enough incentive to offer it.

It has proved impossible to go from a default permit security posture to
default deny. The only way to really deal with spam is to have a situation
where every email is authenticated by its originator and the originating
service.

The core of the proposal here is an infrastructure that maintains a mapping
from a persistent identifier to contact assertions that can be
authenticated to a public key signature.

That enables each user to maintain a contact book that is always up to date
and tells each user what the best way to communicate with each contact.

If Alice and Bob both think Signal is the best way to communicate for
messaging, that is how their apps will establish a messaging communication
between them. If they think it is Splunge, they will use that.

Of course, applications that allow those communications to be established
under keys trusted explicitly and directly are going to be preferable to me
than those which require me to trust some key server that is functionally a
CA but they won't admit functions as a CA and lacks all the controls a
proper CA might have.

@alice is merely a layer of syntactic sugar for Alice's public key that is
her personal root of trust.