REsource LOcation And Discovery (RELOAD) Base Protocol
RFC 6940
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)
[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
()
Stephen Farrell Former IESG member
(was No Objection, Discuss)
Yes
Yes
(2013-02-15 for -24)
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)
Thanks for addressing my Discuss and all my Comments.
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(for -21)
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(for -20)
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -24)
Pete Resnick Former IESG member
No Objection
No Objection
(2013-02-15 for -24)
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)
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
(2011-09-07 for -22)
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)
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(for -25)
Sean Turner Former IESG member
No Objection
No Objection
(2011-09-08)
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)
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)
- 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).