On Jun 11, 2008, at 11:34 PM, Michael Chen wrote: > Cullen et. al., > > I am glad to see RELOAD continues to refine, but here are a few > things I > spotted so far: > > 1. Section 6.2.2.1, the enum value for peer should be 1 instead of 2.
Thanks - fixed > > > 2. Section 6.2.1.1, ResourceId is defined as a variable opaque with an > 8-bit length byte. In section 6.2.2.1, the Destination structure is > defined with a length field before the DestinationData variant, which > means there are two places that store the size of NodeId and > ResourceId. Yes, I see what you are saying about this - perhaps we should change it. We need that anyways for it to be extensible to new types. I guess we could argue we did not need extensibility here but some people did want this to be an protocol extension point and I don't see much harm in that but I realize this is somewhat separate from your second point. > > > I favor having the length in Destination and remove the restriction of > NodeId being a fixed 16 byte opaque, thus allowing the option to embed > the full 20-byte SHA1 hash. This also makes the Destination a simple > type-length-value (no need to define DestinationData). In discussing this with people, they often say that they would like the NodeID to be the same size of the 20-byte hash but I really don't understand the logic of that. We need the NodeID to be large enough that we don't run out of NodeID but 2^128 seems more than enough for nodes in a single overlay. Is there something I am missing here? > > > 3. Section 6.2.2.2, the second paragraph's description on how to use > ROUTE-LOG flag in response conflicts with the first paragraph (towards > the end). The first paragraph says if ROUTE-LOG flag is set in > request, > the response MUST send the log back AND set the ROUTE-LOG flag to 1. > Well there is no choice for the response. > > Also, giving the choice to append the reverse route-log to the > responder > is not a good idea. This choice should be specified by the requester > via > a second flag, say REVERSE-LOG, which must/should be honored by all > intermediate nodes. good point, thanks for catching this, and I like your proposal - I'll see what my co-authors and others think and we can figure out how to change this. > > > Suggestion to the Forwarding Header: > > The length of Via-list and Destination-list are in the fix portion of > the header, but the route-log length is in the 16-bit prefix of the > log. Why not add one more 16-bit length field called "Route Log > Length" > after the "Destination List Length" (of course remove the 16-bit > length > prefix from the route-log). The benefits are obvious, a) easy > calculation of the start of "Message Contents"; b) easy to tell if > route-log exist; c) via/destination list starts at 32-bit boundary. works for me - I'll see if we get any more thoughts on this ... > > > Thank you > > --Michael > > Cullen Jennings wrote: >> We've just uploaded an update to the reload draft. Until it shows up >> in the drafts directory, you can find it at >> >> http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-04.txt >> or >> http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-04.html >> >> reload-04 represents a total rewrite of the presentation of the >> protocol. There were a number of goals: >> >> - add several descriptive sections at the beginning that detail how >> the protocol works and the design choices we made (and some of the >> options we chose not to incorporate at this point) >> - Simplify the presentation (and protocol) wherever possible by >> removing extraneous features from this draft. Some of these may come >> back in future drafts, but we felt simplifying wherever possible was >> good. >> - remove the bit-field diagrams from the protocol descriptions in >> favor of c-like message structure presentations. >> >> We are very interested in comments on this draft. We expect to have >> time for another revision in about 2 weeks. We have tried to address >> as many of the comments and questions that have been raised as we >> can. In some areas we have made deliberate choices to avoid adding >> features that have been requested. Where possible we discuss the >> tradeoffs that adding additional features will require. We think >> it's >> important for the working group to decide as a whole where additional >> features are worth the added complexity. >> >> Please send your comments to the working group list - it would make >> it >> easier for us if people tried to keep separate issues in separate >> threads and start new threads where it appropriate. I think we would >> all like to hash out as many protocol issues as possible before we >> get >> to Dublin. >> >> Cullen >> Bruce >> Eric >> Salman >> Henning >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
