Re: [netlmm] Last call for draft-ietf-netlmm-lma-discovery-03

["Charles E. Perkins" <[e-mail]>]

Hello Jonne,

Below, please find the rest of my comments on this document.

=========================================================================

"In a case" --> "If"

>                                        IKEv2 could be
>    existing example of such lower layer signaling when IPsec
>    is the "lower layer" for the MN.

This is confusing.  Why not have a section entitled something
more properly descriptive?  One suggestion:

"Security Procedure Assistance for Constructing the LMA FQDN"

IPsec isn't a "lower layer", and trying to make it
so is very likely to have unwanted effects that will
require various convoluted explanations.

> MN has no knowledge it being anything LMA related.

--> MN does not associate the information with any LMA function.

>    Some network access technologies (including tunneling solutions)
>    allow the MN to signal the service name that identifies a particular
>    service or the external network it wants to access.

Citations needed for both access technologies and tunneling
solutions.

>               .....   The pre-defined formatting rules are usually
>    agreed on among operators that belong to the same inter-operator
>    roaming consortium ...

Citations needed.

>               .....    network infrastructure vendors defining an
>    open networking system architecture.

I sure wish they would.  They've had 15 years since
Mobile IP was standardized and no luck yet.


"A number of LMA discovery" --> "Some LMA discovery"

"caching of DNS responses effectively delay"
--> "caching of DNS responses effectively delays"

"caching times out" --> "cached data times out"

"Obviously, too low" --> "Low"
- "Obviously" is a red flag word
- "too low" ... as measured by what standard?

"Another alternative could that MAG uses, for example,"
--> "Alternatively, the MAG could use (for example)"

"(assuming the MAG has e.g.
    learned a group of LMA FQDNs via SRV [RFC2782] query)"
Shouldn't this solution be described in a previous
section, like the other solutions?

>    Once the MN completes its initial attachment to a PMIPv6 domain, the
>    information about the LMA that is selected to serve the MN is stored
>    in the Policy Store (or the AAA server).  The LMA information is
>    conveyed to the policy store by the LMA after the initial attachment
>    is completed [I-D.ietf-dime-pmip6].  Typically AAA infrastructure is
>    used for exchanging information between the LMA and the Policy Store.

Here is another reference to the Policy Store.  But it
really boils down to provisioning.  So it would be better
to avoid referencing Policy.

Isn't it dangerous to have the MN's IP address potentially
routed to any one of several LMAs?  Or, if the MN's IP address
determines the LMA, why not return the single LMA that routes
the IP address given to the MN?

The suggested approach seems far more complicated than
necessary.

"the MAG and the LMA belong belong to the same PMIPv6 domain"
-- Was this ever stated in the preceding part of the document?

=========================================================================

Regards,
Charlie P.