Subject: [P2PSIP] Nits on RELOAD base 07

From: "Neil.Young" <[email-masked]>
Date: Wed, 24 Feb 2010 12:55:14 +0100

Nit-picky: Page 18, explanation for "Kind": The last line contains 
several typos.

More important: Inconsistency (?) concerning the number of node_ids per 
certificate. 3.1 is very specific concerning the number of node_ids per 
certificate - just one, if I understand that correctly. In contrary 10.3 
seems to allow more than one node_id per certificate (pg. 118, "one or 
more Node-IDs"). I personally wouldn't know, how to deal with more than 
one node_id per node.

Regards

---

From: "neil.young" <[email-masked]>
Date: Thu, 25 Feb 2010 00:27:56 +0100

Next:
Page 44: Explanation of the possible values of "type". "peer" has to be 
"node"

One question concerning serialization: 5.3.2.2

 struct {
          DestinationType         type;
          uint8                   length;
          DestinationData         destination_data;
        } Destination;

Because DestinationData may contain a type with variable length, the 
DestinationData struct by chance carries a length indicator implicitly 
(e.g. for resource or compressed id types). Is the additional length 
element of the Destination struct an error or really meant to be there? 
If latter case is true, it might not be sufficient to count for all the 
data following:

Given a resource ID of 0x010203 the message would appear like this on 
the wire:

0x02 - Destination type resource
0x04 - Length of the following
0x03 - Length of the resource id as defined by the ABNF notation of 
ressourceID
0x01 0x02 0x03 - Ressource ID

In case, the length of the ressource ID is 255 byte, it would have to 
look like this
0x02
0x00 - ! overflow
0xFF
0x01......

I propose to drop the "length" definition from the Destination struct or 
let this field be an uint16.

Regards

Neil.Young schrieb:
> More important: Inconsistency (?) concerning the number of node_ids 
> per certificate. 3.1 is very specific concerning the number of 
> node_ids per certificate - just one, if I understand that correctly. 
> In contrary 10.3 seems to allow more than one node_id per certificate 
> (pg. 118, "one or more Node-IDs"). I personally wouldn't know, how to 
> deal with more than one node_id per node.
>
> Regards
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: "neil.young" <[email-masked]>
Date: Thu, 25 Feb 2010 16:32:26 +0100

3.1
Each node has a certificate [RFC5280] containing a Node-ID, which is
   globally unique

I'm wondering how you want to ensure global uniqueness.

Regards

neil.young schrieb:
> Next:
> Page 44: Explanation of the possible values of "type". "peer" has to 
> be "node"
>
> element of the Destination struct an error or really meant to be 
> there? If latter case is true, it might not be sufficient to count for 
> all the data following:
>
> I propose to drop the "length" definition from the Destination struct 
> or let this field be an uint16.
>
> Regards
>
>
>
> Neil.Young schrieb:
> ------------------------------------------------------------------------
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2010 08:09:49 -0800

> I'm wondering how you want to ensure global uniqueness.

In most cases, there's a centralized enrollment authority which doesn't
issue duplicates.

In the self-assigned certificate case, the node-id must be a hash of hte
public key so is statistically unique.

-Ekr

---

From: "neil.young" <[email-masked]>
Date: Thu, 25 Feb 2010 17:46:05 +0100

Hi Eric,

<snip>

</snip>

Yes, I believe your claim for self-signed certs. But a centralized 
enrollment server in an overlay which issues certs and guarantees no 
duplicates can't always guarantee global uniqueness. It is likely, but 
not literally guaranteed. The "globally" claim is what I doubt :)

Regards

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 25 Feb 2010 08:51:47 -0800

You would like it to say unique within the Node-ID namespace of the
particular overlay?

Bruce

On Thu, Feb 25, 2010 at 8:46 AM, neil.young <[email-masked]> wrote:
> duplicates can't always guarantee global uniqueness. It is likely, but not
> literally guaranteed. The "globally" claim is what I doubt :)
>
> Regards
>
> Eric Rescorla schrieb:
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2010 08:56:12 -0800

> literally guaranteed. The "globally" claim is what I doubt :)

This actually is not correct.

If the authority pseudorandomly generates them (which it should) then the
nodeids will in fact be statistically globally unique.

-Ekr

---

From: "neil.young" <[email-masked]>
Date: Thu, 25 Feb 2010 20:00:20 +0100

Is there any paper describing the procedures/principles of node_id 
generation anywhere? One should add the term "statistically" to the 
globally unique claim, in order to prevent confusions.
Regards

Regards

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2010 21:13:35 -0800

On Thu, Feb 25, 2010 at 11:00 AM, neil.young <[email-masked]> wrote:
> generation anywhere?

No, it's just common knowledge that the chance that two random 128-bit numbers
will be the same is negligible.

> One should add the term "statistically" to the globally
> unique claim, in order to prevent confusions.

I don't actually agree with this. Any method of generating unique values
has some nonzero chance of producing duplicates. For instance, if you're
using a counter, your memory might be reset to zero by ionizing
radiation.

-Ekr

---

From: "neil.young" <[email-masked]>
Date: Fri, 26 Feb 2010 09:46:48 +0100

If it was your intention to make me feel like the last idiot not knowing 
"globally uniqueness" is the same as "statistically globally 
uniqueness", then you failed. If you intended to get me off this list, 
then - I admit - you succeeded. Who am I to comment on the ideas of 
those, who know it all?

Keep this kind of arrogance. It will help you a lot to find supporters 
and early implementors for your fine draft.

Neil.Young (as individual) has left the building.