RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt

[Abhishek Tiwari <[e-mail]>]

Glen Zorn Wrote:
<<<<
Given that there is no discussion whatsoever of Microsoft SSTP in this
document, I can't see how anyone could judge from reading it whether the
proposed assignment will "negatively impact interoperability or otherwise
extend IETF protocols in an inappropriate or damaging manner" or not.  As I
mentioned in my original review, the best solution would be to separate the
Microsoft proprietary stuff into another document, both documenting SSTP and
allocating a Tunnel-Type value for it.

The only reference given for SSTP is to a Microsoft marketing Web site.
>>>>>

1. The reference is not to a marketing site, but rather to the MS-SSTP documentation within the Windows Communications Protocols (MCPP) specification library, which is part of the Open Specifications Developer Center on MSDN. This is also in line with guidelines provided and approved by EU and DoJ.

2. Previous allocations of Tunnel-Type values have been made for vendor developed protocols, some of which (Bay Dial Virtual Service) are not documented  as an Internet draft.

-- Abhishek

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



Envelope-to: [e-mail]
Delivery-date: Wed, 26 Nov 2008 07:42:16 +0000
From: Abhishek Tiwari <[e-mail]>
To: Glen Zorn <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Wed, 26 Nov 2008 15:41:15 +0800
Subject: RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
Thread-Topic: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEAAN2e3AABwdC8AMessage-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Glen Zorn Wrote:
<<<<
Given that there is no discussion whatsoever of Microsoft SSTP in this
document, I can't see how anyone could judge from reading it whether the
proposed assignment will "negatively impact interoperability or otherwise
extend IETF protocols in an inappropriate or damaging manner" or not.  As I
mentioned in my original review, the best solution would be to separate the
Microsoft proprietary stuff into another document, both documenting SSTP and
allocating a Tunnel-Type value for it.

The only reference given for SSTP is to a Microsoft marketing Web site.
>>>>>

1. The reference is not to a marketing site, but rather to the MS-SSTP documentation within the Windows Communications Protocols (MCPP) specification library, which is part of the Open Specifications Developer Center on MSDN. This is also in line with guidelines provided and approved by EU and DoJ.

2. Previous allocations of Tunnel-Type values have been made for vendor developed protocols, some of which (Bay Dial Virtual Service) are not documented  as an Internet draft.

-- Abhishek

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


Envelope-to: [e-mail]
Delivery-date: Wed, 26 Nov 2008 06:20:00 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>
Subject: FW: I-D Action:draft-zorn-radius-pkmv1-02.txt 
Date: Tue, 25 Nov 2008 22:18:22 -0800
Message-ID: <00d901c94f8e$c9a9f980$5cfdec80$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DA_01C94F4B.BB86B980"
Thread-Index: AclPe3bUkGIoMGBfRgeHM89QWOAvLAAEz6cg
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_00DA_01C94F4B.BB86B980
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Tuesday, November 25, 2008 8:00 PM
To: [e-mail]
Subject: I-D Action:draft-zorn-radius-pkmv1-02.txt 

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

	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
Management Version 1 (PKMv1) Protocol Support
	Author(s)       : G. Zorn
	Filename        : draft-zorn-radius-pkmv1-02.txt
	Pages           : 14
	Date            : 2008-11-25

This document defines a set of RADIUS Attributes which are designed to
provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_000_00DA_01C94F4B.BB86B980
Content-Type: Message/External-body;
	name="draft-zorn-radius-pkmv1-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-zorn-radius-pkmv1-02.txt"

Content-Type: text/plain
Content-ID: <[e-mail]>


------=_NextPart_000_00DA_01C94F4B.BB86B980
Content-Type: text/plain;
	name="ATT00203.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00203.txt"

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_00DA_01C94F4B.BB86B980--


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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 22:26:54 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
Date: Tue, 25 Nov 2008 14:25:42 -0800
Message-ID: <007201c94f4c$c1bc1f10$45345d30$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEAAN2e3AAAew8tAAARV2gA=
Content-Language: en-us

> Glen Zorn writes...
> 
> > The title is so vague as to be meaningless: suggest changing to the
> > extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating
> Security
> > Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see
> > below), w/an appropriate abbreviation for the second & following
> pages.
> 
> Agreed.
> 
> > The document allocates two tunnel types but briefly discusses only
> one of
> > them; the other, proprietary to Microsoft Corporation, receives no
> > attention whatsoever.
> 
> > This is a
> > problem because RFC 2868 states that new Tunnel-Type values are to be
> > assigned using the "IETF Consensus" policy (note that RFC 2868 is
> > specifically _not_ updated by RFC 3575).  RFC 5226 says
> >
> >       IETF Review - (Formerly called "IETF Consensus" in
> >             [IANA-CONSIDERATIONS]) New values are assigned only
> through
> >             RFCs that have been shepherded through the IESG as AD-
> >             Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
> >             intention is that the document and proposed assignment
> will
> >             be reviewed by the IESG and appropriate IETF WGs (or
> >             experts, if suitable working groups no longer exist) to
> >             ensure that the proposed assignment will not negatively
> >             impact interoperability or otherwise extend IETF
> protocols
> >             in an inappropriate or damaging manner.
> >
> > Given that there is no discussion whatsoever of Microsoft SSTP in
> this
> > document, I can't see how anyone could judge from reading it whether
> the
> > proposed assignment will "negatively impact interoperability or
> otherwise
> > extend IETF protocols in an inappropriate or damaging manner" or not.
> 
> Well, there is no attempt to standardize SSTP here, just to allow
> RADIUS to
> provision it.  

In a standard fashion...

> Given that adding a new value of an integer-type
> enumerated
> value attribute is not likely to have any adverse impact on the RADIUS
> protocol, I see no need for extensive discussion there.  One can argue
> whether SSTP itself is a good or bad thing, but that discussion seems
> somewhat orthogonal to the issue at hand.

In that case, perhaps all the discussion of IPSec is extraneous, as well?
My point is that at least a couple of paragraphs in the draft are devoted to
providing justification of the new IPSec tunnel type, but there is no
justification given whatsoever for the allocation of the proprietary one.
This seems a bit backwards to me; OTOH, if we're just going to sanction
allocation for the asking, then why require a document at all?

> 
> > The only reference given for SSTP is to a Microsoft marketing Web
> site.
> 
> Well, the MSDN Library is not a marketing site, but rather a technical
> reference site.  

Ever heard of technical marketing? ;-)

...


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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 21:55:44 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
Date: Tue, 25 Nov 2008 16:54:40 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <CAB0AF9DBF0B458C8870EA31BCD4BB51@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEAAN2e3AAAew8tA
Glen Zorn writes...

> The title is so vague as to be meaningless: suggest changing to the
> extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating Security
> Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see
> below), w/an appropriate abbreviation for the second & following pages.

Agreed.
 
> The document allocates two tunnel types but briefly discusses only one of
> them; the other, proprietary to Microsoft Corporation, receives no
> attention whatsoever.

> This is a
> problem because RFC 2868 states that new Tunnel-Type values are to be
> assigned using the "IETF Consensus" policy (note that RFC 2868 is
> specifically _not_ updated by RFC 3575).  RFC 5226 says
> 
>       IETF Review - (Formerly called "IETF Consensus" in
>             [IANA-CONSIDERATIONS]) New values are assigned only through
>             RFCs that have been shepherded through the IESG as AD-
>             Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
>             intention is that the document and proposed assignment will
>             be reviewed by the IESG and appropriate IETF WGs (or
>             experts, if suitable working groups no longer exist) to
>             ensure that the proposed assignment will not negatively
>             impact interoperability or otherwise extend IETF protocols
>             in an inappropriate or damaging manner.
> 
> Given that there is no discussion whatsoever of Microsoft SSTP in this
> document, I can't see how anyone could judge from reading it whether the
> proposed assignment will "negatively impact interoperability or otherwise
> extend IETF protocols in an inappropriate or damaging manner" or not.

Well, there is no attempt to standardize SSTP here, just to allow RADIUS to
provision it.  Given that adding a new value of an integer-type enumerated
value attribute is not likely to have any adverse impact on the RADIUS
protocol, I see no need for extensive discussion there.  One can argue
whether SSTP itself is a good or bad thing, but that discussion seems
somewhat orthogonal to the issue at hand.

> The only reference given for SSTP is to a Microsoft marketing Web site.

Well, the MSDN Library is not a marketing site, but rather a technical
reference site.  Still, I agree that this is not an absolutely stable
reference.  In a web search I found that SSTP is the subject of a US Patent
Application, (summarized below) so there may at some point be a US Patent
that could serve as a stable reference.  ;-)

Title: Secure Tunnel Over HTTPS Connection

Document Type and Number: United States Patent Application 20080077788 

Kind Code: A1 

Abstract: Many secure tunnels require protocols that require special
handling, authorization or security certificates, such as L2TP and PPTP.
This often eliminates them for use between a corporate or agency network and
outside, public networks. A secure socket tunnel protocol (SSTP) adds
drivers in both the kernel and user mode to route standard protocol traffic,
such as PPP, over a common HTTPS port. In the event of network
interruptions, an exchange of a session cookie allows fast reconnection of
the underlying HTTPS connection without affecting higher level applications.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 19:01:41 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Last Call on draft-ietf-radext-tunnel-type-00.txt 
Date: Tue, 25 Nov 2008 14:01:18 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <F14C1DB76C764AE7809C8D2D79A81108@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclO9bgiwZ4guWGbT1uE/smn8TT+5QAOLXOw

This is an announcement of RADEXT WG Last Call on the "New Tunnel-Type
Values" draft prior to requesting that the IESG publish it as an
Informational RFC.   This document requires IETF Consensus to assign new
value of the RADIUS Tunnel-Type Attribute (an oversight in RFC 3575).
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-tunnel-type-00.txt

WG Last Call will last until December 15, 2008.  Yes, it's a busy time of
year, but this is a *very* short and simple draft.  Please review the
document and post your comments to the RADEXT WG mailing list
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

Regards,

Dave



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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 19:00:17 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Abhishek Tiwari'" <[e-mail]>
Cc: <[e-mail]>
Subject: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
Date: Tue, 25 Nov 2008 10:58:39 -0800
Message-ID: <002701c94f2f$d5a66980$80f33c80$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEAAN2e3A
Content-Language: en-us

I was the first to comment on this draft, the day it came out; apparently,
however, my comments were lost in the flurry of positive comments from
unrecognized (by me) people with Yahoo! email addresses (I suppose that MSN
would have been too obvious ;-) so I'll try again.

The title is so vague as to be meaningless: suggest changing to the
extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating Security
Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see below),
w/an appropriate abbreviation for the second & following pages.

The document allocates two tunnel types but briefly discusses only one of
them; the other, proprietary to Microsoft Corporation, receives no attention
whatsoever.  Were we not supposed to notice that it was there?  This is a
problem because RFC 2868 states that new Tunnel-Type values are to be
assigned using the "IETF Consensus" policy (note that RFC 2868 is
specifically _not_ updated by RFC 3575).  RFC 5226 says

      IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

Given that there is no discussion whatsoever of Microsoft SSTP in this
document, I can't see how anyone could judge from reading it whether the
proposed assignment will "negatively impact interoperability or otherwise
extend IETF protocols in an inappropriate or damaging manner" or not.  As I
mentioned in my original review, the best solution would be to separate the
Microsoft proprietary stuff into another document, both documenting SSTP and
allocating a Tunnel-Type value for it.

The only reference given for SSTP is to a Microsoft marketing Web site.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 14:47:42 +0000
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2008 15:46:57 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Updates to the guidelines document.
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> The "change token" for the guidelines draft is now with the Document
> Shepherd and the IESG.  That's what happens when the WG submits a
> document to the IESG for publication -- it gives up the right to keep
> changing the document.  :-)  You could raise a "late" IETF Last Call
> issue...

  OK.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 12:33:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Comments on draft-ietf-radext-radsec-02 for WGLC
Date: Tue, 25 Nov 2008 13:33:02 +0100
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-ietf-radext-radsec-02 for WGLC
Thread-Index: AclObjQBwOL/R/NwSsCqAxxPvZa2ZwAi4jQg
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Joseph Salowey (jsalowey)" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Joseph 
> Salowey (jsalowey)
> Sent: Monday, November 24, 2008 9:53 PM
> To: [e-mail]
> Subject: Comments on draft-ietf-radext-radsec-02 for WGLC
> 
> Here are some working group last call comments on RADSEC:
> 
> 1.  How is backward compatibility/forward migration of RADSEC handled?
> Operational recommendations in this area should be discussed.   The
> potential for rollback attacks should also be covered in the 
> security considerations section.  
> 

I very much agree with this comment. You would have received it as an AD
or OPS-DIR comment if Joe did not raise it. 

Dan

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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 12:03:21 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Abhishek Tiwari'" <[e-mail]>
Subject: RE: Review of draft-tiwari-radext-tunnel-type-02.txt
Date: Tue, 25 Nov 2008 07:02:59 -0500
Message-ID: <85E9A0BD11094D418ACD921555E36A46@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEAABJESw

> I have submitted the draft "draft-ietf-radext-tunnel-type-00.txt" to I-D
> archive for RADEXT WG last call.

OK, thanks.  We'll start WGLC once the I-D is announced.  This was discussed
briefly at IETF-73 and no one in the room had any objection to an immediate
WGLC on this draft.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 12:00:47 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-tunnel-type-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 25 Nov 2008 04:00:01 -0800 (PST)

--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           : New Tunnel-Type Values
	Author(s)       : A. Tiwari
	Filename        : draft-ietf-radext-tunnel-type-00.txt
	Pages           : 6
	Date            : 2008-11-25

This document defines a set of values for the Tunnel-Type RADIUS
Attribute.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-tunnel-type-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 11:30:56 +0000
From: Abhishek Tiwari <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 25 Nov 2008 19:30:18 +0800
Subject: RE: Review of draft-tiwari-radext-tunnel-type-02.txt
Thread-Topic: Review of draft-tiwari-radext-tunnel-type-02.txt
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEA=
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I have submitted the draft "draft-ietf-radext-tunnel-type-00.txt" to I-D archive for RADEXT WG last call.

Thanks,
Abhishek

-----Original Message-----
From: David B. Nelson [mailto:[e-mail]]
Sent: Thursday, November 13, 2008 5:56 PM
To: [e-mail]
Cc: Abhishek Tiwari
Subject: RE: Review of draft-tiwari-radext-tunnel-type-02.txt

> "The comment period will last until October 5, 2008."
>
> Any progress?

There have been a number of positive comments to the list with regard to
accepting this draft as a WG work item, and no negative comments.  Consider
it accepted.

The window for draft submission will open up again on the Monday of IETF 73
week. Given the simple nature of the draft, we can immediately start a WG
Last Call, perhaps immediately after ITEF 73.




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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 10:48:18 +0000
Message-ID: <[e-mail]>
Date: Tue, 25 Nov 2008 11:47:13 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Greg Weber <[e-mail]>
CC: radext mailing list <[e-mail]>
Subject: Re: Question on Status-Server document and CoA port
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Weber wrote:
> I would suggest to remove this text unless you want to pursue it
> on the Experimental track.

  Fine by me.

>  At least, I would think any watchdog
> traffic should be on the same port/addr path as the signaling traffic
> that it's trying to protect, in order to avoid firewall changes in the POP.

  What does that mean?  CoA packets *are* signaling traffic.  If normal
CoA packets can get from the RADIUS server to the NAS, then this (ab)use
of Status-Server should work, too.

> You are trying to see if the NAS can initiate authentication/accounting,
> right, not if the DAS is operating?

  No.  The idea was to (1) signal to the NAS that the RADIUS server was
alive, and (2) see if the NAS (or dynamic authorization server) was
operating.

>  It just seems like you are trying
> to recreate the Status-Client behavior by using Status-Server on the
> CoA port.

  Quite possibly.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Nov 2008 03:23:20 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=VoOaKJPE7B66a8KrzkVNVBUOw37u0yOFXGOXNhkDQlI=; b=Bu2/w9vTpWKdIaGY/cJmIRhAf/eo1eOK/lsWDbGyLA1RvAKaRbD8PZ3WrKbHkaEfUI PMOPvt3xZx8Gp4t/atNuIU0SC4Pqn7bnJmfSTasOyAxzLbBBf8ZwZyWtoqumVMS+1rhk 27zROa0jKBMNLDOk3r2jry1vzMiv0N1Meht4UDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LM4xhidvbn5IKZWH+gSj54MHOxtXC1Do/+T6oibj4X7fXNI3FHbwTyKrlm5NxZg/0u 63yVPGRuiU1jHx+eeWkCC+iIYX+AYBk/7U64L05Sl6unk43tSSqD5DCPl9GaHTKC0N6c QjLMFaWvXi1487PG5JHWZ7Xwp//SqFRz/7TEQMessage-ID: <[e-mail]>
Date: Mon, 24 Nov 2008 22:22:16 -0500
From: "Greg Weber" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Subject: Re: Question on Status-Server document and CoA port
Cc: "radext mailing list" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Nov 19, 2008 at 1:27 PM, Alan DeKok <[e-mail]> wrote:
>  One issue with the current draft was brought up in the WG meeting
> yesterday.  The draft proposes that when RADIUS servers start, they send
> Status-Server packets to any NASes that have a CoA port defined.  This
> procedure can be used by the NAS to determine that the server is up,
> potentially increasing network stability.
>
>  This behavior, however, is not part of the traditional implementations
> of Status-Server.  It was suggested at the least IETF by Glen, and added
> to the document after that.
>
>  If the server has many NASes configured, it may send tens, or possibly
> hundreds of packets on startup.  It would seem reasonable to add a
> suggestion to use jitter, though the current draft doesn't suggest that.
>
>  Should the document be updated to suggest jitter, or should the text
> relating to CoA be deleted entirely?

I would suggest to remove this text unless you want to pursue it
on the Experimental track.  At least, I would think any watchdog
traffic should be on the same port/addr path as the signaling traffic
that it's trying to protect, in order to avoid firewall changes in the POP.
You are trying to see if the NAS can initiate authentication/accounting,
right, not if the DAS is operating?  It just seems like you are trying
to recreate the Status-Client behavior by using Status-Server on the
CoA port.

Greg

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

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


Envelope-to: [e-mail]
Delivery-date: Mon, 24 Nov 2008 19:53:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Comments on draft-ietf-radext-radsec-02 for WGLC
Date: Mon, 24 Nov 2008 11:52:38 -0800
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-ietf-radext-radsec-02 for WGLC
Thread-Index: AclObjQBwOL/R/NwSsCqAxxPvZa2Zw=
From: "Joseph Salowey (jsalowey)" <[e-mail]>
To: <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l43; t27556360; x28420360; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Joseph Salowey (jsalowey)" <jsalowey@ci sco.com> |Subject: Comments on draft-ietf-radext-radsec-02 f or WGLC |Sender: ; bh=U5bPRMCgfSvL2n9rol56vnG9uLxeEgsc5/R3oHUohAg=; b=GtKqy081B43XAdA11NJp8XnjRCGIctOZon4wRibDP/y7DgE+6KmncLmHyN O7+P7ewylVGlJGzbftk3+xU5+wPhhK3FGGgqLCPIQKgEnfXcOKU1Io4AEHxX xQuykIIqh/;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );

Here are some working group last call comments on RADSEC:

1.  How is backward compatibility/forward migration of RADSEC handled?
Operational recommendations in this area should be discussed.   The
potential for rollback attacks should also be covered in the security
considerations section.  

2.  I think the certificate handling and authorization section needs to
be more specific for supporting mandatory to implement options.
Currently, the document implicitly requires trust root based
authorization where all certs issued by a given trust root are
authorized.  Some more specific rules are discussed in an informative
section.  I believe some of this needs to be normative and more specific
in order to have interoperable implementations.  This should also be
discussed in the security considerations. 

3.  I'm not sure I understand the choice of ciphersuites.

Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that it would be
much preferable to use AES or 3DES? 

4.  The document should state that the fixed string "radsec" shared
secret MUST NOT be used when TLS is not available.  

5. The terms "dynamic peer resolution" and "dynamic peer discovery" are
used in the document and not clearly defined.  

6. Would RADSEC benefit from a mechanism that did not require a PKI?
This could be achieved by specifying a certificate fingerprint or PSK
mode of operation.  

Cheers,

Joe

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


Envelope-to: [e-mail]
Delivery-date: Mon, 24 Nov 2008 16:24:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=7/HA5QufYv+ftPwU5afDvN5LTfSCjMfSMZCKMqZzmEo=; b=TrLG++m6Z2E78rDDbKUNNTIs24R6DDujdrI4iaARuZdUn6Y85rxFTjg7NS8ZlZjQ22 2tzAzj4vosUUMyJmma9gbGc18rNRUmlVGFKFWaeNa0NHscWvZwYadr3lkSkdihdBcPub 39DMjYllSBZdc4yLT2fJUdBgMT3z0LYPg2oW4DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=JTSg6O/PRKpe4ps/TSEaUAQ3c5v7myHZEd20AriA4qgGLXc1ce7VU7NZ223DDLWHVx +99xBl8vlUJOetuw1fcZzMZOCYxXNSQL76EhuWBk2mCfo3giRP6OpmZZkgsN5HoxLuv7 jLtJlPi2IWiXZz+1xDBgfAD52oRkmKy3o3A+gMessage-ID: <[e-mail]>
Date: Mon, 24 Nov 2008 11:23:15 -0500
From: "Greg Weber" <[e-mail]>
To: "radext mailing list" <[e-mail]>
Subject: [ISSUE] Status-Server
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Status-Server comments
Submitter name: Greg Weber
Submitter email address: [e-mail]
Date first submitted: November 24, 2008
Reference: n/a
Document: draft-ietf-radext-status-server-02.txt
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: various

Here are some editorial comments on the Status-Server doc currently in
WG last call.

* idnits says the boilerplate needs to be updated.
*  In section 3, I see: "Status-Server packets MAY include NAS-Identifier,
one of NAS-IP-Address or NAS-IPv6-Address, and Reply-Message."
This conflicts with the Table of Attributes in section 6 which indicates
that Reply-Message cannot be included in Status-Server packets.
* Reply-Message can be included in Access-Accept, but not Acct-Response?
That means the Verbose Query and Response example in section 7.3 works
only for authentication servers and not accounting servers.  That seems like
a discontinuity.
* The Table of Attributes in section 6 indicates that Calling-Station-Id
may be included Status-Server and Access-Accept packets.  This
conflicts with RFC 2865 which disallows that attribute in Access-Accept.
And, how would this attribute be populated in Status-Server packets
where there is no associated calling station?
* I would suggest removing all of section 5.  These topics seem related,
but not germane to the purpose and scope of this doc.
* In section 4.1, I see "Robust implementations SHOULD accept any Response
packet as a valid response to a Status-Server packet..."  That seems to be a
pretty fundamental change to the RADIUS request/response model.  I would
suggest removing that paragraph or changing it to a MAY.

Small changes by section:
ToC: Fix indent & missing title on 2.3.2
Section 3: "MUST NOTE" -> "MUST NOT"
Section 3.1: "is an CoA-ACK packet" -> "is a CoA-ACK packet."
Section 4.3: "to start packets to start" -> "to start"
Section 4.4: "may sent" -> "may be sent"
Section 4.6: "along along" -> "along"
Section 4.6: "impement" -> "implement"
Section 5.1: "has internal RADIUS server that proxy" ->
  "has an internal RADIUS server that proxies"
Section 6: "table provide a guide" -> "table provides a guide"

Small global changes:
"it's" -> "its" (6 times)
"wide-spread" -> "widespread" (2 times)
"inter-operable" -> "interoperable" (1 time)
"use-case" -> "use case" (3 times)
"pro-actively" -> "proactively" (1 time)
"re-use" -> "reuse" (3 times)
"coa" -> "CoA" (2 times)
"16-octet" -> "16 octet" (3 times)

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


Envelope-to: [e-mail]
Delivery-date: Mon, 24 Nov 2008 11:43:26 +0000
Message-ID: <[e-mail]>
Date: Mon, 24 Nov 2008 06:42:57 -0500
From: "David B. Nelson" <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Updates to the guidelines document.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alan DeKok wrote:

>   As noted at IETF 73, we should likely update the guidelines document
> to include a note on the Called-Station-Id attribute.  RFC 3580 defines
> it to contain two independent fields: MAC and SSID.  As this is a
> complex type not used for security or authentication, it should be
> listed in Appendix B.
> 
>   Suggested text is below.  If there are no objections, it can go into
> the next revision of the document.
> 
>   Alan DeKok.

The "change token" for the guidelines draft is now with the Document 
Shepherd and the IESG.  That's what happens when the WG submits a 
document to the IESG for publication -- it gives up the right to keep 
changing the document.  :-)  You could raise a "late" IETF Last Call 
issue...


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


Envelope-to: [e-mail]
Delivery-date: Mon, 24 Nov 2008 11:25:23 +0000
Message-ID: <[e-mail]>
Date: Mon, 24 Nov 2008 12:24:14 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Updates to the guidelines document.
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  As noted at IETF 73, we should likely update the guidelines document
to include a note on the Called-Station-Id attribute.  RFC 3580 defines
it to contain two independent fields: MAC and SSID.  As this is a
complex type not used for security or authentication, it should be
listed in Appendix B.

  Suggested text is below.  If there are no objections, it can go into
the next revision of the document.

  Alan DeKok.


---
B.8. Called-Station-Id

   [RFC3580] Section 3.20 defines a format for the Called-Station-Id
   Attribute which can be sent by a RADIUS client:

      For IEEE 802.1X Authenticators, this attribute is used to store
      the bridge or Access Point MAC address in ASCII format (upper case
      only), with octet values separated by a "-".  Example:
      "00-10-A4-23-19-C0".  In IEEE 802.11, where the SSID is known, it
      SHOULD be appended to the Access Point MAC address, separated from
      the MAC address with a ":".  Example "00-10-A4-23-19-C0:AP1".

   The sub-fields encoded in this attribute are independent, and do not
   carry security or authentication data.  This use of a complex text
   type is therefore NOT RECOMMENDED.  Future specifications SHOULD NOT
   use similar methods to pack multiple fields of type text into one
   text attribute.  This specification should have instead defined a new
   attribute to contain the SSID.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 23 Nov 2008 16:30:01 +0000
Message-ID: <[e-mail]>
Date: Sun, 23 Nov 2008 17:28:48 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Greg Weber <[e-mail]>
CC: radext mailing list <[e-mail]>
Subject: Re: Question on Status-Server document and CoA port
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Weber wrote:
> I am confused about how this WG item is being pursued.
> The WG charter milestone says the document will be
> submitted as a Proposed Standard, but it has been submitted
> as Informational (non-standards track).

  That's likely a typo left over from it originating as an individual
submission.

> Can someone clarify whether the purpose is to:
> 1) Document the original TAOS & CVX implementations from 9-10 yrs back
> as Informational.

  Document, yes.

> 2) Add a bunch of new stuff (CoA) which should probably make this Experimental.

  This was discussed in Dublin && in Minneapolis.  The suggestion in
Dublin was to add CoA.  The suggestion in Minneapolis was to remove it.

  I've asked that the WG respond on this issue.  If there's WG consensus
to remove it, it's gone.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 21 Nov 2008 03:27:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh:W0lt1EUYMJBsxZvHIG+FXFqAOCIsdb28NeMHsU1Fo=; b=DO0pBz1KkvuZHsKPnHHJXlPx4JvwHBRH/Fj/6cmnhZdbQOjGNk9Che+NzvLyRCAJgp j1MTub8cMtP1jLhuEhDB0O0cJWOuM22BE5E4VdqoHNdiZ2OvUAUqtrOYmDvx6pNvhqe8 f1TFfD/kfUrpqVoXlerbawU8V7g41d9K83SiEDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gkvHoZvp0wNind8k/fA69eFdVMM95b9nTXA02JjnlCYPlE6R8fgdcJBVf9KIQjL/1C WmTNZaEl8+GPu881JtAO+9/qH77nR1DZGsxVqEIp968rjdUgUAzWjhnNuOMHDYWtnLAE yAcmVE9H+3zk6/dHpKf5YxIsyzONzOiE5Xt/4Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 22:25:54 -0500
From: "Greg Weber" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Subject: Re: Question on Status-Server document and CoA port
Cc: "radext mailing list" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I am confused about how this WG item is being pursued.
The WG charter milestone says the document will be
submitted as a Proposed Standard, but it has been submitted
as Informational (non-standards track).

Can someone clarify whether the purpose is to:
1) Document the original TAOS & CVX implementations from 9-10 yrs back
as Informational.
2) Add a bunch of new stuff (CoA) which should probably make this Experimental.
3) Develop something on the standards track complete with WG consensus.
4) Something else??

