Subject: FW: RFC 3588 "aaas" Scheme: Feedback Needed!
From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 31 Oct 2006 14:15:28 +0200

Hi all,

Hannes has asked some implementors about aaas scheme. Does anyone else
have any info on implementations of this feature?

John

>I would like to solicit some feedback regarding the usage of 
>AAAS as defined in Section 4.3. of http://www.ietf.org/rfc/rfc3588.txt:
>
>"
>   "aaas://" FQDN [ port ] [ transport ] [ protocol ] "
>
>Questions:
>
>a) Who has implemented the "aaas" scheme?
>b) Who is using the "aaas" scheme?
>
>Ciao
>Hannes
>
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 30 Oct 2006 21:23:01 +0000
Content-class: urn:content-classes:message
Subject: IETF67 RADEXT Agenda Take Two
Date: Mon, 30 Oct 2006 16:22:26 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Agenda for the RADEXT WG Meeting at IETF 67
Tuesday, November 7, 2006, Morning Session I 0900-1130
Room Name: Harbor Island I

WGs meeting at the same time: widex, 16ng, trill, avt, dkim, ippm,
rserpool  

A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes)

B. Agenda Bashing

C. Milestone Status Review (5 minutes)

C.1  Discussion of RADEXT Crypto-Agility work item descriptive text.
(10 minutes)

D. Document Status

D.1  Documents with errata

D.1.1  RFC 4590 has an error in the IANA assignment for a RADIUS
Attribute Type ID.  Discuss whether this can be handled by an RFC Editor
Errata note, or whether it requires an RFC4590bis ID to correct the
error.
http://www.ietf.org/rfc/rfc4590.txt.  (TBD, 5 minutes)
 
D.2  Documents in IESG review

D.2.1  draft-ietf-radext-delegated-prefix-05.txt.  (TBD, 5 minutes)

D.3  Documents in Pre-WG review

D.3.1  NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt 

D.3.2  NAS-Traffic-Rule Attributes (Mauricio Sanchez, 15 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.tx
t 

D.3.3  Extended RADIUS Attributes (TBD, 15 minutes)
http://www.ietf.org/draft-lior-radius-attribute-type-extension-01.txt

General Discussion of Extended Attributes, using this draft as a
straw-man proposal. (WG at large, 30 minutes)

D.3.4  Issues & Fixes (Alan DeKok, 10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.txt

D.3.5  Additional IEEE802 Values for the NAS-Port-Type Attribute (Yan
Renxiang, 5 minutes)
http://www.ietf.org/internet-drafts/draft-yan-radext-port-type-01.txt

D.4  Documents requiring cross-WG review

D.4.1  RADIUS Mobile IPv6 Support (TBD, 10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt

E. Next Steps

E.1  Is it sufficient for the RADIUS Prepaid Attributes work to be
published as an Informational RFC, using Vendor Specific Attributes? (10
minutes)

E.2  The RADIUS WLAN Attributes work is waiting on a finalization of
requirements form IEEE 802.11r.  What should we do with this work item?
(5 minutes)

E.3  Do we need a BCP on attribute design for "classic attributes" or do
we only need a design guideline for "extended attributes"? (10 minutes)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 30 Oct 2006 19:58:19 +0000
Content-class: urn:content-classes:message
Subject: IETF-67 RADEXT Agenda Take One
Date: Mon, 30 Oct 2006 14:57:33 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Proposed Agenda for RADEXT at IETF-67.

Please comment.  BTW, it would be very helpful for attendees to have
read the relevant drafts.  Draft authors who are available to present,
please respond to the chairs, so that we can fill in the TBDs.

-----------------------------------------------------------------------
Agenda for the RADEXT WG Meeting at IETF 67
Tuesday, November 7, 2006, Morning Session I 0900-1130
Room Name: Harbor Island I

WGs meeting at the same time: widex, 16ng, trill, avt, dkim, ippm,
rserpool  

A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes)

B. Agenda Bashing

C. Milestone Status Review (5 minutes)

C.1  Discussion of RADEXT Crypto-Agility work item descriptive text.
(10 minutes)

D. Document Status

D.1  Documents with errata

D.1.1  RFC 4590 has an error in the IANA assignment for a RADIUS
Attribute Type ID.  Discuss whether this can be handled by an RFC Editor
Errata note, or whether it requires an RFC4590bis ID to correct the
error.
http://www.ietf.org/rfc/rfc4590.txt.  (TBD, 5 minutes)
 
D.2  Documents in IESG review

D.2.1  draft-ietf-radext-delegated-prefix-05.txt.  (TBD, 5 minutes)

D.3  Documents in Pre-WG review

D.3.1  NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt 

D.3.2  NAS-Traffic-Rule Attributes (Mauricio Sanchez, 15 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.tx
t 

D.3.3  Extended RADIUS Attributes (TBD, 20 minutes)
http://www.ietf.org/draft-lior-radius-attribute-type-extension-01.txt

General Discussion of Extended Attributes, using this draft as a
straw-man proposal. (WG at large, 30 minutes)
 
D.3.4  Issues & Fixes (TBD, 10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.txt

D.4  Documents requiring cross-WG review

D.4.1  RADIUS Mobile IPv6 Support (TBD, 10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt

E. Next Steps

E.1  Is it sufficient for the RADIUS Prepaid Attributes work to be
published as an Informational RFC, using Vendor Specific Attributes? (10
minutes)

E.2  The RADIUS WLAN Attributes work is waiting on a finalization of
requirements form IEEE 802.11r.  What should we do with this work item?
(5 minutes)

E.3  Do we need a BCP on attribute design for "classic attributes" or do
we only need a design guideline for "extended attributes"? (10 minutes)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Oct 2006 16:43:30 +0000
Content-class: urn:content-classes:message
Subject: RADEXT Crypto-agility work item
Date: Thu, 26 Oct 2006 10:39:08 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

At IETF-66, the RADEXT chairs took the action item to come up with some
charter text that would describe the scope of the crypto-agility work
item.

The following text is being proposed, after having been vetted by Russ
Housley, Security Area AD.

Please comment.  If this text is acceptable to the WG, we will propose
it to the O&M ADs for addition to the RADEXT charter.

<quote>

The RADEXT WG will review the security requirements for crypto-agility
in IETF protocols, and identify the deficiencies of the existing RADIUS
protocol specifications against these requirements.  Specific attention
will be paid to the requirements of draft-housley-aaa-key-mgmt-04.txt.

The RADEXT WG will propose one or more Internet Drafts to remediate any
identified deficiencies in the crypto-agility properties of the RADIUS
protocol.  The known deficiencies include the issue of negotiation of
substitute algorithms for the message digest functions, the key-wrap
functions, and the password hiding function.  Additionally, at least one
mandatory to implement algorithm will be defined in each of these areas,
as required.

</quote>

Regards,
 
Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Oct 2006 12:37:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of Issue: Review of draft-chowdhury-mip6-radius-02
Date: Thu, 26 Oct 2006 15:36:53 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Avi,

Thanks for taking care of the issues. A couple of comments below:

> 11) For the split scenario, the document should define what to put
> in Service-Type and NAS-Port-Type attributes (and maybe also
> Calling-Station-Id and Called-Station-Id).
> 
> [avi] Service Type we should not touch.  NAS-Port-Type should be
> HA-MIP6 or something like that.
>
> We need to find out what is going on in Diameter with this.

It wouldn't hurt to specify what Service-Type the HA should use
("Framed" looks like an obvious choice). And yes, a new NAS-Port-Type
might be needed.

> Not sure about calling Station-ID or Called Station id, I don't
> think we should specify anything for those.  SDOs or specific
> deployements may use those attributes.

In the split scenario, Calling-Station-ID would be the obvious place
to send the MN's CoA from the HA to the AAA server. If we want this to
work in interoperable manner, the spec should say so.

> 13) The document should either point to RFC 2548, or explicitly say
> that this document does not contain an interoperable solution for
> the split scenario, since it does not specify (either here or by
> referencing some other document) how to send the MSK from the RADIUS
> server to the HA.
> 
> [Avi] What do you mean by that?  In the split scenario this document
> does not send an MSK to the HA.
> 
> [Avi] I don't think we should specify how the MSK is carried.  The
> specific EAP methods do that see EAP-AKA EAP-TLSbis etc...  We could
> say in the absence of a method to transport MSK, the method
> specified by RFC 2548 SHOULD be used.  Note that that is not enough,
> since we have to specify what goes in the SEND KEY and RECEIVE KEY.

EAP methods don't carry the MSK to the HA (who needs it to complete
the IKEv2 exchanges with the MN). For send/recv key, we might
adapt/borrow text from RFC 4072:

   o  Diameter EAP-Master-Session-Key AVP can be translated to the
      vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key
      attributes [RFC2548].  The first up to 32 octets of the key is
      stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if
      present) are stored into MS-MPPE-Send-Key.  The encryption of this
      attribute is described in [RFC2548].

> 15) And last (but not least, as everyone who has followed RADEXT knows
> :-): the document does not have a Diameter considerations section.
> 
> Done From vlan06.txt  Modified for our purposes.

The text was fine for vlan-06, but in this case, we also have
draft-ietf-dime-mip6-integrated and draft-ietf-dime-mip6-split
to consider.

The text you proposed more-or-less makes both of them redundant.
I'm not saying that's a bad thing :-) but clearly some coordination
between DIME and MIP6 WGs is needed on this issue (unless we really
want to have two different ways to do MIP6 in Diameter).

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 25 Oct 2006 19:51:04 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-04.txt 
Date: Wed, 25 Oct 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Filter Rule Attribute
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-04.txt
	Pages		: 10
	Date		: 2006-10-25
	
This document defines the NAS-Filter-Rule attribute within the Remote
   Authentication Dial In User Service (RADIUS), equivalent to the
   Diameter NAS-Filter-Rule AVP described in RFC 4005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-filter-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-filter-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 25 Oct 2006 15:58:45 +0000
Subject: Review of Issue: Review of draft-chowdhury-mip6-radius-02
Date: Wed, 25 Oct 2006 11:58:16 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Kuntal Chowdhury @ Starent" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>

Hi Pasi,
 
Thanx for the review.  I belive we have addressed most of your comments.
The responses are enclosed.  The comments were addressed in
ietf-mip6-radius-01.txt

There are some issues that were not addressed.  Take a look at: 7, 11
and 13.

1) The document should give all new attributes short names that don't
contain spaces (e.g. "MIP6-Home-Link-Prefix" or just
"Home-Link-Prefix").

[Avi] Sounds like a good idea. The attributes are now called:

  MIP6-HA   
  MIP6-HA-FQDN  
  MIP6-HL-Prefix      
  MIP6-HOA
  DNS-Update-MO

2) Section 5: "The attributes MAY be present in the Access-Accept and
the Accounting-Request." The accounting part is too ambiguous; 
does e.g. requesting DNS update really make sense for accounting
messages?
At the very least, the document should explicitly say what is included
in accounting messages and what it means.

[avi]  The following attributes MAY be included in RADIUS Accounting
Packets:

MIP6-HA  so that backoffice may know which is the serving HA for this
session.
MIP6-HA-FQDN  same reason as above (one or the other or both maybe used)
MIP6-HOA so that the backoffice may know the IP address of the MN.

3) Section 5.2: This attribute should use the same data type as other
attributes containing FQDNs (i.e., just the FQDN, without the zeroes in
the beginning).

[avi] I agree. Done.

4) Section 5.3: This attribute should use the same data type as other
attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix in RFC
3162).

[avi] The difference is Prefix-Length.  Done.

5) Section 5.5: This section should describe that the status code field
uses values defined in "draft-ietf-mip6-bootstrapping-split-02";
now it gives the impression that totally number space is created (but
doesn't give any IANA considerations on how to manage it).

[avi] Seems reasonable. Done.

6) Section 5.5 first says "response to the request MAY not carry a FQDN
value" but then changes its mind "The data field MUST contain a FQDN".

If we don't use two attributes as suggested by comment 7 then reword:

      FQDN of the mobile node:

         The data field MUST contain a FQDN as described in [9].
TO:
         In an Access-Request the data field MUST contain a FQDN.  In an
Access-Accept the FQDN MAY contain a FQDN.  FQDN is as specified in [9].

7) Section 5.5: This attribute should probably be split to 2..3 separate
attributes (e.g. DNS-Update-FQDN and DNS-Update-Result); this would 
be better in line with other recent RADIUS documents.

[avi] Okay.  BTW CUI didnt do this.  If we try to econmomize radius
attributes then lets not do this. Otherwize why not.

Not done.

8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits MUST
be initialized to zero by the sender, and MUST be ignored by the
receiver."

