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