Sorry if this was covered in the WG mtg this week -did not attend.
[I'd pick 1) above.]

Greg


On Wed, Nov 19, 2008 at 1:27 PM, Alan DeKok <[e-mail]> wrote:
>  One issue with the current draft was brought up in the WG meeting
> yesterday.  The draft proposes that when RADIUS servers start, they send
> Status-Server packets to any NASes that have a CoA port defined.  This
> procedure can be used by the NAS to determine that the server is up,
> potentially increasing network stability.
>
>  This behavior, however, is not part of the traditional implementations
> of Status-Server.  It was suggested at the least IETF by Glen, and added
> to the document after that.
>
>  If the server has many NASes configured, it may send tens, or possibly
> hundreds of packets on startup.  It would seem reasonable to add a
> suggestion to use jitter, though the current draft doesn't suggest that.
>
>  Should the document be updated to suggest jitter, or should the text
> relating to CoA be deleted entirely?
>
>  Alan DeKok.
>
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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


Envelope-to: [e-mail]
Delivery-date: Wed, 19 Nov 2008 19:48:55 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=br7tt26TXa+sLjYvUBNSkJLimVw0FnpZKwxY4XapnMPtV7zxTDCZFqZaVtx4SZA96lDntCRUsaxeYJ25lXq6aQxtWEViGpHoDUynN4KKocszD8TsPgjrU3nGU/lshjlGErs6rT571qpbT0fLtNh8/pqykvOAhlbimU7HnRbqTjk=;
Date: Wed, 19 Nov 2008 11:48:18 -0800 (PST)
From: Behcet Sarikaya <[e-mail]>
Reply-To: Behcet Sarikaya <[e-mail]>
Subject: Service issues in  prefix authorization
To: Bernard Aboba <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1422431512-1227124098=:95491"
Message-ID: <[e-mail]>

--0-1422431512-1227124098=:95491
Content-Type: text/plain; charset=us-ascii

Hi all,

  Bernard asked me to start some discussion on the list regarding what types of services to be used after transporting the prefixes to the Radius Client to assure that the prefixes reach the end user.
  Regards,

Behcet


      
--0-1422431512-1227124098=:95491
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:14pt"><div style="font-family: times new roman,new york,times,serif; font-size: 14pt;">Hi all,<br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 14pt;"><div>&nbsp; Bernard asked me to start some discussion on the list regarding what types of services to be used after transporting the prefixes to the Radius Client to assure that the prefixes reach the end user.<br>&nbsp; Regards,<br><br>Behcet<br>&nbsp; <br></div></div><br>

      </div></div></div><br>



      </body></html>
--0-1422431512-1227124098=:95491--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 19 Nov 2008 18:33:03 +0000
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 12:32:43 -0600
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: TCP transport draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  The WG meeting yesterday raised a number of potential issues with the
draft.

  1) The document doesn't discuss UDP -> TCP and TCP -> UDP issues when
proxying packets.  This needs to be updated.  There are also
head-of-line blocking issues when there are sudden spikes of traffic.

  2) The document needs more review from the transport area for TCP issues.

  3) TCP && RadSec.

	Q: Does the WG want to *forbid* "raw" TCP transport?

  i.e. TCP MUST be used with RadSec.  TCP MUST NOT be used to transport
bare RADIUS.

  4) Use of Status-Server as the RFC3539 watchdog timer packet.  The
issues surrounding Status-Server means that 1 RADIUS ID will have to be
dedicated to Status-Server.  This means that there can only be 255
packets "in flight" on one TCP connection.

	Q: Does the WG want to stay with Status-Server, or define a new
	   packet code?

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 19 Nov 2008 18:27:51 +0000
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 2008 12:27:12 -0600
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Question on Status-Server document and CoA port
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  One issue with the current draft was brought up in the WG meeting
yesterday.  The draft proposes that when RADIUS servers start, they send
Status-Server packets to any NASes that have a CoA port defined.  This
procedure can be used by the NAS to determine that the server is up,
potentially increasing network stability.

  This behavior, however, is not part of the traditional implementations
of Status-Server.  It was suggested at the least IETF by Glen, and added
to the document after that.

  If the server has many NASes configured, it may send tens, or possibly
hundreds of packets on startup.  It would seem reasonable to add a
suggestion to use jitter, though the current draft doesn't suggest that.

  Should the document be updated to suggest jitter, or should the text
relating to CoA be deleted entirely?

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 19 Nov 2008 17:22:34 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-ietf-radext-crypto-agility-requirements-01.txt 
Date: Wed, 19 Nov 2008 12:22:11 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <6BB535653AE44FCF8711B4201CC5E99A@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AclKatGV99UumzDpRU+jy7ywcVTxDgAACEUg

I believe that the -01 version of the RADIUS Crypto-Agility Requirements
draft addresses all the open WGLC issues, as we discussed in yesterday's
RADEXT WG meeting here at IETF-73.  Please take a moment to review the
changes.  Those who have open issues are especially requested to acknowledge
whether they can be closed.

Regards,

Dave



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


Envelope-to: [e-mail]
Delivery-date: Wed, 19 Nov 2008 17:16:08 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 19 Nov 2008 09:15:01 -0800 (PST)

--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           : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
	Author(s)       : D. Nelson
	Filename        : draft-ietf-radext-crypto-agility-requirements-01.txt
	Pages           : 9
	Date            : 2008-11-19

This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-crypto-agility-requirements-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 18 Nov 2008 14:29:39 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_4814e199-34f4-4980-aeea-e588a2a001e0_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: FW: IEEE 802.16 Review Request
Date: Tue, 18 Nov 2008 06:28:48 -0800
MIME-Version: 1.0

--_4814e199-34f4-4980-aeea-e588a2a001e0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




CC: [e-mail]; [e-mail]; [e-mail]; [e-mail]: [e-mail]: [e-mail]: Re: IEEE 802.16 Review RequestDate: Mon, 17 Nov 2008 14:43:39 -0700
Dear Bernard,

Thanks for calling our attention to this issue.

The IEEE 802.16 Working Group has developed the following response:
 <http://ieee802.org/16/liaison/docs/L80216-08_069r1.pdf>.

We appreciate the opportunity to provide the review.

Regards,

Roger



Dr. Roger B. Marks  <[e-mail]>
Chair, IEEE 802.16 Working Group on Broadband Wireless Access <http://WirelessMAN.org>


On 2008/10/30, at 02:25 PM, Bernard Aboba wrote:

Recently, the IETF RADEXT WG has received a request to accept the document "RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1" as a working group work item.  The specification is available here:http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt Since this document relates to IEEE 802.16, we would like to inquire as to whether IEEE 802.16 has an opinion on the advisability of having IETF take on this work, as well as to whether IEEE 802.16 has any editorial or technical feedback relating to the document.  This document is likely to be discussed during IETF 73 in Minneapolis, which will take place from November 16-21, 2008.  
--_4814e199-34f4-4980-aeea-e588a2a001e0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<BR>
<HR id=stopSpelling>
CC: [e-mail]; [e-mail]; [e-mail]; [e-mail]<BR>From: [e-mail]<BR>To: [e-mail]<BR>Subject: Re: IEEE 802.16 Review Request<BR>Date: Mon, 17 Nov 2008 14:43:39 -0700<BR><BR>
<DIV>Dear Bernard,</DIV>
<DIV><BR></DIV>
<DIV>Thanks for calling our attention to this issue.</DIV>
<DIV><BR></DIV>
<DIV>The IEEE 802.16 Working Group has developed the following response:</DIV>
<DIV>&nbsp;&lt;<A href="http://ieee802.org/16/liaison/docs/L80216-08_069r1.pdf">http://ieee802.org/16/liaison/docs/L80216-08_069r1.pdf</A>&gt;.</DIV>
<DIV><BR></DIV>
<DIV>We appreciate the opportunity to provide the review.</DIV>
<DIV><BR></DIV>
<DIV>Regards,</DIV>
<DIV><BR></DIV>
<DIV>Roger</DIV>
<DIV><BR></DIV>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word">
<DIV>Dr. Roger B. Marks&nbsp; &lt;<A href="mailto:[e-mail]">[e-mail]</A>&gt;</DIV>
<DIV>Chair, IEEE 802.16 Working Group on Broadband Wireless Access&nbsp;&lt;<A href="http://wirelessman.org/">http://WirelessMAN.org</A>&gt;</DIV>
<DIV><BR class=EC_khtml-block-placeholder></DIV><BR class=EC_Apple-interchange-newline></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On 2008/10/30, at 02:25 PM, Bernard Aboba wrote:</DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 14px Arial; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Recently, the IETF RADEXT WG has received a request to accept the document "RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1" as&nbsp;a working group work item.&nbsp; The&nbsp;specification is available here:<BR><A href="http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt">http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt</A><BR>&nbsp;<BR>Since this document relates to IEEE 802.16, we would like to&nbsp;inquire as to whether IEEE 802.16 has an opinion on the advisability of having IETF take on this&nbsp;work, as well as&nbsp;to whether IEEE 802.16 has any&nbsp;editorial or technical feedback relating to the document.&nbsp; This document is likely to be discussed during IETF 73 in Minneapolis, which will take place from November 16-21, 2008.<SPAN class=EC_Apple-converted-space>&nbsp;</SPAN><BR>&nbsp;<BR></DIV></SPAN></BLOCKQUOTE></DIV></body>
</html>
--_4814e199-34f4-4980-aeea-e588a2a001e0_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Nov 2008 16:13:31 +0000
Message-ID: <[e-mail]>
Date: Mon, 17 Nov 2008 10:13:02 -0600
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Bernard Aboba' <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Status of Issue 225
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> I'm not really interested in taking a walk on the psychic side just now, so
> how about I just pretend that you are expressing your (necessarily biased)
> opinion based upon your (necessarily limited) experience, just like
> everybody else?

  If it makes you happy.

> But you didn't _say_ that; 

  Yes, well, I am known to make mistakes from time to time.  Please
accept my apologies.

> Amazingly enough, you're not the only person in the world to have talked
> with (or been) a RADIUS developer; _my_ personal experience (which I suppose
> must be less valid than the royal form that you seem to possess) suggests
> that the vast majority of developers are highly intelligent & when questions
> about standards arise they are about far more subtle things than this.

  It pleases me to no end that your experience has been more positive
than mine has been.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Nov 2008 16:06:17 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: Status of Issue 225
Date: Mon, 17 Nov 2008 10:05:00 -0600
Message-ID: <00c601c948ce$45855a80$d0900f80$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclGKKW8HFQ4azBhS3y1PUTuzTOS+gCohOVw
Content-Language: en-us

Alan DeKok [mailto:[e-mail]] writes:

> Glen Zorn wrote:
> 
> >>   It is not *ridiculously* clear from the current document that
> >> "Length"
> >> and "Extended-Length" are strongly related.
> >
> > Maybe not to you...
> 
>   Pretend I'm channeling the 100's of people who've read the specs, and
> implemented broken NASes.

I'm not really interested in taking a walk on the psychic side just now, so
how about I just pretend that you are expressing your (necessarily biased)
opinion based upon your (necessarily limited) experience, just like
everybody else?

> 
> > This would disallow the presence of multiple AVPs in a single
> attribute.
> > Are you claiming "WG Consensus" for this massive change?
> 
>   No.  If there *is* only one AVP in a single attribute, then that
> relationship holds.

But you didn't _say_ that; similarly, your suggestion that " attributes
generated by a client or server MUST NOT be fragmented at boundaries other
than 246 octets" says that values the length of which is not evenly
divisible by 246 are illegal.  I suspect that you actually _meant_ that all
but the final fragment must be 246 octets in length but again, that's not
what you _said_.  I suppose that it's possible that you spent hours
designing these "solutions" but giving you the benefit of the doubt, I'll
assume that it's more like 10 seconds.  Maybe you could take a little bit
more care in crafting your suggestions because as it is you are not offering
solutions so much as you are creating bugs for others to find and fix.

> 
> >>   Experience shows that without this text, people will create
> >> attributes
> >> that don't satisfy this criteria... and claim they're standards
> >> compliant.
> >
> > This comment is fascinating.  What, exactly, is the "experience" you
> are
> > talking about?  Are there already multiple implementations of the
> extended
> > attributes?  Have you perfected time travel?
> 
>   I am, of course, not claiming experience with multiple
> implementations
> of the extended attributes.  Pretending I'm making that claim is
> disingenuous at best.  Instead, I'm claiming something much more
> difficult to understand.
> 
>   The "experience" is with previous standards, and the people who've
> implemented RADIUS software based on them.  It's called "learning from
> experience", and "applying that experience to new situations".
> 
>   I've spent a lot of time talking with implementors of NASes and
> servers about their software.  There are a number of styles of
> misunderstanding that they have about existing specifications.  That
> experience can be used to review new standards, to minimize the
> potential for similar problems.

Amazingly enough, you're not the only person in the world to have talked
with (or been) a RADIUS developer; _my_ personal experience (which I suppose
must be less valid than the royal form that you seem to possess) suggests
that the vast majority of developers are highly intelligent & when questions
about standards arise they are about far more subtle things than this.

...


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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Nov 2008 08:51:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94891.96E97132"
Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
Date: Mon, 17 Nov 2008 09:49:24 +0100
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
Thread-Index: AclHcQpJZ8lpbP2ATnyx5vVlfqe8qQBH7YOA
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>
Cc: "Ralph Droms (rdroms)" <[e-mail]>, <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l289; t26911850; x27775850; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Benoit Lourdelet (blourdel)" <blourdel@ cisco.com> |Subject: RE: RADEXT WG consensus call on = 22IPv6 Attributes for DHCP Networks" |Sender: ; bh=+m+ZJhHZnfSaXvRYJnFopjEITK4426T617nS5mggnzo=; b=rSKMxdtMjtlfDWG2UWbL3W+U5K/tgMuzjPbeFAthZ3Jm3ZruEKDIWiE3aN GGPnd67JGTnMjiLc6qBCJ8SE2qr4t9NUuLUJy5Bm/qEf5fubiQmGqq9cSFEk 6AlGhBwhGX;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C94891.96E97132
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bernard,
 
 
RFC 5080 Section 2.11 comment about  Framed-IPv6-Prefix is a fair point
that would require more thought 
 in revising RFC3162.
 
I have no problem going the "separate document" route and re-publish a
revision including additional attributes only as I did in my first
revision of the document.
 
Let me add that in the presentation for Tuesday WG meeting.
 
regards
 
Benoit
 

 
________________________________

From: Bernard Aboba [mailto:[e-mail]] 
Sent: Saturday, November 15, 2008 11:25 PM
To: Benoit Lourdelet (blourdel); Ralph Droms (rdroms);
[e-mail]
Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP
Networks"


I'd suggest that the issue of whether the document should revise RFC
3162 is somewhat
separate from whether it only relates to DHCPv6 or not. 

As Ralph points out, revising RFC 3162 involves considerably more work.
For example,
it would be necessary to address the issues brought up in RFC 5080
Section 2.11. 
Also, there are existing deployments of RFC 3162, so backward
compatibility issues need
to be taken into account.  So if your desire is to get this work done
quickly, an
RFC 3162 revision is best avoided unless it's nessary. 
 
In your original submission (draft-lourdelet-radext-ipv6-dhcp-00) there
was a normative 
reference to RFC 3162, contained in the following paragraph:
 
   This attributes offers an entire IPv6 address to the DHCPv6 Server in
   contrast to Interface-id [RFC3162] that offers only 64 bits.  Even
   concatenated with Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6
   address, this does not address scenarios where there is a need to
   offer multiple addresses or off-link IPv6 addresses that are not part
   of the prefix stored in the Framed-IPv6-Prefix attribute.  Storing
   the IPv6 address in the subscriber RADIUS profile is particularly
   useful as the Service Provider will know in advance the customers
   uplink IPv6 address, hence facilitating management or security policy
   implementation.

Based on this, it would appear that the major issue relating to RFC 3162
is the potential usage of Framed-IPv6-Prefix to assign an entire IPv6
address (e.g. use of a /128 prefix).   RFC 5080 already addresses this
to some extent in Section 2.11:
 
   The description of the Prefix-Length field in RFC 3162 indicates
   excessively wide latitude:

      The length of the prefix, in bits.  At least 0 and no larger than
      128.

   This length appears too broad, because it is not clear what a NAS
   should do with a prefix of greater granularity than /64.  For
   example, the Framed-IPv6-Prefix may contain a /128.  This does not
   imply that the NAS should assign an IPv6 address to the end user,
   because RFC 3162 already defines a Framed-IPv6-Identifier attribute
   to handle the Identifier portion.

   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
   assigned.  When a /64 or larger prefix is sent, the intent is for the
   NAS to send a routing advertisement containing the information
   present in the Framed-IPv6-Prefix attribute.

In essence, RFC 5080 states that Framed-IPv6-Prefix is not to be used
for IPv6 address assignment, which is the point you make in your
document. 
 
Given this, it would appear to me that your original submission does not
have a normative dependency on an RFC 3162 revision.  Of course, if
you're willing to sign up for the extra work required to complete such
a revision, your efforts would be appreciated. 




i'm EMAILING FOR THE GREATER GOOD
Join me
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 	


> Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP
Networks"
> Date: Thu, 13 Nov 2008 12:41:11 +0100
> From: [e-mail]
> To: [e-mail]; [e-mail]
> CC: [e-mail]
> 
> Ralph,
> 
> The problem I have with this approach is that giving more though to
it,
> I thing that
> 
> IPv6-DNS attribute could be used in the RFC5006 context. So it is not
> DHCP use only.
> 
> IPv6-address could be used in a SLAC context for validation of the
> advertised address by the gateway.
> 
> So it turns that none of the attributes are DHCP specific.
> 
> Regards
> 
> Benoit
> 
> 
> -----Original Message-----
> From: Ralph Droms (rdroms) 
> Sent: Wednesday, November 12, 2008 2:15 AM
> To: [e-mail]
> Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit Lourdelet (blourdel)
> Subject: Re: RADEXT WG consensus call on "IPv6 Attributes for DHCP
> Networks"
> 
> I support accepting "IPv6 Attributes for DHCP Networks" as a RADEXT WG
> work item. There is a need for these attributes to support certain
> IPv6 deployment models.
> 
> I support handling "IPv6 Attributes for DHCP Networks" as a separate
> work item. I am concerned that bundling the attributes into a revision
> of RFC 3162 would incur too much delay.
> 
> - Ralph
> 
> On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba wrote:
> 
> > At IETF 72, the RADEXT WG was polled on the following questions:
> >
> > 1) whether to accept "IPv6 Attributes for DHCP Networks"
> >
(http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-
> > 00.txt
> > )
> > as a RADEXT WG work item;
> >
> > 2) whether to handle this as a standalone work item or bundle it
into 
> > a revision of RFC 3162 (RFC 3162bis).
> >
> > This is a RADEXT WG consensus call, in order to confirm the "sense
of 
> > the room" at IETF 72 with respect to these two items.
> >
> > The RADEXT WG Consensus call will last until November 12, 2008. 
> > Please send your
> > opinions on these two questions to the RADEXT WG mailing list 
> > ([e-mail] ).
> >
> >
> >
> 


------_=_NextPart_001_01C94891.96E97132
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE>.hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Verdana
}
</STYLE>

<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV><FONT face=Arial color=#0000ff><SPAN 
class=083524408-17112008>Bernard,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff><SPAN 
class=083524408-17112008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff><SPAN 
class=083524408-17112008></SPAN></FONT>&nbsp;</DIV>
<DIV>RFC 5080 Section 2.11&nbsp;<SPAN class=083524408-17112008>comment 
about&nbsp; Framed-IPv6-Prefix is a fair point that would require more thought 
</SPAN></DIV>
<DIV><SPAN class=083524408-17112008>&nbsp;in revising RFC3162.</SPAN></DIV>
<DIV><SPAN class=083524408-17112008></SPAN>&nbsp;</DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial color=#0000ff>I have no 
problem going the "separate document" route and re-publish a revision including 
additional attributes only as I did in my first revision of the 
document.</FONT></SPAN></DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial color=#0000ff>Let me add 
that in the presentation for Tuesday WG meeting.</FONT></SPAN></DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial 
color=#0000ff>regards</FONT></SPAN></DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=083524408-17112008><FONT face=Arial 
color=#0000ff>Benoit</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff></FONT><SPAN 
class=083524408-17112008></SPAN><BR>&nbsp;</DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma><B>From:</B> Bernard Aboba [mailto:[e-mail]] 
<BR><B>Sent:</B> Saturday, November 15, 2008 11:25 PM<BR><B>To:</B> Benoit 
Lourdelet (blourdel); Ralph Droms (rdroms); 
[e-mail]<BR><B>Subject:</B> RE: RADEXT WG consensus call on "IPv6 
Attributes for DHCP Networks"<BR></FONT><BR></DIV>
<DIV></DIV>I'd suggest that the issue of whether the document should revise RFC 
3162 is somewhat<BR>separate from whether it only relates to DHCPv6 or not. 
<BR><BR>As Ralph points out, revising RFC 3162 involves considerably more 
work.&nbsp; For example,<BR>it would be necessary to&nbsp;address the issues 
brought up in&nbsp;RFC 5080 Section 2.11. <BR>Also, there are existing 
deployments of RFC 3162, so backward compatibility issues need<BR>to be taken 
into account.&nbsp; So if your desire is to get this work done quickly, 
an<BR>RFC 3162 revision is best avoided unless it's nessary. <BR>&nbsp;<BR>In 
your original submission (draft-lourdelet-radext-ipv6-dhcp-00) there&nbsp;was a 
normative <BR>reference to RFC 3162, contained in the following 
paragraph:<BR>&nbsp;<BR>&nbsp;&nbsp; This attributes offers an entire IPv6 
address to the DHCPv6 Server in<BR>&nbsp;&nbsp; contrast to Interface-id 
[RFC3162] that offers only 64 bits.&nbsp; Even<BR>&nbsp;&nbsp; concatenated with 
Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6<BR>&nbsp;&nbsp; address, 
this does not address scenarios where there is a need to<BR>&nbsp;&nbsp; offer 
multiple addresses or off-link IPv6 addresses that are not part<BR>&nbsp;&nbsp; 
of the prefix stored in the Framed-IPv6-Prefix attribute.&nbsp; 
Storing<BR>&nbsp;&nbsp; the IPv6 address in the subscriber RADIUS profile is 
particularly<BR>&nbsp;&nbsp; useful as the Service Provider will know in advance 
the customers<BR>&nbsp;&nbsp; uplink IPv6 address, hence facilitating management 
or security policy<BR>&nbsp;&nbsp; implementation.<BR><BR>Based on this, it 
would appear that the major issue relating to RFC 3162<BR>is the potential usage 
of Framed-IPv6-Prefix to assign an entire IPv6<BR>address (e.g. use of a /128 
prefix).&nbsp;&nbsp; RFC 5080 already addresses this<BR>to some extent in 
Section 2.11:<BR>&nbsp;<BR>&nbsp;&nbsp; The description of the Prefix-Length 
field in RFC 3162 indicates<BR>&nbsp;&nbsp; excessively wide 
latitude:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The length of the prefix, in 
bits.&nbsp; At least 0 and no larger than<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
128.<BR><BR>&nbsp;&nbsp; This length appears too broad, because it is not clear 
what a NAS<BR>&nbsp;&nbsp; should do with a prefix of greater granularity than 
/64.&nbsp; For<BR>&nbsp;&nbsp; example, the Framed-IPv6-Prefix may contain a 
/128.&nbsp; This does not<BR>&nbsp;&nbsp; imply that the NAS should assign an 
IPv6 address to the end user,<BR>&nbsp;&nbsp; because RFC 3162 already defines a 
Framed-IPv6-Identifier attribute<BR>&nbsp;&nbsp; to handle the Identifier 
portion.<BR><BR>&nbsp;&nbsp; It appears that the Framed-IPv6-Prefix is used for 
the link between<BR>&nbsp;&nbsp; the NAS and Customer Premises Equipment (CPE) 
only if a /64 prefix is<BR>&nbsp;&nbsp; assigned.&nbsp; When a /64 or larger 
prefix is sent, the intent is for the<BR>&nbsp;&nbsp; NAS to send a routing 
advertisement containing the information<BR>&nbsp;&nbsp; present in the 
Framed-IPv6-Prefix attribute.<BR><BR>In essence, RFC 5080 states that 
Framed-IPv6-Prefix is not to be used<BR>for IPv6 address assignment, which is 
the point you make in your document. <BR>&nbsp;<BR>Given this, it would appear 
to me that your original submission does not<BR>have a normative dependency on 
an RFC 3162 revision.&nbsp; Of course, if<BR>you're willing to sign up for the 
extra work required to complete such<BR>a revision, your efforts would be 
appreciated. <BR><BR><BR><BR>
<TABLE 
style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
  <TBODY>
  <TR>
    <TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" 
      href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG 
      style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" 
      alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" 
      NOSEND="1"> EMAILING FOR THE GREATER GOOD<BR><SPAN 
      style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join 
      me</SPAN></A></TD></TR></TBODY></TABLE><BR><BR>&gt; Subject: RE: RADEXT WG 
consensus call on "IPv6 Attributes for DHCP Networks"<BR>&gt; Date: Thu, 13 Nov 
2008 12:41:11 +0100<BR>&gt; From: [e-mail]<BR>&gt; To: 
[e-mail]; [e-mail]<BR>&gt; CC: 
[e-mail]<BR>&gt; <BR>&gt; Ralph,<BR>&gt; <BR>&gt; The problem I 
have with this approach is that giving more though to it,<BR>&gt; I thing 
that<BR>&gt; <BR>&gt; IPv6-DNS attribute could be used in the RFC5006 context. 
So it is not<BR>&gt; DHCP use only.<BR>&gt; <BR>&gt; IPv6-address could be used 
in a SLAC context for validation of the<BR>&gt; advertised address by the 
gateway.<BR>&gt; <BR>&gt; So it turns that none of the attributes are DHCP 
specific.<BR>&gt; <BR>&gt; Regards<BR>&gt; <BR>&gt; Benoit<BR>&gt; <BR>&gt; 
<BR>&gt; -----Original Message-----<BR>&gt; From: Ralph Droms (rdroms) <BR>&gt; 
Sent: Wednesday, November 12, 2008 2:15 AM<BR>&gt; To: 
[e-mail]<BR>&gt; Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit 
Lourdelet (blourdel)<BR>&gt; Subject: Re: RADEXT WG consensus call on "IPv6 
Attributes for DHCP<BR>&gt; Networks"<BR>&gt; <BR>&gt; I support accepting "IPv6 
Attributes for DHCP Networks" as a RADEXT WG<BR>&gt; work item. There is a need 
for these attributes to support certain<BR>&gt; IPv6 deployment models.<BR>&gt; 
<BR>&gt; I support handling "IPv6 Attributes for DHCP Networks" as a 
separate<BR>&gt; work item. I am concerned that bundling the attributes into a 
revision<BR>&gt; of RFC 3162 would incur too much delay.<BR>&gt; <BR>&gt; - 
Ralph<BR>&gt; <BR>&gt; On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba 
wrote:<BR>&gt; <BR>&gt; &gt; At IETF 72, the RADEXT WG was polled on the 
following questions:<BR>&gt; &gt;<BR>&gt; &gt; 1) whether to accept "IPv6 
Attributes for DHCP Networks"<BR>&gt; &gt; 
(http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-<BR>&gt; 
&gt; 00.txt<BR>&gt; &gt; )<BR>&gt; &gt; as a RADEXT WG work item;<BR>&gt; 
&gt;<BR>&gt; &gt; 2) whether to handle this as a standalone work item or bundle 
it into <BR>&gt; &gt; a revision of RFC 3162 (RFC 3162bis).<BR>&gt; &gt;<BR>&gt; 
&gt; This is a RADEXT WG consensus call, in order to confirm the "sense of 
<BR>&gt; &gt; the room" at IETF 72 with respect to these two items.<BR>&gt; 
&gt;<BR>&gt; &gt; The RADEXT WG Consensus call will last until November 12, 
2008. <BR>&gt; &gt; Please send your<BR>&gt; &gt; opinions on these two 
questions to the RADEXT WG mailing list <BR>&gt; &gt; ([e-mail] 
).<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; <BR></BODY></HTML>

------_=_NextPart_001_01C94891.96E97132--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Nov 2008 23:02:50 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_fa9db87a-1777-4942-91cd-4d558589011f_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: REMINDER: Call for Review: RADIUS over TCP
Date: Sat, 15 Nov 2008 15:02:34 -0800
MIME-Version: 1.0

--_fa9db87a-1777-4942-91cd-4d558589011f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







This is a reminder of an ongoing call for review of the individual 
submission "RADIUS over TCP".  The document is available for review here:http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00This review will last until November 19, 2008.  Please respond to the list as to whether yousupport adoption of this document as a RADEXT WG work item.  If you have any issues withthe document, please email them to the list in the RADEXT WG Issues format, described here:http://www.drizzle.com/~aboba/RADEXT/



 EMAILING FOR THE GREATER GOODJoin me
