Marc, Thanks for your detailed comments.
At Thu, 6 Mar 2008 17:28:14 +0100, Willekens, Marc (EXT-Other - BE/Herentals) wrote: > Some comments and remarks to > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-03.txt > <http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-03.txt> > > > page8: Figure > HIP transport protocol is not indicated in the picture Good point. We kinda ran out of room :) > page10: Security Information about the P2P overlay network is also > obtained from the enrollment server. As soon as users have obtained > the XML configuration file from the central server after > authentication and authorization, the obtained file can be misued by > that users or by others. What mechanisms are provided to avoid this? > How is e.g. a Dos attack to the indicated bootstrap servers avoided? > I hope the XML file is also stored in an encrypted way in the peer > node. Well, the bootstrap peers aren't secret, so basically you don't need the configuration document to mount a DoS attack. We don't think of this info as secret. > page12: User > Can a user only be a human being or is a machine also supported? Or > is this excluded on purpose? I think this is just a terminological thing. We think of a machine user as just an automatic peer. > page15: symmetric/asymmetric > Is it also not possible to have something in between, something as > pseudo-symmetric where optimization along the return path can be > used? And why do we have to differentiate between symmetric and > asymmetric? Is it not just about forward and backward routing. When > the receiver knows and can address the sender directly, why should > it then do the symmetric routing? There have been a lot of discussions of the different routing modes, so I think this is a bunch of good questions we should discuss in PHL. > page15: store, fetch, remove > Somewhere in the document, it is indicated as being an "instance" of put, > get, detele. But what is special about that instance? Sorry, I don't recognize the section you're talking about here. > page17 > ... can process STORE/FETCH request. I assume a full member can also > do REMOVE/FIND requests. What methods are provided for "clients"? > Can they also do a STORE and REMOVE or are there actions limited to > a FIND/FETCH? Oh, the pain of the terrible writing in this section. Yes, it can process all the other requests. Clients too. The only thing clients can't do is JOIN and send UPDATE (?), because that would make them peers. > page17, §3.2 > ...Looking at the peer-id "in the destination list" that represents .... > > page29 > Route List Length - > Destination List Length Good catches. > page30 > Version: 7 or a 8 bit field? Version skew. 8. > Message Length: including the "complete forwarding" header? That's the idea. Not saying this is the most aesthetic approach. > Peer-id lengths: Maybe better to avoid a length field for > a) security reasons: better to obtain this information from the XML file > obtained from the enrollment server > b) compact forwarding header structure peer-id lengths are fixed for any overlay. The resource and compressed forms have to be variable length, though. > page33, §4.1.2.2 > ... the first entry on the "request" via list. > > page35 > Via list: Is it not better to call this a '"From" list because its not the > own node which is stored but the node where the message came from. > So, instead of Via List and Destination List, is it not better to talk about > "From" and "To" list? We've had horrible fights over this terminology, so I'm happy to do whatever the WG likes here. > page38, §4.2 > transaction id in the common header? Is this not a field of the forwarding > header? Good catch. > page38, §4.2.1 > Message code: 16 bit (17 bit in the picture)/ Should be 16 bits. > Is it not better to make 0 and 1 reserved and starting the Request > as an Even value so that responses are always odd to align it with > the odd error response code 0xFFFF. Instead of assigning different > numbers in the IANA for Requests and Responses, it's also possible > to define a response bit in the lower order bit of the message code > field. This was a last minute addition, so I'm not wedded to any particular layout. I kind of feel like I could make arguments for all of them :) > page39, §4.2.2 > .....indicating the "byte" length Right. > page41 > Can you explain the signing of the message. Is the message content > in the figure the RELOAD common header+payload part? Just the blocks in the "message_signature_input" diagram. > page43 > Should the Reason Phrase not be definied as an optional (verbose) > parameter and the error code as a mandatory parameter? The way you do optional is a zero-length phrase. > page43, §5 > Every 3 s, request up to 5 times. > Should we go for a linear or logarithmic scale, e.g. 3s, 4.5s, 7.5s; 12s? quite possibly. I'm desperately hoping someone from TSV will tell us what this should say. > page47, §7.1.1.2 > Does the response id has a relation with the node id?. No, it's just random bits. > page48 > type identifier: leading 16 bits??? or leading 8 bits. Doh! diagram error. Thanks for catching that. > page75, §8.10 > Are these keepalive message not too much burden on the p2p overlay > network? Periodic messages every 30 s for the peers behind a NAT and > for the peers in the public internet providing the STUN service. Good question. We derived these from what we understand NATs require. We'd be happy to loosen them if it can be demonstrated that that's safe... > page76, §9 > What about unstructured algorithms which was part of the p2pp? Is this > planned for the next version of the draft? We'd prefer to focus on structured for now, since it seems more in line with the general focus of the WG. We'd welcome another draft that described unstructured... > page109 > Message codes: make the distinction between _Q and _A with the least > significant bit in the message code. > > page110 > What exactly is taken over from the p2pp? There are already p2pp > implementations and it could help them to figure out how Reload is related to > it. There's been a bunch of discussion of this on the list already. Look back for messages from Bruce and Salman. Best, -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
