> > > > > Yes, I agree that it's important that the bootstrap nodes be both > > available and publicly reachable. > > A given bootstrap node only needs to be reachable to a given joining peer - > so, I don't think "publicly reachable" is a hard requirement to serve as a > bootstrap peer. That said, you likely need some bootstrap peers that are > publicly reachable for overlays that are meant to be available across the > Internet.
Using proposed mechanisms in relay draft can also help a node determine whether it is reachable, even if it is behind NAT, for example, a node behind a residential gateway using uPNP-IGD to get assigned address on the public side of the gateway. > > > The question is whether the > > specification needs to actually provide a mechanism for the > > configuration server to determine that's the case or whether > > we can assume that the operators of the system can figure out > > how to do that themselves using existing IETF standards > > such as SNMP. IMO, the latter approach is preferable. > > > > I think there is some merit to specifying how a current bootstrap peer list > can be maintained - it would also help to allow peers to volunteer to serve > the bootstrap function as they join the overlay. I think this can be > specified > outside of the base spec itself though. I agree. A set of bootstrap peers will change because a peer joins the overlay or leaves the overlay, or some bootstrap peers are available. I also think maintain a dynamic bootstrap peers list is useful to bootstrap reliability and reduce the burden of bootstrap peers if the list is static only by configuration. Regards Jiang XingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
