The merger of the best protocol proposals is indeed the right procedure for an accredited standards organization such as the IETF. As such, I would like to add some specific items to a merged protocol proposal and will take Reload-03 as a discussion example. We can then discuss item by item.
1. Naming the protocol 2. Added key technical features need real write up 3. An editor is required 4. Discussing design decisions 1. Naming the protocol Reload-03 is already a nominal merger of about 5 other protocols and more items may be added. In fairness, a new, neutral name is therefore required. Why not call it P2PSIP-00? 2. Added key technical features need real write-up Reload-03 claims the notions of * Selecting the DHT, (we like such as Bamboo, Chord and Kademlia) * Defining a client protocol and * The possibility of using HIP. * Why not include the DHT AS A SERVICE as in the openDHT? These claims must be backed up by meaningful text, definitions, etc. mostly taken from P2PP, the two P2PSIP client I-Ds and HIP BONE and there are probably more. Just make these claims real. Contributors can write to the list what other key technical items should be included in P2PSIP-00 and propose the text for the additional section(s). 3. An editor is required All this work needs an editor to work with the contributors and include the various contributions. An editor is also required to clean up the present Reload-03 I-D, for such reasons as: * Remove the tutorial part and just reference some of the 1,000s of papers on P2P and DHT. * Use common technical terms and avoid confusion. For example the notion of P2P connection in the draft: I believe the writer meant long hop neighbors and near neighbors (leaf set). Also, routing state means the routing table + the neighbor tables. If in doubt, the Wikipedia and openDHT have very extensive text on this. 4. Discussing design decisions * Symmetric routing has been criticized on the list already, but never discussed. It seems to me a bad idea (and I can argue why) * I would also like to understand for example why Via and GRUU are proposed and exactly how it would work here Especially via seems to duplicate SIP routing with the underlying DHT routing - or does it? Please explain. I believe a fair technical process is critical to a successful P2PSIP and to avoid having winners and losers and unhappy campers who feel they may better ignore this emerging standard. What do you think of these items? Thanks, Henry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rosen, Brian Sent: Wednesday, February 27, 2008 10:08 AM To: [email protected] Subject: [P2PSIP] Direction on protocol selection Quite a number of protocols have been merged, by their authors, into one proposal (RELOAD/ASP/P2PSIP). It seems to the chairs that this indicates the beginning of consensus within the group on the direction of the protocol. The chairs invite list discussion, and will allocate agenda time, to determining if in fact consensus exists. There remain a number of protocols on the table, many of which have been introduced later in the process. The chairs invite discussion on the list and will allocate a limited amount of agenda time for the proponents of other protocols to show: 1. That their proposals have characteristics which make them more attractive than the merged protocol 2. That there exists some support within the working group beyond the authors for the protocol Selecting a draft to make WG item is important; we can't document consensus until we have one. This doesn't mean everything in whatever draft is adopted makes it to the final RFC -- the authors become scribes of working group consensus. If you have a proposal and *don't* want it considered for the WG item, but think that it has a good idea you would like in the RFC, we are open to you presenting on that issue. We emphasize that no decisions have been made. There is ample opportunity for discussion on the selection of the base protocol for our work. However, to meet our milestones, we must choose a document to become the basis for a working group protocol RFC. We must focus our attention on this issue and make hard choices. We invite your comments. The Chairs _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
