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

Hi Charlie,

Responses inline.

On May 7, 2010, at 10:41 PM, Charles E. Perkins wrote:

> Hello Jonne,
> 
> Below, please find the rest of my comments on this document.
> 
> =========================================================================
> 
> "In a case" --> "If"

OK.

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

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

> 
>> MN has no knowledge it being anything LMA related.
> 
> --> MN does not associate the information with any LMA function.

Ok. I like this wording.

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

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

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

Ok. Will add a reference to 23.003.

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

OK.

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

OK.

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

OK.

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

OK.

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

Good concern. I'll remove "obviously".

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

OK.

> 
> "(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?

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

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

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

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

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

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

s/belong belong/belong

The PMIPv6 domain assumption comes as-is from RFC5213.

> 
> =========================================================================
> 
> Regards,
> Charlie P.

Thanks again,
	Jouni

> 
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm