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

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

Hello Jonne,

Below, please find some initial comments on this document.
I think it needs at least one more revision, which should
be preceded by close proofreading.  I'll send more comments
later.  But first I am curious about your sentence:

On 4/29/2010 1:16 AM, Soininen, Jonne (NSN-FI/Espoo) wrote:

> As it seems that new reviews are coming to the document,
> it would be time to get this document over with.

Usually, when a document gets more and more comments,
it's not taken as any good indication that the time
has come to get it over with...(??)

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

About the document:

"selecting LMA" --> "selecting a LMA"
BUT:
"selecting {a} LMA based on desired services"
-- are these extensions defined anywhere in
    IETF documents?  If so, please provide
    relevant citations.

"a number of" --> "several"

"a number of different ways" --> "various ways"
-- anyway, in this context no one would
    say "a number of identical ways"
-- and moreover the entire sentence should
    be deleted.

"discussed in this specification" -->
	"discussed in this document"

I don't think the document is really intended
to be a full-blown specification.

"LMA Address" --> "LMA IP address"

"LMA FQDN or IP address received from the lower layers during the
       network attachment followed by an optional DNS lookup."
-- This sentence is wrong, because if the lower layer provides
    an IP address, the DNS lookup would not happen.  And if the
    lower layer provides the FQDN, it's an interesting discussion
    about why the DNS lookup is suddenly optional.

 >  When a MN performs a handover from one MAG to another, the new MAG
 >  must use the same LMA that the old MAG was using.  This is required
 >  for session continuity.  The LMA discovery mechanism used by the new
 >  MAG should be able to return the information about the same LMA that
 >  was being used by the old MAG.  This document also discusses
 >  solutions for LMA discovery during a handover.

I'm surprised to see this.  Wasn't it considered controversial?

"support PMIPv6 functionality" --> "support PMIPv6"

I think this document does not need to use any
instances of the ?word? "functionality", which leads
to additional, extraneous, excessive, unwarranted
verbosity.  A bit too much, eh?  Oh, and did I
mention ...?

"to authenticate to the network access" -->
"to provide authentication for network access"

"the mobility services" --> "mobility services"

"the Policy Profile download"
(a) if you want this included, a citation is needed.
(b) but why even bring up policy management?  It's
     not germane to the solution except tangentially
     insofar as AAA is often also part of policy
     management.
(c) it would be easy to argue that this procedure is
     NOT very much like RFC 5447.  How is this helping
     to illustrate the solution?

 >  This solution is identical to the procedure described in Section 2.1.
 >  The difference is

Well, it's either identical or it's not.  How about
"similar"?

"LMA IP address(es)":
-- Please describe in more detail.  Is it proposed to
    use DNS to supply IP addresses for multiple independent
    hosts?  What are the security implications?  Shouldn't
    this be done by use of an anycast address?
-- The following discussion indicates that any such
    multiplicity of IP addresses supplied for the LMA
    creates the need for a new selection algorithm to
    find the "right" LMA.  Why is this a good idea?

 >         ...         For example, the AAA server might return a generic
 >  LMA FQDN during the MN initial attach and once the LMA gets selected,
 >  return the LMA IP address during the subsequent attachments to other
 >  MAGs in the PMIPv6 domain.  In order for this to work, the resolved
 >  and selected LMA IP address must be updated to the remote Policy
 >  Store.  For example, the LMA could perform the update once it
 >  receives the initial PBU from the MAG for the new mobility session.

(a) It isn't at all clear why Policy Store updates are a
     necessary precondition for this -- unless of course you
     generalize the meaning of Policy Store beyond all useful
     recognition
(b) And anyway why bring it up?
(c) How does the LMA get selected?
(d) What update does the LMA perform?
(e) Is this discussion in any way important for someone
     to understand how to resolve a FQDN for the LMA?

"Lower Layers based Discovery Solutions" -->
"Discovery Solutions based on Data from Lower Layers"

"These solution could essentially" -->
"These solutions could essentially" -->?
"These solution could"
<why "essentially"??>

"without the AAA" ->> "without any AAA"

"mobile node Identity" --> "Mobile Node Identity"

"equals to the" --> "equals the" --> "is the same as"

"MAG receives" --> "MAG may receive"

 >                         (or actually the subscription identity
 >    but from now on we assume that the MN identity equals to the
 >    subscription identity, which is a rather broad simplification)

Since the subscription identity _is_ one of the
identities of the MN, this parenthetical comment
is not needed.  And, anyway, you didn't define
subscription identity.  You don't need to do that.
I don't see how it would help the explanation.

"information elements that can be extracted and at
    minimum used"
-->
"information that can be used"

 >              Thus the MN identity in this solution cannot be a "flat"
 >  identity without any structure and "clear text" parts containing the
 >  hosting entity information.

This sentence should be deleted.  And, anyway, it is
by no means required that the information which
identifies the hosting entity has to be in clear text.

"operator owning the given subscription"
-- I thought the subscriber owned the subscription.
    O.K... perhaps operators act like they own the
    subscriber, but still I must protest.

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

Regards,
Charlie P.