--_fa9db87a-1777-4942-91cd-4d558589011f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<BR>
<TABLE width="100%">
<TBODY>
<TR>
<TD>
This is a reminder of an ongoing call for review of the individual <BR>
submission "RADIUS over TCP".&nbsp; The document is available for review here:<BR>http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<BR><BR>This review will last until November 19, 2008.&nbsp; Please respond to the list as to whether you<BR>support adoption of this document as a RADEXT WG work item.&nbsp; If you have any issues with<BR>the document, please email them to the list in the RADEXT WG Issues format, described here:<BR>http://www.drizzle.com/~aboba/RADEXT/<BR><BR></TD></TR></TBODY></TABLE><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_fa9db87a-1777-4942-91cd-4d558589011f_--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Nov 2008 23:01:20 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_92b2b6ea-7aa6-486a-9cd5-052a947b5e92_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: REMINDER: RADEXT WG last call on RADSEC Document
Date: Sat, 15 Nov 2008 15:01:08 -0800
MIME-Version: 1.0

--_92b2b6ea-7aa6-486a-9cd5-052a947b5e92_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a reminder of the ongoing RADEXT WG last call on the document"TLS Encryption for RADIUS over TCP (RADSEC)", prior to sendingthis document on to the IESG for publication as an ExperimentalRFC.   The document is available for inspection here:http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-02.txtRADEXT WG last call will complete on November 25, 2008.   Pleasesend review comments to the RADEXT WG mailing list([e-mail]) in the format described on the RADEXTIssues List (http://www.drizzle.com/~aboba/RADEXT ).   If youhave no comments, but believe the document should be progressed,please also send a note to the list to this effect. 



 EMAILING FOR THE GREATER GOODJoin me
--_92b2b6ea-7aa6-486a-9cd5-052a947b5e92_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of the ongoing RADEXT WG last call on the document<BR>"TLS Encryption for RADIUS over TCP (RADSEC)", prior to sending<BR>this document on to the IESG for publication as an Experimental<BR>RFC. &nbsp; The document is available for inspection here:<BR>http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-02.txt<BR><BR>RADEXT WG last call will complete on November 25, 2008.&nbsp;&nbsp; Please<BR>send review comments to the RADEXT WG mailing list<BR>([e-mail]) in the format described on the RADEXT<BR>Issues List (http://www.drizzle.com/~aboba/RADEXT ).&nbsp;&nbsp; If you<BR>have no comments, but believe the document should be progressed,<BR>please also send a note to the list to this effect. <BR><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_92b2b6ea-7aa6-486a-9cd5-052a947b5e92_--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Nov 2008 22:59:41 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_29305c24-7d85-4e5e-9ab1-181ecd832b8d_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: REDMINDER:  RADEXT WG Last Call on Status-Server Document
Date: Sat, 15 Nov 2008 14:59:27 -0800
MIME-Version: 1.0

--_29305c24-7d85-4e5e-9ab1-181ecd832b8d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





This is a reminder of an ongoing RADEXT WG last call on the document"Use of Status-Server Packets in the RADIUS Protocol", prior to sendingthis document on to the IESG for publication as an Informational RFC.   The document is available for inspection here:http://tools.ietf.org/html/draft-ietf-radext-status-server-02RADEXT WG last call will complete on November 25, 2008.   Pleasesend review comments to the RADEXT WG mailing list([e-mail]) in the format described on the RADEXTIssues List (http://www.drizzle.com/~aboba/RADEXT ).   If youhave no comments, but believe the document should be progressed,please also send a note to the list to this effect. 



 EMAILING FOR THE GREATER GOODJoin me
--_29305c24-7d85-4e5e-9ab1-181ecd832b8d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<TABLE width="100%">
<TBODY>
<TR>
<TD>This is a reminder of an ongoing RADEXT WG last call on the document<BR>"Use of Status-Server Packets in the RADIUS Protocol", prior to sending<BR>this document on to the IESG for publication as an Informational <BR>RFC. &nbsp; The document is available for inspection here:<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" rel=nofollow>http://tools.ietf.org/html/draft-ietf-radext-status-server-02</A><A href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" rel=nofollow><U><FONT color=#800080></A></FONT></U><BR><BR>RADEXT WG last call will complete on November 25, 2008.&nbsp;&nbsp; Please<BR>send review comments to the RADEXT WG mailing list<BR>([e-mail]) in the format described on the RADEXT<BR>Issues List (http://www.drizzle.com/~aboba/RADEXT ).&nbsp;&nbsp; If you<BR>have no comments, but believe the document should be progressed,<BR>please also send a note to the list to this effect. <BR></TD></TR></TBODY></TABLE><BR><BR><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_29305c24-7d85-4e5e-9ab1-181ecd832b8d_--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Nov 2008 22:57:35 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_569fb7fa-edd0-4183-9963-675b546da5ac_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: REMINDER:  Call for presentations
Date: Sat, 15 Nov 2008 14:57:06 -0800
MIME-Version: 1.0

--_569fb7fa-edd0-4183-9963-675b546da5ac_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG will meet on Tuesday morning at 9:00 AM in Rochester.  The agenda
and presentations are available here:
 
https://datatracker.ietf.org/meeting/73/materials.html
 
If you haven't sent your presentation to Dave and myself, please do so NOW. 



 EMAILING FOR THE GREATER GOODJoin me
--_569fb7fa-edd0-4183-9963-675b546da5ac_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The RADEXT WG will meet on Tuesday morning at 9:00 AM in Rochester.&nbsp; The agenda<BR>
and presentations are available here:<BR>
&nbsp;<BR>
<A href="https://datatracker.ietf.org/meeting/73/materials.html">https://datatracker.ietf.org/meeting/73/materials.html</A><BR>
&nbsp;<BR>
If you haven't sent your presentation to Dave and myself, please do so NOW. <BR><BR><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_569fb7fa-edd0-4183-9963-675b546da5ac_--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Nov 2008 22:26:26 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f40066b8-13cb-4b5a-8b67-0373220b3ae6_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
Date: Sat, 15 Nov 2008 14:25:14 -0800
MIME-Version: 1.0

--_f40066b8-13cb-4b5a-8b67-0373220b3ae6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I'd suggest that the issue of whether the document should revise RFC 3162 is somewhat
separate from whether it only relates to DHCPv6 or not. As Ralph points out, revising RFC 3162 involves considerably more work.  For example,
it would be necessary to address the issues brought up in RFC 5080 Section 2.11. 
Also, there are existing deployments of RFC 3162, so backward compatibility issues need
to be taken into account.  So if your desire is to get this work done quickly, an
RFC 3162 revision is best avoided unless it's nessary. 
 
In your original submission (draft-lourdelet-radext-ipv6-dhcp-00) there was a normative 
reference to RFC 3162, contained in the following paragraph:
 
   This attributes offers an entire IPv6 address to the DHCPv6 Server in   contrast to Interface-id [RFC3162] that offers only 64 bits.  Even   concatenated with Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6   address, this does not address scenarios where there is a need to   offer multiple addresses or off-link IPv6 addresses that are not part   of the prefix stored in the Framed-IPv6-Prefix attribute.  Storing   the IPv6 address in the subscriber RADIUS profile is particularly   useful as the Service Provider will know in advance the customers   uplink IPv6 address, hence facilitating management or security policy   implementation.
Based on this, it would appear that the major issue relating to RFC 3162
is the potential usage of Framed-IPv6-Prefix to assign an entire IPv6
address (e.g. use of a /128 prefix).   RFC 5080 already addresses this
to some extent in Section 2.11:
 
   The description of the Prefix-Length field in RFC 3162 indicates   excessively wide latitude:      The length of the prefix, in bits.  At least 0 and no larger than      128.   This length appears too broad, because it is not clear what a NAS   should do with a prefix of greater granularity than /64.  For   example, the Framed-IPv6-Prefix may contain a /128.  This does not   imply that the NAS should assign an IPv6 address to the end user,   because RFC 3162 already defines a Framed-IPv6-Identifier attribute   to handle the Identifier portion.   It appears that the Framed-IPv6-Prefix is used for the link between   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is   assigned.  When a /64 or larger prefix is sent, the intent is for the   NAS to send a routing advertisement containing the information   present in the Framed-IPv6-Prefix attribute.
In essence, RFC 5080 states that Framed-IPv6-Prefix is not to be used
for IPv6 address assignment, which is the point you make in your document. 
 
Given this, it would appear to me that your original submission does not
have a normative dependency on an RFC 3162 revision.  Of course, if
you're willing to sign up for the extra work required to complete such
a revision, your efforts would be appreciated. 



 EMAILING FOR THE GREATER GOODJoin me> Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"> Date: Thu, 13 Nov 2008 12:41:11 +0100> From: [e-mail]> To: [e-mail]; [e-mail]> CC: [e-mail]> > Ralph,> > The problem I have with this approach is that giving more though to it,> I thing that> > IPv6-DNS attribute could be used in the RFC5006 context. So it is not> DHCP use only.> > IPv6-address could be used in a SLAC context for validation of the> advertised address by the gateway.> > So it turns that none of the attributes are DHCP specific.> > Regards> > Benoit> > > -----Original Message-----> From: Ralph Droms (rdroms) > Sent: Wednesday, November 12, 2008 2:15 AM> To: [e-mail]> Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit Lourdelet (blourdel)> Subject: Re: RADEXT WG consensus call on "IPv6 Attributes for DHCP> Networks"> > I support accepting "IPv6 Attributes for DHCP Networks" as a RADEXT WG> work item. There is a need for these attributes to support certain> IPv6 deployment models.> > I support handling "IPv6 Attributes for DHCP Networks" as a separate> work item. I am concerned that bundling the attributes into a revision> of RFC 3162 would incur too much delay.> > - Ralph> > On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba wrote:> > > At IETF 72, the RADEXT WG was polled on the following questions:> >> > 1) whether to accept "IPv6 Attributes for DHCP Networks"> > (http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-> > 00.txt> > )> > as a RADEXT WG work item;> >> > 2) whether to handle this as a standalone work item or bundle it into > > a revision of RFC 3162 (RFC 3162bis).> >> > This is a RADEXT WG consensus call, in order to confirm the "sense of > > the room" at IETF 72 with respect to these two items.> >> > The RADEXT WG Consensus call will last until November 12, 2008. > > Please send your> > opinions on these two questions to the RADEXT WG mailing list > > ([e-mail] ).> >> >> >> 
--_f40066b8-13cb-4b5a-8b67-0373220b3ae6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I'd suggest that the issue of whether the document should revise RFC 3162 is somewhat<BR>
separate from whether it only relates to DHCPv6 or not. <BR><BR>As Ralph points out, revising RFC 3162 involves considerably more work.&nbsp; For example,<BR>
it would be necessary to&nbsp;address the issues brought up in&nbsp;RFC 5080 Section 2.11. <BR>
Also, there are existing deployments of RFC 3162, so backward compatibility issues need<BR>
to be taken into account.&nbsp; So if your desire is to get this work done quickly, an<BR>
RFC 3162 revision is best avoided unless it's nessary. <BR>
&nbsp;<BR>
In your original submission (draft-lourdelet-radext-ipv6-dhcp-00) there&nbsp;was a normative <BR>
reference to RFC 3162, contained in the following paragraph:<BR>
&nbsp;<BR>
&nbsp;&nbsp; This attributes offers an entire IPv6 address to the DHCPv6 Server in<BR>&nbsp;&nbsp; contrast to Interface-id [RFC3162] that offers only 64 bits.&nbsp; Even<BR>&nbsp;&nbsp; concatenated with Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6<BR>&nbsp;&nbsp; address, this does not address scenarios where there is a need to<BR>&nbsp;&nbsp; offer multiple addresses or off-link IPv6 addresses that are not part<BR>&nbsp;&nbsp; of the prefix stored in the Framed-IPv6-Prefix attribute.&nbsp; Storing<BR>&nbsp;&nbsp; the IPv6 address in the subscriber RADIUS profile is particularly<BR>&nbsp;&nbsp; useful as the Service Provider will know in advance the customers<BR>&nbsp;&nbsp; uplink IPv6 address, hence facilitating management or security policy<BR>&nbsp;&nbsp; implementation.<BR><BR>
Based on this, it would appear that the major issue relating to RFC 3162<BR>
is the potential usage of Framed-IPv6-Prefix to assign an entire IPv6<BR>
address (e.g. use of a /128 prefix).&nbsp;&nbsp; RFC 5080 already addresses this<BR>
to some extent in Section 2.11:<BR>
&nbsp;<BR>
&nbsp;&nbsp; The description of the Prefix-Length field in RFC 3162 indicates<BR>&nbsp;&nbsp; excessively wide latitude:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The length of the prefix, in bits.&nbsp; At least 0 and no larger than<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 128.<BR><BR>&nbsp;&nbsp; This length appears too broad, because it is not clear what a NAS<BR>&nbsp;&nbsp; should do with a prefix of greater granularity than /64.&nbsp; For<BR>&nbsp;&nbsp; example, the Framed-IPv6-Prefix may contain a /128.&nbsp; This does not<BR>&nbsp;&nbsp; imply that the NAS should assign an IPv6 address to the end user,<BR>&nbsp;&nbsp; because RFC 3162 already defines a Framed-IPv6-Identifier attribute<BR>&nbsp;&nbsp; to handle the Identifier portion.<BR><BR>&nbsp;&nbsp; It appears that the Framed-IPv6-Prefix is used for the link between<BR>&nbsp;&nbsp; the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is<BR>&nbsp;&nbsp; assigned.&nbsp; When a /64 or larger prefix is sent, the intent is for the<BR>&nbsp;&nbsp; NAS to send a routing advertisement containing the information<BR>&nbsp;&nbsp; present in the Framed-IPv6-Prefix attribute.<BR><BR>
In essence, RFC 5080 states that Framed-IPv6-Prefix is not to be used<BR>
for IPv6 address assignment, which is the point you make in your document. <BR>
&nbsp;<BR>
Given this, it would appear to me that your original submission does not<BR>
have a normative dependency on an RFC 3162 revision.&nbsp; Of course, if<BR>
you're willing to sign up for the extra work required to complete such<BR>
a revision, your efforts would be appreciated. <BR><BR><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE><BR><BR>&gt; Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"<BR>&gt; Date: Thu, 13 Nov 2008 12:41:11 +0100<BR>&gt; From: [e-mail]<BR>&gt; To: [e-mail]; [e-mail]<BR>&gt; CC: [e-mail]<BR>&gt; <BR>&gt; Ralph,<BR>&gt; <BR>&gt; The problem I have with this approach is that giving more though to it,<BR>&gt; I thing that<BR>&gt; <BR>&gt; IPv6-DNS attribute could be used in the RFC5006 context. So it is not<BR>&gt; DHCP use only.<BR>&gt; <BR>&gt; IPv6-address could be used in a SLAC context for validation of the<BR>&gt; advertised address by the gateway.<BR>&gt; <BR>&gt; So it turns that none of the attributes are DHCP specific.<BR>&gt; <BR>&gt; Regards<BR>&gt; <BR>&gt; Benoit<BR>&gt; <BR>&gt; <BR>&gt; -----Original Message-----<BR>&gt; From: Ralph Droms (rdroms) <BR>&gt; Sent: Wednesday, November 12, 2008 2:15 AM<BR>&gt; To: [e-mail]<BR>&gt; Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit Lourdelet (blourdel)<BR>&gt; Subject: Re: RADEXT WG consensus call on "IPv6 Attributes for DHCP<BR>&gt; Networks"<BR>&gt; <BR>&gt; I support accepting "IPv6 Attributes for DHCP Networks" as a RADEXT WG<BR>&gt; work item. There is a need for these attributes to support certain<BR>&gt; IPv6 deployment models.<BR>&gt; <BR>&gt; I support handling "IPv6 Attributes for DHCP Networks" as a separate<BR>&gt; work item. I am concerned that bundling the attributes into a revision<BR>&gt; of RFC 3162 would incur too much delay.<BR>&gt; <BR>&gt; - Ralph<BR>&gt; <BR>&gt; On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba wrote:<BR>&gt; <BR>&gt; &gt; At IETF 72, the RADEXT WG was polled on the following questions:<BR>&gt; &gt;<BR>&gt; &gt; 1) whether to accept "IPv6 Attributes for DHCP Networks"<BR>&gt; &gt; (http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-<BR>&gt; &gt; 00.txt<BR>&gt; &gt; )<BR>&gt; &gt; as a RADEXT WG work item;<BR>&gt; &gt;<BR>&gt; &gt; 2) whether to handle this as a standalone work item or bundle it into <BR>&gt; &gt; a revision of RFC 3162 (RFC 3162bis).<BR>&gt; &gt;<BR>&gt; &gt; This is a RADEXT WG consensus call, in order to confirm the "sense of <BR>&gt; &gt; the room" at IETF 72 with respect to these two items.<BR>&gt; &gt;<BR>&gt; &gt; The RADEXT WG Consensus call will last until November 12, 2008. <BR>&gt; &gt; Please send your<BR>&gt; &gt; opinions on these two questions to the RADEXT WG mailing list <BR>&gt; &gt; ([e-mail] ).<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; <BR></body>
</html>
--_f40066b8-13cb-4b5a-8b67-0373220b3ae6_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Nov 2008 18:55:26 +0000
From: Avi Lior <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 14 Nov 2008 13:54:40 -0500
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Thread-Topic: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANr5qAAoTRcMA=
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Folks are throwing around terms like RADIUS server and RADIUS client all over the place.

What is really lacking is a defintion - that we can all agree - of what is a RADIUS Server and a RADIUS Client.



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of David B. Nelson
> Sent: November 11, 2008 9:14 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [Dime] [AAA-DOCTORS] AD Review of
> dime-qos-parameters-06.txt
>
> Hi Hannes,
>
> > I don't think that attributes can be opaque to the RADIUS
> client since
> > the client has todo something with them.
>
> Maybe this is a matter of semantics.  Just as the RADIUS
> Server does not comprise the complete set of server-side AAA
> functionality (e.g. policy servers, location servers,
> authentication back-ends, etc. are logically separate), the
> RADIUS Client does not comprise the complete set of AAA
> functionality in the NAS.  The RADIUS Client delivers
> authorization information to the components of the NAS that
> enforce access control.
>
> When you define the RADIUS Server and RADIUS Client in this
> narrow sense, i.e. the code that deals with RADIUS PDUs, I
> think you can claim the certain attributes are opaque to the
> RADIUS Client (but certainly not to the NAS).
>
> -- Dave
>
>
>
> --
> to unsubscribe send a message to
> [e-mail] with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Nov 2008 16:34:43 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: Status of Issue 278
Date: Fri, 14 Nov 2008 10:33:03 -0600
Message-ID: <006b01c94676$ba6b28c0$2f417a40$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclGJpuZV5aV3UivTA6P1kXffyfb6QATO7cw
Content-Language: en-us

Alan DeKok [mailto:[e-mail]] writes:

> Glen Zorn wrote:
> ...
> >>   Without this text, IANA may allocate 0..255 to the new extended-
> type,
> >> potentially confusing people with conflicts between that and the
> >> standard attribute space.
> >
> > Utter and complete nonsense.
> 
>   Which doesn't address the issue.

Very astute.  You are correct, it dismisses the "issue" as nonsense.  Merely
because an "issue" is present in an "issues list" means nothing; in
particular, it doesn't mean that there is any WG consensus that the (in this
case nonexistent) problem is actually an issue.

> 
>   a) Can IANA allocate numbers 0..255 in Ext-Type?

Addressed in the existing draft.

>   b) If not, why not?
>   c) If so, is this a good idea?
> 
>   Alan DeKok.


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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Nov 2008 10:15:50 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt
Date: Fri, 14 Nov 2008 11:14:39 +0100
Message-ID: <[e-mail]>
Thread-Topic: Review of draft-lourdelet-radext-rfc3162bis-01.txt
Thread-Index: Ack5fBVL23bBlqt8TLKXf8KrzmgRfgDzZXkAAWhY4mAApkiaoA=
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l605; t26657680; x27521680; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Benoit Lourdelet (blourdel)" <blourdel@ cisco.com> |Subject: RE: Review of draft-lourdelet-radext-rf c3162bis-01.txt |Sender: ; bh=VTU+0jS5LYLdmpSzlvGggmFo3xHszPGZmmx0xvHmJgk=; b=NnPAtN47J9kN7+2N1/GyJHAWaUzD4cmdlkvLQtJwn8HUiGORz4h5RCm4li fIq1w1reLxP7VS+3OD+k62SK4eqU+/D/OBIrCqq6ErW0moeJWrNxzhXjfwEh lh4desSD2n;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

 Bernard,

Inline after BL>>

-----Original Message-----
From: Bernard Aboba [mailto:[e-mail]] 
Sent: Monday, November 10, 2008 5:36 AM
To: Benoit Lourdelet (blourdel); [e-mail]
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt

It would be helpful to add RFC 5006 as a reference within Section 3.8 so
as to clarify the potential use of the IPv6-DNS-Server-Address
attribute. 


BL>> I will publish rev 03 with that addition.

With respect to DHCP support, at IETF 72, questions were raised about
the usage model in this document versus that in RFC 4014.  For example,
in RFC 4014, the RADIUS server speaks to the NAS, which can then act as
a DHCP relay agent in talking to the DHCP server.  In this document, it
appears that the RADIUS server talks directly to the DHCP server.
Is that right?  If so, when does authentication take place?  Is the
intent to allocate other RADIUS attributes corresponding to existing
DHCPv4/v6 options? 

BL>> there is no intend to add a RADIUS attribute per DHCP option. The
new attributes are aimed at addressing deployment needs and partially
restoring parity with IPv4 attributes (standard or proprietary).

BL>> A possible option is to remove all DHCP references in the document.
That is one way to solve the problem.
The other way is to describe use of the RFc3162bis option in a DHCP
context, but as there are many DHCP deployment scenarii, restricting to
a particular set in RFC3162bis may be a problem.
The generic character of RFC3162 allowed the use of the attribute in a
DHCP context without major problem.

BL>> What we could probably do is to clarify  the use of
Framed-IPv6-Prefix to an actual prefix, not an IPv6 address.

Regards

Benoit

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Benoit Lourdelet (blourdel)
Sent: Sunday, November 09, 2008 10:14 AM
To: Bernard Aboba; [e-mail]
Cc: [e-mail]; Benoit Lourdelet (blourdel)
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt

Hello,


The DHCP context has been removed on purpose to avoid restricting the
use of the new attributes  in different context.
IPv6-DNS-Server-Address is a good example as it could be used by DHCPv6
or RA (see RFC5006).
So we certainly should not restrict its use by DHCPv6.

Even IPv6-Address could be used in an autoconfiguration context for
validation of an address included  in ND messages.

All the above preaches to remove any reference to DHCP as too
restrictive.

A possibility would be to clarify the use of Framed-IPv6-Prefix and
restrict its use to prefix shorter  or equal to 64.

Regards

Benoit

 

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Bernard Aboba
Sent: Wednesday, October 29, 2008 5:07 AM
To: [e-mail]
Subject: Review of draft-lourdelet-radext-rfc3162bis-01.txt


Review of draft-lourdelet-radext-rfc3162bis-01.txt
 
This document represents the folding of the attributes described in
draft-lourdelet-radext-ipv6-dhcp-00.txt with RFC 3162.  Currently, the
RFC 3162 has been brought over to this document verbatim; only Sections
3.7 (defining the IPv6-Address attribute) and Section 3.8 (defining the
IPv6-DNS-Server-Address attribute) have changed. 
 
As discussed at IETF 73, several points of confusion have arisen with
respect to RFC 3162, and one of the reasons to produce an RFC 3162bis
would be to clarify those issues.  One of the issues, whether
Framed-IPv6-Prefix could be used with DHCP Prefix delegation, was
addressed in RFC 4818 (the answer is no). 
 
Another issue relates to whether the Framed-IPv6-Prefix attribute can be
used with a prefix length greater than a /64 (e.g. /128). 
RFC 5080, Section 2.11 discusses this, though strangely it does not
update RFC 3162.  As noted in this section (see below), while this usage
is feasible, it is not entirely clear what a typical NAS would do on
receiving a Framed-IPv6-Prefix Attribute with a /128 prefix, since the
typical practice is to announce the prefix using Router Advertisement.  
 
Given this, as well as the approach in RFC 4818, it would appear that
the easiest way to distinguish RFC 3162 from RFC 4818 and
draft-lourdelet-radext-ipv6-dhcp is that each of these documents
addresses a different set of scenarios.  RFC 3162 was largely focused on
stateless address autoconfiguration (largely focused on PPP); RFC 4818
is about prefix delegation; draft-lourdelet-radext-ipv6-dhcp is about
stateful addressing and configuration via DHCPv6.  
 
However, in merging draft-lourdelet-radext-ipv6-dhcp with RFC 3162, some
of the explanatory information has been removed.  This makes it
difficult to understand that the new attributes relate to stateful
address assignment via DHCPv6.  
 
For example, Section 3.7 introduces the IPv6-Address attribute.  
However, only some of the original text from
draft-lourdelet-radext-ipv6-dhcp-00 is included to explain the usage of
the attribute.  
 
>From the IETF 73 discussion, my understanding is that the purpose of
this attribute is for the RADIUS server to assign one or more IPv6
addresses to a NAS which is acting as a DHCPv6 server, and will
subsequently assign those addresses to a user acting as a DHCPv6 client.
One question that arose during IETF 73 was how address assignment would
relate to the authentication process.  
 
For example, draft-lourdelet-radius-ipv6-dhcp includes the following
diagram:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)  RADIUS Server
       |                           |                                |
       |--Solicit(Address)-------->|                                |
       |                           |-----Request------------------->|
       |                           |<---------Accept(IPv6-Address)--|
       |<-Advertise(Address)-------|                                |
       |---Request(Address)------->|                                |
       |<---Reply(Address)---------|                                |

In this diagram, no authentication is present at all, which lead to
considerable discussion (and confusion) at IETF 73.  
 
Similarly, Section 3.8 defines the IPv6-DNS-Server-Address attribute,
which is assigned to a NAS acting as a DHCPv6 server, with the goal of
providing this DNS server address to the user within the DNS Recursive
Name Server Option [RFC3646].  This was illustrated in the following
diagram from draft-lourdelet-radius-ipv6-dhcp:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)    RADIUS Server
        |                            |                                |
        |--Solicit (DNS)------------>|                                |
        |                            |-Request----------------------->|
        |                            |<-------Accept(Ipv6-DNS)--------|
        |<-Advertise(DNS)------------|                                |
        |-Request(DNS)-------------->|                                |
        |<--Reply(DNS)---------------|       

Again, some context would be helpful. 
 
Overall, if the goal is to clarify issues from RFC 3162bis as well as to
add new DHCPv6-related attributes, then it seems that additional work is
required such as integration of the clarifications from RFC 5080, and
explanation of the DHCPv6 usage scenarios. 

Text from RFC 5080:

"2.11.  Framed-IPv6-Prefix
 
   [RFC3162] Section 2.3 says:
      This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user.  It MAY be used in Access-Accept
      packets, and can appear multiple times.  It MAY be used in an
      Access-Request packet as a hint by the NAS to the server that it
      would prefer these prefix(es), but the server is not required to
      honor the hint.  Since it is assumed that the NAS will plumb a
      route corresponding to the prefix, it is not necessary for the
      server to also send a Framed-IPv6-Route attribute for the same
      prefix.
 
   An Internet Service Provider (ISP) may desire to support Prefix
   Delegation [RFC4818] 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 Routing Information Protocol Next Generation
   (RIPNG).  RFC 2865 Section 5.10 describes the purpose of Framed-
   Routing:
 
      This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets.
 
   The description of the Prefix-Length field in RFC 3162 indicates
   excessively wide latitude:
 
      The length of the prefix, in bits.  At least 0 and no larger than
      128.
 
   This length appears too broad, because it is not clear what a NAS
   should do with a prefix of greater granularity than /64.  For
   example, the Framed-IPv6-Prefix may contain a /128.  This does not
   imply that the NAS should assign an IPv6 address to the end user,
   because RFC 3162 already defines a Framed-IPv6-Identifier attribute
   to handle the Identifier portion.
 
   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
   assigned.  When a /64 or larger prefix is sent, the intent is for the
   NAS to send a routing advertisement containing the information
   present in the Framed-IPv6-Prefix attribute.
 
   The CPE may also require a delegated prefix for its own use, if it is
   decrementing the Hop Limit field of IP headers.  In that case, it
   should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
   attribute [RFC4818].  If the CPE is not decrementing Hop Limit, it
   does not require a delegated prefix."




i'm EMAILING FOR THE GREATER GOOD
Join me
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 	

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


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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Nov 2008 07:14:54 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Nov 2008 08:14:33 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Bernard Aboba' <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Status of Issue 225
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:

