Subject: Re: [netlmm] Working Group Last Call: draft-ietf-netlmm-lma-discovery-02

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 17 Nov 2009 11:23:16 -0800

All,
This WGLC has had zero comments so far and we cannot progress the document to the IESG in its current state.  I am extending the last call on this document until Nov 25, 2009.  If you think the document is complete and is ready to be sent to the IESG, please state so on the mailing list.  Or, if you have comments, please post a review.  If we get no responses, we will be forced to drop the document. 

Thanks,
Vidya

-----Original Message-----
From: Soininen, Jonne (NSN - FI/Espoo) [mailto:[email-masked]] 
Sent: Wednesday, October 28, 2009 5:36 PM
To: Narayanan, Vidya; [email-masked]
Subject: Re: [netlmm] Working Group Last Call: draft-ietf-netlmm-lma-discovery-02

Hello,

I would like to remind people of this last-call and to comment the draft.

Cheers,

Jonne.

On 10/23/09 2:16 AM, "Vidya Narayanan" <[email-masked]> wrote:

> All,
> This is a working group last call for the LMA discovery document
> (http://tools.ietf.org/html/draft-ietf-netlmm-lma-discovery-02).  Please
> review and send your comments to the mailing list by November 6, 2009.
> 
> Thanks,
> Vidya
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: <[email-masked]>
Date: Tue, 17 Nov 2009 22:40:09 +0100

Hello,

I have reviewed the I-D: LMA Discovery for Proxy Mobile IPv6
<draft-ietf-netlmm-lma-discovery-02.txt> and my comments are as
follows:

1. s/Large Proxy Mobile IPv6 deployments would benefit from a
   functionality, where a Mobile Access Gateway could dynamically
   discover/Large Proxy Mobile IPv6 deployments would
   benefit from the functionality which enables a Mobile Access Gateway
   to dynamically discover

2. Clarify what is meant by:
   "selecting LMA based on desired services (i.e. allowing
   service-specific routing of traffic)."

3. s/There are a number of different ways for dynamically discovering the
   LMA at the MAG/There are a number of different ways for dynamically
   discovering the LMA to be assigned to an MN at the MAG.

4. s/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./The LMA discovery mechanism used by
   the new MAG MUST be able to return the information about the same
   LMA that was used by the old MAG w.r.t the MN.

5. s/is typically required to authenticate to the network access
   and/is typically required to authenticate with the access network
   and

6. s/for the network access/for network access

7. In Sec 2. (AAA based discovery) it would be good to add a sentence
   that the address of the LMA to be assigned to the MN is included in
   the policy profile that is downloaded to the MAG.

8. s/authenticated for the network access/authenticated for network
   access
    
9. s/might be a generic/may be generic

10. I-D states:
"   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."

   Is the LMA updating the policy store? And what procedure exists to
   perform such an update? Should there be a reference to some
   Diameter specification for this?

11. s/from lower layers below the IP layer/from lower layers, i.e
    below the IP layer

12. s/These solution/This solution

13. Section 3 is discussing lower-layer solutions. The same section
also includes the following text:
"and tunneling solutions such as IKEv2 [RFC4306] IPsec tunnel
[RFC4303]."

IKEv2 and IPsec are not lower layer solutions. Hence the text in the
section needs to be rephrased.

14. s/as a result of the network access attachment procedure/via the
    network access attachment procedure.

15. Section 3.2 needs to be explained a bit further to make it
    understandable by readers not familiar with APN and 3GPP
    architectures.

16. In section 4, it would be useful to mention the type of DNS
    records that are returned to the MAG as a result of a
    query. 

17. s/is not generally a working solution/is generally not a good
    solution

18. "the situation might not be this desperate."
    desperate??? Really?

 In summary, I believe the I-D is ready to be progressed after at
 least one more revision that would take care of the above comments
 and any others.

-Basavaraj

On 11/17/09 2:23 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> All,
> This WGLC has had zero comments so far and we cannot progress the document to
> the IESG in its current state.  I am extending the last call on this document
> until Nov 25, 2009.  If you think the document is complete and is ready to be
> sent to the IESG, please state so on the mailing list.  Or, if you have
> comments, please post a review.  If we get no responses, we will be forced to
> drop the document.
> 
> Thanks,
> Vidya