Subject: REVISED ANNOUNCEMENT Protocol Action: 'RADIUS Filter Rule Attribute' to Proposed Standard
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Date: Tue, 30 Jan 2007 12:07:16 -0500

The IESG has approved the following document:

- 'RADIUS Filter Rule Attribute '
   <draft-ietf-radext-filter-08.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 While RFC 2865 defines the Filter-Id attribute, this requires that      
    
 the Network Access Server (NAS) be pre-populated with the desired       
    
 filters.  However, in situations where the server operator does not     
    
 know which filters have been pre-populated, it useful to specify        
    
 filter rules explicitly.  This document defines the NAS-Filter-Rule     
    
 attribute within the Remote Authentication Dial In User Service         
    
 (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule      
    
 Attribute Value Pair (AVP) described in RFC 4005, and the               
    
 IPFilterRule syntax defined in RFC 3588.    
 
Working Group Summary
 
 This document is a product of the radext working group.
 
Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

Note to RFC Editor
 
 In '1.  Introduction':

 OLD:

  However, in situations where the server
  operator does not know which filters have been pre-populated, it
  useful to specify filter rules explicitly.
  
 NEW:

  However, in situations where the server
  operator does not know which filters have been pre-populated, it
  is useful to specify filter rules explicitly.

--
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, 30 Jan 2007 16:10:21 +0000
Date: Tue, 30 Jan 2007 17:09:56 +0100
From: Alan DeKok <[email-masked]>
To: radext mailing list <[email-masked]>
Subject: Question re: RFC 2865 and State attribute in table 5.44

  Table 5.44 lists 'State' as "0-1" for Access-Challenge.  Are there any
client and/or server implementations that *don't* send a State in an
Access-Challenge?  Section 4.4 says the Access-Challenge "MAY have a
single State Attribute, or none."  But it doesn't explain why.

  I note that RFC 3579, Section 3.3 doesn't list "State" as being
necessary for EAP conversations.  I can't even find *any* reference to
the attribute in RFC 3579, which seems a little odd.

  Is this something that needs to be addressed?  I'm not aware of any
EAP implementations that *don't* use State, so it would appear to be
required for Access-Challenge, where the packet contains an EAP-Message
that isn't an EAP Success or Failure.  Maybe the lack of use of the
State attribute is why section 2.6.1 (Identifier Space) describes such a
complicated mechanism for discriminating sessions.

  Are there any other use cases where it is not necessary to send the
State attribute in an Access-Challenge?  I can't recall seeing any, and
all of the clients & servers I've written require it.

  Is there a problem with requiring State in Access-Challenge?  I'm not
sure I should file an official ISSUE until I'm sure I understand what
the intent was.

  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: Tue, 30 Jan 2007 15:56:09 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Cc: "'RFC Editor'" <[email-masked]>
Subject: RE: Protocol Action: 'IPv6 Deployment Scenarios in 802.16(e) Networks' to Proposed Standard 
Date: Tue, 30 Jan 2007 10:55:42 -0500

> From: The IESG [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2007 10:39 AM
> To: IETF-Announce
> Cc: Internet Architecture Board; RFC Editor; radext mailing list; radext
> chair
> Subject: Protocol Action: 'IPv6 Deployment Scenarios in 802.16(e)
> Networks' to Proposed Standard
> 
> The IESG has approved the following document:
> 
> - 'IPv6 Deployment Scenarios in 802.16(e) Networks '
>    <draft-ietf-radext-filter-08.txt> as a Proposed Standard

Once again, the document title is incorrect in this announcement. Everything
else is in order.  The correct title is "RADIUS Filter Rule Attribute".

--
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: Tue, 30 Jan 2007 15:40:23 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'IPv6 Deployment Scenarios in  802.16(e) Networks' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Tue, 30 Jan 2007 10:39:02 -0500

The IESG has approved the following document:

- 'IPv6 Deployment Scenarios in 802.16(e) Networks '
   <draft-ietf-radext-filter-08.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 While RFC 2865 defines the Filter-Id attribute, this requires that      
    
 the Network Access Server (NAS) be pre-populated with the desired       
    
 filters.  However, in situations where the server operator does not     
    
 know which filters have been pre-populated, it useful to specify        
    
 filter rules explicitly.  This document defines the NAS-Filter-Rule     
    
 attribute within the Remote Authentication Dial In User Service         
    
 (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule      
    
 Attribute Value Pair (AVP) described in RFC 4005, and the               
    
 IPFilterRule syntax defined in RFC 3588.    
 
Working Group Summary
 
 This document is a product of the radext working group.
 
Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

Note to RFC Editor
 
 In '1.  Introduction':

 OLD:

  However, in situations where the server
  operator does not know which filters have been pre-populated, it
  useful to specify filter rules explicitly.
  
 NEW:

  However, in situations where the server
  operator does not know which filters have been pre-populated, it
  is useful to specify filter rules explicitly.

--
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, 26 Jan 2007 14:51:39 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: FW: Internet-Drafts Submission Cutoff Dates for the 68th IETF  Meeting in Prague, Czech Republic 
Date: Fri, 26 Jan 2007 09:50:45 -0500

> There are two (2) Internet-Draft cutoff dates for the 68th
> IETF Meeting in Prague, Czech Republic:
> 
> February 26th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
> 
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> February 26th at 9:00 AM ET. As always, all initial submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Monday,
> February 19th at 9:00 AM ET.
> 
> March 5th: Cutoff Date for Revised (i.e., version -01 and higher)
> Internet-Draft Submissions
> 
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, March 5th at 9:00 AM ET.
> 
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, March 19th at 9:00
> AM ET, when Internet-Draft posting resumes.  Please do not wait until
> the last minute to submit.
> 
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> [email-masked].
> 
> The IETF Secretariat
> 
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 68th IETF Meeting can be found at
> http://www.ietf.org/meetings/cutoff_dates_68.html.

--
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, 23 Jan 2007 00:45:20 +0000
Date: Mon, 22 Jan 2007 16:44:31 -0800 (PST)
Subject: comments on draft-zorn-radius-keywrap-12.txt
From: "Dan Harkins" <[email-masked]>
To: [email-masked]

  Hi,

  I recently read draft-zorn-radius-keywrap-12.txt and have a few
comments. I hope they can be addressed before this draft is advanced
to RFC.

  general:
    * there is a real lack of requirements in this draft. Most things
      are MAY and it looks like a compliant implementation could do
      almost nothing, which seems odd for an RFC. Furthermore
      interoperability will be extremely difficult since little behavior
      MUST be followed. Ironically. one of the rare MUSTs in the draft
      really should be a SHOULD.

  section 3.1:
    * the Key ID, lifetime, IV and Key material fields MAY be omitted
      but then the length of the keying material attribute would not
      be >= 24 as defined later on when the layout of the attribute is
      defined. I suggest changing the length to be >= 8 and specify that
      if any of these attributes are omitted then they MUST all be omitted
      otherwise someone could legitimately omit one field and include
      another and it would be impossible to parse the attribute on receipt.

    * "if the client requires the use of the Keying-Material Attribute"
      but it's not present then it "MAY ignore the message"? This should
      be MUST or else "require" doesn't mean what I believe most people
      think it means.

    * KEK ID, KM ID are both unspecified. They are supposed to identify
      the key but how? If the Frobnitz corporation defines the ID to be
      sha("the KEK ID") and the Fubar corporation defines it as the
      string "this is your KEK ID!" (both 20 bytes) then how do they
      interoperate? 20 bytes? Why won’t 4 do? Or even 2? Does this have
      something to do with hashing to produce an ID? It’s not specified.

      Having unspecified things and then say "Further specification of the
      content of this field is outside the scope of this document" means
      that specification in its entirety is outside the scope of this
      document. That being the case then why is this even part of an IETF
      document? These fields should be removed before the document is
      advanced.

      The KEK ID and KM ID, being entirely unspecified, are gigantic
      subliminal channels. I really don't think that's appropriate.

    * if the Enc Type field is 0 then "the IV field MUST be as specified
      in RFC3394". Is it supposed to be the "default IV"? If so then why
      even bother sending it in the attribute? It would be painful to
      make the attribute variable length-- i.e. if Enc Type field is 0
      then there is no IV field-- so why not change this MUST to a SHOULD?
      Also, there may be legitimate reasons to use a different IV than the
      default one listed in RFC3394 (which is why that RFC allows it).

  section 3.3:
    * MAC Key ID, same comments apply here as with KEK ID and KM ID above.

  section 5:
    * If two new keys are being defined then there is no point in having 3
      ID fields to identify them. They are implicitly identified here. One
      key is for key wrapping and the other key is used for integrity
      checking. Again, there is no need for a KEK ID, KM ID, or MAC Key ID.

    * I think these two new keys MUST be cryptographically independent of
      the RADIUS shared secret (not SHOULD). The RADIUS shared secret
      already has a defined use and it's not as a key deriving key. There
      is no valid reason in any particular circumstance to ignore this
      particular item (to paraphrase RFC2119).

  I think it's great to have an RFC3394-style way to send keys from a
RADIUS server to a RADIUS client but this seems to go way beyond that
simple task. And there isn't any real apparent justification for those
excesses. KEK ID, KM ID, MAC Key ID... please just get rid of them. If
someone wants to pass VSAs then they should just pass VSAs.

  thanks,

  Dan.

--
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, 22 Jan 2007 20:51:03 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-00.txt 
Date: Mon, 22 Jan 2007 15:50:02 -0500

--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		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-00.txt
	Pages		: 35
	Date		: 2007-1-22
	
   This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-00.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-rfc3576bis-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-ietf-radext-rfc3576bis-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
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-rfc3576bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-00.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: Mon, 22 Jan 2007 13:26:50 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Review of draft-ietf-radext-fixes-00.txt 
Date: Mon, 22 Jan 2007 08:26:36 -0500

Alan DeKok writes...

>   Issue 146 is (I believe) addressed in the updated MIB
> documents. The issue itself lists 'Document: RFC2618bis-2621bis',
> so I don't think it's relevant for Issues & Fixes.

That's not quite correct.  The WG chose to not address this issue in the
revised MIBs, because of the undesirability of deprecating the corresponding
objects in widely deployed MIBs, especially since there was not consensus
that the existing description was really in error.  We decided to discuss
the issue, i.e. the potential for confusion, in the Issues and Fixes
document.

--
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: Mon, 22 Jan 2007 13:03:20 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Review of draft-ietf-radext-fixes-00.txt 
cc: [email-masked]
Date: Mon, 22 Jan 2007 07:51:53 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote re: NITS
>   - In addition to a regular copyright notice, the document also has a
>     copyright notice embedded in the text.

  "Full" copyright statement later in the document, versus just
"Copyright Statement".  Fixed.

>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>   - The page length should not exceed 58 lines per page, but there was 19
>     longer pages, the longest (page 2) being 60 lines
>   - It seems as if not all pages are separated by form feeds - found 0 form
>     feeds but 20 pages

  I'll figure out what's going on.

>   Miscellaneous warnings:
>   - The copyright year in the IETF Trust Copyright Line does not match the
>     current year

  Fixed.

>   Experimental warnings:
>   - Looks like a reference, but probably isn't: '1' on line 465 (?)

  That's just cut & pasted text from the RFC's.  I think it should be
OK.  I'll make a note to the RFC editor when it's finally submitted.

>   - Unused Reference: 'RFC2868' is defined on line 763, but not referenced
>   - Unused Reference: 'RFC2882' is defined on line 770, but not referenced
>   - Unused Reference: 'RFC3575' is defined on line 776, but not referenced

  Deleted.

  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/>

Envelope-to: [email-masked]
Delivery-date: Mon, 22 Jan 2007 12:48:00 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Review of draft-ietf-radext-fixes-00.txt 
cc: [email-masked]
Date: Mon, 22 Jan 2007 07:35:43 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Please spell out VOIP on first usage.

  Fixed.

> I think we also need advice for the RADIUS client.  For example:
> "A NAS SHOULD NOT utilize a link-scope address within a NAS-IPv6-Address
> or NAS-IP-Address attributes."

  Added.

> 2.10.  Responses after retransmissions.
> 
> Remove the "." in the section heading.

  Fixed.

> The first sentence is not complete.  Also, the Delegated-IPv6-Prefix
> document now states that Framed-IPv6-Prefix is not used for the purposes
> of delegation.  Suggest the following rewording:

  Added, thanks.

> This would seem to conflict with the Delegated-IPv6-Prefix attribute.
> Rather, I think that the result is probably for the NAS to send an
> RA containing whatever is placed in the Framed-IPv6-Prefix attribute.

  I've updated the text, thanks.

> This draft does not address Issues 107 and 146 on the RADEXT Issues list:
> http://www.drizzle.com/~aboba/RADEXT/
> 
> Is there an implicit recommendation that these issues be rejected?

  Issue 146 is (I believe) addressed in the updated MIB documents.
The issue itself lists 'Document: RFC2618bis-2621bis', so I don't
think it's relevant for Issues & Fixes.

  As for issue 107, I will add a section to the document about that,
and submit a new version in a little bit.

  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: Wed, 17 Jan 2007 20:50:59 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-08.txt 
Date: Wed, 17 Jan 2007 15:50:02 -0500

--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		: IPv6 Deployment Scenarios in 802.16(e) Networks
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-08.txt
	Pages		: 10
	Date		: 2007-1-17
	
This document provides detailed description of IPv6 deployment and
   integration methods and scenarios in wireless broadband access
   networks in coexistence with deployed IPv4 services.  In this
   document we will discuss main components of IPv6 IEEE 802.16 access
   network and its differences from IPv4 IEEE 802.16 networks and how
   IPv6 is deployed and integrated in each of the IEEE 802.16
   technologies using tunneling mechanisms and native IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-08.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-08.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-08.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-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-08.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, 17 Jan 2007 15:43:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-ietf-radext-fixes-00.txt
Date: Wed, 17 Jan 2007 10:42:37 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> Issues still not addressed
> ----------------------------------
>=20
> This draft does not address Issues 107 and 146 on the RADEXT Issues
list:
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> Is there an implicit recommendation that these issues be rejected?

I don't think so.

With respect to Issue 107, there was discussion on the list, but no
apparent consensus.  My recollection of the issue at hand, from the days
when RFC 2869 was being written, was that the local NAS value for
Acct-Interim-Interval was intended as a MINIMUM value that the NAS and
its network infrastructure could tolerate in terms of the imposed CPU
and network load.  This is something of a scalability issue.  I don't
recall that there was any motivation in defining this behavior for the
NAS to over-rider the RADIUS Server provided value with a smaller (i.e.
more frequent) one, only a larger (less frequent) one.

There is the issue of whether the Issues and Fixes document ought to be
revising a MUST in RFC 2869.  If we were to attempt to provide
implementation advice in this regard, I would tend to support the notion
that the NAS MUST over-ride the server provided value of
Acct-Interim-Interval if the locally configured value is larger than the
server provide value, and SHOULD NOT over-ride it otherwise.

Is there any consensus on this position?  Does this present any
backwards compatibility issues with fielded implementations?

With respect to Issue 146, there was discussion on the list, but not
apparent consensus.  We briefly considered making some changes in this
area to the MIBs themselves during review of the IPv6 capable version of
the MIBs.  We decided against making any changes to the definition of
the counters, as this would have substantial impact on fielded
implementations.  The decision was to document the potential for
mis-interpretation, in the Issues & Fixes document.  I think we need to
do at least that.

If we can come to consensus on something else, that would be OK too.
Either way, I think some text needs to be added to the draft, and I'm
willing to craft some.  If anyone has an additional opinion on this
issue, now would be a good time to comment.

--
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, 17 Jan 2007 02:12:54 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of draft-ietf-radext-fixes-00.txt
Date: Tue, 16 Jan 2007 18:11:59 -0800

Review of draft-ietf-radext-fixes-00.txt

Overall, this document looks good.  Some comments:

Section 2.6

   For example, a NAS may offer multi-link services, where a user may
   have multiple simultaneous network connections. In that case, an
   Access-Reject for a later multi-link connection request does not
   necessarily mean that earlier multi-link connections are torn down.
   Similarly, if a NAS offers both dialup and VOIP services, the
   rejection of a VOIP attempt does not mean that the dialup session is
   torn down.

Please spell out VOIP on first usage.

Section 2.7.1

   Since Link-Local addresses are unique only on the local link, if the
   NAS and RADIUS server are not on the same link, then an IPv6 Link-
   Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927]
   cannot be used to uniquely identify the NAS.  A RADIUS server
   receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a
   Link-Local address SHOULD NOT count such an attribute toward
   satisfying the requirements of [RFC3162] Section 2.1:

I think we also need advice for the RADIUS client.  For example:
"A NAS SHOULD NOT utilize a link-scope address within a NAS-IPv6-Address
or NAS-IP-Address attributes."

2.10.  Responses after retransmissions.

Remove the "." in the section heading.

2.11

   If an ISP desires to support Prefix Delegation at the same time that
   it would like to assign a prefix for the link between the NAS and
   customer premises equipment (CPE). In this situation, the sematics of
   Framed-IPv6-Prefix may be unclear, in that it is difficult to know
   which prefixes are to be used for delegation, and which one is to be
   used for the link.  The intent of the paragraph was to enable the NAS
   to advertise the prefix (such as via a Router Advertisement). If the
   Framed-Routing attribute is used, it is also possible that the prefix
   would be advertised in a routing protocol such as RIPNG.

The first sentence is not complete.  Also, the Delegated-IPv6-Prefix
document now states that Framed-IPv6-Prefix is not used for the purposes
of delegation.  Suggest the following rewording:

   An ISP may desire to support Prefix Delegation at the same time that
   it would like to assign a prefix for the link between the NAS and
   the user.  The intent of the paragraph was to enable the NAS
   to advertise the prefix (such as via a Router Advertisement). If the
   Framed-Routing attribute is used, it is also possible that the prefix
   would be advertised in a routing protocol such as RIPNG.

Also in Section 2.11:

   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and CPE only if a /64 prefix is assigned.  When a larger
   prefix is sent, the intent is to provide the entire prefix to the
   CPE, enabling the CPE to assign sub-prefixes if it wishes to do so.

This would seem to conflict with the Delegated-IPv6-Prefix attribute.
Rather, I think that the result is probably for the NAS to send an
RA containing whatever is placed in the Framed-IPv6-Prefix attribute.

Issues still not addressed
----------------------------------

This draft does not address Issues 107 and 146 on the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Is there an implicit recommendation that these issues be rejected?

IDNITs

I ran IDNITs on the document, and it found some issues:

idnits 1.123

tmp/draft-ietf-radext-fixes-00.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

  - In addition to a regular copyright notice, the document also has a
    copyright notice embedded in the text.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - The page length should not exceed 58 lines per page, but there was 19
    longer pages, the longest (page 2) being 60 lines
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 20 pages

  Miscellaneous warnings:
  - The copyright year in the IETF Trust Copyright Line does not match the
    current year

  Experimental warnings:
  - Looks like a reference, but probably isn't: '1' on line 465 (?)
    '[1]  New RADIUS specifications and implementations MUST NOT use 
Access...'

  - Looks like a reference, but probably isn't: '2' on line 468 (?)
    '[2]  Access-Reject MUST mean denial of access to the requested 
service...'

  - Looks like a reference, but probably isn't: '3' on line 472 (?)
    '[3]  New deployments of ARAP [RFC2869] SHOULD use Access-Challenge...'

  - Missing Reference: 'Note 2' is mentioned on line 489, but not defined
    '[Note 2] As per RFC 3579, the use of the Password-Retry in EAP...'

  - Unused Reference: 'RFC2867' is defined on line 759, but not referenced
    '[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting 
Modifi...'

  - Unused Reference: 'RFC2868' is defined on line 763, but not referenced
    '[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 
M....'

  - Unused Reference: 'RFC2882' is defined on line 770, but not referenced
    '[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended 
R...'

  - Unused Reference: 'RFC3575' is defined on line 776, but not referenced
    '[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, 
July...'

    No nits found.

--
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, 15 Jan 2007 21:03:06 +0000
Content-class: urn:content-classes:message
Subject: FW: Internet-Draft Boilerplate Reminder 
Date: Mon, 15 Jan 2007 16:01:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

FYI to I-D authors, from the IETF Secretariat.=20

--------------------------------------------------------------
This message is to remind you that as of February 1, 2007 the IETF
Secretariat will no longer accept Internet-Drafts with the old=20
(i.e. pre RFC 4748) boilerplate.  For your convenience, below is=20
the text of the message that was sent to the IETF Announcement=20
List by the IETF Chair on October 26, 2006 with Subject: Update to
Internet Draft and RFC Boilerplate.

The IETF Secretariat.
--------------------------------------------------------------
A small update to BCP 78 was recently approved by the IESG as RFC 4748,=20
to update the boilerplate (i.e., standard legal text) in RFCs and=20
Internet-Drafts to recognize the IETF Trust as a rights holder,=20
instead of ISOC.

The actual boilerplate changes are given below this message.

Starting as soon as reasonably possible, all authors of Internet-Drafts=20
are requested to use the new boilerplate. The RFC Editor will in any=20
case be inserting it in all RFCs issued from 2006-11-01. (The rights=20
held by ISOC in older RFCs will be administratively transferred to=20
the IETF Trust.)

The public ID Nits checker already accepts I-Ds with old or new
boilerplate. The Secretariat has started accepting I-Ds with old or=20
new boilerplate.

XML2RFC version 1.32 will generate the new boilerplate.
Users of I-D templates are requested to update them appropriately.

http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html are being updated.

Starting December, the public ID Nits checker will issue warnings for
old
boilerplate.

Starting February 2007, the Secretariat will refuse the old boilerplate
in Internet-Drafts.

We are sorry for the inconvenience, but this change cannot be avoided.

    IETF Chair
    IETF Secretariat
    TOOLS Team

--------

Copyright Notice (required for all IETF Documents)

   (Normally placed at the end of the IETF Document.)

NOTE: by convention, the first line of the copyright statement is
usually
placed near the beginning of each document. This must also be updated.

OLD
      "Copyright (C) The Internet Society (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

NEW
      "Copyright (C) The IETF Trust (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

Disclaimer (required in all IETF Documents)

   (Normally placed at the end of the IETF Document after the copyright
   notice.)

OLD
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE."

NEW
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE=20
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE."

Exceptions

      In MIB modules, PIB modules and similar material commonly
      extracted from IETF Documents, except for material that is being
      placed under IANA maintenance, the following abbreviated notice
      shall be included in the body of the material that will be
      extracted in lieu of the notices otherwise required by Section 5:

OLD
         "Copyright (C) The Internet Society <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

NEW
         "Copyright (C) The IETF Trust <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

      When the MIB or PIB module is the initial version of a module that
      is to be maintained by the IANA, the following abbreviated notice
      shall be included:

OLD
         "Copyright (C) The Internet Society <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

NEW
         "Copyright (C) The IETF Trust <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Sat, 13 Jan 2007 19:34:29 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-filter
Date: Sat, 13 Jan 2007 11:32:59 -0800

How about if we change Section 6 to the following:

"6.  Security Considerations

   This specification describes the use of RADIUS for purposes of
   authentication, authorization and accounting.  Threats and security
   issues for this application are described in [RFC3579] and [RFC3580];
   security issues encountered in roaming are described in [RFC2607].

   This document specifies a new attribute that can be included in
   existing RADIUS packets, which are protected as described in
   [RFC3579] and [RFC3576].  See those documents for a more detailed
   description.

   The security mechanisms supported in RADIUS and Diameter are focused
   on preventing an attacker from spoofing packets or modifying packets
   in transit.  They do not prevent an authorized RADIUS/Diameter server
   or proxy from modifying, inserting or removing attributes with
   malicious intent.  Filter attributes modified or removed by a
   RADIUS/Diameter proxy may enable a user to obtain network access
   without the appropriate filters; if the proxy were also to modify
   accounting packets, then the modification would not be reflected in
   the accounting server logs.

   Since the RADIUS protocol currently does not support capability
   negotiation, a RADIUS server cannot automatically discover whether a
   NAS supports the NAS-Filter-Rule attribute.  A legacy NAS not
   compliant with this specification may silently discard the NAS-
   Filter-Rule attribute while permitting the user to access the
   network.  This can lead to users improperly receiving unfiltered
   access to the network.  As a result, the NAS-Filter-Rule attribute
   SHOULD only be sent to a NAS that is known to support it."

>From: Russ Housley <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: DISCUSS and COMMENT: draft-ietf-radext-filter Date: Thu, 11 Jan 
>2007 11:07:43 -0500
>
>Discuss:
>
>   It is clear that the integrity protection of the filter list is
>   beyond the scope of this document.  However, I do think that the
>   security considerations ought to say something about the impact if
>   that protection is not provided.  What are the consequences of a
>   modification to the filter list.  Consider adding entries, removing
>   entries and altering entries.
>
>Comment:
>
>   From the SecDir Review by Sam Weiler:
>
>   These concerns may stem, in part, from the document's brevity and
>   propensity to cite other docs -- as someone not steeped in RADIUS and
>   Diameter lore, I found it a bit hard to decipher.  The table in
>   section 3, for instance, seems like it must be there to mirror some
>   table in other specs.  Plainer language throughout might be helpful.
>

--
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, 12 Jan 2007 05:53:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: FW: secdir review of draft-ietf-radext-filter-06.txt
Date: Thu, 11 Jan 2007 21:52:11 -0800

Comments below.

>-------------------------------------------------------------
>
>I've reviewed draft-ietf-radext-filter-06.txt as part of the
>security directorate's ongoing effort to review all IETF documents
>being processed by the IESG.  These comments were written primarily
>for the benefit of the security area directors.  Document editors and
>WG chairs should treat these comments just like any other last call
>comments.
>
>I suspect the document is more or less okay, but I'm concerned about
>three things:
>
>-- possible underspecification
>-- legacy NAS
>-- authentication of the filter list (or lack thereof)
>
>These concerns may stem, in part, from the document's brevity and
>propensity to cite other docs -- as someone not steeped in RADIUS and
>Diameter lore, I found it a bit hard to decipher.  The table in
>section 3, for instance, seems like it must be there to mirror some
>table in other specs.  Plainer language throughout might be helpful.

Yes, there is a tradition to include a table of this format in RADIUS 
specifications.   People seem to expect this kind of table by now, so it 
probably makes sense to keep it.

>Underspecification: the "String" definition in section 2 refers to
>section 4.3 of RFC3588.  That definition includes a number of fields
>and options (e.g. dir, frag, ipoptions, tcpoptions, etc.) which I
>wouldn't find obvious how to interpret in this context.  That omission
>leads me to wonder what else is being lost in the referral to other
>docs.

Since the RFC 3588 IPFilter syntax is outside the scope of the RADEXT WG, 
I'm not sure what we can do with this, other than refer the problem to the 
DIME WG, which can choose to include clarifications (or not) in RFC 3588bis. 
  If and when such clarifications are made, this document will inherit them.

>Legacy NAS: the security considerations (section 6) raises this point:
>
>         A NAS-Filter-Rule attribute sent by a RADIUS server may not be
>         understood by the NAS which receives it.  A legacy NAS not
>compliant
>         with this specification may silently discard the NAS-Filter-Rule
>         attribute while permitting the user to access the network.  This
>can
>         lead to users improperly receiving unfiltered access to the
>network.
>         As a result, the NAS-Filter-Rule attribute SHOULD only be sent
>to a
>         NAS that is known to support it.
>
>But there's no method defined to finding out what a NAS does or
>doesn't support.  Is it reasonable to assume that those deploying this
>will readily know which NAS devices support these rules?

We have learned from painful experience that some legwork is required before 
deploying filtering attributes to make sure that the NAS understands and 
provisions them the way that the RADIUS server admin intended.  This may be 
quite painful at times (e.g. particular between providers with roaming 
agreements), but it is currently the best we can do.  So the language in the 
draft is meant to suggest that such legwork is currently unavoidable, and to 
suggest that administrators not punt it.

>Authentication of the filter list: section 6 just points to the base
>radius spec for all authentication, without explicitly saying "the
>methods required by those docs are adequate to assure that a filter
>list can't be spoofed away, nor can it be augmented in such as way as
>to effect a downgrade attack".

Adding a statement defending the adequacy of MD5 is probably not 
appropriate. The overall message (which I think is conveyed in the document) 
is that this particular attribute relies on existing RADIUS security 
mechanisms, whether they be good, bad or ugly.  The point is that the 
mechanisms are not unique to this particular attribute.

--
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, 11 Jan 2007 20:50:51 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-07.txt 
Date: Thu, 11 Jan 2007 15:50:02 -0500

--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-07.txt
	Pages		: 10
	Date		: 2007-1-11
	
While RFC 2865 defines the Filter-Id attribute, this requires that
   the Network Access Server (NAS) be pre-populated with the desired
   filters.  However, in situations where the server operator does not
   know which filters have been pre-populated, it is useful to specify
   filter rules explicitly.  This document defines the NAS-Filter-Rule
   attribute within the Remote Authentication Dial In User Service
   (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule
   Attribute Value Pair (AVP) described in RFC 4005, and the
   IPFilterRule syntax defined in RFC 3588.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-07.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-07.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-07.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-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-07.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, 11 Jan 2007 15:09:20 +0000
Content-class: urn:content-classes:message
Subject: FW: secdir review of draft-ietf-radext-filter-06.txt
Date: Thu, 11 Jan 2007 10:08:31 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The following security review of the draft-ietf-radext-filter-06.txt was
recently provided by Sam Weiler.  Any comments or suggested changes
based on this review?

-------------------------------------------------------------

I've reviewed draft-ietf-radext-filter-06.txt as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

I suspect the document is more or less okay, but I'm concerned about
three things:

-- possible underspecification
-- legacy NAS
-- authentication of the filter list (or lack thereof)

These concerns may stem, in part, from the document's brevity and
propensity to cite other docs -- as someone not steeped in RADIUS and
Diameter lore, I found it a bit hard to decipher.  The table in
section 3, for instance, seems like it must be there to mirror some
table in other specs.  Plainer language throughout might be helpful.

Underspecification: the "String" definition in section 2 refers to
section 4.3 of RFC3588.  That definition includes a number of fields
and options (e.g. dir, frag, ipoptions, tcpoptions, etc.) which I
wouldn't find obvious how to interpret in this context.  That omission
leads me to wonder what else is being lost in the referral to other
docs.

Legacy NAS: the security considerations (section 6) raises this point:

        A NAS-Filter-Rule attribute sent by a RADIUS server may not be
        understood by the NAS which receives it.  A legacy NAS not
compliant
        with this specification may silently discard the NAS-Filter-Rule
        attribute while permitting the user to access the network.  This
can
        lead to users improperly receiving unfiltered access to the
network.
        As a result, the NAS-Filter-Rule attribute SHOULD only be sent
to a
        NAS that is known to support it.

But there's no method defined to finding out what a NAS does or
doesn't support.  Is it reasonable to assume that those deploying this
will readily know which NAS devices support these rules?

Authentication of the filter list: section 6 just points to the base=20
radius spec for all authentication, without explicitly saying "the=20
methods required by those docs are adequate to assure that a filter=20
list can't be spoofed away, nor can it be augmented in such as way as=20
to effect a downgrade attack".

--
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, 10 Jan 2007 22:11:05 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-filter
Date: Wed, 10 Jan 2007 14:10:44 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Nelson, David <> supposedly scribbled on Wednesday, January 10, 2007
1:37 PM:

> As the PROTO Document Shepherd on this draft, it's my job to
> facilitate IESG issue resolution.  Please take a moment to review the
> DISCUSS issue resolution described here.  If you think this is OK,
> please reply to the list. =20

Looks fine to me.

> If you think there is a better resolution
> please provide alternate text.   =20
>=20
> Thanks!
>=20
> Dave Nelson
>=20
>> Here is a proposed resolution to the IESG DISCUSS comment provided
>> below:=20
>>=20
>> In Section 4, change:
>>=20
>> "   Note that a translated Diameter message can be larger than the
>>    maximum RADIUS packet size (4096).  Where a Diameter/RADIUS
>>    gateway receives a Diameter message containing a NAS-Filter-Rule
>>    AVP that is too large to fit into a RADIUS packet, the
>>    Diameter/RADIUS gateway will respond to the originating Diameter
>>    peer with the DIAMETER_INVALID_AVP_LENGTH error (5014), and with
>>    a Failed-AVP AVP containing the NAS-Filter-Rule AVP.  Since
>>    repairing the error will probably require re-working the filter
>>    rules, the originating peer should treat the combination of a
>>    DIAMETER_INVALID_AVP_LENGTH error and a Failed-AVP AVP containing
>> a NAS-Filter-Rule AVP as a terminal    error."=20
>>=20
>> To:
>>=20
>> "  Note that a translated Diameter message can be larger than the
>>    maximum RADIUS packet size (4096).  Where a Diameter/RADIUS
>>    gateway receives a Diameter message containing a NAS-Filter-Rule
>>    AVP that is too large to fit into a RADIUS packet, the
>>    Diameter/RADIUS gateway will respond to the originating Diameter
>> peer with a Result-Code AVP with the value
>>    DIAMETER_RADIUS_AVP_UNTRANSLATABLE (TBD), and with a Failed-AVP
>>    AVP containing the NAS-Filter-Rule AVP.  Since repairing the
>>    error will probably require re-working the filter rules, the
>>    originating peer should treat the combination of a Result-Code
>>    AVP with value DIAMETER_RADIUS_AVP_UNTRANSLATABLE
>>    and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a
>> terminal    error."=20
>>=20
>> In Section 5, add the following paragraph:
>>=20
>> "This document also utilizes the Diameter [RFC3588] namespace.
>> Allocation of a Diameter Result-Code AVP value for
>> theDIAMETER_RADIUS_AVP_UNTRANSLATABLE error is requested.  Since
>> this is a permanent failure, an allocation should be provided in the
>> 5xxx range. "=20

--
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, 10 Jan 2007 21:38:12 +0000
Content-class: urn:content-classes:message
Subject: RE: DISCUSS: draft-ietf-radext-filter
Date: Wed, 10 Jan 2007 16:37:07 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

As the PROTO Document Shepherd on this draft, it's my job to facilitate
IESG issue resolution.  Please take a moment to review the DISCUSS issue
resolution described here.  If you think this is OK, please reply to the
list.  If you think there is a better resolution please provide
alternate text.

Thanks!

Dave Nelson

> Here is a proposed resolution to the IESG DISCUSS comment provided
below:
>=20
> In Section 4, change:
>=20
> "   Note that a translated Diameter message can be larger than the
>    maximum RADIUS packet size (4096).  Where a Diameter/RADIUS gateway
>    receives a Diameter message containing a NAS-Filter-Rule AVP that
is
>    too large to fit into a RADIUS packet, the Diameter/RADIUS gateway
>    will respond to the originating Diameter peer with the
>    DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP
>    containing the NAS-Filter-Rule AVP.  Since repairing the error will
>    probably require re-working the filter rules, the originating peer
>    should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error
>    and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal
>    error."
>=20
> To:
>=20
> "  Note that a translated Diameter message can be larger than the
>    maximum RADIUS packet size (4096).  Where a Diameter/RADIUS gateway
>    receives a Diameter message containing a NAS-Filter-Rule AVP that
is
>    too large to fit into a RADIUS packet, the Diameter/RADIUS gateway
>    will respond to the originating Diameter peer with a Result-Code
AVP
> with
> the value
>    DIAMETER_RADIUS_AVP_UNTRANSLATABLE (TBD), and with a Failed-AVP AVP
>    containing the NAS-Filter-Rule AVP.  Since repairing the error will
>    probably require re-working the filter rules, the originating peer
>    should treat the combination of a Result-Code AVP with value
>    DIAMETER_RADIUS_AVP_UNTRANSLATABLE
>    and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal
>    error."
>=20
> In Section 5, add the following paragraph:
>=20
> "This document also utilizes the Diameter [RFC3588] namespace.
> Allocation of a Diameter Result-Code AVP value for
> theDIAMETER_RADIUS_AVP_UNTRANSLATABLE error is requested.  Since this
is a
> permanent failure, an allocation should
> be provided in the 5xxx range. "

--
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, 10 Jan 2007 18:15:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: DISCUSS: draft-ietf-radext-filter
Date: Wed, 10 Jan 2007 10:14:28 -0800

Here is a proposed resolution to the IESG DISCUSS comment provided below:

In Section 4, change:

"   Note that a translated Diameter message can be larger than the
   maximum RADIUS packet size (4096).  Where a Diameter/RADIUS gateway
   receives a Diameter message containing a NAS-Filter-Rule AVP that is
   too large to fit into a RADIUS packet, the Diameter/RADIUS gateway
   will respond to the originating Diameter peer with the
   DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP
   containing the NAS-Filter-Rule AVP.  Since repairing the error will
   probably require re-working the filter rules, the originating peer
   should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error
   and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal
   error."

To:

"  Note that a translated Diameter message can be larger than the
   maximum RADIUS packet size (4096).  Where a Diameter/RADIUS gateway
   receives a Diameter message containing a NAS-Filter-Rule AVP that is
   too large to fit into a RADIUS packet, the Diameter/RADIUS gateway
   will respond to the originating Diameter peer with a Result-Code AVP with 
the value
   DIAMETER_RADIUS_AVP_UNTRANSLATABLE (TBD), and with a Failed-AVP AVP
   containing the NAS-Filter-Rule AVP.  Since repairing the error will
   probably require re-working the filter rules, the originating peer
   should treat the combination of a Result-Code AVP with value
   DIAMETER_RADIUS_AVP_UNTRANSLATABLE
   and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal
   error."

In Section 5, add the following paragraph:

"This document also utilizes the Diameter [RFC3588] namespace.
Allocation of a Diameter Result-Code AVP value for 
theDIAMETER_RADIUS_AVP_UNTRANSLATABLE error is requested.  Since this is a 
permanent failure, an allocation should
be provided in the 5xxx range. "

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

>Discuss:
>Review comment from Glen Zorn:
>
>The use of DIAMETER_INVALID_AVP_LENGTH as an indication that
>the Diameter NAS-Filter-Rule AVP could not be translated into a RADIUS
>NAS-Filter-Rule Attribute is questionable at best.  The semantics of the
>Diameter error code are that the AVP length is invalid _in Diameter_,
>but this is not the case here.  A new error code indicating the actual
>error encountered (e.g., DIAMETER_RADIUS_AVP_UNTRANSLATABLE or some such
>would be far preferable.

--
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: Wed, 10 Jan 2007 17:14:12 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500
Cc: Internet Architecture Board <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Wed, 10 Jan 2007 17:14:02 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500
Cc: Internet Architecture Board <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Wed, 10 Jan 2007 17:13:50 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500
Cc: Internet Architecture Board <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Wed, 10 Jan 2007 17:13:44 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500
Cc: Internet Architecture Board <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Wed, 10 Jan 2007 17:13:37 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500
Cc: Internet Architecture Board <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Wed, 10 Jan 2007 16:44:43 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500
Cc: Internet Architecture Board <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>, RFC Editor <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--
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: Wed, 10 Jan 2007 15:46:22 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'RADIUS Delegated-IPv6-Prefix  Attribute' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Wed, 10 Jan 2007 10:45:23 -0500

The IESG has approved the following document:

- 'RADIUS Delegated-IPv6-Prefix Attribute '
   <draft-ietf-radext-delegated-prefix-05.txt> as a Proposed Standard

This document is the product of the RADIUS EXTensions Working Group. 

The IESG contact persons are David Kessens and Dan Romascanu.

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

Technical Summary
 
 This document describes a RADIUS attribute that enables assignment
 of an IPv6 prefix for delegation by the Network Access Server.  The need
 for this attribute was discovered during IPv6 deployments using prefix
 delegation.  The document uses an attribute format similar to that used
 for the Framed-IPv6-Prefix attribute in RFC 3162, so that support for the

 attribute can be added to the dictionary in several existing RADIUS
 servers without requiring code changes.
 
Working Group Summary
 
 This document has been through RADEXT WG last call.  Discussion focused
 on aspects of the attribute format, RFC 3162 deployment models, and
 editorial issues.

Protocol Quality
 
 David Kessens has reviewed this document for the IESG.

--
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, 05 Jan 2007 04:29:36 +0000
Date: Thu, 04 Jan 2007 13:47:08 +0300
From: Victor Gamov <[email-masked]>
To: [email-masked]
CC: Bernard Aboba <[email-masked]>
Subject: new Service-Type

Hi, Bernard!

I'm looking for new Service-Type values for our IP-based services and I 
think that some of this may be useful for everyone. For example we use 
Service-Type=Voice (12) when we request Voice call. But we need also to 
differentiate Video service from other services. Is it possible to add 
new Service-Type value "Video" (18) and how I can request it?

Thanks a lot!

--
CU,
Victor Gamov

--
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, 04 Jan 2007 23:10:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: new Service-Type
Date: Thu, 04 Jan 2007 15:09:58 -0800

>From RFC 3575 Section 2.1:

  Values 1-16 of the Service-Type attribute have  been allocated.  
Allocation of
  new Service-Type values are by IETF Consensus.  The intention is that any
  allocation will be accompanied by a published RFC.

Is there an Internet Draft that explains the proposed usage for the new 
values?

>From: Victor Gamov <[email-masked]>
>To: [email-masked]
>CC: Bernard Aboba <[email-masked]>
>Subject: new Service-Type
>Date: Thu, 04 Jan 2007 13:47:08 +0300
>
>Hi, Bernard!
>
>I'm looking for new Service-Type values for our IP-based services and I 
>think that some of this may be useful for everyone. For example we use 
>Service-Type=Voice (12) when we request Voice call. But we need also to 
>differentiate Video service from other services. Is it possible to add new 
>Service-Type value "Video" (18) and how I can request it?
>
>Thanks a lot!
>
>--
>CU,
>Victor Gamov

--
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, 04 Jan 2007 15:47:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Call for Review: RFC 3576bis
Date: Thu, 04 Jan 2007 07:46:56 -0800

This is a call for review of "Dynamic Authorization Extensions to Remote 
Authentication Dial In User
Service (RADIUS)", otherwise known as RFC 3576bis. The document is available 
for inspection here:

http://www.ietf.org/internet-drafts/draft-chiba-radext-rfc3576bis-01.txt

The initial review period will last until January 15, 2006.

Please post your comments to the RADEXT WG mailing list in the format 
described on the RADEXT Issues web page:

http://www.drizzle.com/~aboba/RADEXT/

--
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, 04 Jan 2007 06:18:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for review: draft-ietf-radext-fixes-00.txt
Date: Wed, 03 Jan 2007 22:17:15 -0800

This is a call for review of "Common RADIUS Implementation Issues and 
Suggested Fixes".  The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-00.txt

The initial review period will last until January 15, 2006.

Please post your comments to the RADEXT WG mailing list in the format 
described on the RADEXT Issues web page:
http://www.drizzle.com/~aboba/RADEXT/

--
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, 03 Jan 2007 20:50:59 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-00.txt 
Date: Wed, 03 Jan 2007 15:50:02 -0500

--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		: Common RADIUS Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-00.txt
	Pages		: 20
	Date		: 2007-1-3

   This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-00.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-fixes-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-ietf-radext-fixes-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
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-fixes-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-fixes-00.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: Tue, 02 Jan 2007 20:51:12 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc4590bis-00.txt 
Date: Tue, 02 Jan 2007 15:50:02 -0500

--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 Extension for Digest Authentication
	Author(s)	: B. Sterman, et al.
	Filename	: draft-ietf-radext-rfc4590bis-00.txt
	Pages		: 32
	Date		: 2007-1-2
	
   This document defines an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-00.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-rfc4590bis-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-ietf-radext-rfc4590bis-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
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-rfc4590bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc4590bis-00.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: Tue, 02 Jan 2007 01:30:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 4590bis Issue 206
Date: Mon, 01 Jan 2007 17:30:29 -0800

The text of Issue 206 is enclosed below.  The proposed resolution is as 
follows:

Change Section 5 to the following:

"5.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

   +-----+--------+--------+-----------+-----+-------------------------+
   | Req | Accept | Reject | Challenge | #   | Attribute               |
   +-----+--------+--------+-----------+-----+-------------------------+
   | 1   | 0      | 0      | 0         | 1   | User-Name               |
   | 1   | 1      | 1      | 1         | 80  | Message-Authenticator   |
   | 0-1 | 0      | 0      | 0         | 103 | Digest-Response         |
   | 0-1 | 0      | 0      | 1         | 104 | Digest-Realm            |
   | 0-1 | 0      | 0      | 1         | 105 | Digest-Nonce            |
   | 0   | 0-1    | 0      | 0         | 106 | Digest-Response-Auth    |
   |     |        |        |           |     | (see Note 1, 2)         |
   | 0   | 0-1    | 0      | 0         | 107 | Digest-Nextnonce        |
   | 1   | 0      | 0      | 0         | 108 | Digest-Method           |
   | 0-1 | 0      | 0      | 0         | 109 | Digest-URI              |
   | 0-1 | 0      | 0      | 0+        | 110 | Digest-Qop              |
   | 0-1 | 0      | 0      | 0-1       | 111 | Digest-Algorithm (see   |
   |     |        |        |           |     | Note 3)                 |
   | 0-1 | 0      | 0      | 0         | 112 | Digest-Entity-Body-Hash |
   | 0-1 | 0      | 0      | 0         | 113 | Digest-CNonce           |
   | 0-1 | 0      | 0      | 0         | 114 | Digest-Nonce-Count      |
   | 0-1 | 0      | 0      | 0         | 115 | Digest-Username         |
   | 0-1 | 0      | 0      | 0-1       | 116 | Digest-Opaque           |
   | 0+  | 0+     | 0      | 0+        | 117 | Digest-Auth-Param       |
   | 0-1 | 0      | 0      | 0         | 118 | Digest-AKA-Auts         |
   | 0   | 0      | 0      | 0+        | 119 | Digest-Domain           |
   | 0   | 0      | 0      | 0-1       | 120 | Digest-Stale            |
   | 0   | 0-1    | 0      | 0         | 121 | Digest-HA1 (see Note 1, |
   |     |        |        |           |     | 2)                      |
   | 0-1 | 0      | 0      | 0         | 122 | SIP-AOR                 |
   | 0-1 | 0      | 0      | 1         |  24 | State (see Note 4)      |
   +-----+--------+--------+-----------+-----+-------------------------+

                                     Table 1

   [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
   Digest-Qop is 'auth-int'.

   [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
   Digest-Qop is 'auth'.

   [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.

   [Note 4] An Access-Challenge MUST contain a State attribute, which is
   copied to the subsequent Access-Request.  A server receiving an
   Access-Request that contains a State attribute MUST respond with
   either an Access-Accept or an Access-Reject; the server MUST NOT
   respond with an Access-Challenge."

=============================
Issue 206: Attribute Table
Submitter name: Alan DeKok
Submitter email address: [email-masked]
Date first submitted: Sept. 26, 2006
Reference: https://ops.ietf.org/lists/radiusext/2006/msg00870.html
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           |
....

--
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, 02 Jan 2007 01:28:22 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 4590bis Issue 205
Date: Mon, 01 Jan 2007 17:28:12 -0800

The text of issue 205 is enclosed below.  The proposed resolution is to 
accept the proposed change to the IANA considerations section.

=========================
Issue 205: IANA Error
Submitter name: Wolfgang Beck
Submitter email address: [email-masked]
Date first submitted: September 21, 2006
Reference: https://ops.ietf.org/lists/radiusext/2006/msg00869.html
Document: RFC 4590
Comment type: E
Priority: S
Section: 7
Rationale/Explanation of issue:

Alexander

>In table 2 the Digest-Nextnonce and Digest-Response-Auth are
>numbered 106 and 107. But further 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

--
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, 02 Jan 2007 01:26:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 4590bis Issue 196
Date: Mon, 01 Jan 2007 17:26:30 -0800

The text of issue 196 is enclosed below.

The issue here is that the second example (Web browser) seems to contract 
the Attribute Table which indicates that a User-Name attribute is required 
in an Access-Request containing a Digest-Method attribute.  In the example, 
no User-Name attribute is included.

Since RFC 2865 indicates that empty User-Name attributes can't be sent, one 
possibility is for the Calling-Station-Id attribute to contain the users' IP 
address, which would also be contained in the User-Name attribute.

There is also the question about what a server should do if a User-Name 
attribute is not included in an Access-Request.   Since the Attribute Table 
indicates that the User-Name attribute is required, I think the answer is 
that an Access-Reject is sent.

Finally, I would note that the examples do not include a realm within the 
User-Name attribute, only the userid.  Is this correct or should the 
User-Name attribute contain [email-masked]?

The proposed resolution is as follows:

Change Section 6 to the following:

"6.  Examples

   This is an example selected from the traffic between a softphone (A),
   a Proxy Server (B), and an example.com RADIUS server (C).  The
   communication between the Proxy Server and a SIP Public Switched
   Telephone Network (PSTN) gateway is omitted for brevity.  The SIP
   messages are not shown completely.

   A->B

      INVITE sip:[email-masked] SIP/2.0
      From: <sip:[email-masked]>
      To: <sip:[email-masked]>

   B->A

      SIP/2.0 100 Trying

   B->C

      Code = 1 (Access-Request)
      Attributes:
      NAS-IP-Address = c0 0 2 26 (192.0.2.38)
      NAS-Port-Type = 5 (Virtual)
      User-Name = [email-masked]
      Digest-Method = INVITE
      Digest-URI = sip:[email-masked]
      Message-Authenticator =
       TBD

   C->B

      Code = 11 (Access-Challenge)
      Attributes:
      Digest-Nonce = 3bada1a0
      Digest-Realm = example.com
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Message-Authenticator =
       f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40

   B->A

      SIP/2.0 407 Proxy Authentication Required
      Proxy-Authenticate: Digest realm="example.com"
           ,nonce="3bada1a0",qop=auth,algorithm=MD5
      Content-Length: 0

   A->B

      ACK sip:[email-masked] SIP/2.0

   A->B

      INVITE sip:[email-masked] SIP/2.0
      Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
           ,realm="example.com"
           ,response="f3ce87e6984557cd0fecc26f3c5e97a4"
           ,uri="sip:[email-masked]",username="12345678"
           ,qop=auth,algorithm=MD5
      From: <sip:[email-masked]>
      To: <sip:[email-masked]>

   B->C

      Code = 1 (Access-Request)
      Attributes:
      NAS-IP-Address = c0 0 2 26 (192.0.2.38)
      NAS-Port-Type = 5 (Virtual)
      User-Name = [email-masked]
      Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
      Digest-Realm = example.com
      Digest-Nonce = 3bada1a0
      Digest-Method = INVITE
      Digest-URI = sip:[email-masked]
      Digest-Qop = auth
      Digest-Algorithm = md5
      Digest-Username =  12345678
      SIP-AOR =  sip:[email-masked]
      Message-Authenticator =
          TBD

   C->B

      Code = 2 (Access-Accept)
      Attributes:
      Digest-Response-Auth =
                      6303c41b0e2c3e524e413cafe8cce954
      Message-Authenticator =
          75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1

   B->A

      SIP/2.0 180 Ringing

   B->A

      SIP/2.0 200 OK

   A->B

      ACK sip:[email-masked] SIP/2.0

   A second example shows the traffic between a web browser (A), web
   server (B), and a RADIUS server (C).

   A->B

      GET /index.html HTTP/1.1

   B->C

      Code = 1 (Access-Request)
      Attributes:
      NAS-IP-Address = c0 0 2 26 (192.0.2.38)
      NAS-Port-Type = 5 (Virtual)
      Digest-Method = GET
      Digest-URI = /index.html
      Calling-Station-Id="192.168.1.20"
      User-Name="192.168.1.20"
      Message-Authenticator =
       TBD

   C->B

      Code = 11 (Access-Challenge)
      Attributes:
      Digest-Nonce = a3086ac8
      Digest-Realm = example.com
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Message-Authenticator =
       f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40

   B->A

      HTTP/1.1 401 Authentication Required
      WWW-Authenticate: Digest realm="example.com",
          nonce="a3086ac8",qop=auth,algorithm=MD5
      Content-Length: 0

   A->B

      GET /index.html HTTP/1.1
      Authorization: Digest algorithm=MD5,nonce="a3086ac8"
           ,realm="example.com"
           ,response="f052b68058b2987aba493857ae1ab002"
           ,uri="/index.html",username="12345678"
           ,qop=auth,algorithm=MD5

   B->C

      Code = 1 (Access-Request)
      Attributes:
      NAS-IP-Address = c0 0 2 26 (192.0.2.38)
      NAS-Port-Type = 5 (Virtual)
      User-Name = [email-masked]
      Digest-Response = f052b68058b2987aba493857ae1ab002
      Digest-Realm = example.com
      Digest-Nonce = a3086ac8
      Digest-Method = GET
      Digest-URI = /index.html
      Digest-Username =  12345678
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Message-Authenticator =
          TBD

   C->B

      Code = 2 (Access-Accept)
      Attributes:
      Digest-Response-Auth =
          e644aa513effbfe1caff67103ff6433c
      Message-Authenticator =
          7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7

   B->A

      HTTP/1.1 200 OK
      ...

      <html>
      ..."

=========================
Issue 196: User-Name Attribute
Submitter names: Cristina Ruiz
Submitter email address: [email-masked]
Date first submitted: June 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00527.html
Document: DIGEST-09
Comment type: 'T'echnical
Priority: S
Section: 5, 6
Rationale/Explanation of issue:

The User-Name attribute is mandatory in the RADIUS Access Request as 
indicated in the table of attributes (Section 5). But in the initial HTTP 
GET method, the user-name is not received, and in the example (Section 6) 
nothing is  sent in the User-name attribute in the B->C comunication. What 
does the RADIUS client include in the User-Name attribute in this case? And 
what shall the RADIUS Server do when this dummy user-name is received?

I think the "client nonce generation mode" removed from draft 07 was usefull 
to avoid inventing a user name in  this HTTP case (where the nonce 
generation does not depend on the user and this is not received in the 
initial  request). Why was it removed?

--
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, 02 Jan 2007 01:06:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RFC 4590bis Update
Date: Mon, 01 Jan 2007 17:05:53 -0800

As discussed at IETF 67, a number of errata have been found in RFC 4590.   
Given the number and seriousness of the problems (mistaken IANA allocations, 
errors in the Attribute Table and examples, etc.), it appears that spinning 
a new RFC will be required, rather than merely submitting errata to the RFC 
Editor.

Between now and IETF 68, the goal is to come to closure on fixes to the 
issues that have been submitted, do a month-long WG last call (to catch any 
remaining errors), and get an RFC 4590bis document to the IESG.

A strawman RFC 4590bis document is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-rfc4590bis-00.txt

--
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, 01 Jan 2007 12:53:36 +0000
Date: Mon, 01 Jan 2007 13:52:53 +0100
From: Hannes Tschofenig <[email-masked]>
To:  [email-masked],  [email-masked],  [email-masked]
Subject: Reminder: Diameter Interop

Please don't forget to register!

-------- Original Message --------
Subject: 	Upcoming Diameter Interop
Date: 	Fri, 8 Dec 2006 16:05:06 +0100
From: 	Tschofenig, Hannes <[email-masked]>
To: 	<[email-masked]>, <[email-masked]>

Hi all, 

our interop event planning is finished.
 
WHAT? Diameter Interoperability Event

Further information regarding agenda, test framework, venue and travel
information as well as on-line registration are available at:
http://www.diameterinterop.com
  
WHEN? January 29 - February 2, 2007 
 
WHERE? Orlando, Florida (hosted by IntelliNet Technologies)
 
WHO? Companies implementing Diameter, Diameter extensions and Diameter
applications

A copy-and-paste from the press announcement: 
" 
The Diameter Interoperability Event provides an excellent opportunity
for vendors of the Diameter protocol and applications to test their
implementations in a friendly setting and get a better understanding of
the protocol behavior. Discussions with peers and the experts from DiME
provide a forum to realize an industry leading implementation. We are
expecting a substantial number of participating companies and products,
including the base protocol from several vendors as well as a broad
range of applications using the protocol. This offers you the
opportunity to further refine your own products and assure their
interoperability.
"

IMPORTANT: Please register at http://www.diameterinterop.com 
(deadline: January 15, 2007) 

Ciao
Hannes & John

--
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/>