>>   It is not *ridiculously* clear from the current document that
>> "Length"
>> and "Extended-Length" are strongly related.  
> 
> Maybe not to you...

  Pretend I'm channeling the 100's of people who've read the specs, and
implemented broken NASes.

> This would disallow the presence of multiple AVPs in a single attribute.
> Are you claiming "WG Consensus" for this massive change?  

  No.  If there *is* only one AVP in a single attribute, then that
relationship holds.

>>   Experience shows that without this text, people will create
>> attributes
>> that don't satisfy this criteria... and claim they're standards
>> compliant.
> 
> This comment is fascinating.  What, exactly, is the "experience" you are
> talking about?  Are there already multiple implementations of the extended
> attributes?  Have you perfected time travel?  

  I am, of course, not claiming experience with multiple implementations
of the extended attributes.  Pretending I'm making that claim is
disingenuous at best.  Instead, I'm claiming something much more
difficult to understand.

  The "experience" is with previous standards, and the people who've
implemented RADIUS software based on them.  It's called "learning from
experience", and "applying that experience to new situations".

  I've spent a lot of time talking with implementors of NASes and
servers about their software.  There are a number of styles of
misunderstanding that they have about existing specifications.  That
experience can be used to review new standards, to minimize the
potential for similar problems.

>>   Experience shows that without this text, people will create short
>> fragments, causing problems for everyone else.
> 
> More "experience".  Where does this "experience" come from?  The only
> problems caused will be for those who wrote code that can't handle fragments
> < 246 in length.

  Inefficient packing should be discouraged.  On top of that, the size
limitation of RADIUS packets means that inefficient packing of
attributes can cause packets to fill quickly.  This means that the
packets can carry less information than they would otherwise have been
able to carry.

  This has implications for all networks that depend on implementations
of the standard.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Nov 2008 07:00:54 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Nov 2008 07:59:57 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Bernard Aboba' <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Status of Issue 278
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
...
>>   Without this text, IANA may allocate 0..255 to the new extended-type,
>> potentially confusing people with conflicts between that and the
>> standard attribute space.
> 
> Utter and complete nonsense.

  Which doesn't address the issue.

  a) Can IANA allocate numbers 0..255 in Ext-Type?
  b) If not, why not?
  c) If so, is this a good idea?

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Nov 2008 00:07:33 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Glen Zorn'" <[e-mail]>, "'Alan DeKok'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: Status of Issue 225
Date: Thu, 13 Nov 2008 16:06:41 -0800
Message-ID: <000d01c945ec$ded99690$9c8cc3b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclFg9hgVWmo9iBjT1unV1TwIrQfrgAXYTmwAALL1YAContent-Language: en-us

Glen Zorn said:

"This would disallow the presence of multiple AVPs in a single attribute.
Are you claiming "WG Consensus" for this massive change?"

Multiple AVPs can be included within a vendor-specific attribute today,
right?
Given that, it doesn't seem reasonable to change this.   




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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 22:54:07 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: Status of Issue 225
Date: Thu, 13 Nov 2008 16:53:13 -0600
Message-ID: <001601c945e2$ab792ae0$026b80a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclFg9hgVWmo9iBjT1unV1TwIrQfrgAXYTmw
Content-Language: en-us

> Bernard Aboba wrote:
> > During the RADEXT WG last call on the RADIUS Extended Attributes
> draft,
> > you filed Issue 225:
> > http://www.drizzle.com/~aboba/RADEXT/
> >
> > The editor of the document, Glen Zorn, has now listed Issue 225 as
> > resolved.  However, before
> > closing this issue, we wanted to get your consent.   Please send a
> note
> > to the RADEXT WG
> > mailing list indicating whether Issue 2225 is in fact resolved to
> your
> > satisfaction, and if not,
> > what portion of the issue remains outstanding.  The latest version of
> > the Extended Attributes
> > document is available for inspection here:
> > http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
> 
>   The issue that still need addressing are:
> 
> --
> Section 4:
> ...
>  I suggest also noting that "Extended-Length = Length - 6".  Otherwise,
> it becomes theoretically possible for them to have conflicting values
> ---
> 
>   It is not *ridiculously* clear from the current document that
> "Length"
> and "Extended-Length" are strongly related.  

Maybe not to you...

> I suggest a MUST:
> 
> --
>    Ext-Len
> 
>       >= 3.  The length of the Type-Length-Value tuple in octets,
>       including the Ext-Type, Ext-Len and Value fields.  The contents
>       of the Ext-Len field MUST be 6 less than the contents of the
>       Length field.  That is: Ext-Len = Length - 6.
> --
> 

This would disallow the presence of multiple AVPs in a single attribute.
Are you claiming "WG Consensus" for this massive change?  

>   Experience shows that without this text, people will create
> attributes
> that don't satisfy this criteria... and claim they're standards
> compliant.

This comment is fascinating.  What, exactly, is the "experience" you are
talking about?  Are there already multiple implementations of the extended
attributes?  Have you perfected time travel?  

> 
> --
>   Also, attributes generated by a client or server MUST NOT be
> fragmented at boundaries other than 246 octets.  Doing so would
> decrease
> the efficiency of packing.  Robust implementations SHOULD support
> receiving attributes fragmented at non-246 octet boundaries.
> --
> 
>   The only reference to 246 octets in the document says that attributes
> *can* be fragmented at 246 octets.  It doesn't forbid fragments smaller
> than that.
> 
>   Experience shows that without this text, people will create short
> fragments, causing problems for everyone else.

More "experience".  Where does this "experience" come from?  The only
problems caused will be for those who wrote code that can't handle fragments
< 246 in length.

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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 22:43:37 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: Status of Issue 278
Date: Thu, 13 Nov 2008 16:42:14 -0600
Message-ID: <001501c945e1$237d4460$6a77cd20$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclFg1ESxfJ86tQOQ0uFHVERLOiFXAAXaywQ
Content-Language: en-us

> Bernard Aboba wrote:
> > During the RADEXT WG last call on the RADIUS Extended Attributes
> draft,
> > you filed Issue 278:
> > http://www.drizzle.com/~aboba/RADEXT/
> >
> > The editor of the document, Glen Zorn, has now listed Issue 278 as
> > resolved.  However, before
> > closing this issue, we wanted to get your consent.   Please send a
> note
> > to the RADEXT WG
> > mailing list indicating whether Issue 278 is in fact resolved to your
> > satisfaction,
> 
>   The latest version of the draft addresses most of my comments.  The
> remaining issue that should be addressed is:
> 
> ---
> 8.  IANA Considerations
> ...
>    It also requires that IANA set up a new registry for the RADIUS
>    Extended Attribute Types.
> 
>   I suggest leaving the first 0..255 attributes as unallocated, in
> order
> to avoid confusion with legacy RADIUS attributes.
> ---
> 
>   Without this text, IANA may allocate 0..255 to the new extended-type,
> potentially confusing people with conflicts between that and the
> standard attribute space.

Utter and complete nonsense.

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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 12:26:36 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Abhishek Tiwari'" <[e-mail]>
Subject: RE: Review of draft-tiwari-radext-tunnel-type-02.txt
Date: Thu, 13 Nov 2008 07:25:51 -0500
Message-ID: <A02AD68027764107966F6D76A21462DC@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmA
> "The comment period will last until October 5, 2008."
> 
> Any progress?

There have been a number of positive comments to the list with regard to
accepting this draft as a WG work item, and no negative comments.  Consider
it accepted.

The window for draft submission will open up again on the Monday of IETF 73
week. Given the simple nature of the draft, we can immediately start a WG
Last Call, perhaps immediately after ITEF 73.



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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 11:41:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
Date: Thu, 13 Nov 2008 12:41:11 +0100
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
Thread-Index: AclEZCFswkWx30iWTFOCd9l6YLBR1wBHvGpA
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: "Ralph Droms (rdroms)" <[e-mail]>, <[e-mail]>
Cc: "Bernard Aboba" <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l00; t26576472; x27440472; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Benoit Lourdelet (blourdel)" <blourdel@ cisco.com> |Subject: RE: RADEXT WG consensus call on = 22IPv6 Attributes for DHCP Networks" |Sender: ; bh=Jr03GyRPHn+8tSlHKvY/NfjudmOgJdd0+ydq9jRrVNY=; b=PbCw7rDBgkXARKtGX1eX0I6NvZtaFTCuDOV/i0NEDxCgzWIgoFi2LbsWI3 uYqgovdmjnxtlyDphgc9T1vUvISnUKNY/dYApNxqn+qVIsowU8Rr9amod7iw a6cfUyO7UY;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );

Ralph,

The problem I have with this approach is that giving more though to it,
I thing that

IPv6-DNS attribute could be used in the RFC5006 context. So it is not
DHCP use only.

IPv6-address could be used in a SLAC context for validation of the
advertised address by the gateway.

So it turns that none of the attributes are DHCP specific.

Regards

Benoit


-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, November 12, 2008 2:15 AM
To: [e-mail]
Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit Lourdelet (blourdel)
Subject: Re: RADEXT WG consensus call on "IPv6 Attributes for DHCP
Networks"

I support accepting "IPv6 Attributes for DHCP Networks" as a RADEXT WG
work item.  There is a need for these attributes to support certain
IPv6 deployment models.

I support handling "IPv6 Attributes for DHCP Networks" as a separate
work item.  I am concerned that bundling the attributes into a revision
of RFC 3162 would incur too much delay.

- Ralph

On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba wrote:

> At IETF 72, the RADEXT WG was polled on the following questions:
>
> 1) whether to accept "IPv6 Attributes for DHCP Networks"
> (http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-
> 00.txt
> )
> as a RADEXT WG work item;
>
> 2) whether to handle this as a standalone work item or bundle it into 
> a revision of RFC 3162 (RFC 3162bis).
>
> This is a RADEXT WG consensus call, in order to confirm the "sense of 
> the room" at IETF 72 with respect to these two items.
>
> The RADEXT WG Consensus call will last until November 12, 2008.    
> Please send your
> opinions on these two questions to the RADEXT WG mailing list 
> ([e-mail] ).
>
>
>


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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 11:32:05 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Nov 2008 12:31:52 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Status of Issue 225
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> During the RADEXT WG last call on the RADIUS Extended Attributes draft,
> you filed Issue 225:
> http://www.drizzle.com/~aboba/RADEXT/
>  
> The editor of the document, Glen Zorn, has now listed Issue 225 as
> resolved.  However, before
> closing this issue, we wanted to get your consent.   Please send a note
> to the RADEXT WG
> mailing list indicating whether Issue 2225 is in fact resolved to your
> satisfaction, and if not,
> what portion of the issue remains outstanding.  The latest version of
> the Extended Attributes
> document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05

  The issue that still need addressing are:

--
Section 4:
...
 I suggest also noting that "Extended-Length = Length - 6".  Otherwise,
it becomes theoretically possible for them to have conflicting values
---

  It is not *ridiculously* clear from the current document that "Length"
and "Extended-Length" are strongly related.  I suggest a MUST:

--
   Ext-Len

      >= 3.  The length of the Type-Length-Value tuple in octets,
      including the Ext-Type, Ext-Len and Value fields.  The contents
      of the Ext-Len field MUST be 6 less than the contents of the
      Length field.  That is: Ext-Len = Length - 6.
--

  Experience shows that without this text, people will create attributes
that don't satisfy this criteria... and claim they're standards compliant.

--
  Also, attributes generated by a client or server MUST NOT be
fragmented at boundaries other than 246 octets.  Doing so would decrease
the efficiency of packing.  Robust implementations SHOULD support
receiving attributes fragmented at non-246 octet boundaries.
--

  The only reference to 246 octets in the document says that attributes
*can* be fragmented at 246 octets.  It doesn't forbid fragments smaller
than that.

  Experience shows that without this text, people will create short
fragments, causing problems for everyone else.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 11:31:01 +0000
From: Abhishek Tiwari <[e-mail]>
To: "David B. Nelson" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Thu, 13 Nov 2008 19:30:35 +0800
Subject: RE: Review of draft-tiwari-radext-tunnel-type-02.txt
Thread-Topic: Review of draft-tiwari-radext-tunnel-type-02.txt
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJw
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

On September 9, 2008, David Nelson said:

"The comment period will last until October 5, 2008."

Any progress?

Thanks,
Abhishek

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of David B. Nelson
Sent: Tuesday, September 09, 2008 10:52 PM
To: [e-mail]
Subject: Review of draft-tiwari-radext-tunnel-type-02.txt

This is call for the RADEXT WG to review the I-D
draft-tiwari-radext-tunnel-type-02.txt, which assigns new values of the
RADIUS Tunnel-Type Attribute.

After a discussion among the draft author, our esteemed Area Director and
the WG Co-Chairs, it was decided that review of this document in RADEXT was
appropriate and that, if the WG concurred, we would make it a WG item and
forward it to the IESG to determine IETF Consensus.

This document is now in RADEXT WG Pre-WG Review.

Please review this very short (5 pages) draft located at:
http://www.ietf.org/internet-drafts/draft-tiwari-radext-tunnel-type-02.txt

Please send a message to the RADEXT list indicating:

(1) Should this document be taken on as RADEXT WG work item?

(2) Are the technical or editorial issues with this document?

The comment period will last until October 5, 2008.

Regards,

Dave



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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Nov 2008 11:25:56 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Nov 2008 12:24:55 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Status of Issue 278
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> During the RADEXT WG last call on the RADIUS Extended Attributes draft,
> you filed Issue 278:
> http://www.drizzle.com/~aboba/RADEXT/
>  
> The editor of the document, Glen Zorn, has now listed Issue 278 as
> resolved.  However, before
> closing this issue, we wanted to get your consent.   Please send a note
> to the RADEXT WG
> mailing list indicating whether Issue 278 is in fact resolved to your
> satisfaction,

  The latest version of the draft addresses most of my comments.  The
remaining issue that should be addressed is:

---
8.  IANA Considerations
...
   It also requires that IANA set up a new registry for the RADIUS
   Extended Attribute Types.

  I suggest leaving the first 0..255 attributes as unallocated, in order
to avoid confusion with legacy RADIUS attributes.
---

  Without this text, IANA may allocate 0..255 to the new extended-type,
potentially confusing people with conflicts between that and the
standard attribute space.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 23:03:37 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Hannes Tschofenig'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>, "'ext Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Tue, 11 Nov 2008 17:02:11 -0600
Message-ID: <006701c94451$93bb86b0$bb329410$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AAH7IbEA=
Content-Language: en-us

Tschofenig, Hannes (NSN - FI/Espoo) [mailto:// [e-mail]]
writes:

> Glen,
> 
> >It's very simple: if these attributes/AVPs are meant to be
> >used in RADIUS then do the work in radext (or at the very
> >least, follow the RADIUS design guidelines); note that those
> >attributes could be carried w/o any fuss in Diameter as well.
> >If they are meant to be used in Diameter, then design them as
> >Diameter AVPs, using the features that Diameter enables
> >(grouped AVPs, etc.).  What you have done is neither, and have
> >(predictably) ended up with a mess.
> 
> You obviously don't care too much about my arguments.
> 
> There are three things:
> 
> * The QoS can be carried in RADIUS and Diameter.

If that is the intention, then these should be RADIUS attributes.

> 
> * This approach is totally inline with the RADIUS design guidelines.
> The RADIUS design guidelines document does not require every info
> element to following the standard encoding, as you know.

I think that you've got at least two people who disagree with you on that.

> 
> * Where todo certain documents is a matter of taste and not really a
> bit
> issue (at least so far).

??!  You're not seriously suggesting that Diameter AVPs & RADIUS attributes
are technically equivalent, are you?


> We had a RADIUS draft, as I mentioned, but we focused all our efforts
> on
> the Diameter work.

That's the main problem: the -05 draft contained Diameter AVPs but -06
doesn't.  In fact, this is exactly the kind of application for which
Diameter was designed & I find it rather annoying what's being proposed are
poorly designed RADIUS attributes masquerading as Diameter AVPs.

> 
> Ciao
> Hannes


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 22:44:34 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Hannes Tschofenig'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Tue, 11 Nov 2008 16:42:34 -0600
Message-ID: <006601c9444e$d3591ba0$7a0b52e0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANrK/AAAWF8EAAQyknw
Content-Language: en-us

Hannes Tschofenig [mailto://[e-mail]] writes:


> Hi Mikko,
> 
> the reason is that we essentially "copied" the format defined in the
> NSIS
> group as they have been working on the definition of the QoS
> parameters.
> In the past folks in DIME did not have a problem with the format and I
> also
> specifically asked for feedback on this issue.
> 
> In fact, I even compiled a version of the draft with Diameter encoding
> once:
> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05

As luck would have it, I think that was the one I read :-) -- no wonder I
had no problem.

> As one can see from that document it isn't totally easy either to use
> Diameter AVPs as the format that is being referenced comes directly
> from a
> various RFCs and there is the obvious question whether the format
> should be
> taken as is or also "translated". For example, take a look at Section
> 3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
> (PHB-Class AVP).

What's wrong with it?  It seems at least as comprehensible as section 4.13
of -06...

...


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 19:15:42 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Nov 2008 12:06:10 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Comment on draft-ietf-radext-design-05.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> This document is 36 pages long, yet devotes only a single paragraph to the
> use of extended RADIUS attributes.

  The goal was to finish the design document significantly before the
extended attributes document was finished.  Due to normal WG issues,
this didn't happen.

>  Since the extended attribute set is
> likely the one to be most used in the future, this seems a rather gross
> oversight.

  The extended attributes document is referenced from the guidelines
document.  It suggests that designs not meeting the criteria of the
guidelines document use the practices documented in the extended
attributes document.

>  I would suggest that the authors try to design a few extended
> attribute sets and then document that experience.

  How does this help the guidelines document?

  The extended attributes document meets WG consensus, and follows the
traditional RADIUS data model for attributes.  It would seem that
everyone agrees that the specification it proposes is satisfactory, and
meets their needs.

>  I mention this at this
> late date because I expected this note to become an RFC long before the
> extended attributes doc, but (FWIW) the latter has completed WG "Last"
> Call...

  The guidelines document has seen multiple last calls, with last-minute
comments at each one.

  Alan DeKok.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 16:15:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94418.93C5EA33"
Subject: FW: WiMAX Forum Review Request
Date: Tue, 11 Nov 2008 17:14:30 +0100
Message-ID: <[e-mail]>
Thread-Topic: WiMAX Forum Review Request
Thread-Index: Ack6zj5R1d3BLd5sS7ye19PxDPL7KgJSIknAAABxexAFrom: "Romascanu, Dan (Dan)" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C94418.93C5EA33
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

 

________________________________

From: Alper Yegin [mailto:[e-mail]] 
Sent: Tuesday, November 11, 2008 6:05 PM
To: 'Bernard Aboba'; Romascanu, Dan (Dan); [e-mail];
[e-mail]
Subject: RE: WiMAX Forum Review Request



Hi Bernard,

 

WiMAX Forum NWG Security Team has discussed this I-D during the Seoul
face-to-face meeting last week. 

 

Our NWG specifications use PKMv2, not PKMv1. Therefore, there is no
official opinion of NWG on this I-D. Nevertheless, NWG members are
requested to post their individual feedback on the IETF RADEXT WG
mailing list. 

 

Thank you for keeping us informed.

 

Regards,

 

Alper

 

From: Bernard Aboba [mailto:[e-mail]] 
Sent: Thursday, October 30, 2008 10:30 PM
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: WiMAX Forum Review Request

 

Recently, the IETF RADEXT WG has received a request to accept the
document "RADIUS Attributes for IEEE 802.16 Privacy Key Management
Version 1" as a working group work item.  The specification is available
here:
http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt
 
Since this document relates to the work of the WiMAX Forum, we would
like to inquire as to whether WMF has an opinion on the advisability of
having IETF take on this work, as well as to whether WMF has any
editorial or technical feedback relating to the document.  This document
is likely to be discussed during the IETF 73 RADEXT WG meeting in
Minneapolis. 
 

i'mEMAILING FOR THE GREATER GOOD
Join me
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 

 


------_=_NextPart_001_01C94418.93C5EA33
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3429" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Segoe UI;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV>&nbsp;</DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Alper Yegin [mailto:[e-mail]] 
<BR><B>Sent:</B> Tuesday, November 11, 2008 6:05 PM<BR><B>To:</B> 'Bernard 
Aboba'; Romascanu, Dan (Dan); [e-mail]; 
[e-mail]<BR><B>Subject:</B> RE: WiMAX Forum Review 
Request<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=Section1>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Hi 
Bernard,<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">WiMAX 
Forum NWG Security Team has discussed this I-D during the Seoul face-to-face 
meeting last week. <o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Our 
NWG specifications use PKMv2, not PKMv1. Therefore, there is no official opinion 
of NWG on this I-D. Nevertheless, NWG members are requested to post their 
individual feedback on the IETF RADEXT WG mailing list. <o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Thank 
you for keeping us informed.<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Regards,<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Alper<o:p></o:p></SPAN></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<DIV>
<DIV 
style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=MsoNormal><B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Bernard Aboba 
[mailto:[e-mail]] <BR><B>Sent:</B> Thursday, October 30, 2008 
10:30 PM<BR><B>To:</B> [e-mail]; [e-mail]; 
[e-mail]; [e-mail]<BR><B>Subject:</B> WiMAX Forum 
Review Request<o:p></o:p></SPAN></P></DIV></DIV>
<P class=MsoNormal><o:p>&nbsp;</o:p></P>
<P class=MsoNormal><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">Recently, the IETF 
RADEXT WG has received a request to accept the document "RADIUS Attributes for 
IEEE 802.16 Privacy Key Management Version 1" as&nbsp;a working group work 
item.&nbsp; The&nbsp;specification is available here:<BR><A 
href="http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt" 
target=_blank>http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt</A><BR>&nbsp;<BR>Since 
this document relates to the work of the WiMAX Forum, we would like 
to&nbsp;inquire as to whether WMF has an opinion on the advisability of having 
IETF take on this&nbsp;work, as well as&nbsp;to whether WMF has 
any&nbsp;editorial or technical feedback relating to the document.&nbsp; This 
document is likely to be discussed during the IETF 73 RADEXT WG meeting&nbsp;in 
Minneapolis. <BR>&nbsp;<o:p></o:p></SPAN></P>
<TABLE class=MsoNormalTable 
style="BORDER-RIGHT: medium none; BORDER-TOP: black 1pt solid; BORDER-LEFT: medium none; BORDER-BOTTOM: medium none" 
cellPadding=0 border=1>
  <TBODY>
  <TR>
    <TD 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0.75pt; BORDER-TOP: medium none; PADDING-LEFT: 0.75pt; PADDING-BOTTOM: 0.75pt; BORDER-LEFT: medium none; PADDING-TOP: 0.75pt; BORDER-BOTTOM: medium none">
      <P class=MsoNormal><B><SPAN 
      style="FONT-FAMILY: 'Segoe UI','sans-serif'"><A 
      href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" 
      target=_blank><SPAN 
      style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none"><IMG 
      id=_x0000_i1032 alt="i'm" 
      src="http://gfx1.hotmail.com/mail/w3/pr01/ltr/i_charity.gif" border=0 
      NOSEND="1">EMAILING FOR THE GREATER GOOD<BR></SPAN><SPAN 
      style="FONT-SIZE: 8pt; COLOR: #3fb555">Join 
      me</SPAN></A><o:p></o:p></SPAN></B></P></TD></TR></TBODY></TABLE>
<P class=MsoNormal><o:p>&nbsp;</o:p></P></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C94418.93C5EA33--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 14:53:40 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Tue, 11 Nov 2008 16:52:56 +0200
Message-ID: <00d001c9440d$2f8b4610$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANrK/AAAWF8EA=

Hi Mikko, 

the reason is that we essentially "copied" the format defined in the NSIS
group as they have been working on the definition of the QoS parameters. 
In the past folks in DIME did not have a problem with the format and I also
specifically asked for feedback on this issue. 

In fact, I even compiled a version of the draft with Diameter encoding once:
http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
As one can see from that document it isn't totally easy either to use
Diameter AVPs as the format that is being referenced comes directly from a
various RFCs and there is the obvious question whether the format should be
taken as is or also "translated". For example, take a look at Section
3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
(PHB-Class AVP). 

Ciao
Hannes
 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>Sent: 11 November, 2008 16:24
>To: [e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: RE: [Dime] [AAA-DOCTORS] AD Review of 
>dime-qos-parameters-06.txt
>
>Hi,
>
>Would it be useful to add some text to the draft to explain 
>and justify the usage of the encoding format that you've 
>chosen for the qos parameters?
>
>It is not obvious why is it be better to define separate qos 
>parameter header and formats instead of using normal Diameter 
>AVP header and formats to transfer the data.
>
>
>BR,
>Mikko
>
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of 
>>ext Hannes Tschofenig
>>Sent: 11 November, 2008 14:21
>>To: 'David B. Nelson'; [e-mail]
>>Cc: [e-mail]; [e-mail]
>>Subject: Re: [Dime] [AAA-DOCTORS] AD Review of 
>>dime-qos-parameters-06.txt
>>
>>Hi David,
>> 
>>
>>>Hannes Tschofenig writes...
>>>
>>>> * This approach is totally inline with the RADIUS design 
>guidelines.
>>>> The RADIUS design guidelines document does not require every info 
>>>> element to following the standard encoding, as you know.
>>>
>>>The RADIUS Design Guidelines document is pragmatic.  It
>>>*strongly* suggests (SHOULD not MUST) that attributes which could 
>>>reasonably be implemented in a data-dictionary driven RADIUS 
>server as 
>>>data dictionary entries be encoded in the standard encoding.  
>>>Exceptions are made for (a) attributes which would 
>absolutely require 
>>>code changes in the server, (b) attributes used as authentication 
>>>credentials payloads, and
>>>(c) attributes which are opaque to the RADIUS server and
>>RADIUS client.
>>
>>I don't think that attributes can be opaque to the RADIUS 
>client since 
>>the client has todo something with them.
>>
>>The attributes are opaque to the RADIUS server and the respective 
>>component (dealing with policy-based admission control) needs to be 
>>implemented (=code changes).
>>
>>>
>>>This is not a matter of aesthetics or personal design choice 
>>>-- it is dictated by the usage.
>>>
>>>BTW, *my* definition of opaque means that the data field of 
>>>the attribute, as described in the RADIUS document is a single 
>>>string, whose contents are defined in some non-RADIUS 
>>>document.  Once the RADIUS attribute definition starts 
>>>breaking the attribute data payload into sub-fields it really 
>>>isn't opaque anymore.
>>
>>Currently, we do not yet define the RADIUS attributes (and 
>>that would be a
>>RADEXT document) but they will then be defined as a string and 
>>within that
>>string there will be the content of the QoS parameters. 
>>
>>Ciao
>>Hannes
>


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 14:15:24 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Tue, 11 Nov 2008 09:14:25 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <63F3725E9F224667917650FAC1525074@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQAANr5qA
Hi Hannes,

> I don't think that attributes can be opaque to the RADIUS 
> client since the client has todo something with them.

Maybe this is a matter of semantics.  Just as the RADIUS Server does not
comprise the complete set of server-side AAA functionality (e.g. policy
servers, location servers, authentication back-ends, etc. are logically
separate), the RADIUS Client does not comprise the complete set of AAA
functionality in the NAS.  The RADIUS Client delivers authorization
information to the components of the NAS that enforce access control.

When you define the RADIUS Server and RADIUS Client in this narrow sense,
i.e. the code that deals with RADIUS PDUs, I think you can claim the certain
attributes are opaque to the RADIUS Client (but certainly not to the NAS).

-- Dave



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 12:21:27 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Tue, 11 Nov 2008 14:20:58 +0200
Message-ID: <00c901c943f7$f5568140$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkAAA4/dQ

Hi David, 
 

>Hannes Tschofenig writes...
>
>> * This approach is totally inline with the RADIUS design guidelines.
>> The RADIUS design guidelines document does not require every info 
>> element to following the standard encoding, as you know.
>
>The RADIUS Design Guidelines document is pragmatic.  It 
>*strongly* suggests (SHOULD not MUST) that attributes which 
>could reasonably be implemented in a data-dictionary driven 
>RADIUS server as data dictionary entries be encoded in the 
>standard encoding.  Exceptions are made for (a) attributes 
>which would absolutely require code changes in the server, (b) 
>attributes used as authentication credentials payloads, and 
>(c) attributes which are opaque to the RADIUS server and RADIUS client.

I don't think that attributes can be opaque to the RADIUS client since the
client has todo something with them. 

The attributes are opaque to the RADIUS server and the respective component
(dealing with policy-based admission control) needs to be implemented (=code
changes). 

>
>This is not a matter of aesthetics or personal design choice 
>-- it is dictated by the usage.
>
>BTW, *my* definition of opaque means that the data field of 
>the attribute, as described in the RADIUS document is a single 
>string, whose contents are defined in some non-RADIUS 
>document.  Once the RADIUS attribute definition starts 
>breaking the attribute data payload into sub-fields it really 
>isn't opaque anymore.

Currently, we do not yet define the RADIUS attributes (and that would be a
RADEXT document) but they will then be defined as a string and within that
string there will be the content of the QoS parameters. 

Ciao
Hannes


>
>
>_______________________________________________
>DiME mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dime
>


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Nov 2008 12:03:46 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Tue, 11 Nov 2008 07:02:39 -0500
Message-ID: <AE397DB2A12849609D6FA60186A800D6@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AABcfc6AACOMHkA=

Hannes Tschofenig writes...

> * This approach is totally inline with the RADIUS design guidelines.
> The RADIUS design guidelines document does not require every info
> element to following the standard encoding, as you know.

The RADIUS Design Guidelines document is pragmatic.  It *strongly* suggests
(SHOULD not MUST) that attributes which could reasonably be implemented in a
data-dictionary driven RADIUS server as data dictionary entries be encoded
in the standard encoding.  Exceptions are made for (a) attributes which
would absolutely require code changes in the server, (b) attributes used as
authentication credentials payloads, and (c) attributes which are opaque to
the RADIUS server and RADIUS client.

This is not a matter of aesthetics or personal design choice -- it is
dictated by the usage.

BTW, *my* definition of opaque means that the data field of the attribute,
as described in the RADIUS document is a single string, whose contents are
defined in some non-RADIUS document.  Once the RADIUS attribute definition
starts breaking the attribute data payload into sub-fields it really isn't
opaque anymore.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Nov 2008 23:53:02 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Comment on draft-ietf-radext-design-05.txt
Date: Mon, 10 Nov 2008 17:47:23 -0600
Message-ID: <007d01c9438e$b54c8e00$1fe5aa00$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclDjq0P29MmFNaTQsunFdqXn5HefQ=
Content-Language: en-us

This document is 36 pages long, yet devotes only a single paragraph to the
use of extended RADIUS attributes.  Since the extended attribute set is
likely the one to be most used in the future, this seems a rather gross
oversight.  I would suggest that the authors try to design a few extended
attribute sets and then document that experience.  I mention this at this
late date because I expected this note to become an RFC long before the
extended attributes doc, but (FWIW) the latter has completed WG "Last"
Call...


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Nov 2008 20:58:05 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Mon, 10 Nov 2008 15:57:30 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <13EDB72D1E7749B18E28992307CD40B8@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5AAACe7yA
Glen Zorn writes...

> It's very simple: if these attributes/AVPs are meant to 
> be used in RADIUS then do the work in radext (or at the 
> very least, follow the RADIUS design guidelines); ...

I agree.  If functionality is required in *both* RADIUS and Diameter, it
will need to be cast in the "least common denominator" format of RADIUS
attributes, subject to the RADIUS Design Guidelines.

Is there an actual requirement for these QoS attributes in RADIUS
environments?



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Nov 2008 20:45:14 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Hannes Tschofenig'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>, "'ext Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS]  AD Review of dime-qos-parameters-06.txt
Date: Mon, 10 Nov 2008 14:43:14 -0600
Message-ID: <006901c94375$00051ee0$000f5ca0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUAAdki5A
Content-Language: en-us

> Hi Bernard,
> 
> We have currently three documents in DIME that relate to QoS: The
> Diameter
> QoS application specifies, as the name indicates, a Diameter
> application for
> usage with QoS. The QoS attribute draft provides the encoding of
> classifiers
> and AVPs relevant for QoS. The actual QoS parameters for an initial
> profile
> are defined in the QoS parameters draft. These drafts in DIME focus on
> Diameter usage. We have dependencies from the 3GPP on these documents.
> 
> It is, however, quite easy to imagine that QoS parameters might also be
> useful in a RADIUS context. In fact we had a document some time ago
> that
> described how to re-use the same QoS parameter format for RADIUS. The
> document is, however, expired now and would need a significant update
> given
> the changes we have seen in the DIME documents.

It's very simple: if these attributes/AVPs are meant to be used in RADIUS
then do the work in radext (or at the very least, follow the RADIUS design
guidelines); note that those attributes could be carried w/o any fuss in
Diameter as well.  If they are meant to be used in Diameter, then design
them as Diameter AVPs, using the features that Diameter enables (grouped
AVPs, etc.).  What you have done is neither, and have (predictably) ended up
with a mess.

> 
> When it comes to the format then our believe so far was that the format
> of
> the QoS parameters was not really important as the authorization
> decision
> and related admission control procedures by the AAA server will require
> code
> changes. Code changes to the AAA client will be needed as well since
> the
> parameters need to be feed into a Traffic Control module.
> 
> Ciao
> Hannes
> 
> 
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Bernard Aboba
> >Sent: 10 November, 2008 06:50
> >To: 'ext Romascanu, Dan (Dan)'; [e-mail]
> >Cc: [e-mail]; [e-mail]
> >Subject: Re: [AAA-DOCTORS] [Dime] AD Review of
> >dime-qos-parameters-06.txt
> >
> >Glen Zorn said:
> >
> >"Still looks like (bad) RADIUS to me."
> >
> >Can someone explain the relationship of this document to (bad
> >or good) RADIUS?
> >
> >Looking at the DIME WG charter, there is an item for the
> >Diameter QoS application
> >(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-q
> >os-06.txt),
> >Which in turn has normative references to QoS Attributes for Diameter
> >(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib
> >utes-08.txt)
> >and this document.
> >
> >None of these documents request allocation of any RADIUS
> >attributes, or describe RADIUS Attribute formats.
> >
> >
> >
> >_______________________________________________
> >AAA-DOCTORS mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/aaa-doctors
> >
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Nov 2008 06:42:11 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, "'ext Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [AAA-DOCTORS] [Dime] AD Review of dime-qos-parameters-06.txt
Date: Mon, 10 Nov 2008 08:41:23 +0200
Message-ID: <00a101c942ff$5aa9a210$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAAA6ulUA=

Hi Bernard,

We have currently three documents in DIME that relate to QoS: The Diameter
QoS application specifies, as the name indicates, a Diameter application for
usage with QoS. The QoS attribute draft provides the encoding of classifiers
and AVPs relevant for QoS. The actual QoS parameters for an initial profile
are defined in the QoS parameters draft. These drafts in DIME focus on
Diameter usage. We have dependencies from the 3GPP on these documents. 

It is, however, quite easy to imagine that QoS parameters might also be
useful in a RADIUS context. In fact we had a document some time ago that
described how to re-use the same QoS parameter format for RADIUS. The
document is, however, expired now and would need a significant update given
the changes we have seen in the DIME documents. 

When it comes to the format then our believe so far was that the format of
the QoS parameters was not really important as the authorization decision
and related admission control procedures by the AAA server will require code
changes. Code changes to the AAA client will be needed as well since the
parameters need to be feed into a Traffic Control module.

Ciao
Hannes
 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Bernard Aboba
>Sent: 10 November, 2008 06:50
>To: 'ext Romascanu, Dan (Dan)'; [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: Re: [AAA-DOCTORS] [Dime] AD Review of 
>dime-qos-parameters-06.txt
>
>Glen Zorn said:
>
>"Still looks like (bad) RADIUS to me."
>
>Can someone explain the relationship of this document to (bad 
>or good) RADIUS?
>
>Looking at the DIME WG charter, there is an item for the 
>Diameter QoS application 
>(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-q
>os-06.txt),
>Which in turn has normative references to QoS Attributes for Diameter
>(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib
>utes-08.txt)
>and this document.
>
>None of these documents request allocation of any RADIUS 
>attributes, or describe RADIUS Attribute formats.  
>
>
>
>_______________________________________________
>AAA-DOCTORS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aaa-doctors
>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Nov 2008 04:50:33 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'ext Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [AAA-DOCTORS] [Dime] AD Review of dime-qos-parameters-06.txt
Date: Sun, 9 Nov 2008 20:50:09 -0800
Message-ID: <003801c942ef$cf51c7b0$6df55710$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3KwxgSubQAI3ntvABSALmIAAHkbzAADpyrKAContent-Language: en-us

Glen Zorn said:

"Still looks like (bad) RADIUS to me."

Can someone explain the relationship of this document to (bad or good)
RADIUS?

Looking at the DIME WG charter, there is an item for the Diameter QoS
application
(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt), 
Which in turn has normative references to QoS Attributes for Diameter
(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-08.txt)
and this document.

None of these documents request allocation of any RADIUS attributes, or
describe RADIUS Attribute formats.  




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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Nov 2008 04:36:46 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Benoit Lourdelet \(blourdel\)'" <[e-mail]>, <[e-mail]>
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt
Date: Sun, 9 Nov 2008 20:35:42 -0800
Message-ID: <002e01c942ed$ca8e1000$5faa3000$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ack5fBVL23bBlqt8TLKXf8KrzmgRfgDzZXkAAWhY4mAContent-Language: en-us

It would be helpful to add RFC 5006 as a reference within Section 3.8
so as to clarify the potential use of the IPv6-DNS-Server-Address
attribute. 

With respect to DHCP support, at IETF 72, questions were raised about
the usage model in this document versus that in RFC 4014.  For example,
in RFC 4014, the RADIUS server speaks to the NAS, which can then act
as a DHCP relay agent in talking to the DHCP server.  In this document,
it appears that the RADIUS server talks directly to the DHCP server.
Is that right?  If so, when does authentication take place?  Is the
intent to allocate other RADIUS attributes corresponding to 
existing DHCPv4/v6 options? 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Benoit Lourdelet (blourdel)
Sent: Sunday, November 09, 2008 10:14 AM
To: Bernard Aboba; [e-mail]
Cc: [e-mail]; Benoit Lourdelet (blourdel)
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt

Hello,


The DHCP context has been removed on purpose to avoid restricting the
use of the new attributes
 in different context.
IPv6-DNS-Server-Address is a good example as it could be used by DHCPv6
or RA (see RFC5006).
So we certainly should not restrict its use by DHCPv6.

Even IPv6-Address could be used in an autoconfiguration context for
validation of an address included
 in ND messages.

All the above preaches to remove any reference to DHCP as too
restrictive.

A possibility would be to clarify the use of Framed-IPv6-Prefix and
restrict its use to prefix shorter
 or equal to 64.

Regards

Benoit

 

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Bernard Aboba
Sent: Wednesday, October 29, 2008 5:07 AM
To: [e-mail]
Subject: Review of draft-lourdelet-radext-rfc3162bis-01.txt


Review of draft-lourdelet-radext-rfc3162bis-01.txt
 
This document represents the folding of the attributes described in
draft-lourdelet-radext-ipv6-dhcp-00.txt with RFC 3162.  Currently,
the RFC 3162 has been brought over to this document verbatim; 
only Sections 3.7 (defining the IPv6-Address attribute) and 
Section 3.8 (defining the IPv6-DNS-Server-Address attribute)
have changed. 
 
As discussed at IETF 73, several points of confusion have arisen
with respect to RFC 3162, and one of the reasons to produce
an RFC 3162bis would be to clarify those issues.  One of the
issues, whether Framed-IPv6-Prefix could be used with DHCP 
Prefix delegation, was addressed in RFC 4818 (the answer is no). 
 
Another issue relates to whether the Framed-IPv6-Prefix attribute
can be used with a prefix length greater than a /64 (e.g. /128). 
RFC 5080, Section 2.11 discusses this, though strangely it does not 
update RFC 3162.  As noted in this section (see below), while this
usage is feasible, it is not entirely clear what a typical NAS 
would do on receiving a Framed-IPv6-Prefix Attribute with a /128
prefix, since the typical practice is to announce the prefix using
Router Advertisement.  
 
Given this, as well as the approach in RFC 4818, it would appear
that the easiest way to distinguish RFC 3162 from RFC 4818 and
draft-lourdelet-radext-ipv6-dhcp is that each of these documents
addresses a different set of scenarios.  RFC 3162 was largely 
focused on stateless address autoconfiguration (largely focused
on PPP); RFC 4818 is about prefix delegation; 
draft-lourdelet-radext-ipv6-dhcp is about stateful addressing 
and configuration via DHCPv6.  
 
However, in merging draft-lourdelet-radext-ipv6-dhcp with RFC 3162, 
some of the explanatory information has been removed.  This makes
it difficult to understand that the new attributes relate to stateful
address assignment via DHCPv6.  
 
For example, Section 3.7 introduces the IPv6-Address attribute.  
However, only some of the original text from 
draft-lourdelet-radext-ipv6-dhcp-00 is included to explain
the usage of the attribute.  
 
>From the IETF 73 discussion, my understanding is that the purpose 
of this attribute is for the RADIUS server to assign one or more IPv6
addresses 
to a NAS which is acting as a DHCPv6 server, and will subsequently 
assign those addresses to a user acting as a DHCPv6 client.  One
question that arose during IETF 73 was how address assignment
would relate to the authentication process.  
 
For example, draft-lourdelet-radius-ipv6-dhcp includes the following
diagram:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)  RADIUS Server
       |                           |                                |
       |--Solicit(Address)-------->|                                |
       |                           |-----Request------------------->|
       |                           |<---------Accept(IPv6-Address)--|
       |<-Advertise(Address)-------|                                |
       |---Request(Address)------->|                                |
       |<---Reply(Address)---------|                                |

In this diagram, no authentication is present at all, which lead to
considerable discussion (and confusion) at IETF 73.  
 
Similarly, Section 3.8 defines the IPv6-DNS-Server-Address attribute,
which is assigned to a NAS acting as a DHCPv6 server, with the goal 
of providing this DNS server address to the user within the DNS
Recursive
Name Server Option [RFC3646].  This was illustrated in the following
diagram from draft-lourdelet-radius-ipv6-dhcp:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)    RADIUS Server
        |                            |                                |
        |--Solicit (DNS)------------>|                                |
        |                            |-Request----------------------->|
        |                            |<-------Accept(Ipv6-DNS)--------|
        |<-Advertise(DNS)------------|                                |
        |-Request(DNS)-------------->|                                |
        |<--Reply(DNS)---------------|       

