Subject: Re: [P2PSIP] comments on draft-hardie-p2psip-p2p-pointers-00

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Jul 2008 19:01:50 +0100

At 6:07 AM -0700 7/28/08, Bruce Lowekamp wrote:
>I read through the pointers draft and have a couple comments/questions:
>
>- With the media-type in Section 3, and taking no position on which type
>is better or where it should live, is there a reason this type should be
>functionally different than that in reload's Section 13.2?  They seem
>like they are serving the same purpose, ultimately.

They are certainly related.  The version in p2psip-p2p-pointers is
slimmed down from the previous version (p2poverlay-pointers),
which was written before reload had reached its current state (before
the merge at all,  I think).    Reload's current version is a bit "fatter"
with aspects which are specific to reload. There are a few things about reload's
version that differ in presumption; the reload draft indicates that
it is fetched from an enrollment server for example, and
it does not use a registry for things like chord-128-X-X values.

But could these be merged, or could the reload draft substitute
a pointer to an updated version of the pointers draft?  Almost
certainly.

>- I found Section 5 a bit confusing.  Although the section title is node
>pointer, the text seems to define a resource pointer.  At least, that is
>my understanding of the phrase "focused on the node and its resources is
>proposed here, along with context-dependent ways to use it... to
>represent resources".

The aim of the section is to provide a way to reference a specific
node, or a specific resource at that node, or a specific resource
wherever it exists.  That's why there are three forms.  The most
basic is for the node:

overlay-node://22301203/

that can be decorated with the context id, if there is no existing
context or there would be ambiguity:

overlay-node://22301203/;context="http://introducer.example.net/\
   example.odd"?

but it remains a pointer to the node.

To point to a resource at that node, the draft uses this syntax:

overlay-node://22301203/;context="http://introducer.example.net/\
   example.odd"?resource=service-instance

or

overlay-node://22301203/;context="overlay://enrollment.example.org/\
   ;otype=pastry"?resource=example.iso

when using the overlay URI scheme.

>So if this is pointing to a resource, I would prefer the host-part of
>the URI (is that the right name now?) to be a search term rather than a
>hash, i.e. [email-masked].

For host part, I think you mean authority section.  The syntax allows
you to elide that, so that you can reference a resource within a context
without including any node.

>My understanding of the URI in Section 5 is that resource= would be a
>kind in reload's current terminology.

It could actually be a filename, if you want to say something like
"I want the debian.iso file stored at this node id in this overlay
context"

overlay-node://22301203/;context="overlay://enrollment.example.org/\
   ;otype=pastry"?resource=debian.iso

I think this is different from "kind" in the current document.

>
>Separate from those questions, my other thought when reading this is
>whether the overlay specification needs to be different for something
>that is trying to direct a node to make a query to an overlay as a
>client vs a spec that is intended to be used by new peers.  I think
>reload would support a one-shot query as it exists now, but it certainly
>hasn't been a design focus.

I'm not sure what you mean by overlay specification here.  The
overlay URI scheme and odd files?

				Ted

>Bruce

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Jul 2008 09:02:51 +0100

At 2:15 AM -0700 7/29/08, Bruce Lowekamp wrote:
>
> > overlay-node://22301203/
>
>so my understanding is that 22301203 is a node-id

Yes.

>and this is a pointer to a node-id with a reference to the overlay-pointer

Yes.

>so this is where I get confused.  A "resource at that node" is an
>unusual thing to want a pointer to (unless you're interested in
>diagnostic information).

As an external pointer, it might be rare.  I think it would be more
usual in an internal context (possibly diagnostic, possibly to have
a URI pointer to a specific instance).

> What I would expect to want to be retrieved
>would be a resource in an overlay.

>kind is a type, like a certificate or a sip registration.  A resource
>name is something like [email-masked].   So what I might want to do
>is retrieve the certificate for [email-masked] from the example.com
>overlay.  Normally this is done by hashing [email-masked] to produce
>a Resource-ID and then the peer responsible for that Resource-ID is
>located.  But since you don't know what peer will be storing that
>resource under normal conditions, you wouldn't want to look up a
>resource on a peer.  Evolving from your syntax, if I use a resource-id
>instead of a peer-id, what I could see would be
>
>overlay-resource://resource-id/;context=overlay-pointer;kind=cert
>
>One of my initial thoughts was that I would rather use the resource-name
>than the id since it's expected to be human-readable.
>
>although the ordering of this bothers me.  Hierarchically, wouldn't
>something like
>
>overlay://overlay-pointer/resource-name;kind=cert
>
>be a bit better from a top-down perspective?
>
>I was thinking of the overlay-pointer type.  Essentially random
>wondering of whether there should be a shorter description available of
>how to simply make a query to an overlay as a client than is required to
>join the overlay as a peer.  Or maybe there would be more peers
>available for clients to contact to make query than are available to
>serve as bootstrap peers.
>
>Bruce