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