Again, some context would be helpful. 
 
Overall, if the goal is to clarify issues from RFC 3162bis as well as
to add new DHCPv6-related attributes, then it seems that additional
work is required such as integration of the clarifications from RFC
5080,
and explanation of the DHCPv6 usage scenarios. 

Text from RFC 5080:

"2.11.  Framed-IPv6-Prefix
 
   [RFC3162] Section 2.3 says:
      This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user.  It MAY be used in Access-Accept
      packets, and can appear multiple times.  It MAY be used in an
      Access-Request packet as a hint by the NAS to the server that it
      would prefer these prefix(es), but the server is not required to
      honor the hint.  Since it is assumed that the NAS will plumb a
      route corresponding to the prefix, it is not necessary for the
      server to also send a Framed-IPv6-Route attribute for the same
      prefix.
 
   An Internet Service Provider (ISP) may desire to support Prefix
   Delegation [RFC4818] 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 Routing Information Protocol Next Generation
   (RIPNG).  RFC 2865 Section 5.10 describes the purpose of Framed-
   Routing:
 
      This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets.
 
   The description of the Prefix-Length field in RFC 3162 indicates
   excessively wide latitude:
 
      The length of the prefix, in bits.  At least 0 and no larger than
      128.
 
   This length appears too broad, because it is not clear what a NAS
   should do with a prefix of greater granularity than /64.  For
   example, the Framed-IPv6-Prefix may contain a /128.  This does not
   imply that the NAS should assign an IPv6 address to the end user,
   because RFC 3162 already defines a Framed-IPv6-Identifier attribute
   to handle the Identifier portion.
 
   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
   assigned.  When a /64 or larger prefix is sent, the intent is for the
   NAS to send a routing advertisement containing the information
   present in the Framed-IPv6-Prefix attribute.
 
   The CPE may also require a delegated prefix for its own use, if it is
   decrementing the Hop Limit field of IP headers.  In that case, it
   should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
   attribute [RFC4818].  If the CPE is not decrementing Hop Limit, it
   does not require a delegated prefix."




i'm EMAILING FOR THE GREATER GOOD
Join me
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 	

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


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


Envelope-to: [e-mail]
Delivery-date: Sun, 09 Nov 2008 18:15:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt
Date: Sun, 9 Nov 2008 19:14:12 +0100
Message-ID: <[e-mail]>
Thread-Topic: Review of draft-lourdelet-radext-rfc3162bis-01.txt
Thread-Index: Ack5fBVL23bBlqt8TLKXf8KrzmgRfgDzZXkA
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Benoit Lourdelet (blourdel)" <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; lƒ40; t26254453; x27118453; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Benoit Lourdelet (blourdel)" <blourdel@ cisco.com> |Subject: RE: Review of draft-lourdelet-radext-rf c3162bis-01.txt |Sender: ; bh=lBCT0GTEQbZMN9g4q8WDWl8x8ft5SXRBOCCLDORr8XM=; b=n67yND/IlLrkBYkVZlJ029g8GOisATk9i6bs20oiZmTsYybkPO0CgMmrT2 wvKqeVAkHT8ixRF8dhfJJF/8SBlBnQuO0ADFJ2e8aDhVjIZS5T4xoufVhd0s IwSlN4bzsy;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

Hello,


The DHCP context has been removed on purpose to avoid restricting the
use of the new attributes
 in different context.
IPv6-DNS-Server-Address is a good example as it could be used by DHCPv6
or RA (see RFC5006).
So we certainly should not restrict its use by DHCPv6.

Even IPv6-Address could be used in an autoconfiguration context for
validation of an address included
 in ND messages.

All the above preaches to remove any reference to DHCP as too
restrictive.

A possibility would be to clarify the use of Framed-IPv6-Prefix and
restrict its use to prefix shorter
 or equal to 64.

Regards

Benoit

 

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Bernard Aboba
Sent: Wednesday, October 29, 2008 5:07 AM
To: [e-mail]
Subject: Review of draft-lourdelet-radext-rfc3162bis-01.txt


Review of draft-lourdelet-radext-rfc3162bis-01.txt
 
This document represents the folding of the attributes described in
draft-lourdelet-radext-ipv6-dhcp-00.txt with RFC 3162.  Currently,
the RFC 3162 has been brought over to this document verbatim; 
only Sections 3.7 (defining the IPv6-Address attribute) and 
Section 3.8 (defining the IPv6-DNS-Server-Address attribute)
have changed. 
 
As discussed at IETF 73, several points of confusion have arisen
with respect to RFC 3162, and one of the reasons to produce
an RFC 3162bis would be to clarify those issues.  One of the
issues, whether Framed-IPv6-Prefix could be used with DHCP 
Prefix delegation, was addressed in RFC 4818 (the answer is no). 
 
Another issue relates to whether the Framed-IPv6-Prefix attribute
can be used with a prefix length greater than a /64 (e.g. /128). 
RFC 5080, Section 2.11 discusses this, though strangely it does not 
update RFC 3162.  As noted in this section (see below), while this
usage is feasible, it is not entirely clear what a typical NAS 
would do on receiving a Framed-IPv6-Prefix Attribute with a /128
prefix, since the typical practice is to announce the prefix using
Router Advertisement.  
 
Given this, as well as the approach in RFC 4818, it would appear
that the easiest way to distinguish RFC 3162 from RFC 4818 and
draft-lourdelet-radext-ipv6-dhcp is that each of these documents
addresses a different set of scenarios.  RFC 3162 was largely 
focused on stateless address autoconfiguration (largely focused
on PPP); RFC 4818 is about prefix delegation; 
draft-lourdelet-radext-ipv6-dhcp is about stateful addressing 
and configuration via DHCPv6.  
 
However, in merging draft-lourdelet-radext-ipv6-dhcp with RFC 3162, 
some of the explanatory information has been removed.  This makes
it difficult to understand that the new attributes relate to stateful
address assignment via DHCPv6.  
 
For example, Section 3.7 introduces the IPv6-Address attribute.  
However, only some of the original text from 
draft-lourdelet-radext-ipv6-dhcp-00 is included to explain
the usage of the attribute.  
 
>From the IETF 73 discussion, my understanding is that the purpose 
of this attribute is for the RADIUS server to assign one or more IPv6
addresses 
to a NAS which is acting as a DHCPv6 server, and will subsequently 
assign those addresses to a user acting as a DHCPv6 client.  One
question that arose during IETF 73 was how address assignment
would relate to the authentication process.  
 
For example, draft-lourdelet-radius-ipv6-dhcp includes the following
diagram:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)  RADIUS Server
       |                           |                                |
       |--Solicit(Address)-------->|                                |
       |                           |-----Request------------------->|
       |                           |<---------Accept(IPv6-Address)--|
       |<-Advertise(Address)-------|                                |
       |---Request(Address)------->|                                |
       |<---Reply(Address)---------|                                |

In this diagram, no authentication is present at all, which lead to
considerable discussion (and confusion) at IETF 73.  
 
Similarly, Section 3.8 defines the IPv6-DNS-Server-Address attribute,
which is assigned to a NAS acting as a DHCPv6 server, with the goal 
of providing this DNS server address to the user within the DNS
Recursive
Name Server Option [RFC3646].  This was illustrated in the following
diagram from draft-lourdelet-radius-ipv6-dhcp:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)    RADIUS Server
        |                            |                                |
        |--Solicit (DNS)------------>|                                |
        |                            |-Request----------------------->|
        |                            |<-------Accept(Ipv6-DNS)--------|
        |<-Advertise(DNS)------------|                                |
        |-Request(DNS)-------------->|                                |
        |<--Reply(DNS)---------------|       

Again, some context would be helpful. 
 
Overall, if the goal is to clarify issues from RFC 3162bis as well as
to add new DHCPv6-related attributes, then it seems that additional
work is required such as integration of the clarifications from RFC
5080,
and explanation of the DHCPv6 usage scenarios. 

Text from RFC 5080:

"2.11.  Framed-IPv6-Prefix
 
   [RFC3162] Section 2.3 says:
      This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user.  It MAY be used in Access-Accept
      packets, and can appear multiple times.  It MAY be used in an
      Access-Request packet as a hint by the NAS to the server that it
      would prefer these prefix(es), but the server is not required to
      honor the hint.  Since it is assumed that the NAS will plumb a
      route corresponding to the prefix, it is not necessary for the
      server to also send a Framed-IPv6-Route attribute for the same
      prefix.
 
   An Internet Service Provider (ISP) may desire to support Prefix
   Delegation [RFC4818] 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 Routing Information Protocol Next Generation
   (RIPNG).  RFC 2865 Section 5.10 describes the purpose of Framed-
   Routing:
 
      This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets.
 
   The description of the Prefix-Length field in RFC 3162 indicates
   excessively wide latitude:
 
      The length of the prefix, in bits.  At least 0 and no larger than
      128.
 
   This length appears too broad, because it is not clear what a NAS
   should do with a prefix of greater granularity than /64.  For
   example, the Framed-IPv6-Prefix may contain a /128.  This does not
   imply that the NAS should assign an IPv6 address to the end user,
   because RFC 3162 already defines a Framed-IPv6-Identifier attribute
   to handle the Identifier portion.
 
   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
   assigned.  When a /64 or larger prefix is sent, the intent is for the
   NAS to send a routing advertisement containing the information
   present in the Framed-IPv6-Prefix attribute.
 
   The CPE may also require a delegated prefix for its own use, if it is
   decrementing the Hop Limit field of IP headers.  In that case, it
   should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
   attribute [RFC4818].  If the CPE is not decrementing Hop Limit, it
   does not require a delegated prefix."




i'm EMAILING FOR THE GREATER GOOD
Join me
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 	

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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Nov 2008 07:43:31 +0000
Message-ID: <[e-mail]>
Date: Fri, 07 Nov 2008 08:42:36 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Call for Review: RADIUS over TCP
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

>  This is a call for review of the individual submission "RADIUS over
> TCP".
> The document is available for review here:
> http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
>
> This review will last until November 19, 2008.  Please respond to the
> list as to whether you
> support adoption of this document as a RADEXT WG work item.  If you
> have any issues with
> the document, please email them to the list in the RADEXT WG Issues
> format, described here:
> http://www.drizzle.com/~aboba/RADEXT/

I support adoption.

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Nov 2008 02:11:15 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Greg Weber'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Cmts on ExtAttrs-05
Date: Thu, 6 Nov 2008 18:09:52 -0800
Message-ID: <004201c9407d$ed818d70$c884a850$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclAYtFYvw0DZh39R8yOTBt6k12Q6wAGhRxw
Content-Language: en-us

Greg Weber [mailto:[e-mail]] writes:

...

> A couple editorial comments on the current (-05) extended attributes
> draft:
> 
> Section 5, under More bit description:
>    "exceeds 246 octets" -> "exceeds 245 octets"

Fixed.

> Section 5, under Ext-Len description:
>   ">=3." -> ">=4."

Fixed.

> Figure 3: the second Ext-Type's value:
>   "(0x00" -> "(0x01)"

Fixed.

> Figure 4: I think the very last two octet values swapped.

Fixed.

> Figure 4: The third attribute in this figure violates this earlier
> MUST from section 4:

Yup.  Anybody happen to remember whose idea it was to put that restriction
in place?

>   "If an Extended Attribute contains more than one TLV then all of the
> encapsulated
>   TLVs MUST fit completely within the Extended Attribute."
>   Not sure if this is a problem with the text or the example -or maybe
> just wording.


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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Nov 2008 22:57:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=j9n9Qk6tnLB9qC4W9SbHX5Fja+nOsnodljLY2ZqdGqI=; b=Kg6DAL0DLZDX3CZj/W4qAwvJTehbk7PQsogoP4Nb3XX7COllEIzKVe8xuRKGfwtMiG uJ+im45AvBQ5a8ANEvygTnLwCVwkFGVtxH5ZO2RE5ezlH0bscj01qivOeY4pOE2EHUif spdZrDPt99SzX0vdbc8bwcacXi2Gi77la+ysgDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SJhj/Y+tiOqrRHsVlqxXKK9DV2Uqe14upsId/jSYneiAaXy/46MrdKJY7KcHQ0kVv6 E/I1vbdkLTj5c+/Rt2QC1NWV/LVTBydRajSeyg0W1JevBFE4nuPeUpCfmsnsgilmO2PY XqKbk0G9XhmKm2/WIzsPfM7N1V3z/geU601VwMessage-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 17:57:36 -0500
From: "Greg Weber" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>
Subject: Re: Review Requested: draft-ietf-radext-extended-attributes-05.txt
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think Issue 250 can be closed.

Greg

On Mon, Nov 3, 2008 at 7:06 PM, Bernard Aboba <[e-mail]> wrote:
> Currently the RADEXT WG Issues tracker lists 6 open issues relating to the
> RADIUS Extended Attributes document.  Given that the editor now claims to
> have resolved open Issues from RADEXT WG last call, we are requesting that
> individuals who filed those issues read the current document, and send email
> to the list indicating whether their issue is resolved.
>
> The RADEXT WG Issues list is available here:
> http://www.drizzle.com/~aboba/RADEXT/
>
> The latest version of the Extended Attributes document can be found here:
> http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
>
> The list of previously opened issues is as follows:
>
> Extended Attributes
>
> Issue Number
>
> Status Type Description Owner
> Issue 225 Pending Technical Review Alan DeKok
> Issue 250 Pending Technical Comments Greg Weber
> Issue 251 Pending Technical Review Bernard Aboba
> Issue 272 Pending Technical No overall type in Extended Attributes Glen Zorn
> Issue 278 Pending Technical Comments Alan DeKok
> Issue 279 No Discussion Technical Comments Stefan Winter
>
>
>> From: [e-mail]
>> To: [e-mail]
>> CC: [e-mail]
>> Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt
>> Date: Sun, 2 Nov 2008 17:21:26 -0800
>>
>> All known issues are resolved to my satisfaction but YMMV; complaints to
>> me.
>> ;-)
>
>

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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Nov 2008 22:56:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=JKXhNsG3apRfDm4JvB9UWlcZVHcIsse/nk7j5JsIz1E=; b=iu7tKbknAJEbmq3CLYkxkfXOWm1+LUxuV/6c2VzmOAib7KBkh5H4lFQ1w0Z1HspvZ+ U+QYfCgftWK+LdFdPDigQrYllKUYZa6NcKvgwdfgB5zbWyCvZeT9L9YU+9dN8y7ZU0rG OGG/fblSlnGXN4O5mHa9qntMkVmJuMTPBtyE0DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=x9GZOOD0TLw1fEaX6lMUjWCI9BjpoLsFxdmDhUZQZ4iz+DF6z5wo+KCoD7r3vKJZnB fvvWWuugXTjywAr+PPHsHLNnrKSD769epU1XHQbC1BN/kxGGL+lzi47GYfz+3esCmcQM SGhL11iuuR3JnS1To7kj4Y5AMOKBu4ZtZYHPsMessage-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 17:55:52 -0500
From: "Greg Weber" <[e-mail]>
To: "Glen Zorn" <[e-mail]>, [e-mail]
Subject: Cmts on ExtAttrs-05
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Editorial cmts on ExtAttrs-05
Submitter name: Greg Weber
Submitter email address: [e-mail]
Date first submitted: Nov 6, '08
Reference: none
Document: draft-ietf-radext-extended-attributes-05.txt
Comment type:  'E'ditorial
Priority: 'S' Must fix
Section: various
Rationale/Explanation of issue:

