Diameter Support for Proxy Mobile IPv6 Localized Routing
Note: This ballot was opened for revision 10 and is now closed.
(Benoît Claise) Yes
(Dan Romascanu) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) (was Discuss) No Objection
Comment (2012-07-16 for -15)
Thanks for addressing my remaining Discuss and Comment positions. I've cleared my Discuss. One remaining non-blocking comment: In the abstract, I suggest s/In Diameter Proxy Mobile IPv6/In a Proxy Mobile IPv6 deployment/
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
Comment (2012-02-14 for -)
A question and two comments, that could become discusses, depending on the answer to the question. At present, I'm not sure if there is a real issue here or not. There could be a use-case where the MN's MAG is under the MN's control. If there were, or if a MAG were compromised, or a bad-actor, then this protocol could be used to track any participating CN (whose address is known) at the level of the MAG to which it is anchored, but I'm not sure how much of a concern that ought be. Note: I think (but am not sure) that this is different from a "normally" bad MAG in most of pmipv6, in that it could impact on a whole bunch of CN's and not just on the MN anchored to the bad-MAG. So, the question: How fine-grained a location would me knowing your current MAG give me and is such potential tracking by a bad-MAG a concern? 1. If this is a concern maybe it'd be useful to add something like the following to the security considerations: "An authorised MAG could in principle track the movement of any participating CN at the level of the MAG to which they are anchored. If such a MAG were compromised, or under the control of a bad-actor, then such tracking could represent a privacy breach for the set of tracked CN's. In such a case the traffic pattern from the compromised MAG might be notable so monitoring for e.g. excessive queries from MAGs might be worth while." 2. Assuming again that the answer to my question is that it is a concern, ought there be some way in which e.g. MN2 in figure 6 could be part of the authorisation process for this kind of feature? Perhaps one could note that deployments that wanted to be privacy friendly could provide some way to allow for a user to consent to this? And going further of course any such consent might change over time I guess.
(Russ Housley) (was Discuss) No Objection
(Pete Resnick) No Objection
(Peter Saint-Andre) No Objection
Comment (2012-02-15 for -)
The term "Fully Qualified Domain Name" is undefined (specifically, it's unclear whether internationalized domain names are supported), but it appears that's the fault of RFC 5779 and RFC 5447.
(Robert Sparks) (was Discuss) No Objection
(Sean Turner) No Objection
Comment (2012-02-15 for -)
Curious to hear the response to Stephen's question.