[Dime] Review of draft-korhonen-dime-pmip6-03.txt

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

A few review comments. 

In the abstract you write:

"
Rather than defining a completely new set of
   attributes or a new Diameter application this specification leverages
   the work that has already been done for the Mobile IPv6
   bootstrapping.
"

This sentence is somewhat misleading since you define a Diameter
application. 

Figure 1 is helpful but I think you could point out that you are
actually describing two  different "interfaces" in this document. I
initially did not got that point since you  referred also to the
Diameter Mobile IPv6 boostrapping work where we separated them into 2
documents. 

Hence, I would enhance the figure with something like: 


   +--------+
   | HAAA & | Diameter +-----+
   | Policy |<--(1)--->| LMA |
   | Profile|          +-----+
   +--------+             | <--- LMA-Address
        ^                 |
        |               // \\
    +---|------------- //---\\----------------+
   (    |  IPv4/IPv6  //     \\ Proxy Mobile IPv6
   (    |   Network  //       \\               )
    +---|-----------//---------\\-------------+
        |          //           \\
    Diameter      // <- Tunnel1  \\ <- Tunnel2
      (2)        //               \\
        |        |- MAG-Address1   |- MAG-Address2
        |     +----+             +----+
        +---->|MAG1|             |MAG2|
              +----+             +----+
                 |                 |
                 |                 |
               [MN1]             [MN2]


  Legend:

    (1): LMA <-> HAAA interaction is described
         in Section 6
    (2): MAG <-> HAAA interaction is described
         in Section 5


* I was also lacking sementic of the PMIP6-DHCP-Address AVP a bit. 
How does the information flow look like? 


*  MIP6-Agent-Info AVP

The description currently does not provide enough information why this
AVP is needed. 
What happens when an entity receives this AVP? 
Why would one send it? 

I also wonder whether it wouldn't make sense to create a new AVP if the
semantic is sufficiently different.


* MAG-to-HAAA:

You might want to make it explicit in the text that you do not define a
new Diameter  application for this interface. The LMA to HAAA section
starts very similar but defines a new 
Diameter application. Both sections say "This document re-uses the
Diameter NASREQ [6] and the EAP [7]
applications". While this is correct the outcome is very different. 

I would also shorten the subject header a bit. Something like
"MAG-to-HAAA Interface" and "LMA-to-HAAA Inferface" should be
sufficient. 


The following text seems a bit fuzzy to me: 

"
   The Diameter response messages MAY contain Framed-IPv6-Prefix and/or
   Framed-IPv4-Address AVPs.  For example a local Diameter proxy MAY add
   those in order to advertise locally available prefixes and addresses
   as well [16].  It is also possible that PMIPv6 mobility support is
   not allowed for a subscription.  In this case, a MAG may still
   provide normal IP connectivity to the MN using, for example, local
   address pools.
"

What is the semantic of the Framed-IPv6-Prefix in relationship to the
other 
addresses being defined in this document?


* LMA-to-MAG

The text at the beginning of the sentence is repeated again in Section
6.2. 


You write:

"
The identity SHOULD be the same as
   used on the MAG to HAAA interface, but in a case those identities
   differ the HAAA MUST have a mechanism of mapping the MN identity used
   on the MAG to HAAA interface to the identity used on the LMA to HAAA
   interface.
"

In what cases are they different? 

You write: 
"
   If the PBU contains the MN interface identifier option, the Calling-
   Station-Id AVP SHOULD be included in the request message containing
   the received interface identifier.  Furthermore, if the PBU contains
   the Service Selection mobility option [18], the Called-Station-Id AVP
   SHOULD be included in the request message containing the received
   service identifier.
"

Why do you overload the Called-Station-Id? 
Are those the only two cases, i.e., is it MUST contain either interface
id or service identifier?

In the introduction you say that this is only used for authorization,
see:
"
A new Diameter application is needed for the LMA to HAAA interface
   when authorizing Proxy Binding Updates and subscriber's mobility
   service session.
"

Does this mean that you set the request to 'authorize-only'?

* AVP Occurrence Table section

I would define separate AVP flag tables for the two interfaces and for
the commands. 

For example, in Section 6.2 you define this new application; do you
expect certain AVPs to be understood by the receiving end? 

Ciao
Hannes

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime