We have an agenda item to discuss the merged protocol We have an agenda item to discuss other protocols. So far, no one has requested to speak on the latter item.
We intend to call for a hum on consensus following those discussions, and follow up with subsequent list discussion to confirm consensus if it appears we have one on protocol direction. If we have consensus to move a document such as Reload-03, or any other protocol document, to be a work group item, the chairs will undertake to appoint an editor for that item. If we don't have consensus to move any document forward as the basis of a p2psip protocol, we'll figure out another way forward. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2008 2:07 PM > To: Brian Rosen; P2PSIP Mailing List > Subject: RE: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > Brian, > > Thanks for the clarification! > > Sorry, one more clarification: > > > We will discuss editorship with the authors of the document that is > accepted > as a WG item > > Is this meant as one single document proposal (Reload), or does it include > the other proposals as well? > > Thanks again, > > Henry > > -----Original Message----- > From: Brian Rosen [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2008 10:06 AM > To: Henry Sinnreich; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > Not sure what happened to the archive, but we'll look into it. > > The editor item will not be on the agenda. As I said, if you disagree, > bring it up at agenda bash. > > We will discuss editorship with the authors of the document that is > accepted > as a WG item. "Discuss" doesn't mean they decide. As you know, it is not > uncommon for chairs to appoint an editor who is not in the author group. > At > this point, I have NO OPINIONS on the subject. Anyone wishing to comment > on > editing is welcome to email the chairs or find us at IETF-71. This all > assumes we have consensus to create a WG item. > > While editorship is an important ingredient of an IETF document with lots > of > authors, the editor's power to control what goes in the document is > limited. > Once the document is a WG item, anyone can propose ideas and/or text. If > the WG agrees it should go in the document, the editor must incorporate > it. > A WG item does not "belong" to the editor, or even the authors. It belongs > to the WG. > > Brian > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 07, 2008 12:47 PM > > To: Brian Rosen; P2PSIP Mailing List > > Subject: RE: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > > > Brian, > > > > >" I responded to the author issue in a message sent on 3/3 with the > > subject > > >"Re: [P2PSIP] Agenda for IETF-71" > > > > Sorry, I could not find this message in the archive either - the archive > > starts from 3/5. > > http://www.ietf.org/mail-archive/web/p2psip/current/ > > > > I am still curious if the editor item will be on the agenda. > > > > >> Editor issues will be discussed between the authors and the chairs > > > > Did you mean the authors of all the proposals or only the authors of > > Reload-03? > > > > Thanks again, Henry > > > > -----Original Message----- > > From: Brian Rosen [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 07, 2008 9:30 AM > > To: Henry Sinnreich; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > > > Henry > > > > I responded to the author issue in a message sent on 3/3 with the > subject > > "Re: [P2PSIP] Agenda for IETF-71" > > > > The response was: > > > Editor issues will be discussed between the authors and the chairs > > if/when > > > > > a draft is made into a WG item. > > > > Editors are not chosen by hums. Editors for WG items are appointed by > > chairs. > > > > I don't think agenda time for this is warranted. There will be agenda > > bash > > time. If you feel otherwise, bring it up then. > > > > Brian > > > > ________________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > > Of > > Henry Sinnreich > > Sent: Friday, March 07, 2008 12:00 PM > > To: P2PSIP Mailing List > > Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > > > Folks, > > > > I have just seen that the mail archive does not go back before March 5 > and > > this message is not available in the archive, so I hope people who may > > have > > missed it, can see it now. My apology to those who have already read it > > and > > answered (almost only Reload authors). Well, the proposal to have an > > editor > > with quality time, and being neutral dare I say has not been yet > > discussed. > > The neutral editor with quality time should be an agenda item with a > hum. > > Henry > > > > ________________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > > Of > > Henry Sinnreich > > Sent: Saturday, March 01, 2008 4:13 AM > > To: P2PSIP Mailing List > > Subject: [P2PSIP] Extending the (inclusive) merge for P2PSIP > > > > As mentioned, here is how to extend the inclusive merge for P2PSIP with > > the > > best proposals from various authors. I hope this can make it to the > agenda > > of the P2PSIP WG meeting. > > > > 1. Merge proposals. 1 > > 2. What's wrong with the Core Protocol in Reload-03. 1 > > 3. Discussion of design decisions. 1 > > 4. Why an editor is required. 1 > > > > 1. Merge proposals > > > > * Replace section 4. Base Protocol with P2PP since P2PP has all the > > desirable properties: Works for structured and unstructured overlays, > has > > a > > rigorous I-D, freely available code, large scale deployment and several > > independent implementations. Hopefully SIPit testing and the SIP Forum > can > > be engaged for interoperability testing and debugging as well. By > > contrast, > > the present section 4. Base Protocol is seriously flawed as shown here > > below. > > > > * 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. > > > > * 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? > > > > * Combine the two proposals for using HIP, the high level HIP-Bone and > the > > detailed, step be step p2p-sip-id-loc should be merged into one single > HIP > > (optional for P2PSIP) section. > > > > * There may be more and I apologize for keeping this here to a short > list > > only. > > > > * Remove he tutorial section and replace it with references. > > 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: > > > > a. Churn can break the return path. For a example a 95% probability for > > success in the presence of churn over 10 hops each will result in a > total > > probability of success of 099^10=0.59, that is 59%. The media path > cannot > > work well if the two end points cannot see each other and there is no > > solution given here for the media path. Perhaps another media relay or > > using > > HIP? This is a missing item. In any case the media path MUST NOT follow > > the > > symmetric search path since the delay will be unacceptable over so many > > hops > > and unknown geographic locations that can be anywhere on the Internet. > > > > b. The correct approach for non-transitivity in the DHT is to use more > > than > > one source node for the search in the underlying DHT with smart timeouts > > for > > "node recovery" as described in "Non-Transitive Connectivity and DHTs", > > http://srhea.net/papers/ntr-worlds05.pdf and > > http://srhea.net/papers/bamboo-usenix-talk.ppt . > > > > c. The above shows how the DHT can do the required work and why the > whole > > routing (forwarding) layer with its routing tables, routing state, > > retransmissions, flow control, etc. at the application level in Reload- > 09 > > is > > redundant. This kills the rationale IMHO also for the methods described > in > > section 7. Method Definitions. > > > > 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. > > > > e. Though the use different DHTs is claimed (but not the use of > > unstructured > > overlays), what is shown is only a nailed-down-like use of Chord, much > > less > > general and modular as in P2PP. > > > > 3. Discussion of design decisions > > There are several design decisions that should be discussed on the list > > such > > as the use of SIP GRUU. What is the usage scenario of using GRUU in > P2PSIP > > and in what cases is it useful? We already have defined how to connect > > P2PSIP networks with the DNS world. > > 4. Why an editor is required > > The emerging P2PSIP protocol document will be on of the most complex in > > the > > IETF, probably exceeding the size of RFC 3261. > > Such a document requires a dedicated editor having adequate quality > time, > > besides the authors and contributors of the various original protocol > > proposals. > > > > Thanks, Henry _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