[Avi] Seems okay.  Done.

9) Section 8: According to Section 5, the first four attributes are sent
by the RADIUS server to the NAS, so the first column should be "0"
instead of "0-1" (alternatively, Section 5 needs to specify what these
attributes mean in Access-Requests). 

We kept the attributes in the Access-Request. 

They can act as a hint to the RADIUS server that a) the NAS supports
dynamic HA assignment and b) 
they can be a suggestion as to what values should be used when the
RADIUS server does assing the 
HA in the visited network.  The RADIUS server may use these values or
may use other values.

10) Section 8: The table should probably include accounting messages and
CoA-Request as well.

[avi]  Done.  Not sure if we need anything in COA since I cant think of
any dynamic "actions".
 
11) For the split scenario, the document should define what to put in
Service-Type and NAS-Port-Type attributes 
(and maybe also Calling-Station-Id and Called-Station-Id).

[avi] Service Type we should not touch.  NAS-Port-Type  should be
HA-MIP6 or something like that.

We need to find out what is going on in Diameter with this.

Not sure about calling Station-ID or Called Station id, I don't think we
should specify anything for those.  SDOs or specific deployements may
use those attributes.

12) The document talks about doing EAP authentication over RADIUS, but
never mentions RFC 3579? 

[avi] Add an informational reference to RFC 3579.

13) The document should either point to RFC 2548, or explicitly say that
this document does not contain an interoperable solution for the split
scenario, 
since it does not specify (either here or by referencing some other
document) how to send the MSK from the RADIUS server to the HA.

[Avi] What do you mean by that?  In the split scenario this document
does not send an MSK to the HA.

[Avi]  I don't think we should specify how the MSK is carried.  The
specific EAP methods do that see EAP-AKA EAP-TLSbis etc... 
 We could say in the absence of a method to transport MSK, the method
specified by RFC 2548 SHOULD be used.   
 Note that that is not enough, since we have to specify what goes in the
SEND KEY and RECEIVE KEY.

14) The document should probably have at least informative reference to
RFC 4306.

[avi] Sure. Done.

15) And last (but not least, as everyone who has followed RADEXT knows
:-): the document does not have a Diameter considerations section.

