[netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)

[<[e-mail]>]

Hello,

A few comments regarding this I-D before it is ready to be sent to the
IESG:

1. The abstract is very poorly written. It simply says "This I-D
defines X and Y and Z". It would be preferable to have a real abstract
which states that the PMIP6 uses Radius based interfaces between:
- the MAG and the AAA server
- the LMA and the AAA server
which are used for authentication, authorization and policy functions.

Please update the abstract. In fact part of the 1st paragraph of the
Intro section can be used in the abstract.

2. 

s/In the context of this document, the NAS function is logically
coupled with the MAG./This document makes an assumption that the NAS
function is co-located with the MAG.

s/In deployments where the NAS function and the MAG functions are
decoupled, the specific interactions needed for that to work is
outside the scope of this document./In scenarios where the NAS
function and MAG are decoupled, the messaging interface needed between
them for the operation of PMIP6 is beyond the scope of this document.

3. 
s/Any time a mobile node attaches to an access network/When a mobile
node attaches to an access network

4. In Section 3:
Q: The I-D says: "If the network access authentication succeeds, the
MN is identified " 

The MN identity is already known as part of access authentication. The
above sentence implies that only of network authentication succeeds,
MN identity is known. You may want to rephrase.

5. 
s/access authentication procedure SHALL provide/access authentication
procedure SHOULD provide

(In IETF parlance, we use MUST, SHOULD and MAY)

6. 
"After the successful network access authentication and after
   obtaining the mobile node's Policy Profile, the MAG sends a PBU to
   the LMA."

Rephrase and avoid using After multiple times in the same sentence.

7. 
s/needed for authorizing and setting up the mobility service./which is
required for authorizing and activating mobility service.

8. In Section 4.2
Q: The I-D states: "If the MAG has not acquired a valid MN-Identifier by
other
   means, it MUST use the received MN-Identifier."

How else would the MAG get the MN-ID?

9. In section 4.3:
Q: I-D states: "The MAG MUST include the Service-Selection attribute
in the Access-Request sent to the AAA if the information was
acquired."

How does the MAG obtain the service selection attribute? It needs to
be explained. Because if the MAG is going to populate this attribute
in the Access-Request message, it MUST have obtained that parameter
somehow. 

10. 
s/The AAA MAY
   return the Service-Selection to the MAG even if it was not included
   in the Access-Request as means to indicate MN's default service to
   the MAG./
The AAA MAY include the Service-Selection attribute in the
Acess-Accept response message to the MAG even if it was not included
in the Access-Request as a means of indicating the MN's default service.

11. In sec 4.3 I-D states:
"On the LMA-to-AAA interface, the LMA MAY populate the Service-
   Selection attribute in the Access-Request message using the service
   information found in the received PBU, if such mobility option was
   included."

In which I-D or RFC is the service-information option that can be
carried within a PBU specified?

12. 
s/Before the MAG can engage in Proxy Mobile IPv6 signaling/Before the
MAG can initiate Proxy Mobile IPv6 signaling

13. 
s/PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
   to VAAA in the RADIUS Access-Request packet as a proposal to allocate
   the particular LMA to the MN./
PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
   to the VAAA entity in the RADIUS Access-Request message. It enables
the MAG to request an LMA in the visited network.

Q: How does the MAG decide if it is authorized to request an LMA in
the visited network? Needs to be explained.

This comment also applies to Sec 4.7

14. Sec 4.10:
"For Proxy Mobile IPv6 the Home Network Prefixes assigned to the
   mobile node have to be maintained on a per-interface basis.  When the
   LMA is located in the home network, PMIP6-Home-Interface-ID attribute
   conveys 64 bits interface identifier representing a particular MN's
   interface.  The attribute is assigned by the HAAA to the MAG for
   derivation of the MN-HoA.
"

Is it the MNs interface ID that is being sent? The description in this
section is not clear.

15. Sec 4.18   

Which specific attribute defined in RFC5213 are you suggesting as the
one to be used for the Calling-station-ID. RFC5213 itself does not
mention any such attribute in the nomenclature.

16. Sec 7.1/2

Does this I-D mandate the MAG and LMA entities to do metering of
traffic associated with an MN? RFC5213 itself does not require such
functionality. You may want to make this clear in these sections.

17. The security section needs to be further improved. What are the
types of threats associated with sending MN specific information
between the MAG and AAA server; And between the LMA and AAA server.
The current security considerations section is lacking in detail.

-Basavaraj