Subject: [netext] Review of draft-ietf-netext-radius-pmip6-02

From: Pete McCann <[email-masked]>
Date: Thu, 14 Apr 2011 15:47:38 -0500

Here is my review of draft-ietf-netext-radius-pmip6-02:

Overall, this looks like a straightforward re-use of the
ideas from RFC 5779, so I don't have any major issues.
The one point I will note is that this specification proposes
to allocate 17 new RADIUS Attribute Types, out of a
possible 48 remaining unassigned.  I wonder if the ADs
will look kindly on this.  Perhaps you could have been a
bit more parsimonious with new attribute types as many
seem to be related and could possibly be combined, with
flag values indicating what the AVP contains.

Some editorial comments:

Section 4.19:
   if it was no included
SHOULD BE:
   if it was not included

Section 5.1:
   AVPs are also concerened
SHOULD BE:
   AVPs are also concerned

Section 7.2:
   over tge bi-directional
SHOULD BE:
   over the bi-directional

---

From: xiayangsong <[email-masked]>
Date: Fri, 15 Apr 2011 23:07:07 +0000

Hi Pete

Thank your review, please check my inline response...

BR
Frank
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pete McCann
Sent: Thursday, April 14, 2011 1:48 PM
To: [email-masked]; [email-masked]
Subject: [netext] Review of draft-ietf-netext-radius-pmip6-02

Overall, this looks like a straightforward re-use of the
ideas from RFC 5779, so I don't have any major issues.
The one point I will note is that this specification proposes
to allocate 17 new RADIUS Attribute Types, out of a
possible 48 remaining unassigned.  I wonder if the ADs
will look kindly on this.  Perhaps you could have been a
bit more parsimonious with new attribute types as many
seem to be related and could possibly be combined, with
flag values indicating what the AVP contains.
Frank=>We firstly used flags for express more attributes.
However, we received reviews from other experts who
suggested that we should keep attributes straightforward enough.
Radext WG has been working on attribute field extension for
a while.  IMHO, we should not be worried about this issue.

Some editorial comments:

Section 4.19:
   if it was no included
SHOULD BE:
   if it was not included

Section 5.1:
   AVPs are also concerened
SHOULD BE:
   AVPs are also concerned

Section 7.2:
   over tge bi-directional
SHOULD BE:
   over the bi-directional

Frank=>We will correct these above next revision.
_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext