On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: > > On the topic of a flag to not keep state... just having a flag won't work. It > has to be an overlay option because all the nodes in the overlay need to > support it. Once you have it as an overlay option, you don't need it in the > base spec. I just don't see any reason to put it in the base spec - it can be > done in extension just as well - and I see lots of reasons not to but it in > the base spec. We don't really know how to make this work well yet. Ideally > it would be an optimization you used when you could so that a client could > still connect to a peer that would do state and do the DDR for it. Saying > something like the flag indicates don't keep state breaks clients among other > things. You would need the option to be a little more nuanced than that. I > think we should define all of this in the DDR draft - trying to guess what we > need before we know what we are doing is likely to result in getting it > wrong. >
I don't think this is quite right: the issue isn't really whether all nodes in the overlay support it but rather whether they support DRR. Here's my reasoning: a requester who uses this option is basically committing to only receiving responses via DRR, since the Via List will not be unwindable by the responder. However, because a requester has no real a priori way of knowing a responder's capability this means that any node in the overlay must already support DRR because otherwise any intermediate or terminal node has no way of responding to the request. So, this extension is only useful in an overlay in which everyone supports DRR; where it's basically a way of indicating "use DRR only" and telling intermediaries they don't need to store state. However, with that said, it seems to me that the forward compatibility issue goes away: if we do decide to use this flag to enable DRR, then all the nodes in the overlay will have to be DRR-capable, at which point we can define this extension or similar at the time we define DRR. So while I had originally edited this extension into the draft, I have now concluded we should remove it after all. Best, -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
