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. 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. 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). 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. 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. 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
