Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-flow-identity-02

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.

In support of Stephen's DISCUSS points abut security and privacy, i.e., I did also wonder if nothing has really changed.

I support Stephen's discuss.

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