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

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 06 May 2010 11:54:15 -0700

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.

---

From: "Soininen, Jonne (NSN-FI/Espoo)" <[email-masked]>
Date: Fri, 07 May 2010 18:38:25 +0300

Charlie,

[snip]
> has come to get it over with...(??)

The reason here was that we have once already had a last-call on the
document, but we didn't get any comments. That was at the time there was a
lot of other things to discuss and the concentration was somewhere else.
Basically that last call failed due to lack of comments.

The authors have now asked for comments to finalize the document, and there
seems to be interest to finalize it in the WG. This is a right time for a
LC.

I agree with you that usually getting comments on a document is a sign that
the document is not ready. However, when you already have had a failed last
call due to the _lack_ of comments, actually getting reviews is a good
thing!

BTW, thank you for your review!

Cheers,

Jonne.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 May 2010 12:41:41 -0700

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.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 12 May 2010 21:57:14 +0300

Hi Charlie,

Responses inline.

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

OK.

> require various convoluted explanations.

I know it is not a "lower layer" per se. However, it is used more or less as such in certain systems architectures.

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

Ok. I like this wording.

> Citations needed for both access technologies and tunneling

Ok. I will add a reference to RFC4306 and 24.302.

>>   agreed on among operators that belong to the same inter-operator

Ok. Will add a reference to 23.003.

> Mobile IP was standardized and no luck yet.

;)

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

OK.

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

OK.

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

OK.

> "Obviously, too low" --> "Low"

OK.

> - "too low" ... as measured by what standard?

Good concern. I'll remove "obviously".

> --> "Alternatively, the MAG could use (for example)"

OK.

> section, like the other solutions?

Hmm.. could be. However, I rather keep it here.

> to avoid referencing Policy.

Policy Store is RFC5312 terminology.. and used to hold above information.

> The suggested approach seems far more complicated than

Once the LMA has been selected, the MN is assigned with its HNP by the selected LMA. I don't see a problem here.

> -- Was this ever stated in the preceding part of the document?

s/belong belong/belong

The PMIPv6 domain assumption comes as-is from RFC5213.

Thanks again,
	Jouni

> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 May 2010 09:20:48 -0700 (PDT)

Hi Jouni,

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

;)

OK.

> Hmm.. could be. However, I rather keep 

Why?
Is it related to LMA discovery using SRV RRs?

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

>Policy Store is RFC5312 
> terminology.. and used to hold above information.

It is curious, there is no RFC numbered 5312?

Regards,

Behcet

---

From: Jouni <[email-masked]>
Date: Mon, 17 May 2010 20:33:24 +0300

Hi Bechet,

> It is curious, there is no RFC numbered 5312?

oops.. typo. Naturally meant 5213.

- Jouni