Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (5)

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 11 Mar 2011 08:41:08 -0800

On 02/06/2011 03:42 PM, Marc Petit-Huguenin wrote:
> More questions and comments...

[...]

> A.39. Section 6.2.2
> 
> I am not really sure to understand how the "exists=False" are synthesized when
> doing a Fetch on an array.  For example if a Store was made for an object with
> an index of 0xfffffffe, and the Fetch requests the whole array, will the answer
> contains 4294967294 "exists=False" objects?

Also how are this synthesized elements signed?

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 12 Mar 2011 13:15:38 -0700

> 
> 
> A.41. Section 10.1 expiration definition
> 
> I think that it would be a good idea to say that a Node should wait a random
> time after the expiration time before retrieving the file again from the
> configuration server to not crash it and to let ConfigUpdate do its job.
> 

Makes sense. I'm going to add the text 

   The peer SHOULD retrieve a new copy of the configuration at a randomly selected time that is before the expiration time.

I'm not all that happy with that text it someone wants to suggest something better. It does not tell the implementors what range to select the time over but it's not clear we have to be that specific. 

> A.42. Section 10.1 client-permitted definition
> 
> I have no idea how an overlay can enforce this.  All nodes starts as clients, so
> how an overlay is supposed to know the difference between a real client and a
> client that yet had to do the steps required to become a peer?
> 

Agree. Changed to 

   If it is set to "FALSE" then nodes are not allowed to remain clients after the initial join. There is currently no way for the overlay to enforce this.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 12 Mar 2011 13:15:53 -0700

On Feb 6, 2011, at 4:42 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> A.36. Section 2 "Each Kind is identified with a unique IANA assigned integer
> called a Kind-ID."
fixed

> 
> According to 13.6, Kind-IDs in the 0xf0000001 to 0xfffffffe are not IANA
> assigned.  Same thing in the second paragraph of 4.1.
fixed 

> 
> A.37. Section 5.3.3.1
> 
> Error_In_Progress is missing.
fixed

> 
> Also the definition for Error_Config_Too_New does not match 5.3.2.1.
Fixed

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk1PMeoACgkQ9RoMZyVa61e9jwCffYWuEsxiutkKPIf3PlZdiGpy
> mi0An1+8ztwuBfacvkUdZI1TJytrIJBX
> =cWgV
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 09:03:37 -0700

> I'm not all that happy with that text it someone wants to suggest something better. It does not tell the implementors what range to select the time over but it's not clear we have to be that specif…

One of the reason to use the expiration value is to force the clients to reload
a new version of the configuration document before the root cert expires. For
this reason I would suggest to add something like this:

"The expiration time MUST be lower than the highest expiration time of the root
certificates listed in the configuration element."

As for the range, I would suggest something like this:

"The node SHOULD start retrieving a new copy at a time randomly selected between
the expiration time minus 10 days and the expiration time.  If the copy returned
is not newer than the current copy, then the node SHOULD retry at a time
randomly selected between the time of the previous attempt and the expiration
time, until a new copy is received or the expiration date is reached."

- -- 
Marc Petit-Huguenin