I got lost on this one. Are there any changes we need to make to the draft based on this email thread?
On Dec 27, 2009, at 10:10 AM, Eric Rescorla wrote: > On Sun, Dec 27, 2009 at 8:48 AM, Michael Chen <[email protected]> > wrote: >> Eric, >> >> Thanks for pointing out the replica StoreReq paragraph in 6.4.1.1, but I >> still have 2 questions: >> >> 1. What is the via and destination list look like for a replica StoreReq? >> >> I believe StoreReq (replica or not) should not be routed, thus the via list >> should be empty and the destination list should contain a lone entry of the >> receiving peer (i.e. the successor of the responsible peer). If this is >> true, the draft should enforce it. > > I had assumed that this question was implementation and overlay > dependent. Say for the sake of argument that a node can't establish > direct connections with all the replica set, then it would have to > route replica stores, no? What do you think would be the advantage > of adding this restriction? > >> 2. What are the use cases for the other 3 requests where the resource ID in >> the message differ from the destination list? >> >> FetchReq.resource >> StatReq.resource > > Both of these can be used by the storing node to explicitly address replica > nodes; see 6.4.1.2: > > The list of other peers at which the data was/will be replicated. > In overlays and applications where the responsible peer is > intended to store redundant copies, this allows the storing peer > to independently verify that the replicas have in fact been > stored. It does this verification by using the Stat method. Note > that the storing peer is not require to perform this verification. > > The text probably should say "Stat or Fetch" methods. > > >> FindReq.resource >> >> Replica is not involved in these cases. These messages are only meant to be >> answered by the responsible peer. If this is true, these resource IDs should >> be removed from the message. > > Well, the idea with Find is to allow you to ask a specific node a question, so > it's expected to be addressed to a node directly, not a resourceid, thus > requiring the resourceid in the request. > > -Ekr > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