Done From vlan06.txt  Modified for our purposes.

   Diameter Considerations

   When used in Diameter, the attributes defined in this specification
   can be used as Diameter AVPs from the Code space 1-255 (RADIUS
   attribute compatibility space). No additional Diameter Code values
   are therefore allocated.  The data types and flag rules for the
   attributes are as follows:

                                  +---------------------+
                                  |    AVP Flag rules   |
                                  |----+-----+----+-----|----+
                                  |    |     |SHLD| MUST|    |
   Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
   -------------------------------|----+-----+----+-----|----|
   HA-IPv6             Address    | M  |  P  |    |  V  | Y  |
   HA-FQDN             UTF8String | M  |  P  |    |  V  | Y  |
   Home-Link-Prefix    OctetString| M  |  P  |    |  V  | Y  |
   HOA-IPv6            Address    | M  |  P  |    |  V  | Y  |
   DNS-UPDATE-TYPE     OctetString| M  |  P  |    |  V  | Y  |
   -------------------------------|----+-----+----+-----|----|

   Other than HA-IPv6 and HOA-IPv6, the attributes in this specification

   have no special translation
   requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
   they are copied as is, except for changes relating to headers,
   alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
   4005] Section 9.  HA-IPv6 and HOA-IPv6 must be translated between 
   their RADIUS representation of String to a Diameter Address format 
   which requires that the AddressType field be set to 2 for IP6 (IP
version 6)

   What this specification says about the applicability of the
   attributes for RADIUS Access-Request packets applies in Diameter to
   AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072].  What is
   said about Access-Challenge applies in Diameter to AA-Answer [RFC
   4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH.

   What is said about Access-Accept applies in Diameter to AA-Answer or
   Diameter-EAP-Answer messages that indicate success.  Similarly, what
   is said about RADIUS Access-Reject packets applies in Diameter to AA-
   Answer or Diameter-EAP-Answer messages that indicate failure.

   What is said about COA-Request applies in Diameter to Re-Auth-Request
   [RFC 4005].

   What is said about Accounting-Request applies to Diameter Accounting-
   Request [RFC 4005] as well.

========================

Avi Lior                                    
Bridgewater Systems Corporation 
Phone :  +1 (613) 591-9104 x6417
Cell    :  +1 (613) 796-4183
E-mail : mailto:[email-masked]
<mailto:[email-masked]> 
www.bridgewatersystems.com <http://www.bridgewatersystems.com/>  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 20 Oct 2006 23:24:52 +0000
Content-class: urn:content-classes:message
Subject: FYI: I-D ACTION:draft-lior-radius-attribute-type-extension-01.txt 
Date: Fri, 20 Oct 2006 16:23:51 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F49E.CFBA231E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[email-masked] <mailto:[email-masked]> supposedly
scribbled on Friday, October 20, 2006 12:50 PM:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. 
> 
> 
> 	Title		: Remote Authentication Dial In User Service
(RADIUS)
> 	Attribute Type Extension Author(s)	: A. Lior, et al.
> 	Filename	:
draft-lior-radius-attribute-type-extension-01.txt
> 	Pages		: 11
> 	Date		: 2006-10-20
> 
> In order for the Remote Authentication Dial In User Service protocol
>    to continue to support new applications, the RADIUS attribute space
>    must be extended beyond the current limit of 255 possible attribute
>    types.  This document defines a mechanism to extend the base RADIUS
>    attribute types while maintaining backwards compatibility as well
>    as compatibility with Diameter.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext
ension-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-lior-radius-attribute-type-extension-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE
> /internet-drafts/draft-lior-radius-attribute-type-extension-01.txt". 
> 
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

------_=_NextPart_001_01C6F49E.CFBA231E
Content-Type: application/octet-stream;
	name="ATT4024120.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT4024120.TXT
Content-Disposition: attachment;
	filename="ATT4024120.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0yMDEyMjE1MC5JLURAaWV0Zi5vcmc+DQoNCkVO
Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saW9yLXJhZGl1cy1hdHRy
aWJ1dGUtdHlwZS1leHRlbnNpb24tMDEudHh0DQo
------_=_NextPart_001_01C6F49E.CFBA231E
Content-Type: application/octet-stream;
	name="draft-lior-radius-attribute-type-extension-01.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-lior-radius-attribute-type-extension-01.URL
Content-Disposition: attachment;
	filename="draft-lior-radius-attribute-type-extension-01.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1saW9yLXJhZGl1cy1hdHRyaWJ1dGUtdHlwZS1leHRlbnNpb24tMDEudHh0DQo
------_=_NextPart_001_01C6F49E.CFBA231E
Content-Type: text/plain;
	name="ATT4024121.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT4024121.txt
Content-Disposition: attachment;
	filename="ATT4024121.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo
------_=_NextPart_001_01C6F49E.CFBA231E--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 20 Oct 2006 19:50:48 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-03.txt 
Date: Fri, 20 Oct 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Filter Rule Attribute
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-03.txt
	Pages		: 11
	Date		: 2006-10-20
	
This document defines the NAS-Filter-Rule attribute within the Remote
   Authentication Dial In User Service (RADIUS), equivalent to the
   Diameter NAS-Filter-Rule AVP described in RFC 4005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-filter-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-filter-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 20 Oct 2006 03:55:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Filter Separation using a NUL?
Date: Thu, 19 Oct 2006 20:55:08 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Emile van Bergen <mailto:[email-masked]> supposedly
scribbled on Thursday, October 19, 2006 7:15 AM:

> Hi,
> 
> On Thu, Oct 19, 2006 at 01:52:39AM -0700, Glen Zorn (gwz) wrote:
> 
>> OK, I'm having a little trouble understanding the point of this & the
>> reasoning behind it.  I thought that the problem we were trying to
>> solve was the transmission of a filter set, consisting of one or more
>> rules, which is potentially larger than the data size of a RADIUS
>> attribute. Further, the document leads me to believe that it is
>> expected that 
>> this set will be used as such, giving explicit instructions for its
>> reconstruction on the client ("Where multiple NAS-Filter-Rule
>> attributes are included in a RADIUS packet, the String field of the
>> attributes are to be concatenated to form a set of filter rules.");
>> presumably, the client will need to parse these rules in order to
>> install them, since the syntax used is that of BSD (not the most
>> popular NAS OS on the planet, AFAIK).  So what is the point of taking
>> apart this nice set, parsing it into individual rules, then
>> reconcatenating the
>> (NUL-terminated) rules into a set again for transmission?  I suspect
>> that I'm just confused, but maybe somebody can help me out.
> 
> As far as I've understood the case so far, there is an encoding
> defined for individual rules, but no encoding for a complete rule
> set.  

"Where multiple NAS-Filter-Rule attributes are included in a RADIUS
packet, the String field of the
attributes are to be concatenated to form a set of filter rules."  This
appears to me to state that a filter rule set is exactly the result of
in-order concatenation of the individual rules.

> 
> The knowledge of where each rule begins and ends therefore needs to
> be transported out of band, along with the rule set string. 

OK, one more time: if the goal is to end up w/the concatenation of the
rules into a rule set, why is it necessary to know where the individual
rules begin or end (except, of course, for the first and last rules in
the set)?

> 
> DIAMETER uses separate attribute instances for that purpose; what's
> just been proposed is that RADIUS uses NUL characters instead. Thus,
> we first define a single long rule set string, and then say that it
> is to be transported in a 0-1 "single long" attribute (which is
> formed by concatenating all instances of a string attribute in their
> order of appearance in the packet).   

See above.  Maybe the text I'm quoting is in error?
  
> 
> Cheers,
> 
> 
> Emile.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 19 Oct 2006 22:07:01 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Filter Separation using a NULL? 
cc: [email-masked]
Date: Thu, 19 Oct 2006 17:55:44 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Thanks.  Here is some revised text:

  Looks good to me.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 19:50:40 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-05.txt 
Date: Thu, 19 Oct 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Delegated-IPv6-Prefix Attribute
	Author(s)	: J. Salowey, R. Droms
	Filename	: draft-ietf-radext-delegated-prefix-05.txt
	Pages		: 9
	Date		: 2006-10-19
	
This document defines a RADIUS (Remote Authentication Dial In User
   Service) attribute that carries an IPv6 prefix that is to be
   delegated to the user.  This attribute is usable within either RADIUS
   or Diameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-delegated-prefix-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-delegated-prefix-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-delegated-prefix-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-delegated-prefix-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 16:05:39 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Filter Separation using a NULL?
Date: Thu, 19 Oct 2006 09:04:58 -0700

Thanks.  Here is some revised text:

   String

      The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
      individual filter rules separated by a NUL (0x00).  A NAS-Filter-
      Rule attribute may contain a partial rule, one rule, or more than
      one rule.  Filter rules may be continued across attribute
      boundaries, so implementations cannot assume that individual
      filter rules begin or end on attribute boundaries.

      The set of NAS-Filter-Rule attributes SHOULD be created by
      concatenating the individual filter rules, separated by a NUL
      (0x00) octet.  The resulting data should be split on 253 byte
      boundaries to obtain a set of NAS-Filter-Rule attributes.  On
      reception, the individual filter rules SHOULD be determined by
      concatenating the contents of all NAS-Filter-Rule attributes, and
      then splitting individual filter rules with the the NUL octet
      (0x00) as a delimeter.

>   I would say:
>
>       The String field is one or more octets.  It contains filter rules
>       in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
>       individual filter rules separated by a NULL (0x00). A
>       NAS-Filter-Rule attribute may contain a partial rule, one rule,
>       or more than one rule.  Filter rules may be continued across
>       attribute boundaries, so implementations cannot assume that
>       individual filter rules begin or end on attribute boundaries.
>
>       The set of NAS-Filter-Rule attributes SHOULD be created by
>       concatenating the individual filter rules, separated by a NULL
>       (0x00) character.  The resulting data should be split on 252
>       byte boundaries to obtain a set of NAS-Filter-Rule attributes.
>       On reception, the individual filter rules SHOULD be determined
>       by concatenating the contents of all NAS-Filter-Rule attributes,
>       and then splitting the resulting data at the NULL (0x00) characters.
>
>   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 14:12:24 +0000
Date: Thu, 19 Oct 2006 16:14:40 +0200
From: Emile van Bergen <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Filter Separation using a NUL?
Mail-Followup-To: "Glen Zorn (gwz)" <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked], [email-masked]

Hi,

On Thu, Oct 19, 2006 at 01:52:39AM -0700, Glen Zorn (gwz) wrote:

> OK, I'm having a little trouble understanding the point of this & the
> reasoning behind it.  I thought that the problem we were trying to solve
> was the transmission of a filter set, consisting of one or more rules,
> which is potentially larger than the data size of a RADIUS attribute.
> Further, the document leads me to believe that it is expected that this
> set will be used as such, giving explicit instructions for its
> reconstruction on the client ("Where multiple NAS-Filter-Rule attributes
> are included in a RADIUS packet, the String field of the attributes are
> to be concatenated to form a set of filter rules."); presumably, the
> client will need to parse these rules in order to install them, since
> the syntax used is that of BSD (not the most popular NAS OS on the
> planet, AFAIK).  So what is the point of taking apart this nice set,
> parsing it into individual rules, then reconcatenating the
> (NUL-terminated) rules into a set again for transmission?  I suspect
> that I'm just confused, but maybe somebody can help me out.  

As far as I've understood the case so far, there is an encoding defined
for individual rules, but no encoding for a complete rule set. 

The knowledge of where each rule begins and ends therefore needs to be
transported out of band, along with the rule set string. 

DIAMETER uses separate attribute instances for that purpose; what's just
been proposed is that RADIUS uses NUL characters instead. Thus, we first
define a single long rule set string, and then say that it is to be
transported in a 0-1 "single long" attribute (which is formed by
concatenating all instances of a string attribute in their order of
appearance in the packet).

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 08:53:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Filter Separation using a NULL?
Date: Thu, 19 Oct 2006 01:52:39 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006
9:52 PM:

> To clarify Mauricio's question, I've changed the text somewhat. The
> updated text is available for inspection here: 
> 
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt

OK, I'm having a little trouble understanding the point of this & the
reasoning behind it.  I thought that the problem we were trying to solve
was the transmission of a filter set, consisting of one or more rules,
which is potentially larger than the data size of a RADIUS attribute.
Further, the document leads me to believe that it is expected that this
set will be used as such, giving explicit instructions for its
reconstruction on the client ("Where multiple NAS-Filter-Rule attributes
are included in a RADIUS packet, the String field of the attributes are
to be concatenated to form a set of filter rules."); presumably, the
client will need to parse these rules in order to install them, since
the syntax used is that of BSD (not the most popular NAS OS on the
planet, AFAIK).  So what is the point of taking apart this nice set,
parsing it into individual rules, then reconcatenating the
(NUL-terminated) rules into a set again for transmission?  I suspect
that I'm just confused, but maybe somebody can help me out.  

> 
> Here is how the new Section 2 reads:
> 
> 2.  NAS-Filter-Rule Attribute
> 
>    Description
> 
>       This attribute indicates filter rules to be applied for this
>       user. Zero or more NAS-Filter-Rule attributes MAY be sent in
>       Access- Accept, CoA-Request, or Accounting-Request packets.
> 
>       The NAS-Filter-Rule attribute is not intended to be used
>       concurrently with any other filter rule attribute, including
>       Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and
>       MUST NOT appear in the same RADIUS packet.  If a Filter-Id or
>       NAS- Traffic-Rule attribute is present, then implementations of
>       this specification MUST silently discard NAS-Filter-Rule
>       attributes, if present.
> 
>       Where multiple NAS-Filter-Rule attributes are included in a
>       RADIUS packet, the String field of the attributes are to be
>       concatenated to form a set of filter rules.  As noted in
>       [RFC2865] Section 2.3, "the forwarding server MUST NOT change
>       the order of any attributes of the same type", so that RADIUS
>       proxies will not reorder NAS- Filter-Rule attributes.
> 
>       A summary of the NAS-Filter-Rule Attribute format is shown
>       below. The fields are transmitted from left to right.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      
>      
>      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  
> Type      |    Length     |      String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
> 
>    Type
> 
>       TBD
> 
>    Length
> 
>       >=3
> 
>    String
> 
>       The String field is one or more octets.  It contains filter
>       rules in the IPFilterRule syntax defined in [RFC3588] Section
>       4.3, with filter rules separated by a NULL (0x00).  One or more
>       filter rules may be included within a NAS-Filter-Rule
>       attribute, and filter rules may be continued across attribute
>       boundaries, so in general implementations cannot assume that
>       filter rules begin and end on attribute boundaries.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 06:57:30 +0000
Date: Thu, 19 Oct 2006 08:59:57 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Request for Review: RADIUS Filter Attribute Document
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked], [email-masked]

Hi,

On Wed, Oct 18, 2006 at 09:45:49PM -0700, Bernard Aboba wrote:

> >I have mixed feelings.  On the one hand, there is precedent for glomming
> >all instances of an attribute together, for EAP.  On the other, EAP is
> >different in that the RADIUS code does not parse the result.  What will
> >happen with the next attribute, where a byte value of 0x00 may be valid?
> 
> This approach works for this particular attribute because the IPFilter 
> syntax only permits ASCII characters.  It's not a general solution, as you 
> point out.  That wider problem may be part of the extended attribute 
> discussion.  Since NAS-Filter-Rule isn't an extended attribute I think that 
> discussion is somewhat orthogonal.

Well, the solution may be more general than people think, considering it
has two orthogonal parts: 1. concatenation, 2. splitting.

The first part, concatenation, can be used

a. stand-alone (without subsequent splitting), useful for eg. EAP, but
   also for all other > 253 attributes of which only 0..1 instances can
   occur; 

b. with splitting on a delimiter (as just proposed for NAS-Filter-Rule); 

c. with splitting based on a length, value scheme (needed for octet string 
   attributes), and 
   
d. with splitting based on a type, (flags or tag + child tag), length, 
   value scheme, as proposed in the various extended attribute drafts.

If you can't put any constraints on the values of the octets in an
attribute, then you simply need c. instead of b., but the method of
concatenation while disregarding original attribute boundaries still
stands.

How does c. work? Let's assume we need a new (octet) string attribute,
0..n instances, any number of instances, possibly > 253 in length. 

As said, we first perform standard attribute concatenation, to get a
single octet string of size up to ~4000. 

Then, instead of splitting on a delimiter as proposed for
NAS-Filter-Rule, you decode this string as a series of length, value
pairs to get the real "instances":

0    1    2          
+----+----+----+---- ~ --+----+----+----+----
| Length1 | Value1...    | Length2 | Value2...
+----+----+----+---- ~ --+----+----+----+----

If that looks familiar, it is; it's a normal RADIUS attribute without
the 'type' field and with a 2-octet length field.

So, it's pick and choose. We don't even need to design a single extended
attribute that does it all. 

You can overcome the <= 253 value size limit by concatenation, at the
price of limiting an attribute to one long instance. This is sufficient
for EAP-Message and possibly other attributes.

On top of that facility, you can overcome the single long instance limit
per attribute type by splitting on delimiters, at the price of limiting
value ranges (sufficient for NAS-Filter-Rule), or by splitting using
internal length fields.

On top of the last facility, you can overcome the <= 255 attribute type
number space limit by adding a (wider) type field to each internal
attribute instance contained in the concatenated string.

To overcome the limited outer structure (flat list of attributes), you
can either physically nest attributes inside one another (diameter-based
drafts), or add a tag and a child-tag field (my draft) to each internal
attribute instance contained in the concatenated string.

In short, the concatenation half of the solution is as generic as you
can get; it's already in use for EAP and you can build all other
facilities that were discussed here in the past year on top of it.

The splitting-on-a-delimiter is indeed limited to text values, but we
can just as well decide to split-on-a-two-octet-length-field instead,
which has no other side effects than being slightly less efficient for
text values.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 05:34:38 +0000
Date: Thu, 19 Oct 2006 01:34:26 -0400
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Request for Review: RADIUS Filter Attribute Document

On Wed, Oct 18, 2006 at 10:01:56PM -0700, Glen Zorn (gwz) wrote:
> Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006
> 9:46 PM:
> 
> >> I have mixed feelings.  On the one hand, there is precedent for
> >> glomming all instances of an attribute together, for EAP.  On the
> >> other, EAP is different in that the RADIUS code does not parse the
> >> result.  What will happen with the next attribute, where a byte
> >> value of 0x00 may be valid? 
> > 
> > This approach works for this particular attribute because the
> > IPFilter syntax only permits ASCII characters.  It's not a general
> > solution, as you point out.  That wider problem may be part of the
> > extended attribute discussion.  Since NAS-Filter-Rule isn't an
> > extended attribute I think that discussion is somewhat orthogonal. 
> 
> I think that if we can really come to an agreement upon the extension
> method fairly soon it should be.   

I strongly agree with Glen.  "There's more than one way to do it" works
well for Perl but not for us.

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 19 Oct 2006 05:16:22 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Filter Separation using a NULL? 
cc: [email-masked], [email-masked], [email-masked]
Date: Thu, 19 Oct 2006 01:10:06 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
...

  I would say:

      The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
      individual filter rules separated by a NULL (0x00). A 
      NAS-Filter-Rule attribute may contain a partial rule, one rule,
      or more than one rule.  Filter rules may be continued across
      attribute boundaries, so implementations cannot assume that
      individual filter rules begin or end on attribute boundaries.

      The set of NAS-Filter-Rule attributes SHOULD be created by
      concatenating the individual filter rules, separated by a NULL
      (0x00) character.  The resulting data should be split on 252
      byte boundaries to obtain a set of NAS-Filter-Rule attributes.
      On reception, the individual filter rules SHOULD be determined
      by concatenating the contents of all NAS-Filter-Rule attributes,
      and then splitting the resulting data at the NULL (0x00) characters.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 05:02:08 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review: RADIUS Filter Attribute Document
Date: Wed, 18 Oct 2006 22:01:56 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006
9:46 PM:

>> I have mixed feelings.  On the one hand, there is precedent for
>> glomming all instances of an attribute together, for EAP.  On the
>> other, EAP is different in that the RADIUS code does not parse the
>> result.  What will happen with the next attribute, where a byte
>> value of 0x00 may be valid? 
> 
> This approach works for this particular attribute because the
> IPFilter syntax only permits ASCII characters.  It's not a general
> solution, as you point out.  That wider problem may be part of the
> extended attribute discussion.  Since NAS-Filter-Rule isn't an
> extended attribute I think that discussion is somewhat orthogonal. 

I think that if we can really come to an agreement upon the extension
method fairly soon it should be.   

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 04:52:41 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Filter Separation using a NULL?
Date: Wed, 18 Oct 2006 21:52:27 -0700

To clarify Mauricio's question, I've changed the text somewhat. The updated 
text is available for inspection here:

http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt

Here is how the new Section 2 reads:

2.  NAS-Filter-Rule Attribute

   Description

      This attribute indicates filter rules to be applied for this user.
      Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
      Accept, CoA-Request, or Accounting-Request packets.

      The NAS-Filter-Rule attribute is not intended to be used
      concurrently with any other filter rule attribute, including
      Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST
      NOT appear in the same RADIUS packet.  If a Filter-Id or NAS-
      Traffic-Rule attribute is present, then implementations of this
      specification MUST silently discard NAS-Filter-Rule attributes, if
      present.

      Where multiple NAS-Filter-Rule attributes are included in a RADIUS
      packet, the String field of the attributes are to be concatenated
      to form a set of filter rules.  As noted in [RFC2865] Section 2.3,
      "the forwarding server MUST NOT change the order of any attributes
      of the same type", so that RADIUS proxies will not reorder NAS-
      Filter-Rule attributes.

      A summary of the NAS-Filter-Rule Attribute format is shown below.
      The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |      String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD

   Length

      >=3

   String

      The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
      filter rules separated by a NULL (0x00).  One or more filter rules
      may be included within a NAS-Filter-Rule attribute, and filter
      rules may be continued across attribute boundaries, so in general
      implementations cannot assume that filter rules begin and end on
      attribute boundaries.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 04:46:00 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Request for Review: RADIUS Filter Attribute Document
Date: Wed, 18 Oct 2006 21:45:49 -0700

>I have mixed feelings.  On the one hand, there is precedent for glomming
>all instances of an attribute together, for EAP.  On the other, EAP is
>different in that the RADIUS code does not parse the result.  What will
>happen with the next attribute, where a byte value of 0x00 may be valid?

This approach works for this particular attribute because the IPFilter 
syntax only permits ASCII characters.  It's not a general solution, as you 
point out.  That wider problem may be part of the extended attribute 
discussion.  Since NAS-Filter-Rule isn't an extended attribute I think that 
discussion is somewhat orthogonal.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 19 Oct 2006 04:42:52 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Filter Separation using a NULL?
Date: Wed, 18 Oct 2006 21:41:54 -0700

>Can we be stronger and state MUST NOT instead of SHOULD NOT on the mixture
>of NAS-Traffic-Rule and NAS-Filter-Rule?  If we stick with SHOULD NOT, then
>what is the expected behavior of the NAS when both appear?

We can say MUST NOT, although then we'd probably say what a NAS should do if 
both are included.

>RADIUS packet or RADIUS message?  I thought the right term was message.

The term packet is used in RFC 2865.

>The current wording of "...filter rules separated by a NULL" makes it sound
>like multiple rules can be put in within a single NAS-Filter-Id attribute.

I think this is what Emile suggested -- you concatenate all the attribute 
together and then separate the rules via the NULL character.  So you could 
have multiple rules in one attribute, partial rules split between 
attributes, etc.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 16:53:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Filter Separation using a NULL? 
Date: Wed, 18 Oct 2006 11:52:15 -0500
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_00C3_01C6F29B.1736AE30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

See below...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, October 18, 2006 6:32 AM
> To: [email-masked]; [email-masked]
> Subject: Filter Separation using a NULL? 
>       The NAS-Filter-Rule attribute is not intended to be used
>       concurrently with any other filter rule attribute, including
>       Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and
>       SHOULD NOT appear in the same RADIUS packet.  If a Filter-Id

Can we be stronger and state MUST NOT instead of SHOULD NOT on the mixture
of NAS-Traffic-Rule and NAS-Filter-Rule?  If we stick with SHOULD NOT, then
what is the expected behavior of the NAS when both appear?

RADIUS packet or RADIUS message?  I thought the right term was message.

>       attribute is present, then implementations of this specification
>      MUST silently discard NAS-Filter-Rule attributes, if present.
>       The String field is one or more octets.  It contains 
> filter rules
>       in the IPFilterRule syntax defined in [RFC3588] Section 
> 4.3, with
>       filter rules separated by a NULL (0x00).  A robust 
> implementation
>       SHOULD support the field as undistinguished octets.

The current wording of "...filter rules separated by a NULL" makes it sound
like multiple rules can be put in within a single NAS-Filter-Id attribute.
Is this the case?  If not, consider instead the wording "filter rules
terminated by a NULL (0x00)" and stating that the start of a new rule should
always use an additional attribute.

MS

------=_NextPart_000_00C3_01C6F29B.1736AE30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00C3_01C6F29B.1736AE30--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 16:53:30 +0000
Date: Wed, 18 Oct 2006 12:52:21 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Request for Review: RADIUS Filter Attribute Document

On Wed, Oct 18, 2006 at 06:12:40AM -0700, Bernard Aboba wrote:
> >I am increasingly convinced that the attempt to re-use the tag mechanism
> >for segmentation and concatenation is misguided and will lead implementers
> >into trouble.
> 
> Question:  what do you think of Emile's proposal to just use a \0 as a 
> delimiter?  It would appear that this approach doesn't require any tags at 
> all.

I have mixed feelings.  On the one hand, there is precedent for glomming
all instances of an attribute together, for EAP.  On the other, EAP is
different in that the RADIUS code does not parse the result.  What will
happen with the next attribute, where a byte value of 0x00 may be valid?

I wish the WG would support solving the problems of attribute type
exhaustion, grouping and length limitation once rather than re-invent
polygonal wheels endlessly.  Ok, if the Diameter attribute header is too
big, ugly and NIH to be accepted, RADIUS can have its own extended
attribute header.  But if we're going to bite that bullet, we SHOULD first
agree on requirements and how competing proposals will be evaluated,
before making proposals.  To repeat approximately a slide from last March,
here is my view:

Criteria for evaluating extended attribute format
    This is Transfer syntax, must support desired power & flexibility
      available to definers of new RADIUS features
    Top priorities
        remove 255 limit on attribute type number
        remove 253 limit on attribute value length
        support rich set of standard attribute value types
        support grouping
        easy transition of attributes from vsa to standard
    Mid priorities
        ease of gatewaying <-> Diameter
        support multi-level (nested) grouping
        M-bit
        build on / re-use existing work
    Low priorities
        minimal attribute header size
        elegance, alas

Alternatively, we could with little loss of realistic function simply
declare that no filter rule can exceed 253 bytes.

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 15:21:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Request for Review: RADIUS Filter Attribute Document
Date: Wed, 18 Oct 2006 08:21:16 -0700

>Does anyone see the need for tagged sets of rules, in the same vein that
>we have tagged sets of tunnel attributes, i.e. as alternative sets of
>rules?

The goal of this document is to provide the same functionality as the 
NAS-Filter-Rule AVP in Diameter, which doesn't support alternative rule 
sets.  If there is a need for that feature at all, it can be provided as an 
extension to the filter rule language itself, without the need for tagging.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 15:02:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for Review: RADIUS Filter Attribute Document
Date: Wed, 18 Oct 2006 11:02:40 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> Not for NAS-Filter-Rule's basic function as a transport mechanism
> for a single rule set, no.

Does anyone see the need for tagged sets of rules, in the same vein that
we have tagged sets of tunnel attributes, i.e. as alternative sets of
rules?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 14:59:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Filter Separation using a NULL? 
Date: Wed, 18 Oct 2006 10:59:25 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

>       The String field is one or more octets.  It contains filter
rules
>       in the IPFilterRule syntax defined in [RFC3588] Section 4.3,
with
>       filter rules separated by a NULL (0x00).  A robust
implementation
>       SHOULD support the field as undistinguished octets.

The sentence "A robust implementation SHOULD support the field as
undistinguished octets." is standard in RADIUS documents, achieving the
status of special "words of art". Yet, in this context, I wonder what it
means.  I would think that "undistinguished octets" means the same thing
as "opaque binary blob".  Yet, that clearly can't be the case, as we
anticipate that the attribute contents are a sequence of ASCII strings
delimited by NULs.

So, what exactly does this sentence mean to convey?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 14:39:03 +0000
Date: Wed, 18 Oct 2006 16:41:36 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Request for Review: RADIUS Filter Attribute Document
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked]

Hi,

On Wed, Oct 18, 2006 at 06:11:29AM -0700, Bernard Aboba wrote:

> [EvB]
> >To my mind, such an approach to long attributes (concatenate first; then
> >resplit if necessary) is both more generic and simpler, and solves the
> >issue at hand.
> 
> It should be easy to implement, either in a NAS or in a RADIUS/Diameter 
> gateway.  Do we even need a tag at all if we adopt this proposal?

Not for NAS-Filter-Rule's basic function as a transport mechanism for a
single rule set, no.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 13:32:05 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Filter Separation using a NULL? 
Date: Wed, 18 Oct 2006 06:31:51 -0700

A respin of the document based on your suggestion is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt

Here is what Section 2 now looks like -- it is indeed much simpler, and I 
can't see that any functionality has been lost.   What do people think?

2.  NAS-Filter-Rule Attribute

   Description

      This attribute indicates filter rules to be applied for this user.
      Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
      Accept, CoA-Request, or Accounting-Request packets.

      The NAS-Filter-Rule attribute is not intended to be used
      concurrently with any other filter rule attribute, including
      Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and
      SHOULD NOT appear in the same RADIUS packet.  If a Filter-Id
      attribute is present, then implementations of this specification
      MUST silently discard NAS-Filter-Rule attributes, if present.

      Where multiple NAS-Filter-Rule attributes are included in a RADIUS
      packet, the String field of the attributes are to be concatenated
      to form a set of filter rules.  As noted in [RFC2865] Section 2.3,
      "the forwarding server MUST NOT change the order of any attributes
      of the same type", so that RADIUS proxies will not reorder NAS-
      Filter-Rule attributes.

      A summary of the NAS-Filter-Rule Attribute format is shown below.
      The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |      String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD

   Length

      >=4

   String

      The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
      filter rules separated by a NULL (0x00).  A robust implementation
      SHOULD support the field as undistinguished octets.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 13:12:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Request for Review: RADIUS Filter Attribute Document
Date: Wed, 18 Oct 2006 06:12:40 -0700

>I am increasingly convinced that the attempt to re-use the tag mechanism
>for segmentation and concatenation is misguided and will lead implementers
>into trouble.

Question:  what do you think of Emile's proposal to just use a \0 as a 
delimiter?  It would appear that this approach doesn't require any tags at 
all.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 13:12:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: Re: Request for Review: RADIUS Filter Attribute Document
Date: Wed, 18 Oct 2006 06:11:29 -0700

>I still strongly feel the tag scheme is needlessly complex for what it
>intends to achieve.

Simple is better, of course.

>Also, the requirement that even though the attribute has a tag, a strict
>ordering of attribute instances must be maintained /disregarding the
>tags/, meaning that you have to maintain the order in which the tagged
>sets appear, including their interleaving, seems a little at odds with
>the spirit of other uses of tags, such as eg. RFC2869. Of course it is
>allowed because of the ordering requirements in RFC2865, but it creates
>a new requirement from a tagged attribute viewpoint.

Right.

>With 'normal' tagged attributes, there is no relative ordering between
>tagged sets that must be maintained, i.e. for most purposes you can
>consider an attribute with a different tag a wholly different attribute
>type.
>
>I think there is a simpler solution, /if/ you let go of the desire to
>represent a single rule in a single attribute 'most of the time'.
>
>Once you do that, you can specify that in order to interpret
>NAS-Filter-Rule, the values of /all/ instances must first be bluntly
>concatenated based on their normal order of appearance (as also done for
>EAP; it's perfectly OK to rely on relative ordering among attributes
>having the same type and tag), and then split using a simple delimiting
>to obtain the individual filtering rules.
>
>Whether that splitting is done the same way as in DNS (a length byte (in
>our case that would be 2 bytes) before every individual rule), or using
>a real delimiter (\0, \n, whatever, anything that does not appear in an
>individual filter rule), is mostly a matter of taste.

Since in practice the rules are only expressed in ASCII, \0 would work.

>To my mind, such an approach to long attributes (concatenate first; then
>resplit if necessary) is both more generic and simpler, and solves the
>issue at hand.

It should be easy to implement, either in a NAS or in a RADIUS/Diameter 
gateway.  Do we even need a tag at all if we adopt this proposal?

>Because of its layering, it's also more future proof, as the upper half
>of the solution (splitting) may be preserved when other generic methods
>of transporting longer values appear, and creates a useful de-facto
>representation of a rule set as a single octet string as a byproduct;
>the lower half of the solution -- the method of encoding a single long
>attribute by plain concatenation of RADIUS attributes -- can also be
>used for other attribute types and delimiting styles.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 08:13:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Review requested: draft-ietf-radext-filter-02.txt
Date: Wed, 18 Oct 2006 10:12:35 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,

I have basically few issues related to the tags. RFC2868 says that tags
are between 0x01-0x1f. Then RFC2882 says tags are between 0x01-0x3f
(and giving the reference to RFC2868) like this draft also. I lack
history here for the reason, which I assume exists. But I guess we 
should go for the original range if there is no compelling reason
to use the extended range. Also why using tags in a middle of range?
Can't we just use 0x01 when the attribute is not concatenated and
0x02 -> 0x1f when the attribute is concatenated?

Honestly, whether we use tags or one bit, I don't really care ;)
Maybe the one bit approach as suggested by some ppl could be simpler.

Cheers,
	Jouni

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: 3. lokakuuta 2006 23:14
> To: [email-masked]
> Subject: Review requested: draft-ietf-radext-filter-02.txt
> 
> A new version has been posted to the archive:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt
> 
> Does this version address the open issues (198 & 202)?   Are 
> there any other 
> issues/problems with it?
> 
> 3GPP asked out the status of it in the last IETF/3GPP liaison 
> conference 
> call.
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 07:17:57 +0000
Date: Wed, 18 Oct 2006 09:20:33 +0200
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: Bernard Aboba <[email-masked]>
Subject: Re: Request for Review: RADIUS Filter Attribute Document
Mail-Followup-To: [email-masked], Bernard Aboba <[email-masked]>

Hi,

On Tue, Oct 17, 2006 at 07:01:57PM -0700, Bernard Aboba wrote:

> The RADIUS Filter Attribute document has gone through another revision to 
> address the filter continuation issue.  Please review the current version 
> and send comments to the WG list:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt
> 
> Are the changes an improvement?

I still strongly feel the tag scheme is needlessly complex for what it
intends to achieve. 

Also, the requirement that even though the attribute has a tag, a strict
ordering of attribute instances must be maintained /disregarding the
tags/, meaning that you have to maintain the order in which the tagged
sets appear, including their interleaving, seems a little at odds with
the spirit of other uses of tags, such as eg. RFC2869. Of course it is
allowed because of the ordering requirements in RFC2865, but it creates
a new requirement from a tagged attribute viewpoint.

With 'normal' tagged attributes, there is no relative ordering between
tagged sets that must be maintained, i.e. for most purposes you can
consider an attribute with a different tag a wholly different attribute
type.

I think there is a simpler solution, /if/ you let go of the desire to
represent a single rule in a single attribute 'most of the time'. 

Once you do that, you can specify that in order to interpret
NAS-Filter-Rule, the values of /all/ instances must first be bluntly
concatenated based on their normal order of appearance (as also done for
EAP; it's perfectly OK to rely on relative ordering among attributes
having the same type and tag), and then split using a simple delimiting
to obtain the individual filtering rules.

Whether that splitting is done the same way as in DNS (a length byte (in
our case that would be 2 bytes) before every individual rule), or using
a real delimiter (\0, \n, whatever, anything that does not appear in an
individual filter rule), is mostly a matter of taste.

To my mind, such an approach to long attributes (concatenate first; then
resplit if necessary) is both more generic and simpler, and solves the
issue at hand.

Because of its layering, it's also more future proof, as the upper half
of the solution (splitting) may be preserved when other generic methods
of transporting longer values appear, and creates a useful de-facto
representation of a rule set as a single octet string as a byproduct;
the lower half of the solution -- the method of encoding a single long
attribute by plain concatenation of RADIUS attributes -- can also be
used for other attribute types and delimiting styles.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 06:56:21 +0000
Date: Wed, 18 Oct 2006 02:54:34 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Request for Review: RADIUS Filter Attribute Document

On Tue, Oct 17, 2006 at 07:01:57PM -0700, Bernard Aboba wrote:
> The RADIUS Filter Attribute document has gone through another revision to 
> address the filter continuation issue.  Please review the current version 
> and send comments to the WG list:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt
> 
> Are the changes an improvement?

I am increasingly convinced that the attempt to re-use the tag mechanism
for segmentation and concatenation is misguided and will lead implementers
into trouble.  In the realm of biology, frequent instances of genes and
structures being re-used, often quite clumsily, for completely new
functions is one of the proofs of natural evolution rather than intelligent
design.  But protocols do, or should, have intelligent designers.

Tags were designed to collect different attributes, in arbitrary order,
into groups.  Limitations on tag values (originally 0x01-0x1f - when did
that change to 0x3f?) were motivated by allowing the tags to be optional.
Group precedence was defined by an explicit attribute.

For segmentation, a simple 1-bit question needs to be answered:  Does
this attribute, of maximum length, stand on its own or is the next
filter attribute to be concatenated with it?  From that point of view,
the rules on tag values and especially against repetition of a tag
value, make no sense.

But there is a more subtle trap waiting for the implementer who blindly
uses existing tag code.  Filter rule precedence is governed by
the order of appearance in the RADIUS message.  Within a given tag
value, the code may well just happen to work that way.  But across
different tag values it most likely will not.  Thus all the attributes
with tag '0' will maintain order, but any rule that needs segmentation
will lose its position information relative to all others.  Since huge
rules are actually quite rare, I suspect such bugs will survive to be
fielded.

I propose, instead, that Avi's suggestion of reserving one bit of the
tag field for segmentation and leaving the other 7 for grouping be
adopted, and that the bit be called MORE, indicating that this
attribute is not the last piece of the rule.  (One could just as
well name it EXT and have it set only in the attribute that extends
the previous one.  There are pros and cons either way.)

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Oct 2006 02:02:52 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for Review: RADIUS Filter Attribute Document
Date: Tue, 17 Oct 2006 19:01:57 -0700

The RADIUS Filter Attribute document has gone through another revision to 
address the filter continuation issue.  Please review the current version 
and send comments to the WG list:

http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt

Are the changes an improvement?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 16 Oct 2006 21:16:58 +0000
Content-class: urn:content-classes:message
Subject: RADEXT - Requested session has been scheduled for IETF 67
Date: Mon, 16 Oct 2006 17:15:50 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The RADEXT session at IETF-67 has been scheduled for:

RADEXT Session 1 (2.5 hours)
Tuesday, Morning Session I 0900-1130
Room Name: Harbor 1
----------------------------------------------

Please respond to the chairs with requests for agenda slots, including
the subject, the I-D, and requested time.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 15 Oct 2006 11:25:42 +0000
content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-carpenter-extension-recs-00.txt 
Date: Sun, 15 Oct 2006 13:24:43 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F04C.8333E0D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe that radext participants may be interested in this document. 

Dan

 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 9:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-carpenter-extension-recs-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Design issues for protocol extensions
	Author(s)	: B. Carpenter
	Filename	: draft-carpenter-extension-recs-00.txt
	Pages		: 15
	Date		: 2006-10-12
	
   This document discusses issues related to the extensibility of IETF
   protocols, with a focus on the architectural design considerations
   involved.  Concrete case study examples are included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-extension-recs-00.tx
t

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-carpenter-extension-recs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-carpenter-extension-recs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C6F04C.8333E0D0
Content-Type: application/octet-stream;
	name="ATT138496.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT138496.TXT
Content-Disposition: attachment;
	filename="ATT138496.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0xMC0xMjExMzkzOS5JLURAaWV0Zi5vcmc+DQoNCkVO
Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jYXJwZW50ZXItZXh0ZW5z
aW9uLXJlY3MtMDAudHh0DQo
------_=_NextPart_001_01C6F04C.8333E0D0
Content-Type: application/octet-stream;
	name="draft-carpenter-extension-recs-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-carpenter-extension-recs-00.URL
Content-Disposition: attachment;
	filename="draft-carpenter-extension-recs-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1jYXJwZW50ZXItZXh0ZW5zaW9uLXJlY3MtMDAudHh0DQo
------_=_NextPart_001_01C6F04C.8333E0D0
Content-Type: text/plain;
	name="ATT138496.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT138496.txt
Content-Disposition: attachment;
	filename="ATT138496.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo
------_=_NextPart_001_01C6F04C.8333E0D0--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Fri, 13 Oct 2006 00:12:45 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
cc:
Subject: ISSUE: Table of attributes in RFC 4590
Message-Id: <[email-masked]>
Date: Tue, 26 Sep 2006 13:31:18 -0400 (EDT)

Description of issue: The table of attributes in Section 5 of RFC 4590
lists "0-1", or "0+" for all of the Digest attributes in the
Access-Request.  This would seem to indicate that we can have Digest
authentication where no Digest attributes exist in the Access-Request.

Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: Sept. 26, 2006
Reference: 
Document: RFC 4590
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:

The body text, and examples in Section 6 appear to indicate that at
least Digest-Method is required in every Access-Request.  Yet in
Section 5, the Table of Attributes indicates that no Digest attributes
are required in an Access-Request packet.

I first ran into this issue when I was looking at an implementation of
RFC 4590, and wanted to enforce the requirement that the
Message-Authenticator attribute must appear in every packet
implementing Digest authentication.  If the server sends an
Access-Accept or Access-Challenge packet with Digest attributes, it is
simple to determine that the Message-Authenticator must be included in
the packet.

However, for Access-Request, there appears to be no way to determine
if the request is, in fact a request for Digest authentication,
because there is no requirement that any Digest attributes exist in
the Access-Request.

Reading Section 1.3, the paragraph at the top of page 6 seems to
indicate that a Digest-Method is always sent in an Access-Request.
Other text in the document also indicates that the first
Access-Request always contains a Digest-Method attribute.

It may be that Digest-Method does NOT have to appear in Access-Request
if the Access-Request is in response to an Access-Challenge, but this
is not clear from the text.  My recommendation is to make
Digest-Method required in the Access-Request, which simplifies
implementation.  It also appears that this requirement is the intent
in RFC 4590, because all of the examples have Digest-Method in every
Access-Request.

I also have noted that none of the Access-Challenges in the examples
contain a State attribute, and the State attribute is not mentioned
anywhere in RFC 4590.  That indicates to me that the Access-Request in
response to an Access-Challenge MUST contain sufficient information to
finish the authentication process, and have the server return either
Access-Accept or Access-Reject.  The alternative is for the server to
repeatedly challenge the client, which does not appear to be the
intent.

That says to me that the Access-Challenge MUST contain a State
attribute, which is copied to the subsequent Access-Request.  The
server MUST respond with either an Access-Accept or Access-Reject to
an Access-Request that contains a State attribute.  The server MUST
NOT respond with Access-Challenge to an Access-Request that contains a
State attribute.

I believe that may be another issue.

Requested change:

Update the Table of Attributes as follows:

.
   | 1   | 0      | 0      | 0         | 108 | Digest-Method           |
.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 12 Oct 2006 23:26:53 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Serious error in RFC4590
Date: Sat, 23 Sep 2006 05:52:01 -0700

I agree that we need to get the IANA web pages corrected and also need to 
submit an errata to the RFC Editor.

However, I'm concerned that even with these measures, there is the potential 
for confusion to linger.  As I recall, the original RADIUS RFCs had to be 
re-issued to fix a port allocation problem.

I'm wondering what the WG thinks we should do in this situation.

>---------- Forwarded message ----------
>Date: Thu, 21 Sep 2006 09:21:55 +0200
>From: "Beck01, Wolfgang" <[email-masked]>
>To: [email-masked], [email-masked], [email-masked],
>     [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: AW: Serious error in RFC4590
>
>Alexander
>
> > In table 2 the Digest-Nextnonce and Digest-Response-Auth are
> > numbered 106 and 107. But furthur down they are numbered in
> > reverse order.
>This is ugly. The numbering is consistent in the main text
>and in the attributes table. The exception is section 7, IANA
>considerations. It's wrong in the IANA registry www.iana.org
>as well.
>
>Not an excuse, but an explanation: the IANA section is inserted
>at the end of the standardization process. It did not get the
>same attention and review time as the rest of the text.
>
> > If you already know about this problem I am sorry for
> > spamming you. But I feel it is important that this error
> > doesn't sneek it's way into implementations...
>
>Hopefully, the implementors will stick to the text and to the
>attribute table in section 5.
>
>I've cc'ed this mail to the chairs of the RADEXT WG. We should
>correct the IANA registry entries and issue an errata.
>
>106 is Digest-Response-Auth
>107 is Digest-Nextnonce
>
>Wolfgang
>
>--
>T-Systems
>Next Generation IP Services and Systems
>+49 6151 937 2863
>Am Kavalleriesand 3
>64295 Darmstadt
>Germany

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 12 Oct 2006 08:59:47 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
cc:
Subject: ISSUE: Table of attributes in RFC 4590
Message-Id: <[email-masked]>
Date: Tue, 26 Sep 2006 13:31:18 -0400 (EDT)

Description of issue: The table of attributes in Section 5 of RFC 4590
lists "0-1", or "0+" for all of the Digest attributes in the
Access-Request.  This would seem to indicate that we can have Digest
authentication where no Digest attributes exist in the Access-Request.

Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: Sept. 26, 2006
Reference: 
Document: RFC 4590
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:

The body text, and examples in Section 6 appear to indicate that at
least Digest-Method is required in every Access-Request.  Yet in
Section 5, the Table of Attributes indicates that no Digest attributes
are required in an Access-Request packet.

I first ran into this issue when I was looking at an implementation of
RFC 4590, and wanted to enforce the requirement that the
Message-Authenticator attribute must appear in every packet
implementing Digest authentication.  If the server sends an
Access-Accept or Access-Challenge packet with Digest attributes, it is
simple to determine that the Message-Authenticator must be included in
the packet.

However, for Access-Request, there appears to be no way to determine
if the request is, in fact a request for Digest authentication,
because there is no requirement that any Digest attributes exist in
the Access-Request.

Reading Section 1.3, the paragraph at the top of page 6 seems to
indicate that a Digest-Method is always sent in an Access-Request.
Other text in the document also indicates that the first
Access-Request always contains a Digest-Method attribute.

It may be that Digest-Method does NOT have to appear in Access-Request
if the Access-Request is in response to an Access-Challenge, but this
is not clear from the text.  My recommendation is to make
Digest-Method required in the Access-Request, which simplifies
implementation.  It also appears that this requirement is the intent
in RFC 4590, because all of the examples have Digest-Method in every
Access-Request.

I also have noted that none of the Access-Challenges in the examples
contain a State attribute, and the State attribute is not mentioned
anywhere in RFC 4590.  That indicates to me that the Access-Request in
response to an Access-Challenge MUST contain sufficient information to
finish the authentication process, and have the server return either
Access-Accept or Access-Reject.  The alternative is for the server to
repeatedly challenge the client, which does not appear to be the
intent.

That says to me that the Access-Challenge MUST contain a State
attribute, which is copied to the subsequent Access-Request.  The
server MUST respond with either an Access-Accept or Access-Reject to
an Access-Request that contains a State attribute.  The server MUST
NOT respond with Access-Challenge to an Access-Request that contains a
State attribute.

I believe that may be another issue.

Requested change:

Update the Table of Attributes as follows:

..
   | 1   | 0      | 0      | 0         | 108 | Digest-Method           |
..

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 12 Oct 2006 05:59:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Serious error in RFC4590
Date: Sat, 23 Sep 2006 05:52:01 -0700

I agree that we need to get the IANA web pages corrected and also need to 
submit an errata to the RFC Editor.

However, I'm concerned that even with these measures, there is the potential 
for confusion to linger.  As I recall, the original RADIUS RFCs had to be 
re-issued to fix a port allocation problem.

I'm wondering what the WG thinks we should do in this situation.

>---------- Forwarded message ----------
>Date: Thu, 21 Sep 2006 09:21:55 +0200
>From: "Beck01, Wolfgang" <[email-masked]>
>To: [email-masked], [email-masked], [email-masked],
>     [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: AW: Serious error in RFC4590
>
>Alexander
>
> > In table 2 the Digest-Nextnonce and Digest-Response-Auth are
> > numbered 106 and 107. But furthur down they are numbered in
> > reverse order.
>This is ugly. The numbering is consistent in the main text
>and in the attributes table. The exception is section 7, IANA
>considerations. It's wrong in the IANA registry www.iana.org
>as well.
>
>Not an excuse, but an explanation: the IANA section is inserted
>at the end of the standardization process. It did not get the
>same attention and review time as the rest of the text.
>
> > If you already know about this problem I am sorry for
> > spamming you. But I feel it is important that this error
> > doesn't sneek it's way into implementations...
>
>Hopefully, the implementors will stick to the text and to the
>attribute table in section 5.
>
>I've cc'ed this mail to the chairs of the RADEXT WG. We should
>correct the IANA registry entries and issue an errata.
>
>106 is Digest-Response-Auth
>107 is Digest-Nextnonce
>
>Wolfgang
>
>--
>T-Systems
>Next Generation IP Services and Systems
>+49 6151 937 2863
>Am Kavalleriesand 3
>64295 Darmstadt
>Germany

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 10 Oct 2006 19:50:49 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-04.txt 
Date: Tue, 10 Oct 2006 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Delegated-IPv6-Prefix Attribute
	Author(s)	: J. Salowey, R. Droms
	Filename	: draft-ietf-radext-delegated-prefix-04.txt
	Pages		: 8
	Date		: 2006-10-10
	
This document defines a RADIUS (Remote Authentication Dial In User
Service) attribute that carries an IPv6 prefix that is to be
delegated to the user.  This attribute is usable within either RADIUS
or Diameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-delegated-prefix-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-delegated-prefix-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-delegated-prefix-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-delegated-prefix-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 06 Oct 2006 19:01:04 +0000
Content-Class: urn:content-classes:message
Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt
Date: Fri, 6 Oct 2006 14:59:54 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: "Behcet Sarikaya" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E979.9C421BB5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 

________________________________

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, October 06, 2006 10:35 AM
To: Chowdhury, Kuntal
Cc: [email-masked]
Subject: Re: Review requested: draft-ietf-radext-delegated-prefix-03.txt

Hi Kuntal,

Comments inline.

Regards,

--behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <[email-masked]>
To: [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, October 03, 2006 5:04 PM
To: ' Behcet Sarikaya '
Cc: [email-masked]
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: [email-masked]
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 < [email-masked] >
To: [email-masked]
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-0
3.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 [email-masked] 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
[email-masked] -- and destroy all copies of this message
and any attachments without reading or disclosing their contents. Thank
you." 

------_=_NextPart_001_01C6E979.9C421BB5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
_filtered {font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
_filtered {font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
_filtered {font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
_filtered {
panose-1:0 0 0 0 0 0 0 0 0 0;}
_filtered {
margin:1.0in 1.25in 1.0in 1.25in;}

 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.emailstyle17
	{font-family:Arial;
	color:navy;}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Behcet Sarikaya</st1:PersonName> [mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, October 06, 2006
10:35 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Chowdhury, Kuntal<br>
<b><span style='font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: Review requested:
draft-ietf-radext-delegated-prefix-03.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Hi Kuntal,<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Comments inline.<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Regards,<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>--behcet<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>----- Original Message
----<br>
From: &quot;Chowdhury, Kuntal&quot; &lt;[email-masked]&gt;<br>
To: [email-masked]<br>
Sent: Thursday, October 5, 2006 11:23:33 PM<br>
Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I don&#8217;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:</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;&nbsp;&nbsp; </span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The Delegated-IPv6-Prefix is a RADIUS
attribute [1] that carries an</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; IPv6 prefix to be delegated
to the user, for use in the user's</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; network.&nbsp; </span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>==&gt; True. So I suggest &nbsp;the
following fix:</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The Delegated-IPv6-Prefix is a new RADIUS
[1] attribute that carries an ...</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;</span></font><font size=2
face=Arial><span style='font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[KC&gt;] Ok, but I still think referencing RFC 2865 in the
above sentence is odd. A _</span></font></i></b><b><i><font size=2 color=navy
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:navy;
font-weight:bold;font-style:italic'>new</span></font></i></b><b><i><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>_ attribute cannot be in an RFC
unless the RFC is revised. This is just an editorial nit, IMHO.<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></b></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>For example, the prefix in a
Delegated-IPv6-Prefix</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; attribute can be delegated to
another node through DHCP Prefix</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; Delegation [2].</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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. &nbsp;I request
that the authors clarify using this figure where the RADIUS transaction with
this attribute applies.</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;==&gt; I think you missed the point
with this whole draft.</span></font><font size=2 face=Arial><span
style='font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 color=navy face="Times New Roman"><span
style='font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[KC&gt;] Since you seem to have understood the point in the
draft very well, why don&#8217;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. &nbsp;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)? <o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>The text in this draft SHOULD clarify the use case.<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></b></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>-Kuntal</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font><o:p></o:p></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabIndex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Bernard Aboba<br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, October 03, 2006
5:04 PM<br>
<b><span style='font-weight:bold'>To:</span></b> ' <st1:PersonName w:st="on">Behcet
 Sarikaya</st1:PersonName> '<br>
<b><span style='font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: Review requested:
draft-ietf-radext-delegated-prefix-03.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>In RADIUS/Diameter Accounting messages
announce both the beginning and end of a session. </span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font><o:p></o:p></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabIndex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Behcet Sarikaya</st1:PersonName> [mailto:behcetsarikaya@ yahoo .com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, October 03, 2006
2:05 PM<br>
<b><span style='font-weight:bold'>To:</span></b> Bernard Aboba<br>
<b><span style='font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: Review requested:
draft-ietf-radext-delegated-prefix-03.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Hello Bernard, I agree with your changes, please also add
this typo too:</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>The AVP flag rules [5] for the Delegate-IPv6-Prefix
attribute are:<br>
-&gt;The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:<br>
<br>
Is session termination communicated with Accounting Request message in
Radius/Diameter?</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Behcet</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>----- Original Message
----<br>
From: Bernard Aboba &lt; <st1:PersonName w:st="on">[email-masked]</st1:PersonName>
&gt;<br>
To: [email-masked]<br>
Sent: Tuesday, October 3, 2006 3:21:42 PM<br>
Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>A new version of the Delegated Prefix attribute has been posted to the <br>
archive:<br>
<a
href="http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt"
target="_blank">http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt</a><br>
<br>
This document has already gone through IESG review, so it is one step away <br>
from publication.<br>
<br>
Can people take a look at it?<br>
<br>
I found one typo, in Section 5:<br>
<br>
&nbsp;&nbsp; The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;AVP
Flag rules&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|----+-----+----+-----|----+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AVP&nbsp;&nbsp;Section&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |SHLD|
MUST|&nbsp;&nbsp;&nbsp;&nbsp;|<br>
&nbsp;&nbsp; Attribute Name&nbsp;&nbsp;Code Defined&nbsp;&nbsp;Value Type
|MUST| MAY | NOT|&nbsp;&nbsp;NOT|Encr|<br>
&nbsp;&nbsp;
-----------------------------------------|----+-----+----+-----|----|<br>
&nbsp;&nbsp;
Framed-IPv6-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;97&nbsp;&nbsp;6.11.6&nbsp;&nbsp;OctetString|
M&nbsp;&nbsp;|&nbsp;&nbsp;P&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;V&nbsp;&nbsp;|
Y&nbsp;&nbsp;|<br>
&nbsp;&nbsp;&nbsp;&nbsp;
Prefix&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|<br>
<br>
<br>
Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix; <br>
the AVP should be TBD instead of 97, and the Section Defined entry should be <br>
deleted.<br>
<br>
One other quibble.&nbsp;&nbsp; In Section 1, it is stated:<br>
<br>
&quot;&nbsp;&nbsp; The Framed-IPv6-Prefix attribute [4] is not designed to
carry an IPv6<br>
&nbsp;&nbsp; prefix to be used in the user's network, and therefore
Framed-IPv6-<br>
&nbsp;&nbsp; Prefix and Delegated-IPv6-Prefix attributes may be included in the<br>
&nbsp;&nbsp; same RADIUS packet.&quot;<br>
<br>
It strikes me that this statement is not necessarily accurate.&nbsp;&nbsp;For
example, <br>
if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix <br>
attribute *could* be used to carry an IPv6 prefix to be used in the user's <br>
network.&nbsp;&nbsp;However, if we are talking about a router, then this will
not <br>
work.&nbsp;&nbsp;So I think the sentence should be changed to:<br>
<br>
&quot;&nbsp;&nbsp;The Framed-IPv6-Prefix attribute [4] is not designed to
support <br>
delegation of prefixes to<br>
&nbsp;&nbsp; be used in the user's network, and therefore Framed-IPv6-Prefix
and <br>
Delegated-IPv6-Prefix<br>
&nbsp;&nbsp; attributes may be included in the same RADIUS packet.&quot;<br>
<br>
<br>
<br>
--<br>
to unsubscribe send a message to <st1:PersonName w:st="on">[email-masked]</st1:PersonName>
with<br>
the word 'unsubscribe' in a single line as the message text body.<br>
archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>&gt;<o:p></o:p></span></font></p>

</div>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;</span></font><o:p></o:p></p>

</div>

</div>

</div>

</div>

<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>&quot;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 [email-masked] -- and destroy all copies of
this message and any attachments without reading or disclosing their contents.
Thank you.&quot; <o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6E979.9C421BB5--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 06 Oct 2006 04:24:30 +0000
Content-Class: urn:content-classes:message
Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt
Date: Fri, 6 Oct 2006 00:23:33 -0400
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E8FF.2F4ECD90
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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.

"

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.

-Kuntal

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, October 03, 2006 5:04 PM
To: 'Behcet Sarikaya'
Cc: [email-masked]
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:[email-masked]] 
Sent: Tuesday, October 03, 2006 2:05 PM
To: Bernard Aboba
Cc: [email-masked]
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 <[email-masked]>
To: [email-masked]
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-0
3.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 [email-masked] 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 [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

------_=_NextPart_001_01C6E8FF.2F4ECD90
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="mswterms"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="time"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="date"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I don&#8217;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:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;&nbsp;&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The Delegated-IPv6-Prefix is a RADIUS
attribute [1] that carries an<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; IPv6 prefix to be delegated
to the user, for use in the user's<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; network.&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>For example, the prefix in a
Delegated-IPv6-Prefix<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; attribute can be delegated to
another node through DHCP Prefix<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; Delegation [2].<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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. &nbsp;I request
that the authors clarify using this figure where the RADIUS transaction with
this attribute applies.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>-Kuntal<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Bernard Aboba<br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, October 03, 2006
5:04 PM<br>
<b><span style='font-weight:bold'>To:</span></b> '<st1:PersonName w:st="on">Behcet
 Sarikaya</st1:PersonName>'<br>
<b><span style='font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: Review requested:
draft-ietf-radext-delegated-prefix-03.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>In RADIUS/Diameter Accounting messages
announce both the beginning and end of a session. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> <st1:PersonName
w:st="on">Behcet Sarikaya</st1:PersonName> [mailto:behcetsarikaya@<st1:mswterms
w:st="on">yahoo</st1:mswterms>.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, <st1:date
Year="2006" Day="03" Month="10" ls="trans" w:st="on">October 03, 2006</st1:date>
<st1:time Minute="05" Hour="14" w:st="on">2:05 PM</st1:time><br>
<b><span style='font-weight:bold'>To:</span></b> Bernard Aboba<br>
<b><span style='font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: Review requested:
draft-ietf-radext-delegated-prefix-03.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Hello Bernard, I agree with your changes, please also add
this typo too:<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>The AVP flag rules [5] for the Delegate-IPv6-Prefix
attribute are:<br>
-&gt;The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:<br>
<br>
Is session termination communicated with Accounting Request message in
Radius/Diameter?<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Thanks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Behcet<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>----- Original Message
----<br>
From: Bernard Aboba &lt;<st1:PersonName w:st="on">[email-masked]</st1:PersonName>&gt;<br>
To: [email-masked]<br>
Sent: Tuesday, <st1:date Year="2006" Day="3" Month="10" ls="trans" w:st="on">October
 3, 2006</st1:date> 3:21:42 PM<br>
Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>A new version of the Delegated Prefix attribute has been posted to the <br>
archive:<br>
<a
href="http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt"
target="_blank">http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt</a><br>
<br>
This document has already gone through IESG review, so it is one step away <br>
from publication.<br>
<br>
Can people take a look at it?<br>
<br>
I found one typo, in Section 5:<br>
<br>
&nbsp;&nbsp; The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;AVP
Flag rules&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|----+-----+----+-----|----+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AVP&nbsp;&nbsp;Section&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |SHLD|
MUST|&nbsp;&nbsp;&nbsp;&nbsp;|<br>
&nbsp;&nbsp; Attribute Name&nbsp;&nbsp;Code Defined&nbsp;&nbsp;Value Type
|MUST| MAY | NOT|&nbsp;&nbsp;NOT|Encr|<br>
&nbsp;&nbsp; -----------------------------------------|----+-----+----+-----|----|<br>
&nbsp;&nbsp;
Framed-IPv6-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;97&nbsp;&nbsp;6.11.6&nbsp;&nbsp;OctetString|
M&nbsp;&nbsp;|&nbsp;&nbsp;P&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;V&nbsp;&nbsp;|
Y&nbsp;&nbsp;|<br>
&nbsp;&nbsp;&nbsp;&nbsp;
Prefix&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;|<br>
<br>
<br>
Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix; <br>
the AVP should be TBD instead of 97, and the Section Defined entry should be <br>
deleted.<br>
<br>
One other quibble.&nbsp;&nbsp; In Section 1, it is stated:<br>
<br>
&quot;&nbsp;&nbsp; The Framed-IPv6-Prefix attribute [4] is not designed to
carry an IPv6<br>
&nbsp;&nbsp; prefix to be used in the user's network, and therefore
Framed-IPv6-<br>
&nbsp;&nbsp; Prefix and Delegated-IPv6-Prefix attributes may be included in the<br>
&nbsp;&nbsp; same RADIUS packet.&quot;<br>
<br>
It strikes me that this statement is not necessarily accurate.&nbsp;&nbsp;For
example, <br>
if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix <br>
attribute *could* be used to carry an IPv6 prefix to be used in the user's <br>
network.&nbsp;&nbsp;However, if we are talking about a router, then this will
not <br>
work.&nbsp;&nbsp;So I think the sentence should be changed to:<br>
<br>
&quot;&nbsp;&nbsp;The Framed-IPv6-Prefix attribute [4] is not designed to
support <br>
delegation of prefixes to<br>
&nbsp;&nbsp; be used in the user's network, and therefore Framed-IPv6-Prefix
and <br>
Delegated-IPv6-Prefix<br>
&nbsp;&nbsp; attributes may be included in the same RADIUS packet.&quot;<br>
<br>
<br>
<br>
--<br>
to unsubscribe send a message to <st1:PersonName w:st="on">[email-masked]</st1:PersonName>
with<br>
the word 'unsubscribe' in a single line as the message text body.<br>
archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>&gt;<o:p></o:p></span></font></p>

</div>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</div>

<P>"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 [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."</body>

</html>

------_=_NextPart_001_01C6E8FF.2F4ECD90--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 18:22:45 +0000
Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Wed, 4 Oct 2006 14:22:04 -0400
From: "Avi Lior" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Okay Barney.

So at one hand having 61 rules is definitely limiting -- that is you see
an application that would require more then 61 rules.  Therefore
regardless of how we handle fragmentation, by the same token 16 rules
will not sufficie either and we need another solution whereby we can
send on the order of 60 rules whether they fragment or not.

But realistically, perhaps we need in the order of 10 rules where some
may overflow - or something like that.

With respect to apriori knowledge of RADIUS client knowing about
fragementation, I agree that it is an advantage but only marginally.

The current scheme has issues as I pointed out in the first email.

BTW you can have grouping and fragmentation if you use the approach
whereby you use the most significant bit of the TAG as fragmentation
bit.  The rest of the bits of the tag are used for grouping.

If you don't have fragmentation the the MSB is clear.  If you have
fragmentation the MSB is set.

If you don't have grouping the 7 LSBs are zero, if you do have grouping
then the 7LSBs indicate the group id.

So we can have our cake an eat it too!!!

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Wednesday, October 04, 2006 1:35 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Proposed Resolution to Issue 198: Attribute 
> Concatenation/Splitting
> 
> On Wed, Oct 04, 2006 at 01:00:10PM -0400, Avi Lior wrote:
> > 
> > Do you think that allowing 62 NAS Filter rules per message 
> is limiting?
> 
> Yes, definitely.
> 
> > If yes then I suggest that even with the existing text we have an 
> > unreasonable limitation since I can only support 61 NAS 
> Filter Rules 
> > per message that overflow.
> 
> Well, no.  4096/255 is about 16.
> 
> > > Why would we want to hide from the receiver whether a 
> rule is going 
> > > to be segmented?
> > 
> > We are not.  The receiver can easily detect that a rule is a 
> > continuation.
> 
> Only when it sees the continuation, if every rule needs a unique tag.
> It would be useful, potentially, to know when seeing the 
> first part of the rule that there is more to come.
> 
> > Note that both approaches (or all approaches) presented so 
> far have a 
> > flaw in that they will prevent us from grouping 
> NAS-Filter-Rules into 
> > groups of rules.  This could be harmful in the future.  We 
> arleady see 
> > evidence that a filter-rule can be used for several 
> purposes.  We wont 
> > be able to express these in RADIUS.
> 
> There was an attempt to provide such power for RADIUS, by 
> adopting the Diameter attribute header.  It did not meet with 
> group approval.  Of course I would prefer to see a general 
> mechanism for handling both grouping and segmentation, rather 
> than have to debate it over again for every attribute that 
> might need such facilities.
> 
> -- 
> Barney Wolff         I never met a computer I didn't like.
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 17:53:06 +0000
Date: Wed, 4 Oct 2006 13:51:38 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

On Wed, Oct 04, 2006 at 10:15:01AM -0700, Bernard Aboba wrote:
> >Why would we want to limit the number of possible rules?
> 
> I don't think we want to do that.  As a Glen has pointed out, there are 
> deployments in which a very large number of rules are being used.
> 
> >Why would we want to hide from the receiver whether a rule is going
> >to be segmented?
> 
> It's probably best not to hide that from the receiver.
> 
> >	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
> >	continuation of this one.  If TAG is zero, this attribute is
> >	the last or only segment of this rule.
> 
> So if a continued filter is followed by a non-continued one, then we have 
> two attributes with zero (0) tag fields?

Yes.  What's wrong with that?

> Why not just say that the tag field needs to be different between adjacent 
> filter rules, with the exception of a zero tag that represents a 
> non-continued filter rule?

A rule may potentially need more than two segments.  The receiver might
like to be able to predict whether a rule is 504 octets or >P5 before
seeing the next attribute.

Once we're using the Tag only for continuation, and not for grouping,
it really is a 1-bit field, and different nonzero values convey no
meaning.  If we want grouping as well, Avi's idea of using the hi-bit
of the Tag for continuation is a good one, at the cost of making it 
harder to enter the value by typing ASCII.  Perhaps we should use the
low-bit for continuation, leaving the high 7 for grouping.

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 17:35:15 +0000
Date: Wed, 4 Oct 2006 13:34:44 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

On Wed, Oct 04, 2006 at 01:00:10PM -0400, Avi Lior wrote:
> 
> Do you think that allowing 62 NAS Filter rules per message is limiting?

Yes, definitely.

> If yes then I suggest that even with the existing text we have an
> unreasonable limitation since I can only support 61 NAS Filter Rules per
> message that overflow.

Well, no.  4096/255 is about 16.

> > Why would we want to hide from the receiver whether a rule is 
> > going to be segmented?
> 
> We are not.  The receiver can easily detect that a rule is a
> continuation.

Only when it sees the continuation, if every rule needs a unique tag.
It would be useful, potentially, to know when seeing the first part of
the rule that there is more to come.

> Note that both approaches (or all approaches) presented so far have a
> flaw in that they will prevent us from grouping NAS-Filter-Rules into
> groups of rules.  This could be harmful in the future.  We arleady see
> evidence that a filter-rule can be used for several purposes.  We wont
> be able to express these in RADIUS.

There was an attempt to provide such power for RADIUS, by adopting the
Diameter attribute header.  It did not meet with group approval.  Of
course I would prefer to see a general mechanism for handling both
grouping and segmentation, rather than have to debate it over again
for every attribute that might need such facilities.

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 17:30:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Resolution to Issue 198: Another attempt
Date: Wed, 04 Oct 2006 10:30:10 -0700

So as to lessen restrictions on the number of potential rules, here is 
another attempt at text relating to the Tag field.  Is this better?

"  Tag

      The Tag field is used to identify the filter rule that is
      represented; the length of the Tag field is one octet and it MUST
      always be present.

      Where a single filter rule is less than or equal to 252 octets in
      length, it MUST be encoded with a Tag field value of zero (0) and
      MUST NOT be split between multiple NAS-Filter-Rule attributes.  On
      receipt, attributes with a Tag field value of zero (0) MUST NOT be
      concatenated to form a single filter rule.

      Where a single filter rule exceeds 252 octets in length, the rule
      MUST be encoded across multiple NAS-Filter-Rule attributes, each
      with the same Tag value which MUST be in the range 0x01 - 0x3F.
      NAS-Filter-Rule attributes comprising a single filter rule MUST be 
sent
      consecutively, without intervening attributes with another Tag
      field value.  The Tag field value of 0xFF is reserved and 
NAS-Filter-Rule
      attributes containing this Tag field value should be ignored upon 
receipt.

      Adjacent filter rules exceeding 252 octets in length MUST be
      encoded with different non-zero Tag field values; however, the Tag
      field value used for a given filter rule need not be unique within
      the entire RADIUS packet.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 17:17:58 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Wed, 04 Oct 2006 10:15:01 -0700

>Why would we want to limit the number of possible rules?

I don't think we want to do that.  As a Glen has pointed out, there are 
deployments in which a very large number of rules are being used.

>Why would we want to hide from the receiver whether a rule is going
>to be segmented?

It's probably best not to hide that from the receiver.

>	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
>	continuation of this one.  If TAG is zero, this attribute is
>	the last or only segment of this rule.

So if a continued filter is followed by a non-continued one, then we have 
two attributes with zero (0) tag fields?

Why not just say that the tag field needs to be different between adjacent 
filter rules, with the exception of a zero tag that represents a 
non-continued filter rule?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 17:00:49 +0000
Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Wed, 4 Oct 2006 13:00:10 -0400
From: "Avi Lior" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney,

Do you think that allowing 62 NAS Filter rules per message is limiting?

If yes then I suggest that even with the existing text we have an
unreasonable limitation since I can only support 61 NAS Filter Rules per
message that overflow.

I just think that allowing for 62 per packet is more then enough.

> Why would we want to hide from the receiver whether a rule is 
> going to be segmented?

We are not.  The receiver can easily detect that a rule is a
continuation.

If you want we can use the MSB to indicate whether an attribute is
continuation or not.  This is what I am proposing for Extended RADIUS.

> The "TAG thing" is very complex because we're using an 8-bit 
> field to convey 1 bit of meaning.  We could just as well say:
> 
> 	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
> 	continuation of this one.  If TAG is zero, this attribute is
> 	the last or only segment of this rule.
> 
> The attempt to reuse the existing tag mechanism has failed.  
> It's time to move on.

So I agree with that as well.

This is another issue.

Note that both approaches (or all approaches) presented so far have a
flaw in that they will prevent us from grouping NAS-Filter-Rules into
groups of rules.  This could be harmful in the future.  We arleady see
evidence that a filter-rule can be used for several purposes.  We wont
be able to express these in RADIUS.

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Wednesday, October 04, 2006 12:38 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Proposed Resolution to Issue 198: Attribute 
> Concatenation/Splitting
> 
> On Wed, Oct 04, 2006 at 12:22:41PM -0400, Avi Lior wrote:
> > 
> > This TAG thing is very complex. We can get rid of the '0' tag 
> > requirement by saying that every NAS Filter Rule MUST have a unique 
> > non-zero TAG value in the range of 0x01 to 0x3F.
> > If an NAS filter rule attribute needs to be fragmeneted (length is 
> > greater then 252) then the fragments is placed in a subsequent 
> > NAS-Filter-Rule attribute and the same TAG value is used.
> 
> Why would we want to limit the number of possible rules?
> Why would we want to hide from the receiver whether a rule is 
> going to be segmented?
> 
> The "TAG thing" is very complex because we're using an 8-bit 
> field to convey 1 bit of meaning.  We could just as well say:
> 
> 	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
> 	continuation of this one.  If TAG is zero, this attribute is
> 	the last or only segment of this rule.
> 
> The attempt to reuse the existing tag mechanism has failed.  
> It's time to move on.
> 
> -- 
> Barney Wolff         I never met a computer I didn't like.
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 16:38:21 +0000
Date: Wed, 4 Oct 2006 12:37:50 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

On Wed, Oct 04, 2006 at 12:22:41PM -0400, Avi Lior wrote:
> 
> This TAG thing is very complex. We can get rid of the '0' tag
> requirement by saying that every NAS Filter Rule MUST have a unique
> non-zero TAG value in the range of 0x01 to 0x3F.
> If an NAS filter rule attribute needs to be fragmeneted (length is
> greater then 252) then the fragments is placed in a subsequent
> NAS-Filter-Rule attribute and the same TAG value is used. 

Why would we want to limit the number of possible rules?
Why would we want to hide from the receiver whether a rule is going
to be segmented?

The "TAG thing" is very complex because we're using an 8-bit field
to convey 1 bit of meaning.  We could just as well say:

	If TAG is non-zero, the next NAS-Filter-Rule attribute is a
	continuation of this one.  If TAG is zero, this attribute is
	the last or only segment of this rule.

The attempt to reuse the existing tag mechanism has failed.  It's
time to move on.

-- 
Barney Wolff         I never met a computer I didn't like.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Oct 2006 16:24:17 +0000
Subject: RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting
Date: Wed, 4 Oct 2006 12:22:41 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Bernard and all,

This TAG thing is very complex. We can get rid of the '0' tag
requirement by saying that every NAS Filter Rule MUST have a unique
non-zero TAG value in the range of 0x01 to 0x3F.
If an NAS filter rule attribute needs to be fragmeneted (length is
greater then 252) then the fragments is placed in a subsequent
NAS-Filter-Rule attribute and the same TAG value is used. 

Anyway...here are some comments on the proposed text... See inline...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 4:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Proposed Resolution to Issue 198: Attribute 
> Concatenation/Splitting
> 
> How about this?
> 
>    Tag
> 
>       The Tag field is used to identify the filter rule that is
>       represented; 

The tag field is not identifying the filter rule because filter rules
that are not fragmented will have a tag of '0'. My proposal above makes
the TAG identify the filter rule uniquely.

> the length of the Tag field is one octet 
> and it MUST
>       always be present.  The Tag field value MUST be in the range
>       0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of
>       0x00 are ignored upon receipt.
> 
>       Where a single filter rule is less than or equal to 252 
> octets in
>       length, it MUST be encoded with a tag value of '0' 
> (0x30) and MUST
>       NOT be split between multiple NAS-Filter-Rule 
> attributes.  Where a
>       single filter rule is split into multiple NAS-Filter-Rule
>       attributes, the attributes SHOULD be sent consecutively, without
>       intervening attributes with another Tag field value.  

I think you want to say:

"the attributes MUST be sent consecutively, without intervening
NAS-Filter-Rule attributes with a different Tag field value."

RADIUS already covers in order delivery.

Yes the above statement does allow for a RADIUS server to insert other
attributes between two NAS-Filter-Rules.  And yes receivers have to cope
with that. However that is allowed behavior of RADIUS and we must not
change that even with a SHOULD.

> On receipt,
>       attributes with a Tag value of '0' (0x30) MUST NOT be 
> concatenated
>       to form a single filter rule.
> 
>       Where a single filter rule exceeds 252 octets in 
> length, the rule
>       MUST be encoded across multiple NAS-Filter-Rule attributes, each
>       with the same Tag value which MUST NOT be '0' (0x30).  
> Tag values
>       MUST be unique for each filter rule present in a RADIUS packet
>       with the exception of a Tag value of '0' (0x30), which 
> may be used
>       in multiple attributes, each describing a single filter rule.
> 
> 
> >From: Barney Wolff <[email-masked]>
> >To: Bernard Aboba <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: Proposed Resolution to Issue 198: Attribute 
> >Concatenation/Splitting
> >Date: Fri, 29 Sep 2006 14:57:30 -0400
> >
> >On Thu, Sep 28, 2006 at 11:27:23PM -0700, Bernard Aboba wrote:
> > >   Tag
> > >
> > >      The Tag field is one octet, and MUST always be 
> present.  It is
> > >      used to identify the filter rule that is 
> represented.  Where a
> > >      single filter rule exceeds 253 octets in length, the 
> rule MUST be
> > >      encoded across multiple NAS-Filter-Rule attributes, 
> each with the
> > >      same Tag value; Tag values MUST be unique for each 
> filter rule
> > >      present in a RADIUS packet with the exception of a 
> Tag value of
> > >      '0' (0x30).  The value of '0' (0x30) in the Tag 
> field indicates
> > >      that the attribute contains a filter rule that does 
> not exceed 253
> > >      octets in length; as a result attributes with a Tag 
> value of 0x30
> > >      MUST NOT be concatenated, and one or more 
> Filter-Rule attributes
> > >      with a tag value of 0x30 may be included in a single RADIUS
> > >      packet, each describing a single filter rule.
> >
> >May I suggest that NAS-Filter-Rule attributes with different 
> tag values 
> >MUST NOT appear between the segments into which a long rule is split?
> >There is no benefit to the sender to allowing anything else, and 
> >considerable nuisance to the receiver.
> >
> >Also, I suggest that a rule which is not split MUST have tag 
> value '0'.
> >Again, there is no value to the sender for anything else, 
> and this way 
> >the receiver can know whether a rule is going to be 
> extended.  Perhaps 
> >the language implying that a rule <252 octets MUST NOT be 
> split should 
> >be made more explicit, too.
> >
> >As an aside, it is a general misfeature of RADIUS that senders are 
> >allowed to do things, such as random ordering of attributes, 
> that have 
> >little value for the sender but cause hardship for the receiver.  We 
> >are all so used to this nuisance that we hardly perceive it as such.
> >
> >--
> >Barney Wolff         I never met a computer I didn't like.
> >
> >--
> >to unsubscribe send a message to [email-masked] with 
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 03 Oct 2006 22:04:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Behcet Sarikaya'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Review requested: draft-ietf-radext-delegated-prefix-03.txt
Date: Tue, 3 Oct 2006 15:04:17 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C6E6FD.3293A8D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

  _____  

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 2:05 PM
To: Bernard Aboba
Cc: [email-masked]
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 <[email-masked]>
To: [email-masked]
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.tx
t

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------=_NextPart_000_0009_01C6E6FD.3293A8D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="mswterms"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="time"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="date"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>In RADIUS/Diameter Accounting messages
announce both the beginning and end of a session. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Behcet Sarikaya
[mailto:behcetsarikaya@<st1:mswterms w:st="on">yahoo</st1:mswterms>.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, <st1:date
Year="2006" Day="03" Month="10" ls="trans" w:st="on">October 03, 2006</st1:date>
<st1:time Minute="05" Hour="14" w:st="on">2:05 PM</st1:time><br>
<b><span style='font-weight:bold'>To:</span></b> Bernard Aboba<br>
<b><span style='font-weight:bold'>Cc:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: Review requested:
draft-ietf-radext-delegated-prefix-03.txt</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Hello Bernard, I agree with your changes, please also add
this typo too:<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>The AVP flag rules [5] for the Delegate-IPv6-Prefix
attribute are:<br>
-&gt;The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:<br>
<br>
Is session termination communicated with Accounting Request message in
Radius/Diameter?<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Thanks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'>Behcet<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>----- Original Message
----<br>
From: Bernard Aboba &lt;[email-masked]&gt;<br>
To: [email-masked]<br>
Sent: Tuesday, <st1:date Year="2006" Day="3" Month="10" ls="trans" w:st="on">October
 3, 2006</st1:date> 3:21:42 PM<br>
Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>A new version of the Delegated Prefix attribute has been posted to the <br>
archive:<br>
<a
href="http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt"
target="_blank">http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-03.txt</a><br>
<br>
This document has already gone through IESG review, so it is one step away <br>
from publication.<br>
<br>
Can people take a look at it?<br>
<br>
I found one typo, in Section 5:<br>
<br>
&nbsp;&nbsp; The AVP flag rules [5] for the Delegate-IPv6-Prefix attribute are:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+---------------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;AVP
Flag rules&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|----+-----+----+-----|----+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AVP&nbsp;&nbsp;Section&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |SHLD| MUST|&nbsp;&nbsp;&nbsp;&nbsp;|<br>
&nbsp;&nbsp; Attribute Name&nbsp;&nbsp;Code Defined&nbsp;&nbsp;Value Type
|MUST| MAY | NOT|&nbsp;&nbsp;NOT|Encr|<br>
&nbsp;&nbsp;
-----------------------------------------|----+-----+----+-----|----|<br>
&nbsp;&nbsp;
Framed-IPv6-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;97&nbsp;&nbsp;6.11.6&nbsp;&nbsp;OctetString|
M&nbsp;&nbsp;|&nbsp;&nbsp;P&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;V&nbsp;&nbsp;|
Y&nbsp;&nbsp;|<br>
&nbsp;&nbsp;&nbsp;&nbsp;
Prefix&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;|<br>
<br>
<br>
Here the attribute should be Delegated-IPv6-Prefix, not Framed-IPv6-Prefix; <br>
the AVP should be TBD instead of 97, and the Section Defined entry should be <br>
deleted.<br>
<br>
One other quibble.&nbsp;&nbsp; In Section 1, it is stated:<br>
<br>
&quot;&nbsp;&nbsp; The Framed-IPv6-Prefix attribute [4] is not designed to
carry an IPv6<br>
&nbsp;&nbsp; prefix to be used in the user's network, and therefore
Framed-IPv6-<br>
&nbsp;&nbsp; Prefix and Delegated-IPv6-Prefix attributes may be included in the<br>
&nbsp;&nbsp; same RADIUS packet.&quot;<br>
<br>
It strikes me that this statement is not necessarily accurate.&nbsp;&nbsp;For
example, <br>
if a bridge device connected to a NAS, then in fact the Framed-IPv6-Prefix <br>
attribute *could* be used to carry an IPv6 prefix to be used in the user's <br>
network.&nbsp;&nbsp;However, if we are talking about a router, then this will
not <br>
work.&nbsp;&nbsp;So I think the sentence should be changed to:<br>
<br>
&quot;&nbsp;&nbsp;The Framed-IPv6-Prefix attribute [4] is not designed to
support <br>
delegation of prefixes to<br>
&nbsp;&nbsp; be used in the user's network, and therefore Framed-IPv6-Prefix
and <br>
Delegated-IPv6-Prefix<br>
&nbsp;&nbsp; attributes may be included in the same RADIUS packet.&quot;<br>
<br>
<br>
<br>
--<br>
to unsubscribe send a message to [email-masked] with<br>
the word 'unsubscribe' in a single line as the message text body.<br>
archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>&gt;<o:p></o:p></span></font></p>

</div>

</div>

<div>

<p class=MsoNormal><font size=3 face=Courier><span style='font-size:12.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_0009_01C6E6FD.3293A8D0--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 03 Oct 2006 20:22:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review requested: draft-ietf-radext-delegated-prefix-03.txt
Date: Tue, 03 Oct 2006 13:21:42 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 03 Oct 2006 20:15:32 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review requested: draft-ietf-radext-filter-02.txt
Date: Tue, 03 Oct 2006 13:14:23 -0700

A new version has been posted to the archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt

Does this version address the open issues (198 & 202)?   Are there any other 
issues/problems with it?

3GPP asked out the status of it in the last IETF/3GPP liaison conference 
call.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 02 Oct 2006 14:50:38 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-02.txt 
Date: Mon, 02 Oct 2006 10:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: RADIUS Filter Rule Attribute
	Author(s)	: P. Congdon
	Filename	: draft-ietf-radext-filter-02.txt
	Pages		: 10
	Date		: 2006-10-2
	
This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dial In User Service (RADIUS), equivalent to the
Diameter NAS-Filter-Rule AVP described in RFC 4005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-filter-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-filter-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-filter-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>