A couple editorial comments on the current (-05) extended attributes draft:

Section 5, under More bit description:
   "exceeds 246 octets" -> "exceeds 245 octets"
Section 5, under Ext-Len description:
  ">=3." -> ">=4."
Figure 3: the second Ext-Type's value:
  "(0x00" -> "(0x01)"
Figure 4: I think the very last two octet values swapped.
Figure 4: The third attribute in this figure violates this earlier
MUST from section 4:
  "If an Extended Attribute contains more than one TLV then all of the
encapsulated
  TLVs MUST fit completely within the Extended Attribute."
  Not sure if this is a problem with the text or the example -or maybe
just wording.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Nov 2008 15:17:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=o/FT53Qv1FSGJa+v8tbOP68iR29NmL2fJaWzZBpVdUk=; b=oyuKrXJ9yPFiSJsuIGsB8R++gbKFK7rej/ICFcAHylt7FyyF0Yth+fqydZcjvQh0kf 9BpOTqCWdy2emiVGRGGATNGMy87Chnucg/gheVnO/MhTl1PjUVBxBbIzKKNfylGEQPB8 E3x5DB0deTTBlsJyZMm+gP8XW6FPfjEuX1x3wDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=p/ggkSO9L3nUeNwysexBxB/C1+5kT9BulyInBHKatjQAxfi6Hs8lrij7o2XEaedCyX Tj/cY7jXet0QbdgWgNllTDOkfa4dgxx2RvcP5z5AWCkoF9binKUMPBza5TrBXLtzdvmf V/FSmQZW0f1tJQ1KCaiIv1W+L4gNzT3YHI89gMessage-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 13:16:32 -0200
From: "Claudio Lapidus" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>
Subject: Re: Call for Review: RADIUS over TCP
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_4974_24215922.1225984592892"

------=_Part_4974_24215922.1225984592892
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I support the adoption of this document as a WG work item.

regards,
cl.


On Tue, Nov 4, 2008 at 10:46 AM, Bernard Aboba <[e-mail]>wrote:

>  This is a call for review of the individual submission "RADIUS over TCP".
> The document is available for review here:
> http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
>
> This review will last until November 19, 2008.  Please respond to the list
> as to whether you
> support adoption of this document as a RADEXT WG work item.  If you have
> any issues with
> the document, please email them to the list in the RADEXT WG Issues format,
> described here:
> http://www.drizzle.com/~aboba/RADEXT/<http://www.drizzle.com/%7Eaboba/RADEXT/>
>
> [image: i'm] EMAILING FOR THE GREATER GOOD
> Join me<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
>

------=_Part_4974_24215922.1225984592892
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I support the adoption of this document as a WG work item.<br><br>regards,<br>cl.<br><br><br><div class="gmail_quote">On Tue, Nov 4, 2008 at 10:46 AM, Bernard Aboba <span dir="ltr">&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div>
This is a call for review of the individual submission &quot;RADIUS over TCP&quot;. <br>The document is available for review here:<br><a href="http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00" target="_blank">http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00</a><br>
<br>This review will last until November 19, 2008.&nbsp; Please respond to the list as to whether you<br>support adoption of this document as a RADEXT WG work item.&nbsp; If you have any issues with<br>the document, please email them to the list in the RADEXT WG Issues format, described here:<br>
<a href="http://www.drizzle.com/%7Eaboba/RADEXT/" target="_blank">http://www.drizzle.com/~aboba/RADEXT/</a><br><br><table style="border-top: 1px solid black; font-weight: bold;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;" target="_blank"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/pr01/ltr/i_charity.gif" alt="i&#39;m"> EMAILING FOR THE GREATER GOOD<br>
<span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></div>
</blockquote></div><br>

------=_Part_4974_24215922.1225984592892--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Nov 2008 14:01:04 +0000
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 15:00:07 +0100
From: Stig Venaas <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20081007)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Call for Review: RADIUS over TCP
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> This is a call for review of the individual submission "RADIUS over TCP".
> The document is available for review here:
> http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
> 
> This review will last until November 19, 2008.  Please respond to the
> list as to whether you
> support adoption of this document as a RADEXT WG work item.  If you have

I support adoption,

Stig

> any issues with
> the document, please email them to the list in the RADEXT WG Issues
> format, described here:
> http://www.drizzle.com/~aboba/RADEXT/
> 
> i'm EMAILING FOR THE GREATER GOOD
> Join me <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
> 


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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 17:01:42 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 12:00:49 -0500
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Stig Venaas <[e-mail]>
CC: Bernard Aboba <[e-mail]>, [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stig Venaas wrote:
> I've found some issues that I just reported in two separate mails.
> Once those are addressed I support progressing the document. FWIW
> I've also implemented it based on this draft, and successfully
> tested with other implementations.

  Those issues are minor, and will be addressed in the next revision.
Thanks for your review.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 14:09:49 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 09:08:50 -0500
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-radext-status-server-02.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> 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		: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol

   This draft contains that changes that were recommended by the WG at 
the last meeting:  Ability to send Status-Server packets to a CoA port.

   Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 12:46:52 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_bf28e224-771d-4c72-9c61-b81d2647ffcc_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Call for Review: RADIUS over TCP
Date: Tue, 4 Nov 2008 04:46:30 -0800
MIME-Version: 1.0

--_bf28e224-771d-4c72-9c61-b81d2647ffcc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a call for review of the individual submission "RADIUS over TCP". 
The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00

This review will last until November 19, 2008.  Please respond to the list as to whether you
support adoption of this document as a RADEXT WG work item.  If you have any issues with
the document, please email them to the list in the RADEXT WG Issues format, described here:
http://www.drizzle.com/~aboba/RADEXT/

 EMAILING FOR THE GREATER GOOD
Join me
--_bf28e224-771d-4c72-9c61-b81d2647ffcc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
This is a call for review of the individual submission "RADIUS over TCP". <br>The document is available for review here:<br>http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<br><br>This review will last until November 19, 2008.&nbsp; Please respond to the list as to whether you<br>support adoption of this document as a RADEXT WG work item.&nbsp; If you have any issues with<br>the document, please email them to the list in the RADEXT WG Issues format, described here:<br>http://www.drizzle.com/~aboba/RADEXT/<br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target="_blank" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/pr01/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_bf28e224-771d-4c72-9c61-b81d2647ffcc_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 12:08:43 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 13:08:18 +0100
From: Stig Venaas <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20081007)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
Cc: [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> This is an announcement of RADEXT WG last call on the document
> "Use of Status-Server Packets in the RADIUS Protocol", prior to sending
> this document on to the IESG for publication as an Informational
> RFC.   The document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-status-server-02__
> <http://tools.ietf.org/html/draft-ietf-radext-status-server-02>
> 
> RADEXT WG last call will complete on November 25, 2008.   Please
> send review comments to the RADEXT WG mailing list
> ([e-mail]) in the format described on the RADEXT
> Issues List (http://www.drizzle.com/~aboba/RADEXT ).   If you
> have no comments, but believe the document should be progressed,
> please also send a note to the list to this effect.

I've found some issues that I just reported in two separate mails.
Once those are addressed I support progressing the document. FWIW
I've also implemented it based on this draft, and successfully
tested with other implementations.

Stig

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 12:05:51 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 13:05:07 +0100
From: Stig Venaas <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20081007)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
Cc: [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Submitter name: Stig Venaas
Submitter email address: [e-mail]
Date first submitted: November 4, 2008
Document: Status Server
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

I've read carefully through draft-ietf-radext-status-server-02 and
found several editorial issues.

In most places (but not all) the draft uses the term "Status-Server
packet" or just "packet". Wouldn't it be better to replace "packet"
with "message"? Especially since it's not limited to UDP transport.

"it's" should be replaced with "its" throughout (genitive).

TOC formatting is slightly broken (2.3.1/2.3.2).

Section 2.3.2 has no title (missing both in TOC and body).

In 2.2:

   A similar solution for the problem of querying server status may be
   for a NAS to send specially formed Accounting-Request packets to a
   RADIUS servers authentication port.  The NAS can then look for a
          ^^^^^^^^^^^^^^^^^^^^^^
 server's accounting

In 3:

   Note that when a server responds to a Status-Server request, it MUST
   NOTE send more than one response packet.
s/NOTE/NOT/

In 4.2:

   The server MAY prioritize the handling Status-Server queries over the

Insert "of"                            ^^^^^

   The server MAY decide to not respond to a Status-Server, depending on
Insert "packet" or "message"                        ^^^^^^^

In 4.3:
   unresponsive, this change would enable the NAS to start packets to
                                                    ^^^^^^^^^^^^^^^^^^
   start sending packets to that RADIUS server again.  The NAS MAY
Remove " start packets to".


In 4.6:
   In the worst case, failures in routing for Realm A may affect users
   Realm B.  For example, if Proxy Server P can reach Realm B but not
 ^^^^^
Insert "of"

   In this situation, if all participants impement Status-Server as
s/impement/implement/                    ^^^^^^^^^^

In 6:
   The following table provide a guide to which attributes may be found
s/provide/provides/   ^^^^^^^^^

Stig

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 10:50:17 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 11:49:08 +0100
From: Stig Venaas <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20081007)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
Cc: [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Submitter name: Stig Venaas
Submitter email address: [e-mail]
Date first submitted: November 4, 2008
Document: Status Server
Comment type: T
Priority: 1
Section: 2.3.2
Rationale/Explanation of issue:

I think clients should allow Access-Accept responses to status-server
messages sent to the accounting port. Even if it's not the expected
message, it shows that the server is alive.

Also, towards the end of section 4.2 the draft says:

   Some server implementations accept both Access-Request and
   Accounting-Request packets on the same port, and do not distinguish
   between "authentication only" ports, and "accounting only" ports.
   Those implementations SHOULD reply to Status-Server packets with an
   Access-Accept packet.

Due to this, I think the text in 2.3.2 is too strict:

   The Status-Server packet MUST contain a Message-Authenticator
   attribute for security.  The response (if any) to a Status-Server
   packet sent to an accounting port MUST be an Accounting-Response
   packet.  The list of attributes that are permitted in the Accounting-
   Response packet is given in the Table of Attributes in Section 6,
   below.

I think the second MUST should be a SHOULD. Or at the very least, in
section 4.1 where it talks about clients being liberal at what they
accept. Add a note that they SHOULD accept this.

Stig

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 07:21:04 +0000
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 08:20:24 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Bernard Aboba' <[e-mail]>, [e-mail]
Subject: Re: Review Requested: draft-ietf-radext-extended-attributes-05.txt
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi,

> Just for the record, I made no such claim: I stated that the issues
> were resolved to my satisfaction.  Certain elements of one of the
> issues I disputed, but since the owner thereof hasn't bothered to
> respond to my comments in over a month, I unilaterally marked it as
> resolved.  It is possible (likely?) that the owner will now respond,
> helping to delay publication further (inadvertently, no doubt).
>

I hope you weren't thinking of me. Going through my list of comments,
the majority of items has been taken care of, with some exceptions.
Breakdown below:

- TLV encoding and M flag: not resolved. Discussion on the list resolved
in that we should make sure also morons are forced to split attributes
correctly (choice of words property of the original commenter). Proposed
text from Alan DeKok was: "The More Flag MUST NOT be set if the Length
is less than 255." I suggest to include that line.

- TLV encoding rules: not resolved. I suggest adding two words to the
sentence in question: "The next octet is the Ext-Len field, representing
the length of the entire TLV *in octets*, including ..."

- figure 3: resolved

- figure 4, other encodings possible: not resolved. I suggest adding
"Note that this encoding is only one out of several possibilities since
there is no strict order in attribute marshalling."

- figure 4, diagram: mostly resolved, one thing missed: Integer c of
value 0x12345678 is still depicted in the Value field as 0x12 0x34 0x78
0x56 (twist in the last two segments)

- nitbit in intro: resolved

- nitbit in first example: resolved

- security considerations: resolved

***
New issues with this -05 draft:
***

- figure 3: Ext-Type (cont) is listed as "(0x00" while it is actually
"(0x01)".


Greetings,

Stefan Winter
>
> we are requesting that individuals who filed those issues read the
> current document, and send email to the list indicating whether their
> issue is resolved.
>
> I apparently "own" Issue 272 although it was you, I believe, who
> brought it up initially.  I withdraw it, since it's become quite
> apparent that it's not really a problem at all (except, perhaps, for
> those poor souls who actually try to _use_ Extended Attributes).  Oh,
> well…
>
>
>  
> The RADEXT WG Issues list is available here:
> http://www.drizzle.com/~aboba/RADEXT/
> <http://www.drizzle.com/%7Eaboba/RADEXT/>
>  
> The latest version of the Extended Attributes document can be found here:
> http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
>  
> The list of previously opened issues is as follows:
>  
>
> *Extended Attributes*
>
> *Issue Number*
>
> 	
>
> *Status*
>
> 	
>
> *Type*
>
> 	
>
> *Description*
>
> 	
>
> *Owner*
>
> Issue 225
>
> 	
>
> Pending
>
> 	
>
> Technical
>
> 	
>
> Review
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20225>
>
> 	
>
> Alan DeKok <mailto:[e-mail]>
>
> Issue 250
>
> 	
>
> Pending
>
> 	
>
> Technical
>
> 	
>
> Comments
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20250>
>
> 	
>
> Greg Weber <mailto:[e-mail]>
>
> Issue 251
>
> 	
>
> Pending
>
> 	
>
> Technical
>
> 	
>
> Review
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20251>
>
> 	
>
> Bernard Aboba <mailto:[e-mail]>
>
> Issue 272
>
> 	
>
> Pending
>
> 	
>
> Technical
>
> 	
>
> No overall type in Extended Attributes
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20272>
>
> 	
>
> Glen Zorn <mailto:[e-mail]>
>
> Issue 278
>
> 	
>
> Pending
>
> 	
>
> Technical
>
> 	
>
> Comments
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20278>
>
> 	
>
> Alan DeKok <mailto:[e-mail]>
>
> Issue 279
>
> 	
>
> No Discussion
>
> 	
>
> Technical
>
> 	
>
> Comments
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20279>
>
> 	
>
> Stefan Winter <mailto:[e-mail]>
>
>  
>  
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> > Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt
> > Date: Sun, 2 Nov 2008 17:21:26 -0800
> >
> > All known issues are resolved to my satisfaction but YMMV; complaints
> to me.
> > ;-)
>


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 05:42:51 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Review Requested: draft-ietf-radext-extended-attributes-05.txt
Date: Mon, 3 Nov 2008 21:42:03 -0800
Message-ID: <011a01c93e40$118afc00$34a0f400$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01C93DFD.0367BC00"
Thread-Index: Ack+OWoMmUg3MpwLRNWUlLFAD/gymQABnHOA
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_011B_01C93DFD.0367BC00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Bernard Aboba
Sent: Monday, November 03, 2008 8:51 PM
To: Glen Zorn
Cc: [e-mail]
Subject: RE: Review Requested: draft-ietf-radext-extended-attributes-05.txt

 

Glen Zorn said:

"I apparently "own" Issue 272 although it was you, I believe, who brought it
up initially."
 
Here is a link to your original post on the subject:
http://ops.ietf.org/lists/radiusext/2008/msg00458.html

Since you raised it, it was assigned to you. 

I withdraw it, since it's become quite apparent that it's not really a
problem at all (except, perhaps, for those poor souls who actually try to
_use_ Extended Attributes).  Oh, well.

Unless anyone raises an objection on the list, I'll mark Issue 272 as
resolved. 

Abandoned might be a better term.

"It is possible (likely?) that the owner will now respond, helping to delay
publication further (inadvertently, no doubt)."

Given the document's relatively modest size (13 pages) and scope,  if you
can turn the remaining feedback around quickly, my expectation would be that
it will take at most one more WG last call before the document is ready to
go to IESG.   As a result, most of the remaining "delays" in publication are
likely to come from the IESG, not from the WG. 


------=_NextPart_000_011B_01C93DFD.0367BC00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Bernard Aboba<br>
<b>Sent:</b> Monday, November 03, 2008 8:51 PM<br>
<b>To:</b> Glen Zorn<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> RE: Review Requested:
draft-ietf-radext-extended-attributes-05.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Glen
Zorn said:<br>
<br>
</span><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>&quot;I apparently &quot;own&quot; Issue 272 although it was
you, I believe, who brought it up initially.&quot;<br>
&nbsp;<br>
</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Here is
a link to your original post on the subject:<br>
http://ops.ietf.org/lists/radiusext/2008/msg00458.html<br>
</span><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'><br>
</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Since
you raised it, it was assigned to you. <br>
<br>
</span><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>I withdraw it, since it's become quite apparent that it's not
really a problem at all (except, perhaps, for those poor souls who actually try
to _use_ Extended Attributes).&nbsp; Oh, well&#8230;</span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
<br>
Unless anyone raises an objection on the list, I'll mark Issue 272 as resolved.
<span style='color:#1F497D'><o:p></o:p></span></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#FFC000'>Abandoned might be a better term&#8230;</span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
<br>
&quot;</span><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>It is possible (likely?) that the owner will now respond,
helping to delay publication further (inadvertently, no doubt).</span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&quot;<br>
<br>
Given the document's relatively modest size (13 pages) and scope,&nbsp; if you
can turn the remaining feedback around quickly, my expectation would be that it
will take at most one more WG last call before the document is ready to go to
IESG.&nbsp;&nbsp; As a result, most of the remaining &quot;delays&quot; in
publication are likely to come from the IESG, not from the WG. <o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_011B_01C93DFD.0367BC00--



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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 04:51:33 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_14b74d99-f032-449d-a1c9-5fc3ebe4dfee_"
From: Bernard Aboba <[e-mail]>
To: Glen Zorn <[e-mail]>
CC: <[e-mail]>
Subject: RE: Review Requested: draft-ietf-radext-extended-attributes-05.txt
Date: Mon, 3 Nov 2008 20:50:40 -0800
MIME-Version: 1.0

--_14b74d99-f032-449d-a1c9-5fc3ebe4dfee_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Glen Zorn said:

"I apparently "own" Issue 272 although it was you, I
believe, who brought it up initially."
 
Here is a link to your original post on the subject:
http://ops.ietf.org/lists/radiusext/2008/msg00458.html

Since you raised it, it was assigned to you. 

I withdraw it, since it's become
quite apparent that it's not really a problem at all (except, perhaps, for
those poor souls who actually try to _use_ Extended Attributes).  Oh, well…



Unless anyone raises an objection on the list, I'll mark Issue 272 as resolved. 

"It is
possible (likely?) that the owner will now respond, helping to delay
publication further (inadvertently, no doubt)."

Given the document's relatively modest size (13 pages) and scope,  if you can turn the remaining feedback around quickly, my expectation would be that it will take at most one more WG last call before the document is ready to go to IESG.   As a result, most of the remaining "delays" in publication are likely to come from the IESG, not from the WG. 

--_14b74d99-f032-449d-a1c9-5fc3ebe4dfee_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Glen Zorn said:<br><br><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);">"I apparently "own" Issue 272 although it was you, I
believe, who brought it up initially."<br>&nbsp;<br></span>Here is a link to your original post on the subject:<br>http://ops.ietf.org/lists/radiusext/2008/msg00458.html<br><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);"><br></span>Since you raised it, it was assigned to you. <br><br><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);">I withdraw it, since it's become
quite apparent that it's not really a problem at all </span><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);">(except, perhaps, for
those poor souls who actually try to _use_ Extended Attributes).&nbsp; Oh, well…</span><br>

<br><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);"></span>Unless anyone raises an objection on the list, I'll mark Issue 272 as resolved. <br><span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);"></span><br>"<span style="font-size: 11pt; font-family: 'Arial Black','sans-serif'; color: rgb(112, 48, 160);">It is
possible (likely?) that the owner will now respond, helping to delay
publication further (inadvertently, no doubt).</span>"<br><br>Given the document's relatively modest size (13 pages) and scope,&nbsp; if you can turn the remaining feedback around quickly, my expectation would be that it will take at most one more WG last call before the document is ready to go to IESG.&nbsp;&nbsp; As a result, most of the remaining "delays" in publication are likely to come from the IESG, not from the WG. <br></body>
</html>
--_14b74d99-f032-449d-a1c9-5fc3ebe4dfee_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 01:22:17 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Review Requested: draft-ietf-radext-extended-attributes-05.txt
Date: Mon, 3 Nov 2008 17:19:34 -0800
Message-ID: <00fc01c93e1b$6612ff90$3238feb0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01C93DD8.57EFBF90"
Thread-Index: Ack+EarwD4M04wYsRWeyohP3stZ4RQACA4dQ
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_00FD_01C93DD8.57EFBF90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Currently the RADEXT WG Issues tracker lists 6 open issues relating to the
RADIUS Extended Attributes document.  Given that the editor now claims to
have resolved open Issues from RADEXT WG last call, 

Just for the record, I made no such claim: I stated that the issues were
resolved to my satisfaction.  Certain elements of one of the issues I
disputed, but since the owner thereof hasn't bothered to respond to my
comments in over a month, I unilaterally marked it as resolved.  It is
possible (likely?) that the owner will now respond, helping to delay
publication further (inadvertently, no doubt).

we are requesting that individuals who filed those issues read the current
document, and send email to the list indicating whether their issue is
resolved. 

I apparently "own" Issue 272 although it was you, I believe, who brought it
up initially.  I withdraw it, since it's become quite apparent that it's not
really a problem at all (except, perhaps, for those poor souls who actually
try to _use_ Extended Attributes).  Oh, well.


 
The RADEXT WG Issues list is available here:
http://www.drizzle.com/~aboba/RADEXT/
 
The latest version of the Extended Attributes document can be found here:
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
 
The list of previously opened issues is as follows:
 


Extended Attributes 

Issue Number

Status

Type

Description

Owner


Issue 225

Pending

Technical

 <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 225> Review

 <mailto:[e-mail]> Alan DeKok


Issue 250

Pending

Technical

 <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 250> Comments

 <mailto:[e-mail]> Greg Weber


Issue 251

Pending

Technical

 <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 251> Review

 <mailto:[e-mail]> Bernard Aboba


Issue 272

Pending

Technical

 <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 272> No overall
type in Extended Attributes

 <mailto:[e-mail]> Glen Zorn


Issue 278

Pending

Technical

 <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 278> Comments

 <mailto:[e-mail]> Alan DeKok


Issue 279

No Discussion

Technical

 <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 279> Comments

 <mailto:[e-mail]> Stefan Winter

 
 
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt 
> Date: Sun, 2 Nov 2008 17:21:26 -0800
> 
> All known issues are resolved to my satisfaction but YMMV; complaints to
me.
> ;-)


------=_NextPart_000_00FD_01C93DD8.57EFBF90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=Section1>

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

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Currently
the RADEXT WG Issues tracker lists 6 open issues relating to the RADIUS
Extended Attributes document.&nbsp; Given that the editor now claims to have
resolved open Issues from RADEXT WG last call, <span style='color:#1F497D'><o:p></o:p></span></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>Just for the record, I made no such claim: I stated that the
issues were resolved to my satisfaction.&nbsp; Certain elements of one of the
issues I disputed, but since the owner thereof hasn't bothered to respond to my
comments in over a month, I unilaterally marked it as resolved.&nbsp; It is
possible (likely?) that the owner will now respond, helping to delay
publication further (inadvertently, no doubt).<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>we
are requesting that individuals who filed those issues read the current
document, and send email to the list indicating whether their issue is
resolved. <span style='color:#1F497D'><o:p></o:p></span></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>I apparently &quot;own&quot; Issue 272 although it was you, I
believe, who brought it up initially.&nbsp; I withdraw it, since it's become
quite apparent that it's not really a problem at all (except, perhaps, for
those poor souls who actually try to _use_ Extended Attributes).&nbsp; Oh, well&#8230;<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
&nbsp;<br>
The RADEXT WG Issues list is available here:<br>
<a href="http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~aboba/RADEXT/</a><br>
&nbsp;<br>
The latest version of the Extended Attributes document can be found here:<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05</a><br>
&nbsp;<br>
The list of previously opened issues is as follows:<br>
&nbsp;<o:p></o:p></span></p>

<table class=MsoNormalTable border=1 cellpadding=0 width=761 style='width:570.75pt'
 id=table62>
 <tr style='height:25.5pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:25.5pt'>
  <p class=MsoNormal><strong><span style='font-size:13.5pt'>Extended Attributes</span></strong>
  <o:p></o:p></p>
  <p class=MsoNormal><b><span style='font-size:13.5pt'>Issue Number</span></b><o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:25.5pt'>
  <p class=MsoNormal><b><span style='font-size:13.5pt'>Status</span></b><o:p></o:p></p>
  </td>
  <td width=84 style='width:63.0pt;padding:.75pt .75pt .75pt .75pt;height:25.5pt'>
  <p class=MsoNormal><b><span style='font-size:13.5pt'>Type</span></b><o:p></o:p></p>
  </td>
  <td width=272 style='width:204.0pt;padding:.75pt .75pt .75pt .75pt;
  height:25.5pt'>
  <p class=MsoNormal><b><span style='font-size:13.5pt'>Description</span></b><o:p></o:p></p>
  </td>
  <td width=112 style='width:84.0pt;padding:.75pt .75pt .75pt .75pt;height:
  25.5pt'>
  <p class=MsoNormal><b><span style='font-size:13.5pt'>Owner</span></b><o:p></o:p></p>
  </td>
 </tr>
 <tr style='height:38.25pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Issue 225<o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Pending<o:p></o:p></p>
  </td>
  <td width=73 style='width:54.75pt;padding:.75pt .75pt .75pt .75pt;height:
  38.25pt'>
  <p class=MsoNormal>Technical<o:p></o:p></p>
  </td>
  <td width=277 style='width:207.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a
  href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 225"><span
  style='color:#0066CC'>Review</span></a><o:p></o:p></p>
  </td>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a href="mailto:[e-mail]"><span
  style='color:#0066CC'>Alan DeKok</span></a><o:p></o:p></p>
  </td>
 </tr>
 <tr style='height:45.0pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:45.0pt'>
  <p class=MsoNormal>Issue 250<o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:45.0pt'>
  <p class=MsoNormal>Pending<o:p></o:p></p>
  </td>
  <td width=84 style='width:63.0pt;padding:.75pt .75pt .75pt .75pt;height:45.0pt'>
  <p class=MsoNormal>Technical<o:p></o:p></p>
  </td>
  <td width=272 style='width:204.0pt;padding:.75pt .75pt .75pt .75pt;
  height:45.0pt'>
  <p class=MsoNormal><a
  href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 250"><span
  style='color:#0066CC'>Comments</span></a><o:p></o:p></p>
  </td>
  <td width=112 style='width:84.0pt;padding:.75pt .75pt .75pt .75pt;height:
  45.0pt'>
  <p class=MsoNormal><a href="mailto:[e-mail]"><span style='color:
  #0066CC'>Greg Weber</span></a><o:p></o:p></p>
  </td>
 </tr>
 <tr style='height:46.5pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:46.5pt'>
  <p class=MsoNormal>Issue 251<o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:46.5pt'>
  <p class=MsoNormal>Pending<o:p></o:p></p>
  </td>
  <td width=84 style='width:63.0pt;padding:.75pt .75pt .75pt .75pt;height:46.5pt'>
  <p class=MsoNormal>Technical<o:p></o:p></p>
  </td>
  <td width=272 style='width:204.0pt;padding:.75pt .75pt .75pt .75pt;
  height:46.5pt'>
  <p class=MsoNormal><a
  href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 251"><span
  style='color:#0066CC'>Review</span></a><o:p></o:p></p>
  </td>
  <td width=112 style='width:84.0pt;padding:.75pt .75pt .75pt .75pt;height:
  46.5pt'>
  <p class=MsoNormal><a href="mailto:[e-mail]"><span
  style='color:#0066CC'>Bernard Aboba</span></a><o:p></o:p></p>
  </td>
 </tr>
 <tr style='height:38.25pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Issue 272<o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Pending<o:p></o:p></p>
  </td>
  <td width=73 style='width:54.75pt;padding:.75pt .75pt .75pt .75pt;height:
  38.25pt'>
  <p class=MsoNormal>Technical<o:p></o:p></p>
  </td>
  <td width=277 style='width:207.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a
  href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 272"><span
  style='color:purple'>No overall type in Extended Attributes</span></a><o:p></o:p></p>
  </td>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a href="mailto:[e-mail]"><span
  style='color:#0066CC'>Glen Zorn</span></a><o:p></o:p></p>
  </td>
 </tr>
 <tr style='height:38.25pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Issue 278<o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Pending<o:p></o:p></p>
  </td>
  <td width=73 style='width:54.75pt;padding:.75pt .75pt .75pt .75pt;height:
  38.25pt'>
  <p class=MsoNormal>Technical<o:p></o:p></p>
  </td>
  <td width=277 style='width:207.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a
  href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 278"><span
  style='color:#0066CC'>Comments</span></a><o:p></o:p></p>
  </td>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a href="mailto:[e-mail]"><span
  style='color:#0066CC'>Alan DeKok</span></a><o:p></o:p></p>
  </td>
 </tr>
 <tr style='height:38.25pt'>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>Issue 279<o:p></o:p></p>
  </td>
  <td width=146 style='width:109.5pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal>No Discussion<o:p></o:p></p>
  </td>
  <td width=73 style='width:54.75pt;padding:.75pt .75pt .75pt .75pt;height:
  38.25pt'>
  <p class=MsoNormal>Technical<o:p></o:p></p>
  </td>
  <td width=277 style='width:207.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a
  href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 279"><span
  style='color:purple'>Comments</span></a><o:p></o:p></p>
  </td>
  <td width=117 style='width:87.75pt;padding:.75pt .75pt .75pt .75pt;
  height:38.25pt'>
  <p class=MsoNormal><a href="mailto:[e-mail]"><span
  style='color:#0066CC'>Stefan Winter</span></a><o:p></o:p></p>
  </td>
 </tr>
