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. 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. >> >> * 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. >> >> 2. What's wrong with section 4. Core Protocol in Reload-03 >> * The basic assumption on which the whole section 4. Base >> Protocol and the related section 3. Overview is written is based on >> symmetric routing from the source to the root and back using the same >> path. This is a flawed approach: >> > >In my previous response, I pointed you to a thread from November with >detailed discussion of the pros/cons of different routing modes. I also don't think symmetric routing always works well under churn. But if you have an operator to deploy these high reliable "Peers", then it will. As consideration for various application scenarios, other routing modes and "P2P Relay" concept must be adopted. It maybe depend on the service to choose the specific routing mode or whether to use a "P2P Relay". >> d. As mentioned, technical terms such as connection, long hop and >> nearby neighbors (leaf set) are treated in a cavalier way and this must >> be fixed in the sense of using Internet and P2P terminology common in >> the technical literature. A glossary with references would help. >> > >My response to your previous message discussed why we chose the >terminology we did. Please suggest specific terms and what you would like >to see instead. I suggest a term for all those peers in an overlay. We give a term "P2P Overlay Base" for it in our SEP client protocol (http://tools.ietf.org/wg/p2psip/draft-zheng-p2psip-client-protocol-01.txt). I don't know whether other guys have better terms for it. Maybe other additional terms for other things are still needed in the workgroup. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
