Skip to main content

REsource LOcation And Discovery (RELOAD) Base Protocol
draft-ietf-p2psip-base-26

Discuss


Yes

(Gonzalo Camarillo)

No Objection

(Dan Romascanu)
(Jari Arkko)
(Martin Stiemerling)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)

Note: This ballot was opened for revision 20 and is now closed.

Peter Saint-Andre Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-01-17) Unknown
[UPDATED based on -20.]

I'd like to talk about several points that I haven't seen mentioned in
other reviews.

1. Section 1.3 appears to couple issuance of certificates and assignment
of Node-IDs (in most cases):

   RELOAD's security model is based on each node having one or more
   public key certificates.  In general, these certificates will be
   assigned by a central server which also assigns Node-IDs, although
   self-signed certificates can be used in closed networks.

What is the reason for this coupling? Does it have security
implications? At the least, a forward reference to later sections
(e.g., 3.1) might help.

2. Does the use of list compression (Section 5.1.2) and private IDs
(Section 5.1.3) prevent an intermediate node from routing return messages
if its neighbor goes offline? In your example, if E has a destination
list of (D, I) but D goes offline, then E won't be able to unpack the
private ID "I" to recover the via list "(A, B, C)".

3. In Section 10.1, the format of the 'expiration' attribute is not
fully specified (e.g., are timezone offsets allowed or must the datetime
be UTC?). UPDATE: I'm sorry if my comment was unclear, but I think
it would be good to cite RFC 3339 here; when doing so, please make 
sure that you document all the details about various options, such as 
use of non-UTC time zones and fractional seconds.

4. Addressed in -20.

5. Addressed in -20.
Gonzalo Camarillo Former IESG member
Yes
Yes () Unknown

                            
Stephen Farrell Former IESG member
(was No Objection, Discuss) Yes
Yes (2013-02-15 for -24) Unknown
Thanks again for handling my gigantic discuss/comments last
time around.

I had a (not so quick:-) check of the diffs between -18 and
-24 and all seems well, but I do have one question: is the
overlay-reliability-timer in the configuration defined in 11.1
supposed to override the "15 second" timer ("Maximum Request
Lifetime") defined in section 2 and and used in various
places, if the value of the overlay-reliability-timer is more
than 15000? 

If so, then it might be worth yet another pass over this to
check that all the hard-coded time values (and there are a few
in both seconds and ms) are in whack with that configuration
element. 

If not, then it might be worth saying that these are different
and how, in 11.1 and/or section 2.

Or, maybe I didn't read enough and that's a dumb question, in
which case, sorry about that.

And lastly, since I do DTN stuff now and then I'm really
curious as to what might happen if I wanted to set the
overlay-reliability-timer to 86400000 (one day). But I don't
expect you to give an answer or do anything about that:-)
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2013-02-19 for -24) Unknown
Thanks for addressing my Discuss and all my Comments.
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection (for -21) Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (for -20) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2013-02-15 for -24) Unknown
Note: Gonzalo didn't reset the ballot, so I am assuming that there's no need to do a full re-review. So I checked on my comments that I had in earlier. Only two outstanding:

6.3.4 - No discussion of wildcard in this section. Does there need to be?

6.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 6.5 (and maybe sections 6.6 and 9) is not a separate document. (I understand that this is the WG wanted to do it. Just registering my complaint, but I won't make a fuss.)
Ralph Droms Former IESG member
(was No Record, No Objection, Discuss) No Objection
No Objection (2013-02-20 for -24) Unknown

                            
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2011-09-07 for -22) Unknown
Page 38 - Section 5.2.1 - might be worth calling out that the sending node will be doing both e2e and hopbyhop retransmissions

Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved

Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document.

Page 107 - the formula at the end of 9.5 has unbalanced parentheses

Page 112 - In the implementer note in 9.7.4.3, can you point to references to get the implementer started?
Ron Bonica Former IESG member
No Objection
No Objection (for -24) Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (for -25) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2011-09-08) Unknown
Nothing like getting to your review after there's already 8 lengthy discusses on it.  I'll not be adding anything new (and possibly avoiding the record for total number and length of discusses) - everything I noted somebody else caught.  I'll pop some popcorn and watch p2psip-base vs IESG form the cheap seats.
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2013-01-28 for -24) Unknown
This is a well written document, and is much improved over the last version that I read. I thank the editors for the work that they have done.

I understand that the example using port "6100" is an error and will be corrected in the next version to the assigned port.

I am therefore clearing with the request that the shepherding AD verifies this change.
Wesley Eddy Former IESG member
(was Discuss) No Objection
No Objection (2012-07-23 for -22) Unknown
- The document seems to be schizophrenic about Head of Line blocking.  The section 6.5.1.6 text on why TCP is not a desirable Overlay Link Protocol notes Head of Line blocking as the primary reason to prefer another protocol, yet the stop and wait algorithm in 6.6.3.1 for use over DTLS, says that only one message can be unacknowledged at a time, so it's unclear how this avoid Head of Line blocking issues (if at all).  It seems like you seay HoL issues are worth avoiding, and then define operation only over transports with HoL issues (TCP and the DTLS-based ones).