Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-18

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.

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/

Curious to hear the response to Stephen's question.

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.