On Sat, Mar 13, 2010 at 10:28 AM, David A. Bryan <[email protected]> wrote: > As long as I have a way to specify an alternate transport/security > model, I'm pretty flexible, and the more I think about it, the right > place for the flag may very well be to have it lower, in the root of > the config, rather than with the bootstrap field (since, as you point > out, this really isn't specific to the bootstrap peer/process, that > just happens to be the first time you need to know the transport). > > The one thing I'd personally prefer is to have a field that specifies > the transport by default (including TLS in the base case) rather than > an assumption that it if it isn't present we use TLS. My reasoning > being to make clear what the behavior of a peer that only implements > TLS will be when it gets a bootstrap with an unsupported transport. It > might not understand the extension in the XML if it's not in the base > (i.e., what do I do if there is one parameter in the XML I don't get)? > If it just ignores it, it would try to connect with TLS (and fail). I > think it's better to understand that parameter, and recognize it is a > value for transport that isn't supported.
I don't have a problem with this. > (Which just now made me think of one out there question...should we > allow multiple values for the field? I guess the overlay could allows > connections with different transports...haven't really thought about > that. If we do that, then is there a need to specify which ports the > bootstrap accepts which transport on? Personally, i think this may be > more bother than it is worth, and I can't really think of a good > reason for it, but mentioning it for completeness in case someone else > knows a reason why we might need it) I think this is a bad idea. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
