Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Jul 2007 22:14:52 -0700

Short answer: Yes, Dean, I basically like what you are proposing.

Long answer:

I got pretty lost on the thread that came out of this but it occurred  
to me that looking at this as domains and overlays might be trying to  
wag the dog from the wrong end. Consider the other end of the dog,  
namespaces and enrollment servers.

I think we can all agree that if Cullen is known on some overlay as  
[email-masked], then we really don't want Dean to also be known  
on some other overlay as [email-masked]. We need the names to be  
useful and refer to a unique human user. So who decided who gets the  
name [email-masked], Dean or Cullen? The enrollment server that  
is responsible for example.org gets to decide. I think this more or  
less means that an enrollment server may be able to have more than  
one domain mapped to it but a domain maps to at most one enrollment  
server. Now all the peers on the overlay need to be able to have a  
common trust root of some form on who the peers believe is allowed to  
allocate the names in this particular overlay. Once again, that is  
the enrollment server. So an given overlay can only have one logical  
enrollment server. (Someone will say there could be multiple trust  
roots here but given the peers in the overlay have to know about  
*everyone* of the trust roots, I would just argue this had virtually  
formed all the trust roots into a single logical enrollment server).  
Similarly, if someone is trying to reach [email-masked], unless  
fluffy is in all the overlays that the example.org enrollment server  
is responsible for, then we need to know which overlay to look in and  
it seems the only way to know this is to have at most one overlay for  
each domain. So if you follow this somewhat confused logic, I come  
out thinking that the easiest solution looks like the following:

A set of one more domain name (typically one) maps to a exactly one  
logical enrollment server. The single logical enrollment server maps  
to exactly one overlay. The enrollment server creates unique names  
inside the namespace that is delegated to it by the domain names that  
map to it.

So to answer Deans question below - model one works for me. Model two  
only works for me if every peer in the overlay knows about the  
credentials of every enrollment server for every domain that can  
allocate names in the overlay *before* any peer ever enrolls in the  
overlay. This seems pretty impractical for anything but a very small  
set of enrollment servers.

Cullen <with my individual hat on>

On Jun 13, 2007, at 4:00 PM, Dean Willis wrote:

>
> Someone brought this up on the list, and I wanted to clarify the  
> consensus here before nailing it down further in the concepts doc.
>
> We think of usernames as domain-scoped, like "[email-masked]".
>
> One model of an overlay allows users to enroll names from many  
> domains. In this model, there might be only one overlay serving  
> every domain in the world, including (for example) "example.com"  
> and "example.net". Clearly routing messages within this overlay is  
> straightforward, and there's no need to talk to any other overlay.
>
> In another model, each overlay corresponds to one or more but not  
> all domains, and we use RFC 3263 procedures to route between  
> overlays. So "example.com" might be in one overlay, and  
> "example.net" in another. Each overlay can look up the other in DNS  
> to find it.
>
> This second model mostly precludes having one domain scattered  
> across multiple overlays.
>
> Here's the deal: Assume we have overlays A and B. [email-masked]  
> enrolls with overlay A, and [email-masked] enrolls with overlay B.
>
> Alice now wants to call Bob. She looks him up in her overlay, and  
> he's not there. What to do? She can't just look up example.com in  
> DNS, because it has been split across A and B and DNS just doesn't  
> work that way. Now, if both A and B registered with some "upstream"  
> lookup function (a meta-overlay), then Alice could perhaps look  
> there. But this starts to get messy really quickly.
>
> So unless we want to solve the namespace-split-across-overlays  
> problem (and that's not easy), we're much better off at this time  
> having a model where each domain can be mapped onto only one  
> overlay at a time.
>
> Y'all ok with that?
>
> --
> Dean
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 3 Jul 2007 08:07:24 -0700

This is a fascinating discussion and very helpful as well.

I would like to suggest adding some ingredients close to earth:

Can there be tracking models for usage of the S2PSIP applications across
several overlays, security implications, CALEA support (perish the
thought!), _outside the counting of credentials provided by the various
enrollment servers_?

If such tracking is nonsense, please state so and why.

On what features would you spend your own time and money, if you had the
power to decide?

Thanks, Henry

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 12:15 AM
To: Dean Willis
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays

Long answer:

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 8 Jul 2007 11:06:59 -0700

Cullen Jennings wrote:

> Consider the other end of the dog,  

This is an extremely useful contribution since the critical importance
of the enrollment server cannot be over emphasized. The enrollment
server can also play a role by linking p2p domains from a business
perspective, for example:

- p2p.com runs a global commercial p2p overlay and has resellers, such
as

- myisp.com who resells p2p service to

- ourit.com who enrolls its employees into the ourit.com overlay, and to

- ourschool.edu for students and alumni of ourschool.edu

Note there must be a hierarchy of enrollment servers to make this happen
and the hierarchy is controlled by cryptographic means.

The advantage of creating the enrollment hierarchy include greater reach
for p2p.com and the accompanying better functioning of the partitioned
overlay: The more users, the better it works.

Contrary to the golden tree of the DNS hierarchy however we would want
many such p2p trees for a healthy competitive market place. (This is no
endorsement in any way for private ENUM, but that's a rat hole to please
avoid here on the list).

Does it make sense to have a BCP on namespaces and enrollment servers?
Such a BCP could also discuss the use the UUID (RFC 4122) that has been
mentioned in several I-Ds submitted to the P2PSIP WG.

Henry

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 12:15 AM
To: Dean Willis
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays

Long answer: