At Mon, 03 Mar 2008 18:15:15 +0800, Song Yongchao wrote: > > Please see inline. > > >> * Subsection for the client protocol: The proposals for the > >> client protocol, one of which (draft-pascual-p2psip-clients) is based on > >> P2PP anyway, and should be merged here as well. > >> > > > >No separate client protocol is required. What features of a client > >protocol do you believe are not met by the base protocol? > > You can find the features of client in draft-pascual-p2psip-clients, only > when you are clear about that, you will know what features are not met with > Reload-03.
Well, I certainly have reviewed that draft, but I don't think that there's WG consensus on the exact feature set described in it. In particular, I'm pretty skeptical about the notion that clients will be acting as storing nodes. > No matter whether we need a separate client protocol or a > subsection for client protocol, those features should be discussed first. I > support Victor to make a presentation and discussion of "clients" at the > meeting. Well, one of the nice features about RELOAD, IMHO, is that very little explicit support for clients is needed. Basically, a client is a node which connects to other nodes but does not issue JOINs or UPDATEs. Therefore: - The peers it is explicitly connected to can route to it directly. - It is in their neighbor table but not their route table so it never routes packets. - Because it doesn't JOIN it never stores data. Note that a client can connect to peers at one of two places: - At the location indicated by its peer-id. - At a random location. In the first case, routing to the clients peer-id simpyly works, since it goes through the node responsible through that space, which is directly connected to the client. In the second case, the client can advertise a destination list [this is one use for this feature] consisting of the peer it is connected to and then itself. > >> > >> * Security (I like these sections very much): Should the various > >> sections on certificate security and secure transport be consolidated > >> into one section on Security? Where does the security for the HIP part > >> belong? If HIP is secured, when/if is TLS and DTL still useful? > > I think we need a separate document to discuss security issues. I don't in principle have a problem with a separate non-normative document containing security analysis of P2PSIP systems. However, I believe all of the security features need to be part of the core protocol and the core document, which is why we built them into RELOAD. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
