Cullen Jennings wrote:
How does a node decide it should be a bootstrap peer. The current
document more or less say configuration.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
So points I see in various comments are that:
- bootstrap peer selection is going to be use-case dependent
- the proper reaction to inability to locate a bootstrap peer is
use-case dependent
- how can you figure out if you're a good bootstrap peer?
options for obtaining bootstrap peers include:
- configuration file
- cached previous neighbors
- mDNS etc
I think the real question here is what needs to be in the base draft and
what is appropriate for extensions or simply implementation/deployment
specific. I would like to propose:
- the configuration file can contain a list, can indicate whether local
search (mDNS, etc) can be used, and can indicate whether no bootstrap
peers being contacted is a failure (there's a minor bootstrapping(!)
problem here for starting a new overlay, but that's not too bad)
- the draft will specify the format of the list and the mDNS parameters.
- caching previous peers will be left as an option for implementers,
presumably falling back to the other mechanisms. (I don't see a reason
to want to prohibit this, but am open to suggestions.)
- determining whether you make a good bootstrap peer and whether/how to
update the configuration list will be out of scope for the base draft.
Bruce
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
