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

From: Song Yongchao <[email-masked]>
Date: Fri, 09 Nov 2007 11:08:14 +0800

Hi, dear co-chairs
This topic was discussed four months ago, and there was a lot of arguments
about it. I think it is a very basic and important concept in P2PSIP, and it
should be discussed and achieve a consensus in Vancouver, anyone agree with
me?

Best Regards!
Song Yongchao

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Monday, July 09, 2007 2:07 AM
> To: Cullen Jennings; Dean Willis
> Cc: P2PSIP Mailing List
> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays
> 
> Cullen Jennings wrote:
> 
> > Consider the other end of the dog,
> > namespaces and enrollment servers.
> 
> 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
> 
> 
> 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
> 
> _______________________________________________
> 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: Song Yongchao <[email-masked]>
Date: Fri, 09 Nov 2007 11:23:08 +0800

And here is section 6.5 from the [Concepts].
"
6.5.  Relationships of Domains to Overlays
   1.  Can there be names from more than one domain in a single overlay?
   2.  Can there be names from one domain in more than a single overlay?
       If so, how do we route Client/Server SIP requests to the right
       overlay?
   3.  Can the domain of an AoR be in more than one overlay?
   4.  Should we have a "default overlay" to search for peers in many
       domains?
"

Best Regards!
Song Yongchao

> From: Song Yongchao [mailto:[email-masked]]
> Sent: Friday, November 09, 2007 11:08 AM
> To: 'P2PSIP Mailing List'