-----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.

>> 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.

> 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

Reply via email to