I generally agree that having a simple solution is good, and the current algorithm may be ok, but as I raised in Hiroshima (via the Jabber room), my only concern here is that we have not seen any results showing it works. There have been claims, but in the real engineering/academic sense, no proof (simulation, analytical, published measurements from real deployments or otherwise) to show this very simple algorithm works and isn't harmful. Getting this wrong seems ripe for problems. I'm a bit worried that standardizing an algorithm with no evidence it works is a bit dangerous. This is standardization, not research, so we need hard evidence to back up what we do.
At the Hiroshima meeting there was a claim made that simulations showed it worked, but despite my asking, the editors declined to publish/share any results from those simulations, so I'll ask again: can the editors please publish and share these results and let the group look them over before we standardize this? In the absence of that, I can't support including this algorithm in the draft. This is a technical group, so we should be operating on not making decisions without the studies to back them up, if nothing else to make sure the group doesn't look bad later if something inadvertently got missed that the group might pick up in a more rigorous examination. I'm sure it's fine, but really, it should be easy to put something out there so we can see the results and make an educated decision and make sure the group has made the right decision. David (as individual) On Wed, Feb 17, 2010 at 5:35 PM, Cullen Jennings <[email protected]> wrote: > > This has been discussed many times. We need some mandatory to implement type > relay system for the draft to work with NATs. Thats a charter requirement so > I don't think there is any argument that we need something. The question is > what. I will continue to argue for the simplest thing possible because > generalized service discovery is highly depended end on what application it > is being used for. What is there is good enough to meet it's needs - I don't > think there is much debate on that. I'd love to see development of more > complex algorithms and encourage that as well but I would object to something > more complex when all we need for the base case is the simple stuff. > > Cullen <in my individual contributor role> > > > On Nov 23, 2009, at 1:02 AM, Song Haibin wrote: > >> >> I agree with taking the document to WGLC if the authors take the TURN >> discovery usage out of this document and leave it to another task of a >> generic service discovery mechanism. It's weird to have two different >> service discovery mechanisms. If the authors think their TURN discovery >> mechanism is good, then how about writing it in a separate proposal for >> service discovery (not limited to TURN usage), and we will have several >> candidate drafts. >> >> Xie Xie, >> Haibin > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
