Re: [netext] Review of draft-ietf-netext-radius-pmip6-01

["Damic, Damjan" <[e-mail]>]

Hello Glen,

Please accept sincere appologies for a long, long overdue response, but
this work was on hold for a while.
A new I-D revision has just been published, and your valuable comments
have been taken into account.

- Please mark this I-D is the RADIUS counterpart and a follow-up of the
RFC5779 that deals with Diameter support for PMIPv6. The AAA concept and
fundamentals are pretty much inherited or slightly redefined for the
RADIUS use case.

- Terminology issues, grammar nits and other consistency flaws are
hopefully corrected. Everything however spins around the mobility
protocol Proxy Mobile IPv6 and we have to retain this focus including
use of the rather explicit jargon.

- A point was raised on suspected ambiguity in the functional split
definitions. Some real world deployments that actually drive this
publication do allow such variations in the architecture. We are trying
not to rule them out by this general purpose I-D write up.

- Remark to the scope is valid. Obviously the aim is to provide more
then just attribute listing, and I agree there may be room for further
improvements.

Thank you.
Damjan


-----Original Message-----
Date: Sun, 2 Jan 2011 13:08:09 +0700
From: "Glen Zorn" <[e-mail]>
Subject: [netext] Review of draft-ietf-netext-radius-pmip6-01
To: <[e-mail]>
Message-ID: <000001cbaa43$705b1820$51114860$@net>
Content-Type: text/plain;	charset="us-ascii"

There are many grammatical errors.  For example, in the very first
sentence
of section 1

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility
   management protocol which allows IP mobility session continuity for a
   Mobile Node (MN) without its involvement in mobility management
   signaling.  

This should read something like

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility
   management protocol which allows IP mobility session continuity for a
   Mobile Node (MN) without its involvement in mobility management
   signaling.  

However, this still reads pretty clumsily; in particular, it's difficult
for
me to tell which entity "its" refers to and the usage of "network-based"
is
jargon that only has meaning if one is already familiar with PMIP; since
this draft is presumably aimed at RADIUS implanters, I think it would be
good to avoid as much PMIP-specific jargon as possible.  Similarly, the
terms "download" and "interface" are used repeatedly.  "Download" has
AFAIK
no meaning WRT to RADIUS and "interface", while "real 3G" is also not
particularly useful in this context.  For example, Section 1 says:

   This document defines the RADIUS [RFC2865] based profile and the
   corresponding attributes to be used on the AAA interface between the
   MAG and the RADIUS server.  This interface is used to download the
   per MN Policy Profile from the remote Policy Store to the MAG, at the
   point when MN attaches to a PMIPv6 Domain. 

I suspect that what this means that the per-MN profile is returned in a
RADIUS Access-Accept message encapsulated in the Attributes defined by
this
draft (and I shouldn't need to guess).  The same section continues:

   Furthermore, this document also defines a RADIUS-based interface
between
the LMA and 
   the RADIUS server for authorization of the received Proxy Binding
   Update (PBU) messages for the mobility service session.  

Actually, it doesn't: some Attributes are defined, but how they are used
is
left almost completely unspecified.

The statement that "The terminology in this document is based on the
definitions found in   [RFC5213] and
[I-D.ietf-netlmm-pmip6-ipv4-support]"
in Section 2 strongly suggests that the reader must have read and
understood
draft-ietf-netlmm-pmip6-ipv4-support and that, therefore, that draft
would
be a normative reference but it's not.

In Section 2, the definition of "Network Access Server (NAS)" says

      A device that provides the access service for a user to a network.
      In the context of this document the NAS may be integrated into or
      co-located with the MAG.  The NAS device contains the RADIUS
      Client function.

What happens in the context of this document if the NAS is _not_
integrated
or co-located with the MAG?  Since the statement is that the NAS
"contains
the RADIUS Client (sic) functionality", my guess is nothing ;-).
Similarly,
even if the MAG and NAS are co-located, unless they communicate nothing
will
happen. Furthermore, Section 3 says that the MAG 'acts as a NAS', which
seems more accurate but isn't the same as 'integrated with' or
'co-located
with'.  I _think_ that what is really meant is that the MAG acts as a
RADIUS
client, but it's really hard to tell...

I could go on at (much) greater length, but basically this draft either
a)
says too much (i.e., claims to provide a "solution" while just doing a
lot
of hand-waving) or b) says way too little for the same reason.  My
suggestion would be to either a) get rid of the "solution" stuff and
_only_
define the needed Attributes or b) actually describe how these
Attributes
are to be used in detail.