Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)
RFC 6915
Note: This ballot was opened for revision 01 and is now closed.
(Robert Sparks) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Benoît Claise) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) (was Discuss) No Objection
Comment (2013-02-28 for -01)
No email
send info
send info
My original Discuss read... > This is borderline for me, but I am trying to understand how an > existing deployed implementation of RFC 6155 handles the case > that a protocol element it is using has been deprecated. More > importantly, how a new implementation handles receipt of a > now-illegal protocol element. > > I understand that the change is "before, we said you could do this, > but we have discovered that you can't get it through some NATs, > so don't." But it seems to me that the problem is not with all NATs, > and anyway, not all circumstances inevitably involve the presence > of a NAT. So surely there will be some deployments using the > deprecated feature that are operating just fine and will find this > deprecation at least inconvenient. > > You can probably resolve this by adding a short section on > backwards compaitiblity noting: > - that deprecation means that new implementation MUST NOT, > but that existing implementations MAY continue > - that new implementations SHOULD continue to receive and > process Robert has explained to me that the problem being fixed is basically one that the entired deployed codebase has found and avoided. Therefore there is no risk of backward compatibility issues. That's enough for me to clear my Discuss, but maybe the issue could be addressed with a couple of lines of text, so I'll leave this Comment in place.
(Stephen Farrell) (was Discuss) No Objection
Comment (2013-02-28 for -01)
No email
send info
send info
- The RFC editor note on the privacy considerations is good, thanks. - I had a security discuss on this draft but Robert convinced me there was no problem so I'll record it here as a comment. The potential problem would be if a bad actor could ask about flows and received "no information" for non-existent flows but "unauthorized" when the bad actor stumbled onto an existing flow. Robert told me that in that case the bad actor will get "unauthorized" all the time so its not a problem. - general: how (if at all) would this be affected by shared address space? (I ask since you say this is motivated by CGNs.) - section 3: Interesting that the example on p5 looks like its not something from which you could (by itself) determine a specific location. Where does it explain how you could determine a location based on that info? - section 3: I was confused on 1st reading by the last para here - I thought you were saying that the src/dst elements from the example were attributes, might be worth saying that src is both an element name and an attribute value or something. - 4: The "layer3" attribute just seems broken since it assumes both ends of the flow are using the same address family and they might not. - 4: I guess the layer4 attribute might be broken by an ALG. I'm also not sure how tcp or udp will really help there. - 4: What'd you put in layer4 if using e.g. SCTP/UDP? Don't you need to say? - 4: I don't get what it might mean if I put in number for a port that's usable with either tcp or udp, e.g. 53. Its just hard to believe there are no tricky combinations based on use of port numbers that'd need explaining. I've gotta say: given the above comments, and that this is deprecating a feature from a pretty recent (2011) but presumably now known-faulty RFC, and that there are no known implementations (inferred from the write-up), and that this'll be referenced from other "national" specs, I'd be quite nervous that this isn't fully baked and might have to be fixed yet again after someone does write code and try it out.
(Brian Haberman) No Objection
(Russ Housley) No Objection
(Barry Leiba) No Objection
(Pete Resnick) No Objection
(Martin Stiemerling) No Objection
Comment (2013-02-26 for -01)
No email
send info
send info
In support of Stephen's DISCUSS points abut security and privacy, i.e., I did also wonder if nothing has really changed.
(Sean Turner) No Objection
Comment (2013-02-28 for -01)
No email
send info
send info
I support Stephen's discuss.