</table>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>&nbsp;<br>
&nbsp;<br>
&gt; From: [e-mail]<br>
&gt; To: [e-mail]<br>
&gt; CC: [e-mail]<br>
&gt; Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt <br>
&gt; Date: Sun, 2 Nov 2008 17:21:26 -0800<br>
&gt; <br>
&gt; All known issues are resolved to my satisfaction but YMMV; complaints to
me.<br>
&gt; ;-)<o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_00FD_01C93DD8.57EFBF90--



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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 01:12:53 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_43bde25b-9ff4-4365-b255-e4c550994455_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Call for Presentations
Date: Mon, 3 Nov 2008 17:12:09 -0800
MIME-Version: 1.0

--_43bde25b-9ff4-4365-b255-e4c550994455_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a call for presentations for the IETF 73 meeting of the RADEXT WG.  
 
If you currently have time on the agenda, please send your presentations to Dave Nelson and myself ASAP. 



 EMAILING FOR THE GREATER GOODJoin me
--_43bde25b-9ff4-4365-b255-e4c550994455_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
This is a call for presentations for the IETF 73 meeting of the RADEXT WG.&nbsp; <BR>
&nbsp;<BR>
If you currently have time on the agenda, please send your presentations to Dave Nelson and myself ASAP. <BR><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target=_blank><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/pr01/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_43bde25b-9ff4-4365-b255-e4c550994455_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 00:26:18 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_523ce502-b564-4371-a0ab-2c7912eaea00_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Agenda at IETF 73 - Take Five
Date: Mon, 3 Nov 2008 16:25:50 -0800
MIME-Version: 1.0

--_523ce502-b564-4371-a0ab-2c7912eaea00_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. Currently the Agenda is as follows: 9 AM - 9:10 Preliminaries (10 minutes)   Blue Sheets   Note Takers   Jabber Scribe   Agenda bashing   Document Status Documents completing IETF Last Call (20 minutes) 9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10 minutes)http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06 9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)http://tools.ietf.org/html/draft-ietf-radext-design-05 Documents completing RADEXT WG Last Call (40 minutes)
 
9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)http://tools.ietf.org/html/draft-ietf-radext-status-server-02 9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)http://tools.ietf.org/html/draft-ietf-radext-radsec-02
 
9:50 AM - 10:00 AM Extended RADIUS Attributes, TBD (10 minutes)http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
 
10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02  Pre-Working Group Work Item Review (30 minutes) 10:10 AM - 10:20 AM TCP Transport, Alan DeKok (10 minutes)http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
10:20 AM - 10:25 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02 10:25 AM - 10:30 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)http://tools.ietf.org/html/draft-aboba-radext-wlan-09 10:30 AM - 10:40 AM , Transmitting Confidential Data in RADIUS, Joe Salowey (10 minutes)http://tools.ietf.org/html/draft-zorn-radius-encattr-15Internationalization (20 minutes) 10:40 AM - 10:50 AM i8n Issues with RFC 4282, Alan DeKok (10 minutes)http://tools.ietf.org/html/rfc428210:50 AM - 11:00 AM Discussion
IPv6 (20 minutes)11:00 AM - 11:10 AM  Prefix Authorization, Behcet Sarikaya (10 minutes)http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-0111:10 AM - 11:20 AM  DHCPv6 Attributes, Benoit Lourdelet (10 minutes)http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02Summary & Wrapup11:20 AM - 11:30 AM, Chairs 



 EMAILING FOR THE GREATER GOODJoin me
--_523ce502-b564-4371-a0ab-2c7912eaea00_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. <BR>Currently the Agenda is as follows:<BR>&nbsp;<BR>9 AM - 9:10 Preliminaries (10 minutes)<BR>&nbsp;&nbsp; Blue Sheets<BR>&nbsp;&nbsp; Note Takers<BR>&nbsp;&nbsp; Jabber Scribe<BR>&nbsp;&nbsp; Agenda bashing<BR>&nbsp;&nbsp; Document Status<BR>&nbsp;<BR>Documents completing IETF Last Call (20 minutes)<BR>&nbsp;<BR>9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06" target=_blank rel=nofollow><U><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</FONT></U></A><BR>&nbsp;<BR>9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-design-05" target=_blank rel=nofollow><U><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-design-05</FONT></U></A><BR>&nbsp;<BR>Documents completing RADEXT WG Last Call (40 minutes)<BR>
&nbsp;<BR>
9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target=_blank rel=nofollow><U><FONT color=#800080>http://tools.ietf.org/html/draft-ietf-radext-status-server-02</FONT></U></A><BR>&nbsp;<BR>9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" target=_blank rel=nofollow><U><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-radsec-02</FONT></U></A><BR>
&nbsp;<BR>
9:50 AM -&nbsp;10:00 AM Extended RADIUS Attributes, TBD (10 minutes)<BR><FONT color=#444444><A href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05</A></FONT><BR>
&nbsp;<BR>
10:00&nbsp;AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02" target=_blank rel=nofollow><U><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</FONT></U></A><BR>&nbsp;&nbsp;<BR>Pre-Working Group Work Item Review (30 minutes)<BR>&nbsp;<BR>10:10 AM - 10:20 AM TCP Transport, Alan DeKok (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00">http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00</A><BR><BR>
10:20 AM - 10:25 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)<BR><A href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target=_blank rel=nofollow><U><FONT color=#0066cc>http://tools.ietf.org/html/</FONT></U></A><A href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target=_blank rel=nofollow><U><FONT color=#0066cc>draft-tiwari-radext-tunnel-type-02</FONT></U></A><BR>&nbsp;<BR>10:25 AM - 10:30 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)<BR>http://tools.ietf.org/html/draft-aboba-radext-wlan-09<BR>&nbsp;<BR>10:30 AM - 10:40 AM , Transmitting Confidential Data in RADIUS, Joe Salowey (10 minutes)<BR><A href="http://tools.ietf.org/html/draft-zorn-radius-encattr-15">http://tools.ietf.org/html/draft-zorn-radius-encattr-15</A><BR><BR>Internationalization (20 minutes)<BR>&nbsp;<BR>10:40 AM - 10:50 AM i8n Issues with RFC 4282, Alan DeKok (10 minutes)<BR><A href="http://tools.ietf.org/html/rfc4282" target=_blank rel=nofollow><U><FONT color=#0066cc>http://tools.ietf.org/html/rfc4282</FONT></U></A><BR><BR>10:50 AM - 11:00 AM Discussion<BR>
<BR>IPv6 (20 minutes)<BR><BR>11:00 AM - 11:10 AM&nbsp; Prefix Authorization, Behcet Sarikaya (10 minutes)<BR>http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-01<BR><BR>11:10 AM - 11:20 AM&nbsp; DHCPv6 Attributes, Benoit Lourdelet (10 minutes)<BR>http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02<BR><BR>Summary &amp; Wrapup<BR><BR>11:20 AM - 11:30 AM, Chairs <BR><BR><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target=_blank><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/pr01/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_523ce502-b564-4371-a0ab-2c7912eaea00_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 00:11:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_e7e1610d-5647-413d-94fc-f25fc30c686f_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Last Call on Status-Server Document
Date: Mon, 3 Nov 2008 16:10:56 -0800
MIME-Version: 1.0

--_e7e1610d-5647-413d-94fc-f25fc30c686f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






This is an announcement of RADEXT WG last call on the document"Use of Status-Server Packets in the RADIUS Protocol", prior to sendingthis document on to the IESG for publication as an Informational 
RFC.   The document is available for inspection here:http://tools.ietf.org/html/draft-ietf-radext-status-server-02RADEXT WG last call will complete on November 25, 2008.   Pleasesend review comments to the RADEXT WG mailing list([e-mail]) in the format described on the RADEXTIssues List (http://www.drizzle.com/~aboba/RADEXT ).   If youhave no comments, but believe the document should be progressed,please also send a note to the list to this effect. 



 EMAILING FOR THE GREATER GOODJoin me
--_e7e1610d-5647-413d-94fc-f25fc30c686f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
<TABLE width="100%">
<TBODY>
<TR>
<TD>
This is an announcement of RADEXT WG last call on the document<BR>"Use of Status-Server Packets in the RADIUS Protocol", prior to sending<BR>this document on to the IESG for publication as an Informational <BR>
RFC. &nbsp; The document is available for inspection here:<BR><A href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</A><A href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02"><U><FONT color=#800080></A></FONT></U><BR><BR>RADEXT WG last call will complete on November 25, 2008.&nbsp;&nbsp; Please<BR>send review comments to the RADEXT WG mailing list<BR>([e-mail]) in the format described on the RADEXT<BR>Issues List (http://www.drizzle.com/~aboba/RADEXT ).&nbsp;&nbsp; If you<BR>have no comments, but believe the document should be progressed,<BR>please also send a note to the list to this effect. <BR></TD></TR></TBODY></TABLE><BR><BR>
<TABLE style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
<TBODY>
<TR>
<TD><A style="FONT-SIZE: 9pt; COLOR: #0184cb; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target=_blank><IMG style="BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/pr01/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<BR><SPAN style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: #3fb555; PADDING-TOP: 0px; TEXT-DECORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_e7e1610d-5647-413d-94fc-f25fc30c686f_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 04 Nov 2008 00:07:21 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_8c0db615-245f-478d-8546-b2ca9622d9f8_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Review Requested: draft-ietf-radext-extended-attributes-05.txt
Date: Mon, 3 Nov 2008 16:06:11 -0800
MIME-Version: 1.0

--_8c0db615-245f-478d-8546-b2ca9622d9f8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Currently the RADEXT WG Issues tracker lists 6 open issues relating to the RADIUS Extended Attributes document.  Given that the editor now claims to have resolved open Issues from RADEXT WG last call, we are requesting that individuals who filed those issues read the current document, and send email to the list indicating whether their issue is resolved. 
 
The RADEXT WG Issues list is available here:
http://www.drizzle.com/~aboba/RADEXT/
 
The latest version of the Extended Attributes document can be found here:
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05
 
The list of previously opened issues is as follows:
 




Extended Attributes 
Issue Number
Status
Type
Description
Owner

Issue 225
Pending
Technical
Review
Alan DeKok

Issue 250
Pending
Technical
Comments
Greg Weber

Issue 251
Pending
Technical
Review
Bernard Aboba

Issue 272
Pending
Technical
No overall type in Extended Attributes
Glen Zorn

Issue 278
Pending
Technical
Comments
Alan DeKok

Issue 279
No Discussion
Technical
Comments
Stefan Winter
 
 
> From: [e-mail]> To: [e-mail]> CC: [e-mail]> Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt > Date: Sun, 2 Nov 2008 17:21:26 -0800> > All known issues are resolved to my satisfaction but YMMV; complaints to me.> ;-)
--_8c0db615-245f-478d-8546-b2ca9622d9f8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Currently the RADEXT WG Issues tracker lists 6 open issues relating to the RADIUS Extended Attributes document.&nbsp; Given that the editor now claims to have resolved open Issues from RADEXT WG last call, we are requesting that individuals who filed those issues read the current document, and send email to the list indicating whether their issue is resolved. <BR>
&nbsp;<BR>
The RADEXT WG Issues list is available here:<BR>
<A href="http://www.drizzle.com/~aboba/RADEXT/">http://www.drizzle.com/~aboba/RADEXT/</A><BR>
&nbsp;<BR>
The latest version of the Extended Attributes document can be found here:<BR>
<A href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05</A><BR>
&nbsp;<BR>
The list of previously opened issues is as follows:<BR>
&nbsp;<BR>

<TABLE id=table62 height=1 width=761 border=1>
<TBODY>
<TR>
<TD width=117 height=34><FONT size=4><STRONG>Extended Attributes</STRONG></FONT> 
<P><B><FONT size=4>Issue Number</FONT></B><BR></TD>
<TD width=146 height=34><B><FONT size=4>Status</FONT></B></TD>
<TD width=84 height=34><FONT size=4><B>Type</B></FONT></TD>
<TD width=272 height=34><B><FONT size=4>Description</FONT></B></TD>
<TD width=112 height=34><B><FONT size=4>Owner</FONT></B></TD></TR>
<TR>
<TD width=117 height=62>Issue 225</TD>
<TD width=146 height=34>Pending</TD>
<TD width=73 height=62>Technical</TD>
<TD width=277 height=62><A href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 225"><FONT color=#0066cc><U>Review</U></FONT></A></TD>
<TD width=117 height=51><A href="mailto:[e-mail]"><U><FONT color=#0066cc>Alan DeKok</FONT></U></A></TD></TR>
<TR>
<TD style="HEIGHT: 60px" width=117>Issue 250</TD>
<TD style="HEIGHT: 60px" width=146>Pending</TD>
<TD style="HEIGHT: 60px" width=84>Technical</TD>
<TD style="HEIGHT: 60px" width=272><A href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 250"><FONT color=#0066cc><U>Comments</U></FONT></A></TD>
<TD style="HEIGHT: 60px" width=112><A href="mailto:[e-mail]"><U><FONT color=#0066cc>Greg Weber</FONT></U></A></TD></TR>
<TR>
<TD style="HEIGHT: 62px" width=117>Issue 251</TD>
<TD style="HEIGHT: 62px" width=146>Pending</TD>
<TD style="HEIGHT: 62px" width=84>Technical</TD>
<TD style="HEIGHT: 62px" width=272><A href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 251"><FONT color=#0066cc><U>Review</U></FONT></A></TD>
<TD style="HEIGHT: 62px" width=112><A href="mailto:[e-mail]"><U><FONT color=#0066cc>Bernard Aboba</FONT></U></A></TD></TR>
<TR>
<TD width=117 height=62>Issue 272</TD>
<TD width=146 height=34>Pending</TD>
<TD width=73 height=62>Technical</TD>
<TD width=277 height=62><A href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 272"><FONT color=#800080><U>No overall type in Extended Attributes</U></FONT></A></TD>
<TD width=117 height=51><A href="mailto:[e-mail]"><U><FONT color=#0066cc>Glen Zorn</FONT></U></A></TD></TR>
<TR>
<TD width=117 height=62>Issue 278</TD>
<TD width=146 height=34>Pending</TD>
<TD width=73 height=62>Technical</TD>
<TD width=277 height=62><A href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 278"><FONT color=#0066cc><U>Comments</U></FONT></A></TD>
<TD width=117 height=51><A href="mailto:[e-mail]"><U><FONT color=#0066cc>Alan DeKok</FONT></U></A></TD></TR>
<TR>
<TD width=117 height=62>Issue 279</TD>
<TD width=146 height=34>No Discussion</TD>
<TD width=73 height=62>Technical</TD>
<TD width=277 height=62><A href="http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 279"><FONT color=#800080><U>Comments</U></FONT></A></TD>
<TD width=117 height=51><A href="mailto:[e-mail]"><U><FONT color=#0066cc>Stefan Winter</FONT></U></A></TD></TR></TBODY></TABLE></P>
&nbsp;<BR>
&nbsp;<BR>
&gt; From: [e-mail]<BR>&gt; To: [e-mail]<BR>&gt; CC: [e-mail]<BR>&gt; Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt <BR>&gt; Date: Sun, 2 Nov 2008 17:21:26 -0800<BR>&gt; <BR>&gt; All known issues are resolved to my satisfaction but YMMV; complaints to me.<BR>&gt; ;-)<BR><BR></body>
</html>
--_8c0db615-245f-478d-8546-b2ca9622d9f8_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 20:01:00 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: IETF 73 Agenda - Take Three
Date: Mon, 3 Nov 2008 12:00:18 -0800
Message-ID: <012901c93dee$cc9c83d0$65d58b70$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_012A_01C93DAB.BE7943D0"
Thread-Index: Ack9l/U0kGxPtBthQaC7HJrG3axEhwAVphsg
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_012A_01C93DAB.BE7943D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

You might want to remove the Extended Attributes draft (or at least the
presentation) from the agenda since none of the authors will be at the
meeting.

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Bernard Aboba
Sent: Monday, November 03, 2008 12:24 AM
To: [e-mail]
Subject: IETF 73 Agenda - Take Three

 




Currently the Agenda is as follows:
 
9 AM - 9:10 Preliminaries (10 minutes)
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document Status
 
Documents completing IETF Last Call (20 minutes)
 
9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10
minutes)
http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06
 
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-05
 
Documents completing RADEXT WG Last Call (40 minutes)

9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server-02
 
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10
minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02

10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04
 
RADEXT WG Work Items (10 minutes)
  
10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 
Pre-Working Group Work Item Review (10 minutes)
 
10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)
http://tools.ietf.org/html/
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02>
draft-tiwari-radext-tunnel-type-02
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02> 
 
10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba
(5 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt
 
Internationalization (20 minutes)
 
10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)
http://tools.ietf.org/html/rfc4282

10:50 AM - 11 AM Discussion

IPv6 (20 minutes)

11:00 AM - 11:10 AM  Prefix Authorization, Behcet Sarikaya (10 minutes)
http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00

11:10 AM - 11:20 AM  DHCPv6 Attributes, Benoit Lourdelet (10 minutes)
http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02

Summary & Wrapup

11:20 AM - 11:30 AM, Chairs 
  

	

 


------=_NextPart_000_012A_01C93DAB.BE7943D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>You might want to remove the Extended Attributes draft (or at
least the presentation) from the agenda since none of the authors will be at
the meeting.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Behalf
Of </b>Bernard Aboba<br>
<b>Sent:</b> Monday, November 03, 2008 12:24 AM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> IETF 73 Agenda - Take Three<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
<br>
<br>
Currently the Agenda is as follows:<br>
&nbsp;<br>
9 AM - 9:10 Preliminaries (10 minutes)<br>
&nbsp;&nbsp; Blue Sheets<br>
&nbsp;&nbsp; Note Takers<br>
&nbsp;&nbsp; Jabber Scribe<br>
&nbsp;&nbsp; Agenda bashing<br>
&nbsp;&nbsp; Document Status<br>
&nbsp;<br>
Documents completing IETF Last Call (20 minutes)<br>
&nbsp;<br>
9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10
minutes)<br>
<a
href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</a><br>
&nbsp;<br>
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-design-05" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-design-05</a><br>
&nbsp;<br>
Documents completing RADEXT WG Last Call (40 minutes)<br>
<br>
9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</a><br>
&nbsp;<br>
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-radsec-02</a><br>
<br>
9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<br>
<a
href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</a><br>
<br>
10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</a><br>
&nbsp;<br>
RADEXT WG Work Items (10 minutes)<br>
&nbsp; <br>
10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)<br>
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<br>
&nbsp;<br>
Pre-Working Group Work Item Review (10 minutes)<br>
&nbsp;<br>
10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)<br>
<span style='color:#0068CF'><a
href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02"
target="_blank">http://tools.ietf.org/html/</a></span><a
href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02"
target="_blank">draft-tiwari-radext-tunnel-type-02</a><br>
&nbsp;<br>
10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5
minutes)<br>
http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt<br>
&nbsp;<br>
Internationalization (20 minutes)<br>
&nbsp;<br>
10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)<br>
<a href="http://tools.ietf.org/html/rfc4282" target="_blank">http://tools.ietf.org/html/rfc4282</a><br>
<br>
10:50 AM - 11 AM Discussion<br>
<br>
IPv6 (20 minutes)<br>
<br>
11:00 AM - 11:10 AM&nbsp; Prefix Authorization, Behcet Sarikaya (10 minutes)<br>
http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00<br>
<br>
11:10 AM - 11:20 AM&nbsp; DHCPv6 Attributes, Benoit Lourdelet (10 minutes)<br>
http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02<br>
<br>
Summary &amp; Wrapup<br>
<br>
11:20 AM - 11:30 AM, Chairs <br>
&nbsp; <o:p></o:p></span></p>

<table class=MsoNormalTable border=1 cellpadding=0 style='border:none;
 border-top:solid black 1.0pt'>
 <tr>
  <td style='border:none;padding:.75pt .75pt .75pt .75pt'></td>
 </tr>
</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_012A_01C93DAB.BE7943D0--



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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 18:30:40 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-radext-status-server-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  3 Nov 2008 10:30:01 -0800 (PST)

--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		: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
	Author(s)	: A. DeKok
	Filename	: draft-ietf-radext-status-server-02.txt
	Pages		: 28
	Date		: 2008-11-3
	
RFC 2865 defines a Status-Server code for use in RADIUS, but labels
   it as "Experimental" without further discussion.  This document
   describes a practical use for the Status-Server packet code, which is
   to let clients query the status of a RADIUS server.  These queries,
   and responses (if any) enable the client to make more informed
   decisions.  The result is a more stable, and more robust RADIUS
   architecture.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-status-server-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--


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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 16:44:57 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f946c587-6585-40e9-9d1f-4d70d1c8c4fe_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG IETF 73 Agenda - Take Four
Date: Mon, 3 Nov 2008 08:44:20 -0800
MIME-Version: 1.0

--_f946c587-6585-40e9-9d1f-4d70d1c8c4fe_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. 

Currently the Agenda is as follows:

 

9 AM - 9:10 Preliminaries (10 minutes)

   Blue Sheets

   Note Takers

   Jabber Scribe

   Agenda bashing

   Document Status

 

Documents completing IETF Last Call (20 minutes)

 

9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06

 

9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-05

 

Documents completing RADEXT WG Last Call (40 minutes)

9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-status-server-02

 

9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02

10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04

 
RADEXT WG Work Items (10 minutes)
 

10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 

Pre-Working Group Work Item Review (10 minutes)

 

10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)

http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02

 

10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09
 

Internationalization (20 minutes)

 

10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)

http://tools.ietf.org/html/rfc4282

10:50 AM - 11 AM Discussion

IPv6 (20 minutes)

11:00 AM - 11:10 AM  Prefix Authorization, Behcet Sarikaya (10 minutes)
http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-01

11:10 AM - 11:20 AM  DHCPv6 Attributes, Benoit Lourdelet (10 minutes)
http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02

Summary & Wrapup

11:20 AM - 11:30 AM, Chairs 




--_f946c587-6585-40e9-9d1f-4d70d1c8c4fe_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. <br>
Currently the Agenda is as follows:<br>
&nbsp;<br>
9 AM - 9:10 Preliminaries (10 minutes)<br>
&nbsp;&nbsp; Blue Sheets<br>
&nbsp;&nbsp; Note Takers<br>
&nbsp;&nbsp; Jabber Scribe<br>
&nbsp;&nbsp; Agenda bashing<br>
&nbsp;&nbsp; Document Status<br>
&nbsp;<br>
Documents completing IETF Last Call (20 minutes)<br>
&nbsp;<br>
9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</a><br>
&nbsp;<br>
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-design-05" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-design-05</a><br>
&nbsp;<br>
Documents completing RADEXT WG Last Call (40 minutes)<br><br>9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</a><br>
&nbsp;<br>
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-radsec-02</a><br><br>9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</a><br><br>10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</a><br>
&nbsp;<br>RADEXT WG Work Items (10 minutes)<br>&nbsp;
<br>10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<br>&nbsp;<br>
Pre-Working Group Work Item Review (10 minutes)<br>
&nbsp;<br>
10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)<br>
<font color="#0068cf"><a href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target="_blank">http://tools.ietf.org/html/</a></font><a href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target="_blank">draft-tiwari-radext-tunnel-type-02</a><br>
&nbsp;<br>
10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)<br>http://tools.ietf.org/html/draft-aboba-radext-wlan-09<br>&nbsp;<br>
Internationalization (20 minutes)<br>
&nbsp;<br>
10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)<br>
<a href="http://tools.ietf.org/html/rfc4282" target="_blank">http://tools.ietf.org/html/rfc4282</a><br><br>10:50 AM - 11 AM Discussion<br><br>IPv6 (20 minutes)<br><br>11:00 AM - 11:10 AM&nbsp; Prefix Authorization, Behcet Sarikaya (10 minutes)<br>http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-01<br><br>11:10 AM - 11:20 AM&nbsp; DHCPv6 Attributes, Benoit Lourdelet (10 minutes)<br>http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02<br><br>Summary &amp; Wrapup<br><br>11:20 AM - 11:30 AM, Chairs <br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target="_blank" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_f946c587-6585-40e9-9d1f-4d70d1c8c4fe_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 15:27:24 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=aNs176mUiwwtkZjs1z1lgvwNkyqxnwoqniPH8VslWfoc5zHiKrxCEv0g7tw3C/554/tZYPXoyMDRezo/Xeo/ezPNEDZIghE4bjiq/4q/hmmxgw9NxiR3lWJvayhzCh31BYskm9XqFlLLdIsZrlvSxV5ecXEAKnuiIZzhYtGRxJs=;
Date: Mon, 3 Nov 2008 07:26:42 -0800 (PST)
From: Behcet Sarikaya <[e-mail]>
Reply-To: Behcet Sarikaya <[e-mail]>
Subject: Re: IETF 73 Agenda - Take Three
To: Bernard Aboba <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-126567652-1225726002=:96663"
Message-ID: <[e-mail]>

--0-126567652-1225726002=:96663
Content-Type: text/plain; charset=us-ascii

Hi Bernard,
  Please reserve a slot for this draft.

Kind regards,

Behcet

A new version of I-D, draft-sarikaya-radext-prefix-authorization-01.txt
has been successfuly submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename:     draft-sarikaya-radext-prefix-authorization
Revision:     01
Title:         RADIUS Support for Prefix Authorization
Creation_date:     2008-11-02
WG ID:         Independent Submission
Number_of_pages: 18

Abstract:
This document specifies new attributes for supporting prefix
authorization.  Using RADIUS protocol, a client requests prefixes
from a server; the client gives back the prefixes to the server; the
client is responsible for renewing the prefixes when the lifetime
expires.  The RADIUS server can also renumber prefixes.  RADIUS
clients can be home agents in MIPv6 and NEMO scenario, local mobile
anchors in Proxy MIPv6 scenario, or common access routers.
                                                                                  


The IETF Secretariat.



________________________________
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Sent: Monday, November 3, 2008 2:23:42 AM
Subject: IETF 73 Agenda - Take Three

 

At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. 
Currently the Agenda is as follows:
 
9 AM - 9:10 Preliminaries (10 minutes)
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document Status
 
Documents completing IETF Last Call (20 minutes)
 
9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06
 
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-05
 
Documents completing RADEXT WG Last Call (40 minutes)

9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server-02
 
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02

10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04
 
RADEXT WG Work Items (10 minutes)
  
10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 
Pre-Working Group Work Item Review (10 minutes)
 
10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)
http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02
 
10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt
 
Internationalization (20 minutes)
 
10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)
http://tools.ietf.org/html/rfc4282

10:50 AM - 11 AM Discussion

IPv6 (20 minutes)

11:00 AM - 11:10 AM  Prefix Authorization, Behcet Sarikaya (10 minutes)
http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00

11:10 AM - 11:20 AM  DHCPv6 Attributes, Benoit Lourdelet (10 minutes)
http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02

Summary & Wrapup

