[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt



 

 


From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Friday, October 06, 2006 10:35 AM
To: Chowdhury, Kuntal
Cc: radiusext@ops.ietf.org
Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt

 

Hi Kuntal,

Comments inline.

 

Regards,

 

--behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: radiusext@ops.ietf.org
Sent: Thursday, October 5, 2006 11:23:33 PM
Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt

I don’t know at what stage we are in with respect to this draft, but it seems that the draft lacks a description of the use case that it is trying to address. The introduction seems to be conveying very little about the motivation for this document:

 

“  

The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an

   IPv6 prefix to be delegated to the user, for use in the user's

   network. 

 

Comment: Delegated-IPv6-Prefix is NOT a RADIUS attribute that is defined in reference [1] i.e. RFC 2865. If it was, we would not need this document.

==> True. So I suggest  the following fix:

The Delegated-IPv6-Prefix is a new RADIUS [1] attribute that carries an ...

[KC>] Ok, but I still think referencing RFC 2865 in the above sentence is odd. A _new_ attribute cannot be in an RFC unless the RFC is revised. This is just an editorial nit, IMHO.

 

For example, the prefix in a Delegated-IPv6-Prefix

   attribute can be delegated to another node through DHCP Prefix

   Delegation [2].

Comment: If prefix delegation by DHCP as described in RFC 3633 already exists, then why we need another mechanism? RFC 3633 has figure 1 which shows the prefix delegation scenario.  I request that the authors clarify using this figure where the RADIUS transaction with this attribute applies.

 ==> I think you missed the point with this whole draft.

 

[KC>] Since you seem to have understood the point in the draft very well, why don’t you help me understand it? In RFC 3633 there are several entities shown in fig 1, ISP, Aggregation Device (delegating router), CPE (requesting router), and Subscriber PC.  So, we need to know how this RADIUS draft fits into this scenario. Where is the RADIUS Client? If it is the Aggregation Device why is it outsourcing the prefix management to a RADIUS server? What is the motivation for doing this? Is the motivation to avoid prefix provisioning in the Aggregation Device? Does the Aggregation Device have a NAS that performs user auth/authz. What is the user? Is it one of the Customers PC or is it the CPE (requesting router)?

 

The text in this draft SHOULD clarify the use case.

 

-Kuntal

 


From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, October 03, 2006 5:04 PM
To: ' Behcet Sarikaya '
Cc: radiusext@ops.ietf.org
Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt

 

In RADIUS/Diameter Accounting messages announce both the beginning and end of a session.

 


From: Behcet Sarikaya [mailto:behcetsarikaya@ yahoo .com]
Sent: Tuesday, October 03, 2006 2:05 PM
To: Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt

 

Hello Bernard, I agree with your changes, please also add this typo too:

The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:
->The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:

Is session termination communicated with Accounting Request message in Radius/Diameter?

 

Thanks,

 

Behcet

----- Original Message ----
From: Bernard Aboba < bernard_aboba@hotmail.com >
To: radiusext@ops.ietf.org
Sent: Tuesday, October 3, 2006 3:21:42 PM
Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt

A new version of the Delegated Prefix attribute has been posted to the
archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt

This document has already gone through IESG review, so it is one step away
from publication.

Can people take a look at it?

I found one typo, in Section 5:

   The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:

                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|    |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   Framed-IPv6-      97  6.11.6  OctetString| M  |  P  |    |  V  | Y  |
     Prefix                                 |    |     |    |     |    |


Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix;
the AVP should be TBD instead of 97, and the Section Defined entry should be
deleted.

One other quibble.   In Section 1, it is stated:

"   The Framed-IPv6-Prefix attribute [4] is not designed to carry an IPv6
   prefix to be used in the user's network, and therefore Framed-IPv6-
   Prefix and Delegated-IPv6-Prefix attributes may be included in the
   same RADIUS packet."

It strikes me that this statement is not necessarily accurate.  For example,
if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix
attribute *could* be used to carry an IPv6 prefix to be used in the user's
network.  However, if we are talking about a router, then this will not
work.  So I think the sentence should be changed to:

"  The Framed-IPv6-Prefix attribute [4] is not designed to support
delegation of prefixes to
   be used in the user's network, and therefore Framed-IPv6-Prefix and
Delegated-IPv6-Prefix
   attributes may be included in the same RADIUS packet."



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

 

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."