On Fri, Mar 4, 2011 at 2:44 PM, Marc Petit-Huguenin <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/04/2011 10:59 AM, Bruce Lowekamp wrote: >> On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin <[email protected]> >> wrote: >> On 02/27/2011 05:15 PM, Bruce Lowekamp wrote: >>>>> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin <[email protected]> >>>>> wrote: >> >> [...] >> >>>>> >>>>> OK, so the Signature extension is mandatory to use multiple Node-IDs in >>>>> certificates. But the IceExtension still seems useless, as, thanks to the >>>>> Signature extension, we always know the Node-Id on each side of the >>>>> Attach. >>>>> >>>>> >>>>>> I think the IceExtension would be needed for connection sharing, so >>>>>> since you said you're setting that aside for now, I agree. >>>>> >>>>> Also a client joining the overlay using a certificate with multiple >>>>> Node-IDs, >>>>> using the procedure in the second bullet of section 3.2.1 will still have >>>>> problems. >>>>> >>>>> >>>>>> Assuming the Attach is using SignerIdentity, I don't see any problems >>>>>> with that, since the peer would know the node-id that the node is >>>>>> using. >> >> Clients that are using the mechanism described in the last paragraph of >> section >> 3.2.1 do not send Attach, so a peer would have to spy on the first message >> coming from the connection of this client to extract the Node-ID from the >> SignerIdentity and be able to add the connection to the connection table. >> >> >>> I believe the intention has always been that all node connections use >>> an Attach. > > This is not what the second bullet of 3.2.1 says. >
Marc, I'm sorry, but can you quote the text you're referring to? I don't see the word "Attach" in that bullet. You're looking at -12? I like this feature too, but it's intended to allow a client to Attach to a peer other than its responsible peer, rather than route the Attach to its responsible peer. >>> The only exception is initial bootstrapping (3.4). Those >>> nodes don't send Update. >> >>> You're doing this because you have clients coded with the address of a >>> peer they should connect through? > > No, I am writing an implementation that will cover 100% of the I-D. It's in > the > spec, so I am trying to implement it. And I think that the mechanism in the > second bullet of 3.2.1 is elegant as it permits to not consider the first > connection of a new node as a special case, and so should not be removed from > the spec. > Thanks for working on such a thorough implementation. You are definitely identifying numerous issues that people who did implementations awhile ago wouldn't notice, and I appreciate your insights into other possible solutions to some of the problems. Thanks, Bruce >> I think it would still be better >>> to have them doing an attach, either by encoding the peer ID in the >>> same place they learn about the node from or using the ping mechanism >>> in 10.4, followed by an Attach.(I think the draft is a little >>> unclear that any node receiving a message sent to the wildcard simply >>> responds to it) > > Yes. And in my opinion, a node MUST send a Ping with wildcard immediately > after > any connection is established, so a client does not need to send an Attach. > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk1xQRQACgkQ9RoMZyVa61c6dQCghEB2UkC7ygEs45PvMtx8WIup > zVQAoKHRekHKpe8IzJnVoR21AgTsdgXI > =JubW > -----END PGP SIGNATURE----- > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