11:20 AM - 11:30 AM, Chairs 


      
--0-126567652-1225726002=:96663
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:14pt"><div>Hi Bernard,<br>&nbsp; Please reserve a slot for this draft.<br><br>Kind regards,<br><br>Behcet<br><br>A new version of I-D, draft-sarikaya-radext-prefix-authorization-01.txt
has been successfuly submitted by Behcet Sarikaya and posted to the
IETF repository.<br><br>Filename:&nbsp;&nbsp;&nbsp;  draft-sarikaya-radext-prefix-authorization<br>Revision:&nbsp;&nbsp;&nbsp;  01<br>Title:&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;  RADIUS Support for Prefix <span style="border-bottom: 1px dashed rgb(0, 102, 204); cursor: pointer;" class="yshortcuts" id="lw_1225725864_0">Authorization</span><br>Creation_date:&nbsp;&nbsp;&nbsp;  2008-11-02<br>WG ID:&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;  Independent Submission<br>Number_of_pages: 18<br><br>Abstract:<br>This document specifies new attributes for supporting prefix<br>authorization.&nbsp; Using RADIUS protocol, a client requests prefixes<br>from a server; the client gives back the prefixes to the server; the<br>client is responsible for renewing the prefixes when the lifetime<br>expires.&nbsp; The RADIUS server can also renumber prefixes.&nbsp; RADIUS<br>clients can be <span class="yshortcuts" id="lw_1225725864_1">home agents</span> in MIPv6 and NEMO scenario,
 local mobile<br>anchors in Proxy MIPv6 scenario, or common access routers.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br><br><br>The IETF Secretariat.</div><div style="font-family: times new roman,new york,times,serif; font-size: 14pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Bernard Aboba &lt;[e-mail]&gt;<br><b><span style="font-weight: bold;">To:</span></b> [e-mail]<br><b><span style="font-weight: bold;">Sent:</span></b> Monday, November 3, 2008 2:23:42 AM<br><b><span style="font-weight: bold;">Subject:</span></b> IETF 73 Agenda - Take
 Three<br></font><br>


<style>
.hmmessage P
{
margin:0px;padding:0px;}
body.hmmessage
{
FONT-SIZE:10pt;FONT-FAMILY:Tahoma;}
</style>

<br>

 
 
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}</style><br>



<style>
.ExternalClass .EC_hmmessage P
{</style>At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. <br>
Currently the Agenda is as follows:<br>
&nbsp;<br>
9 AM - 9:10 Preliminaries (10 minutes)<br>
&nbsp;&nbsp; Blue Sheets<br>
&nbsp;&nbsp; Note Takers<br>
&nbsp;&nbsp; Jabber Scribe<br>
&nbsp;&nbsp; Agenda bashing<br>
&nbsp;&nbsp; Document Status<br>
&nbsp;<br>
Documents completing IETF Last Call (20 minutes)<br>
&nbsp;<br>
9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06">http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</a><br>
&nbsp;<br>
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-design-05">http://tools.ietf.org/html/draft-ietf-radext-design-05</a><br>
&nbsp;<br>
Documents completing RADEXT WG Last Call (40 minutes)<br><br>9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</a><br>
&nbsp;<br>
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02">http://tools.ietf.org/html/draft-ietf-radext-radsec-02</a><br><br>9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</a><br><br><a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02"></a>10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</a><br>
&nbsp;<br><a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02"></a>RADEXT WG Work Items (10 minutes)<br>&nbsp;
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02"></a><br>10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)<br><a target="_blank" href="http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00">http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00</a><br>&nbsp;<br>
Pre-Working Group Work Item Review (10 minutes)<br>
&nbsp;<br>
10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)<br>
<font color="#0068cf"><a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02">http://tools.ietf.org/html/</a></font><a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02">draft-tiwari-radext-tunnel-type-02</a><br>
&nbsp;<br>
10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)<br><a target="_blank" href="http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt">http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt</a><br>&nbsp;<br>
Internationalization (20 minutes)<br>
&nbsp;<br>
10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)<br>
<a rel="nofollow" target="_blank" href="http://tools.ietf.org/html/rfc4282">http://tools.ietf.org/html/rfc4282</a><br><br>10:50 AM - 11 AM Discussion<br><br>IPv6 (20 minutes)<br><br>11:00 AM - 11:10 AM&nbsp; Prefix Authorization, Behcet Sarikaya (10 minutes)<br><a target="_blank" href="http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00">http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00</a><br><br>11:10 AM - 11:20 AM&nbsp; DHCPv6 Attributes, Benoit Lourdelet (10 minutes)<br><a target="_blank" href="http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02">http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02</a><br><br>Summary &amp; Wrapup<br><br>11:20 AM - 11:30 AM, Chairs <br>&nbsp;
<br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma;"><tbody><tr><td><a rel="nofollow" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;" target="_blank" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table>

</div></div></div><br>

      </body></html>
--0-126567652-1225726002=:96663--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 09:35:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_4a7e93a4-1e7e-4ce3-abb8-7fe8e348e254_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: IETF 73 Agenda - Take Three
Date: Mon, 3 Nov 2008 00:23:42 -0800
MIME-Version: 1.0

--_4a7e93a4-1e7e-4ce3-abb8-7fe8e348e254_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. 

Currently the Agenda is as follows:

 

9 AM - 9:10 Preliminaries (10 minutes)

   Blue Sheets

   Note Takers

   Jabber Scribe

   Agenda bashing

   Document Status

 

Documents completing IETF Last Call (20 minutes)

 

9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06

 

9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-05

 

Documents completing RADEXT WG Last Call (40 minutes)

9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-status-server-02

 

9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02

10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04

 
RADEXT WG Work Items (10 minutes)
 

10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 

Pre-Working Group Work Item Review (10 minutes)

 

10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)

http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02

 

10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt
 

Internationalization (20 minutes)

 

10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)

http://tools.ietf.org/html/rfc4282

10:50 AM - 11 AM Discussion

IPv6 (20 minutes)

11:00 AM - 11:10 AM  Prefix Authorization, Behcet Sarikaya (10 minutes)
http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00

11:10 AM - 11:20 AM  DHCPv6 Attributes, Benoit Lourdelet (10 minutes)
http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02

Summary & Wrapup

11:20 AM - 11:30 AM, Chairs 
 





--_4a7e93a4-1e7e-4ce3-abb8-7fe8e348e254_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
<br>

<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}</style><br>



<style>
.ExternalClass .EC_hmmessage P
{paddi</style>At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. <br>
Currently the Agenda is as follows:<br>
&nbsp;<br>
9 AM - 9:10 Preliminaries (10 minutes)<br>
&nbsp;&nbsp; Blue Sheets<br>
&nbsp;&nbsp; Note Takers<br>
&nbsp;&nbsp; Jabber Scribe<br>
&nbsp;&nbsp; Agenda bashing<br>
&nbsp;&nbsp; Document Status<br>
&nbsp;<br>
Documents completing IETF Last Call (20 minutes)<br>
&nbsp;<br>
9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</a><br>
&nbsp;<br>
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-design-05" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-design-05</a><br>
&nbsp;<br>
Documents completing RADEXT WG Last Call (40 minutes)<br><br>9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</a><br>
&nbsp;<br>
9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-radsec-02</a><br><br>9:50 AM - 10:00 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</a><br><br><a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target="_blank"></a>10:00 AM - 10:10 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</a><br>
&nbsp;<br><a href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02" target="_blank"></a>RADEXT WG Work Items (10 minutes)<br>&nbsp;
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target="_blank"></a><br>10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<br>&nbsp;<br>
Pre-Working Group Work Item Review (10 minutes)<br>
&nbsp;<br>
10:30 AM - 10:35 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes)<br>
<font color="#0068cf"><a href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target="_blank">http://tools.ietf.org/html/</a></font><a href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target="_blank">draft-tiwari-radext-tunnel-type-02</a><br>
&nbsp;<br>
10:35 AM - 10:40 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes)<br>http://tools.ietf.org/html/draft-aboba-radext-wlan-09.txt<br>&nbsp;<br>
Internationalization (20 minutes)<br>
&nbsp;<br>
10:40 AM - 10:50 AM Issues with RFC 4282, Alan DeKok (15 minutes)<br>
<a href="http://tools.ietf.org/html/rfc4282" target="_blank">http://tools.ietf.org/html/rfc4282</a><br><br>10:50 AM - 11 AM Discussion<br><br>IPv6 (20 minutes)<br><br>11:00 AM - 11:10 AM&nbsp; Prefix Authorization, Behcet Sarikaya (10 minutes)<br>http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-00<br><br>11:10 AM - 11:20 AM&nbsp; DHCPv6 Attributes, Benoit Lourdelet (10 minutes)<br>http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02<br><br>Summary &amp; Wrapup<br><br>11:20 AM - 11:30 AM, Chairs <br>&nbsp;
<br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target="_blank"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table>

</body>
</html>
--_4a7e93a4-1e7e-4ce3-abb8-7fe8e348e254_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 07:06:49 +0000
Message-ID: <[e-mail]>
Date: Mon, 03 Nov 2008 07:49:00 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>
CC: Bernard Aboba <[e-mail]>, [e-mail]
Subject: Re: Call for IETF 73 Agenda Items
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

>  Could we also add the TCP transport draft?
>
> http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00 

Speaking of which: that draft is an individual submission. We have TCP
transport on the charter, scheduled for Jan 09, and personally I think
that this draft is well written and suited to be adopted as a wg draft,
rather than an individual submission.
I suggest we try to get a feeling in the room about whether to make this
document a proper wg document.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 01:29:45 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>
Cc: "'Glen Zorn'" <[e-mail]>
Subject: RE: I-D Action:draft-ietf-radext-extended-attributes-05.txt 
Date: Sun, 2 Nov 2008 17:21:26 -0800
Message-ID: <00f601c93d52$7ef81550$7ce83ff0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: Ack9S41YohLII645Sz+7E3TBra18lwABsT6g
Content-Language: en-us

All known issues are resolved to my satisfaction but YMMV; complaints to me.
;-)

> -----Original Message-----
> From: [e-mail] [mailto:i-d-announce-
> [e-mail]] On Behalf Of [e-mail]
> Sent: Sunday, November 02, 2008 4:30 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: I-D Action:draft-ietf-radext-extended-attributes-05.txt
> 
> 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           : Extended Remote Authentication Dial In User
> Service (RADIUS) Attributes
> 	Author(s)       : Y. Li, et al.
> 	Filename        : draft-ietf-radext-extended-attributes-05.txt
> 	Pages           : 13
> 	Date            : 2008-11-02
> 
> For the Remote Authentication Dial In User Service (RADIUS) protocol to
> continue to support new applications, the RADIUS attribute type space
> must be extended beyond the current limit of 255 possible attribute
> types while maintaining backwards compatibility with the existing
> protocol.  This document defines a mechanism to accomplish that task,
> along with standard methods to group together related attributes and to
> encode values that don't fit into 253 octets.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-
> attributes-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 00:30:43 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-extended-attributes-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun,  2 Nov 2008 16:30:01 -0800 (PST)

--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           : Extended Remote Authentication Dial In User Service (RADIUS) Attributes
	Author(s)       : Y. Li, et al.
	Filename        : draft-ietf-radext-extended-attributes-05.txt
	Pages           : 13
	Date            : 2008-11-02

For the Remote Authentication Dial In User Service (RADIUS) protocol
to continue to support new applications, the RADIUS attribute type
space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with the
existing protocol.  This document defines a mechanism to accomplish
that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-radext-extended-attributes-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 00:15:29 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>
Subject: FW: I-D Action:draft-lourdelet-radext-rfc3162bis-02.txt 
Date: Sun, 2 Nov 2008 16:04:57 -0800
Message-ID: <00b301c93d47$cf581b40$6e0851c0$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B4_01C93D04.C134DB40"
thread-index: Ack9RyBCd8FzivyASza7qNTzefRPggAAKEhQ
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_00B4_01C93D04.C134DB40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Sunday, November 02, 2008 4:00 PM
To: [e-mail]
Subject: I-D Action:draft-lourdelet-radext-rfc3162bis-02.txt 

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

	Title           : RADIUS Attributes for IPv6 Support
	Author(s)       : B. Lourdelet, G. Zorn
	Filename        : draft-lourdelet-radext-rfc3162bis-02.txt
	Pages           : 14
	Date            : 2008-11-02

This document specifies the operation of RADIUS (Remote Authentication Dial
In User Service) when run over IPv6 as well as the RADIUS attributes used to
support IPv6 network access.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_000_00B4_01C93D04.C134DB40
Content-Type: Message/External-body;
	name="draft-lourdelet-radext-rfc3162bis-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-lourdelet-radext-rfc3162bis-02.txt"

Content-Type: text/plain
Content-ID: <[e-mail]>


------=_NextPart_000_00B4_01C93D04.C134DB40
Content-Type: text/plain;
	name="ATT00177.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00177.txt"

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_00B4_01C93D04.C134DB40--



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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Nov 2008 00:02:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93D47.551BAD78"
Subject: RE: IETF 73 Agenda - Take Two
Date: Mon, 3 Nov 2008 01:01:33 +0100
Message-ID: <[e-mail]>
Thread-Topic: IETF 73 Agenda - Take Two
Thread-Index: Ack9LcWuuFAzyA4nSl+Ay9VmmrurZgAGKYYw
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; lˆ96; t25670494; x26534494; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From: "Benoit Lourdelet (blourdel)" <blourdel@ cisco.com> |Subject: RE: IETF 73 Agenda - Take Two |Sender: ; bh=JQa6p48uprE12+sYbOPZz9UU3li7n5oWA2CvE+UnwmU=; b=bP5Wbv6GvakctMB+SMFxC1DplZZ7nzMQ9dSvIlYKrsDFbqAkZ+ZZemYRdg 2l+FZhPPJoTNYJa0aEfqZoWTiZgg3JMV2zpca8scGSW7fDhC7v8EHEaKJDPu 0shDDboXBc;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93D47.551BAD78
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
 
I suggest we include that individual submission :
 
draft-lourdelet-radext-rfc3162bis-02 (10 min)

 

regards

 

Benoit


________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Bernard Aboba
Sent: Sunday, November 02, 2008 9:58 PM
To: [e-mail]
Subject: IETF 73 Agenda - Take Two



At IETF 73, the RADEXT WG is currently scheduled to meet on November 18,
2008 from 9 AM - 11:30 AM. 
Currently the Agenda is as follows:
 
9 AM - 9:10 Preliminaries
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document Status
 
Documents completing IETF Last Call
 
9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson
(10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06
 
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-05
 
Documents completing RADEXT WG Last Call
 
9:30 AM - 9:40 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:40 AM - 9:50 AM Status-Server, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server-02
 
9:50 AM - 10:00 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04
 
10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10
minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements
-02
 
RADEXT WG Work Items
  <http://tools.ietf.org/html/draft-ietf-radext-status-server-02> 
10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 
Pre-Working Group Work Item Review
 
10:30 AM - 10:40 AM New Tunnel-Type Values, Abhishek Tiwari (10 minutes)
http://tools.ietf.org/html/
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02>
draft-tiwari-radext-tunnel-type-02
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02> 
 
10:40 AM - 10:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard
Aboba (10 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09
<http://tools.ietf.org/html/draft-aboba-radext-wlan-089> 
 
Internationalization
 
10:50 AM - 11:05 AM Issues with RFC 4282, Alan DeKok (15 minutes)
http://tools.ietf.org/html/rfc4282
  

<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 
	

------_=_NextPart_001_01C93D47.551BAD78
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE>.hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content="MSHTML 6.00.6000.16705" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV><SPAN class=208025523-02112008><FONT face=Arial 
color=#0000ff>Hello,</FONT></SPAN></DIV>
<DIV><SPAN class=208025523-02112008><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=208025523-02112008><FONT face=Arial color=#0000ff>I suggest we 
include that individual submission :</FONT></SPAN></DIV>
<DIV><SPAN class=208025523-02112008><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=208025523-02112008><FONT size=3>
<P>draft-lourdelet-radext-rfc3162bis-02<SPAN class=208025523-02112008> (10 
min)</SPAN></P>
<P>&nbsp;</P>
<P><SPAN class=208025523-02112008><FONT face=Arial color=#0000ff 
size=2>regards</FONT></SPAN></P>
<P><SPAN class=208025523-02112008><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</P>
<P><SPAN class=208025523-02112008><FONT face=Arial color=#0000ff 
size=2>Benoit</FONT></SPAN></P></FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma><B>From:</B> [e-mail] 
[mailto:[e-mail]] <B>On Behalf Of </B>Bernard 
Aboba<BR><B>Sent:</B> Sunday, November 02, 2008 9:58 PM<BR><B>To:</B> 
[e-mail]<BR><B>Subject:</B> IETF 73 Agenda - Take 
Two<BR></FONT><BR></DIV>
<DIV></DIV><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>.ExternalClass .EC_hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
.ExternalClass BODY.EC_hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>
At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 
from 9 AM - 11:30 AM. <BR>Currently the Agenda is as follows:<BR>&nbsp;<BR>9 AM 
- 9:10 Preliminaries<BR>&nbsp;&nbsp; Blue Sheets<BR>&nbsp;&nbsp; Note 
Takers<BR>&nbsp;&nbsp; Jabber Scribe<BR>&nbsp;&nbsp; Agenda 
bashing<BR>&nbsp;&nbsp; Document Status<BR>&nbsp;<BR>Documents completing IETF 
Last Call<BR>&nbsp;<BR>9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS 
Management, David Nelson (10 minutes)<BR><A 
href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06" 
target=_blank>http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</A><BR>&nbsp;<BR>9:20 
- 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<BR><A 
href="http://tools.ietf.org/html/draft-ietf-radext-design-05" 
target=_blank>http://tools.ietf.org/html/draft-ietf-radext-design-05</A><BR>&nbsp;<BR>Documents 
completing RADEXT WG Last Call<BR>&nbsp;<BR>9:30 AM - 9:40 AM RADSEC, Stefan 
Winter (10 minutes)<BR><A 
href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" 
target=_blank>http://tools.ietf.org/html/draft-ietf-radext-radsec-02</A><BR><BR>9:40 
AM - 9:50 AM Status-Server, Alan DeKok (10 minutes)<BR><A 
href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" 
target=_blank>http://tools.ietf.org/html/draft-ietf-radext-status-server-02</A><BR>&nbsp;<BR>9:50 
AM - 10:00 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<BR><A 
href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04" 
target=_blank>http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</A><BR>&nbsp;<BR>10:00 
AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<BR><A 
href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02" 
target=_blank>http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</A><BR>&nbsp;<BR>RADEXT 
WG Work Items<BR>&nbsp; <A 
href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" 
target=_blank></A><BR>10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 
minutes)<BR>http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<BR>&nbsp;<BR>Pre-Working 
Group Work Item Review<BR>&nbsp;<BR>10:30 AM - 10:40 AM New Tunnel-Type Values, 
Abhishek Tiwari (10 minutes)<BR><FONT color=#0068cf><A 
href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" 
target=_blank>http://tools.ietf.org/html/</A></FONT><A 
href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" 
target=_blank>draft-tiwari-radext-tunnel-type-02</A><BR>&nbsp;<BR>10:40 AM - 
10:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 
minutes)<BR><FONT color=#0068cf><A 
href="http://tools.ietf.org/html/draft-aboba-radext-wlan-089" 
target=_blank>http://tools.ietf.org/html/draft-aboba-radext-wlan-09</A></FONT><BR>&nbsp;<BR>Internationalization<BR>&nbsp;<BR>10:50 
AM - 11:05 AM Issues with RFC 4282, Alan DeKok (15 minutes)<BR><A 
href="http://tools.ietf.org/html/rfc4282" 
target=_blank>http://tools.ietf.org/html/rfc4282</A><BR>&nbsp; <BR>
<TABLE 
style="BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: 'Segoe UI',Tahoma,san-serif">
  <TBODY>
  <TR>
    <TD><A 
      style="FONT-SIZE: 9pt; COLOR: rgb(1,132,203); TEXT-DECORATION: none" 
      href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" 
      target=_blank><SPAN 
      style="PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: 8pt; PADDING-BOTTOM: 0px; COLOR: rgb(63,181,85); PADDING-TOP: 0px; TEXT-DECORATION: underline"></SPAN></A><BR></TD></TR></TBODY></TABLE></BODY></HTML>

------_=_NextPart_001_01C93D47.551BAD78--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 02 Nov 2008 21:59:50 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: IETF 73 Agenda - Take Two
Date: Sun, 2 Nov 2008 13:58:38 -0800
Message-ID: <006201c93d36$29ee6f30$7dcb4d90$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C93CF3.1BCB2F30"
thread-index: Ack9LgPmQSJbpHBqSp6z/oOOoFOGXAAB+FNQ
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0063_01C93CF3.1BCB2F30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I do not plan to attend the meeting; maybe one of my co-authors would like
to talk about the Extended Attributes draft (of which there will be -05
posted presently).

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Bernard Aboba
Sent: Sunday, November 02, 2008 12:58 PM
To: [e-mail]
Subject: IETF 73 Agenda - Take Two

 



Currently the Agenda is as follows:
 
9 AM - 9:10 Preliminaries
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document Status
 
Documents completing IETF Last Call
 
9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10
minutes)
http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06
 
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-05
 
Documents completing RADEXT WG Last Call
 
9:30 AM - 9:40 AM RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:40 AM - 9:50 AM Status-Server, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server-02
 
9:50 AM - 10:00 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04
 
10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10
minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02
 
RADEXT WG Work Items
  
10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 
Pre-Working Group Work Item Review
 
10:30 AM - 10:40 AM New Tunnel-Type Values, Abhishek Tiwari (10 minutes)
http://tools.ietf.org/html/
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02>
draft-tiwari-radext-tunnel-type-02
<http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02> 
 
10:40 AM - 10:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba
(10 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan-09
<http://tools.ietf.org/html/draft-aboba-radext-wlan-089> 
 
Internationalization
 
10:50 AM - 11:05 AM Issues with RFC 4282, Alan DeKok (15 minutes)
http://tools.ietf.org/html/rfc4282
  

	

 


------=_NextPart_000_0063_01C93CF3.1BCB2F30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Arial Black","sans-serif";
color:#7030A0'>I do not plan to attend the meeting; maybe one of my co-authors
would like to talk about the Extended Attributes draft (of which there will be
-05 posted presently).<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Behalf
Of </b>Bernard Aboba<br>
<b>Sent:</b> Sunday, November 02, 2008 12:58 PM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> IETF 73 Agenda - Take Two<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
<br>
Currently the Agenda is as follows:<br>
&nbsp;<br>
9 AM - 9:10 Preliminaries<br>
&nbsp;&nbsp; Blue Sheets<br>
&nbsp;&nbsp; Note Takers<br>
&nbsp;&nbsp; Jabber Scribe<br>
&nbsp;&nbsp; Agenda bashing<br>
&nbsp;&nbsp; Document Status<br>
&nbsp;<br>
Documents completing IETF Last Call<br>
&nbsp;<br>
9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10
minutes)<br>
<a
href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</a><br>
&nbsp;<br>
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-design-05" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-design-05</a><br>
&nbsp;<br>
Documents completing RADEXT WG Last Call<br>
&nbsp;<br>
9:30 AM - 9:40 AM RADSEC, Stefan Winter (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-radsec-02</a><br>
<br>
9:40 AM - 9:50 AM Status-Server, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</a><br>
&nbsp;<br>
9:50 AM - 10:00 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</a><br>
&nbsp;<br>
10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10
minutes)<br>
<a
href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02"
target="_blank">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</a><br>
&nbsp;<br>
RADEXT WG Work Items<br>
&nbsp; <br>
10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)<br>
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<br>
&nbsp;<br>
Pre-Working Group Work Item Review<br>
&nbsp;<br>
10:30 AM - 10:40 AM New Tunnel-Type Values, Abhishek Tiwari (10 minutes)<br>
<span style='color:#0068CF'><a
href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02"
target="_blank">http://tools.ietf.org/html/</a></span><a
href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02"
target="_blank">draft-tiwari-radext-tunnel-type-02</a><br>
&nbsp;<br>
10:40 AM - 10:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10
minutes)<br>
<span style='color:#0068CF'><a
href="http://tools.ietf.org/html/draft-aboba-radext-wlan-089" target="_blank">http://tools.ietf.org/html/draft-aboba-radext-wlan-09</a></span><br>
&nbsp;<br>
Internationalization<br>
&nbsp;<br>
10:50 AM - 11:05 AM Issues with RFC 4282, Alan DeKok (15 minutes)<br>
<a href="http://tools.ietf.org/html/rfc4282" target="_blank">http://tools.ietf.org/html/rfc4282</a><br>
&nbsp; <o:p></o:p></span></p>

<table class=MsoNormalTable border=1 cellpadding=0 style='border:none;
 border-top:solid black 1.0pt'>
 <tr>
  <td style='border:none;padding:.75pt .75pt .75pt .75pt'></td>
 </tr>
</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0063_01C93CF3.1BCB2F30--



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


Envelope-to: [e-mail]
Delivery-date: Sun, 02 Nov 2008 20:58:26 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_0e556ca2-a208-423b-a3fa-3ab1c9d0af51_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: IETF 73 Agenda - Take Two
Date: Sun, 2 Nov 2008 12:57:31 -0800
MIME-Version: 1.0

--_0e556ca2-a208-423b-a3fa-3ab1c9d0af51_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. 

Currently the Agenda is as follows:

 

9 AM - 9:10 Preliminaries

   Blue Sheets

   Note Takers

   Jabber Scribe

   Agenda bashing

   Document Status

 

Documents completing IETF Last Call

 

9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06

 

9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-05

 

Documents completing RADEXT WG Last Call

 

9:30 AM - 9:40 AM RADSEC, Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec-02

9:40 AM - 9:50 AM Status-Server, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-status-server-02

 

9:50 AM - 10:00 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04

 
10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02

 

RADEXT WG Work Items
 

10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00
 

Pre-Working Group Work Item Review

 

10:30 AM - 10:40 AM New Tunnel-Type Values, Abhishek Tiwari (10 minutes)

http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02

 

10:40 AM - 10:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)

http://tools.ietf.org/html/draft-aboba-radext-wlan-09

 

Internationalization

 

10:50 AM - 11:05 AM Issues with RFC 4282, Alan DeKok (15 minutes)

http://tools.ietf.org/html/rfc4282
 




--_0e556ca2-a208-423b-a3fa-3ab1c9d0af51_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
<br>

<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma</style>At IETF 73, the RADEXT WG is currently scheduled to meet on November 18, 2008 from 9 AM - 11:30 AM. <br>
Currently the Agenda is as follows:<br>
&nbsp;<br>
9 AM - 9:10 Preliminaries<br>
&nbsp;&nbsp; Blue Sheets<br>
&nbsp;&nbsp; Note Takers<br>
&nbsp;&nbsp; Jabber Scribe<br>
&nbsp;&nbsp; Agenda bashing<br>
&nbsp;&nbsp; Document Status<br>
&nbsp;<br>
Documents completing IETF Last Call<br>
&nbsp;<br>
9:10 - 9:20 AM&nbsp; RADIUS Authorization for NAS Management, David Nelson (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06</a><br>
&nbsp;<br>
9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-design-05" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-design-05</a><br>
&nbsp;<br>
Documents completing RADEXT WG Last Call<br>
&nbsp;<br>
9:30 AM - 9:40 AM RADSEC, Stefan Winter (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-radsec-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-radsec-02</a><br><br>9:40 AM - 9:50 AM Status-Server, Alan DeKok (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-status-server-02</a><br>
&nbsp;<br>
9:50 AM - 10:00 AM Extended RADIUS Attributes, Glen Zorn (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-04</a><br>
&nbsp;<br>10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes)<br>
<a href="http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02" target="_blank">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02</a><br>
&nbsp;<br>
RADEXT WG Work Items<br>&nbsp;
<a href="http://tools.ietf.org/html/draft-ietf-radext-status-server-02" target="_blank"></a><br>10:20 AM - 10:30 AM TCP Transport, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00<br>&nbsp;<br>
Pre-Working Group Work Item Review<br>
&nbsp;<br>
10:30 AM - 10:40 AM New Tunnel-Type Values, Abhishek Tiwari (10 minutes)<br>
<font color="#0068cf"><a href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target="_blank">http://tools.ietf.org/html/</a></font><a href="http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02" target="_blank">draft-tiwari-radext-tunnel-type-02</a><br>
&nbsp;<br>
10:40 AM - 10:50 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)<br>
<font color="#0068cf"><a href="http://tools.ietf.org/html/draft-aboba-radext-wlan-089" target="_blank">http://tools.ietf.org/html/draft-aboba-radext-wlan-09</a></font><br>
&nbsp;<br>
Internationalization<br>
&nbsp;<br>
10:50 AM - 11:05 AM Issues with RFC 4282, Alan DeKok (15 minutes)<br>
<a href="http://tools.ietf.org/html/rfc4282" target="_blank">http://tools.ietf.org/html/rfc4282</a><br>&nbsp;
<br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" target="_blank"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table>
</body>
</html>
--_0e556ca2-a208-423b-a3fa-3ab1c9d0af51_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 02 Nov 2008 19:45:28 +0000
Message-ID: <[e-mail]>
Date: Sun, 02 Nov 2008 14:44:15 -0500
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Call for IETF 73 Agenda Items
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
...

  Could we also add the TCP transport draft?

http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00

   Alan DeKok.



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