Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext

From: <[email-masked]>
Date: Thu, 29 Jul 2010 16:56:34 +0200

Here is an example of what could be the content of tyhe draft describing the use of the Tunnel attributes for DS-Lite Tunneling.
This is based on the draft published by Alain and Roberta as well as the RFC 2868.

This kind of approach would avoid having to define a new set of attributes.
Please comment the idea based on the following draft attempt!

BR,

Lionel

***********************

Title: Use of RADIUS Tunnel Attributes for Dual-Stack Lite

Abstract

   This document describes the use of the set of RADIUS attributes defined in the RFC 2868 to support
   establishment of Dual-Stack Lite tunnel.

1. Motivation

   Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] is a solution to
   offer both IPv4 and IPv6 connectivity to customers which are
   addressed only with an IPv6 prefix (no IPv4 address is assigned to
   the attachment device).  One of its key components is an IPv4-over-
   IPv6 tunnel, but a DS-Lite Basic Bridging BroadBand (B4) will not
   know if the network it is attached to offers Dual-Stack Lite support,
   and if it did, would not know the remote end of the tunnel to
   establish a connection.

   To inform the B4 of the AFTR's location, either an IPv6 address or
   Fully Qualified Domain Name (FQDN) may be used.  Once this
   information is conveyed, the presence of the configuration indicating
   the AFTR's location also informs a host to initiate Dual-Stack Lite
   (DS-Lite) service and become a Softwire Initiator.

   The draft draft-ietf-softwire-ds-lite-tunnel-option
   [I-D.ietf-softwire-ds-lite-tunnel-option] specifies two DHCPv6
   options which are meant to be used by a Dual-Stack Lite client (Basic
   Bridging BroadBand element, B4) to discover its Address Family
   Transition Router (AFTR) address.  In order to be able to populate
   such options the DHCPv6 Server must be pre-provisioned with the
   Address Family Transition Router (AFTR) address or name.

   In Broadband environments, customer profile may be managed by AAA
   servers, together with user Authentication, Authorization, and
   Accounting (AAA).  RADIUS protocol [RFC2865] is usually used by AAA
   Servers to communicate with network elements.
   [I-D.ietf-radext-ipv6-access] describes a typical broadband network
   scenario in which the Network Access Server (NAS) acts as the access
   gateway for the users (hosts or CPEs) and the NAS embeds a DHCPv6
   Server function that allows it to locally handle any DHCPv6 requests
   issued by the clients.

   Since the DS-Lite AFTR information can be stored as tunneling information
   in AAA servers and the client configuration is mainly provided through 
   DHC protocol running between the NAS and the requesting clients, this 
   document aims at describing the use of the RADIUS tunnel attributes 
   defined in RFC 2868 for carrying the DS-Lite tunnel information (DS-Lite
   Tunnel Name and DS-Lite Tunnel Address), this information being populated in
   in DHCPv6 options already specified in [I-D.ietf-softwire-ds-lite-tunnel-option].

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS-
   Lite Address Family Transition Router element (AFTR) are defined in
   [I-D.ietf-softwire-dual-stack-lite].

3. DS-Lite Configuration with RADIUS and DHCPv6

   The Figure 1 illustrates how the RADIUS protocol and DHCPv6 work
   together to accomplish DS-Lite configuration on the B4 element.

         B4                        NAS                           AAA
         |                          |                          Server
         |                          |                             |
         |                          |                             |
         |                          |-----Access Request -------->|
         |                          |                             |
         |                          |<----Access Accept           |
         |                          |    (Tunnel-Type,            |
         |                          |     Tunnel-Medium-Type ,    |
         |                          |     Tunnel-Server-Endpoint) |
         |                          |                             |
         |------DHCPv6 Request----->|                             |
         |  (DS-Lite tunnel Option) |                             |
         |                          |                             |
         |<-----DHCPv6 Reply--------|                             |
         | (DS-Lite tunnel option)  |                             |

                   DHCPv6                         RADIUS

                 Figure 1: RADIUS and DHCPv6 Message Flow

   The Network Access Server (NAS) operates as a client of RADIUS and as
   DHCP Server for DHC protocol.  The NAS initially sends a RADIUS
   Access Request message to the RADIUS server, requesting
   authentication.  Once the RADIUS server receives the request, it
   validates the sending client and if the request is approved, the AAA
   server replies with an Access Accept message including a list of
   attributes that describe the parameters to be used for
   this session.  This list may also contain the RADIUS Tunnel attributes 
   Tunnel-Type, Tunnel-Medium-Type and Tunnel-Server-Endpoint (and 
   Tunnel-Preference if multiple tunnels information are provided).
   These attirbutes are used to provide the NAS with AFTR Tunnel IPv6  
   Address and/or the AFTR Tunnel Name.  When the NAS receives a 
   DHCPv6 client request containing the DS-Lite tunnel Options, the NAS
   shall use the address and/or name returned in the RADIUS 
   Tunnel-Server-Endpoint attribute to populate the 
   DHCPv6 OPTION_DS_LITE_ADDR option in the DHCPv6 reply message.

3. Use of the RADIUS Tunnel Attributes

   This section describes the RADIUS attributes defined in RFC 2868 and
   used to provide a NAS  with DS-Lite tunnel information. The use of these
   attributes shall follow the recommendations given in the RFC 2868.
   Any other attirbutes defined in RFC 2868 SHOULD NOT be used.

3.1. Tunnel-Type

   The Tunnel-Type Attribute (64) [RFC 2868] SHALL be used to indicate the type
   of tunnel to be used. This document defines a new value of tunnel type
   to be populated in the Value field of the Tunnel-Type attribute for DS-Lite
   Tunneling information. 

   Value   Name
   TBD1    DS-Lite Tunneling

3.2. Tunnel-Medium-Type

   The Tunnel-Medium-Type Attribute (65) SHALL be used to indicate IPv6 
   (value 2) as transport medium for DS-Lite Tunnel.

3.4. Tunnel-Server-Endpoint

    The Tunnel-Server-Endpoint attribute ((67) SHALL be used to provide
    either the FQDN of the AFTR Tunnel or a text representation of the 
    IPv6 address in either the preferred or alternate form [17].

    If the The Tunnel-Type Attribute (64) indicates the tunnet type "DS-Lite 
    Tunneling" (value TBD1), at least one Tunnel-Server-Endpoint attribute 
    MUST be provided by the RADIUS server and at least two if the IPv6 address
    and the FQDN of the  AFTR Tunnel are both provided.

3.8. Tunnel-Preference

   If more than one set of DS-Lite tunneling attributes is returned by the
   RADIUS server to the NAS, this Attribute MAY be included in each
   set to indicate the relative preference assigned to each tunnel. 

4. Table of Attributes

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

Request Accept Reject Challenge Acct-Request #  Attribute
0+      0+     0      0         0-1          64 Tunnel-Type
0+      0+     0      0         0-1          65 Tunnel-Medium-Type
0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
0+      0+     0      0         0            83 Tunnel-Preference

   The following table defines the meaning of the above table entries.

0 This attribute MUST NOT be present in packet.

0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.

5. Security Considerations

   TBD.

6. IANA Considerations

   This document defines a new value of tunnel type to be assigned by the IANA.

   Value   Name
   TBD1    DS-Lite Tunneling

7. References

________________________________

	De : MORAND Lionel RD-CORE-ISS 
	Envoyé : mercredi 28 juillet 2010 10:31
	À : 'radext mailing list'
	Objet : Comment on draft-maglione-softwire-dslite-radius-ext

	Following my comment during the meeting, about (re-)using an existing attribute to convey tunnel info for DS-Lite, what about re-using attributes defined in RFC 2868 ???
	 
	It should be straightforward to create a new type for DS-Lite.
	 
	BR,
	 
	Lionel

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

---

From: <[email-masked]>
Date: Thu, 29 Jul 2010 17:16:30 +0200

It seems that the first mail, sent yesterday, was not delivered.

> 	Following my comment during the meeting, about 
> (re-)using an existing attribute to convey tunnel info for 
> DS-Lite, what about re-using attributes defined in RFC 2868 ???
> 	 

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Envoyé : jeudi 29 juillet 2010 16:57
> À : [email-masked]
> Cc : [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Objet : RE: Comment on draft-maglione-softwire-dslite-radius-ext
> 
> Here is an example of what could be the content of tyhe draft 
> describing the use of the Tunnel attributes for DS-Lite Tunneling.
>    This document describes the use of the set of RADIUS 
> attributes defined in the RFC 2868 to support
>    in DHCPv6 options already specified in 
> [I-D.ietf-softwire-ds-lite-tunnel-option].
> 
> 2. Terminology
> 
> 
> 	Following my comment during the meeting, about 
> (re-)using an existing attribute to convey tunnel info for 
> DS-Lite, what about re-using attributes defined in RFC 2868 ???
> 	 
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Thu, 29 Jul 2010 15:17:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext
Date: Thu, 29 Jul 2010 17:16:30 +0200
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

 It seems that the first mail, sent yesterday, was not delivered.

> 	Following my comment during the meeting, about 
> (re-)using an existing attribute to convey tunnel info for 
> DS-Lite, what about re-using attributes defined in RFC 2868 ???
> 	 

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Envoyé : jeudi 29 juillet 2010 16:57
> À : [email-masked]
> Cc : [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Objet : RE: Comment on draft-maglione-softwire-dslite-radius-ext
> 
> Here is an example of what could be the content of tyhe draft 
> describing the use of the Tunnel attributes for DS-Lite Tunneling.
>    This document describes the use of the set of RADIUS 
> attributes defined in the RFC 2868 to support
>    in DHCPv6 options already specified in 
> [I-D.ietf-softwire-ds-lite-tunnel-option].
> 
> 2. Terminology
> 
> 
> 	Following my comment during the meeting, about 
> (re-)using an existing attribute to convey tunnel info for 
> DS-Lite, what about re-using attributes defined in RFC 2868 ???
> 	 
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Thu, 29 Jul 2010 15:00:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext
Date: Thu, 29 Jul 2010 16:56:34 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

BR,

Lionel

***********************

Abstract

1. Motivation

2. Terminology

         B4                        NAS                           AAA
         |                          |                          Server
         |                          |                             |
         |                          |                             |

                   DHCPv6                         RADIUS

3.1. Tunnel-Type

   Value   Name
   TBD1    DS-Lite Tunneling

3.2. Tunnel-Medium-Type

3.8. Tunnel-Preference

4. Table of Attributes

   TBD.

6. IANA Considerations

   Value   Name
   TBD1    DS-Lite Tunneling

7. References

	 
	 
	BR,
	 
	Lionel

Delivery-date: Wed, 28 Jul 2010 10:40:39 +0000
From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
To: radext mailing list <[email-masked]>
CC: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jul 2010 10:37:36 +0000
Subject: RADEXT WG Last Call: "RADIUS attributes for IPv6 Access Networks"
Accept-Language: en-US
acceptlanguage: en-US

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384A74C9GVW0671EXCame_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG last call on "RADIUS attributes for IPv6 Access Networks", prior to sending the document to the IESG for publication as a proposed standard RFC.

The document is available for inspection here:
http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/
The RADEXT WG last call will last until August 11, 2010.   If you have comments on the document, please file using TRAC system.  See below for summary of instructions.
Thanks,
MS

1.       To submit an issue in TRAC, you first need to login to the RADEXT WG site on the tools server:  http://tools.ietf.org/wg/radext/trac/login

2.       If you don't already have a login ID, you can obtain one by navigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account, and have logged in, you can file an issue by navigating to the  ticket entry form: http://trac.tools.ietf.org/wg/radext/trac/newticket

4.       When opening an issue:

a.       The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement).
b.      The Priority: field is set based on the severity of the Issue.   For example, editorial issues are typically "minor" or "trivial".
c.       The Milestone: field should be set to milestone1 (useless, I know).
d.      The Component: field should be set to the document you are filing the issue on.
e.      The Version: field should be set to "1.0".
f.        The Severity: field should be set to based on the status of the document (e.g. "In WG Last Call" for a document in WG last call)
g.        The Keywords: and CC: fields can be left blank unless inspiration seizes you.
h.      The Assign To: field is generally filled in with the email address of the editor.

5.       Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket".

6.       If you want to preview your Issue, click on the "Preview" button.  When you're ready to submit the issue, click on the "Create Ticket" button.

7.       If you want to update an issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1  Click on the ticket # you want to update, and then modify the ticket fields as required

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384A74C9GVW0671EXCame_
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:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</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=WordSection1>

<p class=MsoNormal style='line-height:14.4pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>This is an announcement of RADEXT WG last
call on &quot;</span><span style='font-size:10.0pt;font-family:"Courier New"'>RADIUS
attributes for IPv6 Access Networks</span><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>&quot;, prior to sending the document to
the IESG for publication as a proposed standard RFC. <br>
<br>
The document is available for inspection here:</span><span style='font-size:
10.0pt;font-family:"Courier New"'><o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'><a
href="http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/">http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/</a><o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>The RADEXT WG last call will last until August
11, 2010.&nbsp;&nbsp; If you have comments on the document, please file using
TRAC system.&nbsp; See below for summary of instructions. <o:p></o:p></span></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>Thanks,<br>
MS<o:p></o:p></span></p>

<div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>

<p class=MsoNormal style='margin-bottom:12.0pt;border:none;padding:0in'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p>&nbsp;</o:p></span></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To
submit an issue in TRAC, you first need to login to the RADEXT WG site on the
tools server:&nbsp; <a href="http://tools.ietf.org/wg/radext/trac/login">http://tools.ietf.org/wg/radext/trac/login</a>
<br>
<br>
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you don&#8217;t already have a login
ID, you can obtain one by navigating to this site:&nbsp;&nbsp; <a
href="http://trac.tools.ietf.org/newlogin">http://trac.tools.ietf.org/newlogin</a><br>
<br>
3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Once you have obtained an account, and
have logged in, you can file an issue by navigating to the&nbsp; ticket entry
form: <a href="http://trac.tools.ietf.org/wg/radext/trac/newticket">http://trac.tools.ietf.org/wg/radext/trac/newticket</a><br>
<br>
4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When opening an issue:<br>
<br>
a.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Type: field should be set to
&#8220;defect&#8221; for an issue with the current document text, or
&#8220;enhancement&#8221; for a proposed addition of functionality (such as an
additional requirement). <br>
b.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Priority: field is set based on the
severity of the Issue.&nbsp;&nbsp; For example, editorial issues are typically
&#8220;minor&#8221; or &#8220;trivial&#8221;. <br>
c.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Milestone: field should be set to
milestone1 (useless, I know). <br>
d.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Component: field should be set to the
document you are filing the issue on.&nbsp; <br>
e.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Version: field should be set to
&#8220;1.0&#8221;. <br>
f.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Severity: field should be set
to based on the status of the document (e.g. &#8220;In WG Last Call&#8221; for
a document in WG last call)<br>
g.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Keywords: and CC: fields can
be left blank unless inspiration seizes you. <br>
h.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Assign To: field is generally filled in
with the email address of the editor. <br>
<br>
5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Typically it won&#8217;t be necessary to
enclose a file with the ticket, but if you need to, select &#8220;I have files
to attach to this ticket&#8221;. <br>
<br>
6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you want to preview your Issue, click
on the &#8220;Preview&#8221; button.&nbsp; When you&#8217;re ready to submit
the issue, click on the &#8220;Create Ticket&#8221; button. <br>
<br>
7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you want to update an issue, go to
the &quot;View Tickets&quot; page: <a
href="http://trac.tools.ietf.org/wg/radext/trac/report/1">http://trac.tools.ietf.org/wg/radext/trac/report/1</a>&nbsp;
Click on the ticket # you want to update, and then modify the ticket fields as
required</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p>

</div>

</body>

</html>

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384A74C9GVW0671EXCame_--

Delivery-date: Wed, 28 Jul 2010 08:14:30 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Wed, 28 Jul 2010 08:14:15 -0000
Reply-To: [email-masked]
Subject: [radext] #60: Behavior in response to CoA-Request

#60: Behavior in response to CoA-Request
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  radsec                     |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------
 A question arose as to whether CoA/Disconnect traffic should go on the
 same connection as other RADIUS traffic and if so, how a NAS should behave
 if it receives a CoA/Disconnect-Request and it doesn't support RFC 5176.
 If the DAS drops it, the DAC will retransmit.  Should the DAS send a
 Disconnect/CoA-NAK instead?

-- 
Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/60>
radext <http://tools.ietf.org/radext/>

Delivery-date: Wed, 28 Jul 2010 08:10:43 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Wed, 28 Jul 2010 08:10:00 -0000
Reply-To: [email-masked]
Subject: [radext] #59: Section 2.2 Assigned Ports

#59: Section 2.2 Assigned Ports
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  defect                     |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  tcp-transport              |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
 * radius          1812/tcp
       * radius-acct     1813/tcp
       * radius-dynauth  3799/tcp
       * radsec          2083/tcp

 The question arose in the RADIUS over TLS document about which ports are
 used for Dynauth over TLS.  Looking at the above table, it seems unclear.
 Do you use port 3799/tcp or 2083/tcp?  This also relates to whether the
 same TCP/TLS connection can be used for traffic in both directions.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/59>
radext <http://tools.ietf.org/radext/>

Delivery-date: Tue, 27 Jul 2010 22:14:52 +0000
From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
To: radext mailing list <[email-masked]>
CC: Bernard Aboba <[email-masked]>
Date: Tue, 27 Jul 2010 22:12:27 +0000
Subject: RE: RADEXT agenda: Take IV
Accept-Language: en-US
acceptlanguage: en-US

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384A73A7GVW0671EXCame_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Take IV of agenda.

Cheers,
MS

RADEXT WG IETF 78 Agenda

Chairs:  Bernard Aboba <[email-masked]>
Mauricio Sanchez <[email-masked]>

Wednesday, July 28, 2010

0900-1015 Morning Session (0.8 Rome)

0900 - 0910:  Preliminaries
                                Blue Sheets
                                Note takers
                                Jabber Scribe
                                Agenda bash
                                Document Status

0910 - 0930:  RADIUS over TLS, Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

0930 - 0940:  RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

0940 - 0955:  NAI Discovery, Stefan Winter (15 minutes)
http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery

0955 - 1005:  RADIUS Attributes for DS-LITE, Roberta Maglione (10 minutes)
http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext

1005 - 1015:  Discussion (10 minutes)

1030 - 1130 Morning Session II (0.8 Rome)

1030 - 1040:  Preliminaries

                                Blue Sheets
                                Note takers
                                Jabber Scribe
                                Agenda bash

1040 - 1100:  Design Guidelines, Alan DeKok (20 minutes)
http://tools.ietf.org/wg/radext/draft-ietf-radext-design/

1100 - 1120:  Extended Attributes, Avi Lior and Alan DeKok (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes

1120 - 1130:  Wrap-up (10 minutes)

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

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri, sans-serif" size="2">
<div><font color="#1F497D">Take IV of agenda. </font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">Cheers,</font></div>
<div><font color="#1F497D">MS</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font face="Calibri, sans-serif" color="#1F497D">&nbsp;</font></div>
<div><font face="Calibri, sans-serif" color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">RADEXT WG IETF 78 Agenda</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">Chairs:&nbsp; Bernard Aboba &lt;[email-masked]&gt;</font></div>
<div><font color="#1F497D">Mauricio Sanchez &lt;[email-masked]&gt;</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">Wednesday, July 28, 2010</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">0900-1015 Morning Session (0.8 Rome)</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">0900 - 0910:&nbsp; Preliminaries</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Blue Sheets</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note takers</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jabber Scribe</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Agenda bash</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Document Status</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">0910 - 0930:&nbsp; RADIUS over TLS, Stefan Winter (20 minutes)</font></div>
<div><font color="#1F497D"><a href="http://tools.ietf.org/html/draft-ietf-radext-radsec">http://tools.ietf.org/html/draft-ietf-radext-radsec</a></font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">0930 - 0940:&nbsp; RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)</font></div>
<div><font color="#1F497D"><a href="http://tools.ietf.org/html/draft-dekok-radext-dtls">http://tools.ietf.org/html/draft-dekok-radext-dtls</a></font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">0940 - 0955:&nbsp; NAI Discovery, Stefan Winter (15 minutes)</font></div>
<div><font color="#1F497D"><a href="http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery">http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery</a></font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">0955 - 1005:&nbsp; RADIUS Attributes for DS-LITE, Roberta Maglione (10 minutes)</font></div>
<div><font color="#1F497D"><a href="http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext">http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext</a></font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">1005 - 1015:&nbsp; Discussion (10 minutes)</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">1030 - 1130 Morning Session II (0.8 Rome)</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">1030 - 1040:&nbsp; Preliminaries</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Blue Sheets</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note takers</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jabber Scribe</font></div>
<div><font color="#1F497D">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Agenda bash</font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">1040 - 1100:&nbsp; Design Guidelines, Alan DeKok (20 minutes)</font></div>
<div><font color="#1F497D"><a href="http://tools.ietf.org/wg/radext/draft-ietf-radext-design/">http://tools.ietf.org/wg/radext/draft-ietf-radext-design/</a></font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">1100 - 1120:&nbsp; Extended Attributes, Avi Lior and Alan DeKok (20 minutes)</font></div>
<div><font color="#1F497D"><a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes</a></font></div>
<div><font color="#1F497D">&nbsp;</font></div>
<div><font color="#1F497D">1120 - 1130:&nbsp; Wrap-up (10 minutes)</font></div>
<div><font face="Calibri, sans-serif">&nbsp;</font></div>
</font>
</body>
</html>

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384A73A7GVW0671EXCame_--

Delivery-date: Tue, 27 Jul 2010 16:21:44 +0000
From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
To: radext mailing list <[email-masked]>
CC: Bernard Aboba <[email-masked]>
Date: Tue, 27 Jul 2010 16:19:27 +0000
Subject: RADEXT agenda: Take III
Accept-Language: en-US
acceptlanguage: en-US

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384225CDGVW0671EXCame_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Take III of agenda for tomorrow. Any feedback on agenda, please email me or Bernard directly.

Cheers,
MS

RADEXT WG IETF 78 Agenda

Chairs:  Bernard Aboba <[email-masked]>
Mauricio Sanchez <[email-masked]>

Wednesday, July 28, 2010

0900-1015 Morning Session (0.8 Rome)

0900 - 0910:  Preliminaries
                                Blue Sheets
                                Note takers
                                Jabber Scribe
                                Agenda bash
                                Document Status

0910 - 0930:  RADIUS over TLS, Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

0930 - 0940:  RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

0940 - 1000:  NAI Discovery, Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery

1000 - 1015:   Discussion

1030 - 1130 Morning Session II (0.8 Rome)

1030 - 1040:  Preliminaries

                                Blue Sheets
                                Note takers
                                Jabber Scribe
                                Agenda bash

1040 - 1100:  Design Guidelines, Alan DeKok (20 minutes)
http://tools.ietf.org/wg/radext/draft-ietf-radext-design/

1100 - 1120:  Extended Attributes, Avi Lior and Alan DeKok (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes

1120 - 1130:  Wrap-up (10 minutes)

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384225CDGVW0671EXCame_
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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" 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;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</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=WordSection1>

<div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>

<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:10.0pt;
font-family:"Courier New"'>Take III of agenda for tomorrow. Any feedback on
agenda, please email me or Bernard directly. &nbsp;<o:p></o:p></span></p>

<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:10.0pt;
font-family:"Courier New"'>Cheers,<o:p></o:p></span></p>

<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:10.0pt;
font-family:"Courier New"'>MS<o:p></o:p></span></p>

<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal style='border:none;padding:0in'><span style='font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

</div>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>RADEXT
WG IETF 78 Agenda<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Chairs:&nbsp;
Bernard Aboba &lt;[email-masked]&gt;<o:p></o:p></span></p>

<p class=MsoNormal><span lang=ES-MX style='font-size:10.0pt;font-family:"Courier New"'>Mauricio
Sanchez &lt;[email-masked]&gt;<o:p></o:p></span></p>

<p class=MsoNormal><span lang=ES-MX style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Wednesday,
July 28, 2010<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>0900-1015
Morning Session (0.8 Rome)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>0900
- 0910:&nbsp; Preliminaries<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Blue Sheets<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Note takers<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Jabber Scribe<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Agenda bash<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Document Status<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>0910
- 0930:&nbsp; RADIUS over TLS, Stefan Winter (20 minutes)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>http://tools.ietf.org/html/draft-ietf-radext-radsec<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>0930
- 0940:&nbsp; RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>http://tools.ietf.org/html/draft-dekok-radext-dtls<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>0940
- 1000:&nbsp; NAI Discovery, Stefan Winter (20 minutes)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>1000
- 1015:&nbsp;&nbsp; Discussion<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>1030
- 1130 Morning Session II (0.8 Rome)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>1030
- 1040:&nbsp; Preliminaries<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Blue Sheets<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Note takers<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Jabber Scribe<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Agenda bash<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>1040
- 1100:&nbsp; Design Guidelines, Alan DeKok (20 minutes)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><a
href="http://tools.ietf.org/wg/radext/draft-ietf-radext-design/">http://tools.ietf.org/wg/radext/draft-ietf-radext-design/</a><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>1100
- 1120:&nbsp; Extended Attributes, Avi Lior and Alan DeKok (20 minutes)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><a
href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes</a><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>1120
- 1130:&nbsp; Wrap-up (10 minutes)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9BC2F7926B33FE4AB10D69891D58FC1C55384225CDGVW0671EXCame_--

Delivery-date: Mon, 26 Jul 2010 14:40:13 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 26 Jul 2010 14:40:02 -0000
Reply-To: [email-masked]
Subject: [radext] #58: Section A.4

#58: Section A.4
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  defect                     |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
 * Provisioning of service in an Access-Reject or
         Disconnect-Request.  Such provisioning is not permitted, and
         MUST NOT be used.  If limited access needs to be provided, then
         an Access-Accept with appropriate authorizations can be used
         instead.

       * Provisioning of service in a Disconnect-Request.
         Such provisioning is not permitted, and MUST NOT be used.
         If limited access needs to be provided, then a CoA-Request
         with appropriate authorizations can be used instead

 [BA] The text duplicates Section 3.1, yet is different (including
 different normative text).  Suggestion:

        * Provisioning of service in an Access-Reject.
         Such provisioning is not permitted, and
         MUST NOT be used.  If limited access needs to be provided, then
         an Access-Accept with appropriate authorizations can be used
         instead.

       * Provisioning of service in a Disconnect-Request.
         Such provisioning is not permitted, and MUST NOT be used.
         If limited access needs to be provided, then a CoA-Request
         with appropriate authorizations can be used instead.

-- 
Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/58>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 26 Jul 2010 14:36:47 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 26 Jul 2010 14:36:00 -0000
Reply-To: [email-masked]
Subject: [radext] #57: Disconnect-Request

#57: Disconnect-Request
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  defect                     |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
 Section 3.1

 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
    to deny access to the requested service.  As a result, RADIUS does
    not allow the provisioning of services within an Access-Reject or
    Disconnect-Request.  Documents which include provisioning of services
    within an Access-Reject or Disconnect-Request are inherently
    incompatible with RADIUS, and SHOULD be redesigned.

    As noted in [RFC5176] Section 3:

       A Disconnect-Request MUST contain only NAS and session
       identification attributes.  If other attributes are included in a
       Disconnect- Request, implementations MUST send a Disconnect-NAK;
       an Error-Cause Attribute with value "Unsupported Attribute" MAY be
       included.

    As a result, documents which include provisioning of services within
    a Disconnect-Request are inherently incompatible with RADIUS, and
    SHOULD be redesigned.

 [BA] This text says "SHOULD redesign" to recommend against a practice that
 is a MUST NOT in the specifications.  Given that there is a mandate, that
 seems like a bad idea.

    As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
    to deny access to the requested service.  As a result, RADIUS does
    not allow the provisioning of services within an Access-Reject.
    Documents which include provisioning of services
    within an Access-Reject are inherently
    incompatible with RADIUS, and need to be redesigned.

    As noted in [RFC5176] Section 3:

       A Disconnect-Request MUST contain only NAS and session
       identification attributes.  If other attributes are included in a
       Disconnect- Request, implementations MUST send a Disconnect-NAK;
       an Error-Cause Attribute with value "Unsupported Attribute" MAY be
       included.

    As a result, documents which include provisioning of services within
    a Disconnect-Request are inherently incompatible with RADIUS, and
    need to be redesigned.

-- 
Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/57>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 26 Jul 2010 12:01:31 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-17.txt 
Date: Mon, 26 Jul 2010 05:00:01 -0700 (PDT)

--NextPart

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

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-17.txt
	Pages           : 37
	Date            : 2010-07-26

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-17.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-design-17.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Wed, 21 Jul 2010 18:46:47 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IETF 78 RADEXT Agenda - Take Two
Date: Wed, 21 Jul 2010 11:45:26 -0700

--_5765c1fd-8f78-4dd0-9d09-1affa673551b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please find enclosed a draft IETF 78 Agenda for RADEXT
WG.  If you'd like to propose an agenda item, please contact Mauricio or
myself ASAP. 

Wednesday, July 28, 2010

0900-1015 Morning Session (0.8 Rome)

0900 - 0910:  Preliminaries

                                Blue
Sheets

                                Note
takers

                                Jabber
Scribe

                                Agenda
bash

                                Document
Status

0910 - 0930:  RADIUS over TLS, Stefan Winter (20
minutes)

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

0930 - 0940:  RADIUS over DTLS, Alan DeKok or Stefan
Winter (10 minutes)

http://tools.ietf.org/html/draft-dekok-radext-dtls

0940 - 0955:  NAI Discovery, Stefan Winter (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery
0955 - 1005: RADIUS Attributes for DS-LITE Address Family Translation Router, Roberta Maglione (10 minutes)http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext 

1005 - 1015:   Discussion

1030 - 1130 Morning Session II (0.8 Rome)

1030 - 1040:  Preliminaries

                                Blue
Sheets

                                Note
takers

                                Jabber
Scribe

                                Agenda
bash

1040 - 1110:  Extended Attributes, Avi Lior and Alan
DeKok (30 minutes)

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

--_5765c1fd-8f78-4dd0-9d09-1affa673551b_
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'>
<div class="WordSection1">

<p class="MsoNormal">Please find enclosed a draft IETF 78 Agenda for RADEXT
WG.&nbsp; If you'd like to propose an agenda item, please contact Mauricio or
myself ASAP. <o:p></o:p></p>

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

<p class="MsoNormal">Wednesday, July 28, 2010<o:p></o:p></p>

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

<p class="MsoNormal">0900-1015 Morning Session (0.8 Rome)<o:p></o:p></p>

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

<p class="MsoNormal">0900 - 0910:&nbsp; Preliminaries<o:p></o:p></p>

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

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

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

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

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

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

<p class="MsoNormal">0910 - 0930:&nbsp; RADIUS over TLS, Stefan Winter (20
minutes)<o:p></o:p></p>

<p class="MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-radsec<o:p></o:p></p>

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

<p class="MsoNormal">0930 - 0940:&nbsp; RADIUS over DTLS, Alan DeKok or Stefan
Winter (10 minutes)<o:p></o:p></p>

<p class="MsoNormal">http://tools.ietf.org/html/draft-dekok-radext-dtls<o:p></o:p></p>

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

<p class="MsoNormal">0940 - 0955:&nbsp; NAI Discovery, Stefan Winter (15 minutes)<o:p></o:p></p>

<p class="MsoNormal">http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery</p><p class="MsoNormal"><br></p><p class="MsoNormal">0955 - 1005: RADIUS Attributes for DS-LITE Address Family Translation Router, Roberta Maglione (10 minutes)</p><p class="MsoNormal">http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext</p><p class="MsoNormal"></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p>

<p class="MsoNormal">1005 - 1015:&nbsp;&nbsp; Discussion<o:p></o:p></p>

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

<p class="MsoNormal">1030 - 1130 Morning Session II (0.8 Rome)<o:p></o:p></p>

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

<p class="MsoNormal">1030 - 1040:&nbsp; Preliminaries<o:p></o:p></p>

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

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

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

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

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

<p class="MsoNormal">1040 - 1110:&nbsp; Extended Attributes, Avi Lior and Alan
DeKok (30 minutes)<o:p></o:p></p>

<p class="MsoNormal">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes<o:p></o:p></p>

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

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

</div> 		 	   		  </body>
</html>
--_5765c1fd-8f78-4dd0-9d09-1affa673551b_--

Delivery-date: Wed, 21 Jul 2010 18:46:38 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Slides
Date: Wed, 21 Jul 2010 11:46:11 -0700

--_fabc4637-5274-41e5-a29d-154f1d06964a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you are on the agenda for the IETF 78 RADEXT WG, please send slides to myself and Mauricio. 
 		 	   		  
--_fabc4637-5274-41e5-a29d-154f1d06964a_
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'>
If you are on the agenda for the IETF 78 RADEXT WG, please send slides to myself and Mauricio. <br> 		 	   		  </body>
</html>
--_fabc4637-5274-41e5-a29d-154f1d06964a_--

Delivery-date: Wed, 21 Jul 2010 18:46:32 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: IETF 78 Agenda - Take One
Date: Wed, 21 Jul 2010 11:45:30 -0700

--_8d873d67-2c1d-4547-9a48-dbf87af462c8_
Content-Type: multipart/alternative;
	boundary="_b2dab9e1-0ef4-4748-ab50-d9f8c9023087_"

--_b2dab9e1-0ef4-4748-ab50-d9f8c9023087_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No problem. 

From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]
Date: Tue, 13 Jul 2010 09:31:43 +0200
Subject: RE: IETF 78 Agenda - Take One

Hello,
    If it is possible I'd like to have 10 min to present draft-maglione-softwire-dslite-radius-ext-00 (http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext-00)
This document describes two new RADIUS attributes to carry Dual-Stack Lite Address Family Transition Router (AFTR) IPv6
 address and name.
Our intention would be to keep this work in softwire WG, but we would appreciate a review from RADEXT WG.  
 
Thanks and best regards,
Roberta

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba

Sent: lunedì 12 luglio 2010 21.21

To: [email-masked]

Subject: IETF 78 Agenda - Take One

Please find enclosed a draft IETF 78 Agenda for RADEXT WG.  If you'd like to propose an agenda item, please contact Mauricio or myself ASAP.

Wednesday, July 28, 2010
 
0900-1015 Morning Session (0.8
Rome)
 
0900 - 0910:  Preliminaries
                                Blue Sheets
                                Note takers
                                Jabber Scribe
                                Agenda bash
                                Document Status
 
0910 - 0930:  RADIUS over TLS, Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
 
0930 - 0940:  RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls
 
0940 - 1000:  NAI Discovery, Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery
 
1000 - 1015:   Discussion

1030 - 1130 Morning Session II (0.8
Rome)
 
1030 - 1040:  Preliminaries
                                Blue Sheets
                                Note takers
                                Jabber Scribe
                                Agenda bash
 
1040 - 1110:  Extended Attributes, Avi Lior and Alan DeKok (30 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi
 altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential
 and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender
 by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

--_b2dab9e1-0ef4-4748-ab50-d9f8c9023087_
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'>
No problem. <br><br><hr id="stopSpelling">From: [email-masked]<br>To: [email-masked]; [email-masked]<br>CC: [email-masked]<br>Date: Tue, 13 Jul 2010 09:31:43 +0200<br>Subject: RE: IETF 78 Agenda - Take One<br><br>

<style>
.ExternalClass .ecxshape
{;}
</style>

<style>
</style>
<style>
.ExternalClass a:link
{;}
.ExternalClass span.ecxMSOHYPERLINK
{;}
.ExternalClass a:visited
{;}
.ExternalClass span.ecxMSOHYPERLINKFOLLOWED
{;}
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal
{margin-bottom:.0001pt;font-size:11.0pt;font-family:Calibri;}
.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink
{color:blue;text-decoration:underline;}
.ExternalClass a:visited, .ExternalClass span.ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
.ExternalClass span.ecxEmailStyle17
{font-family:Calibri;color:windowtext;}
.ExternalClass span.ecxEmailStyle18
{font-family:Arial;color:navy;}
@page Section1
{size:612.0pt 792.0pt;}
.ExternalClass div.ecxSection1
{page:Section1;}
</style>

<div class="ecxSection1">
<p class="ecxMsoNormal" style=""><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';">Hello,</span></font></p>
<p class="ecxMsoNormal" style=""><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;&nbsp;&nbsp; If it is possible I'd like to have 10 min to present draft-maglione-softwire-dslite-radius-ext-00 (http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext-00)</span></font></p>
<p class="ecxMsoNormal" style=""><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';">This document describes two new RADIUS attributes to carry Dual-Stack Lite Address Family Transition Router (AFTR) IPv6
 address and name.</span></font></p>
<p class="ecxMsoNormal" style=""><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';">Our intention would be to keep this work in softwire WG, but we would appreciate a review from RADEXT WG. &nbsp;</span></font></p>
<p class="ecxMsoNormal" style=""><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';">&nbsp;</span></font></p>
<p class="ecxMsoNormal" style=""><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';" lang="IT">Thanks and best regards,</span></font></p>
<p class="ecxMsoNormal"><font face="Courier New" size="2"><span style="font-size: 10pt; font-family: 'Courier New';" lang="IT">Roberta</span></font><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"></span></font></p>
<p class="ecxMsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">&nbsp;</span></font></p>
<div>
<div class="ecxMsoNormal" style="text-align: center;" align="center"><font face="Times New Roman" size="3"><span style="font-size: 12pt; font-family: 'Times New Roman';">
<hr align="center" size="2" width="100%">
</span></font></div>
<p class="ecxMsoNormal"><b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma;"> [email-masked] [mailto:[email-masked]]
<b><span style="font-weight: bold;">On Behalf Of </span></b>Bernard Aboba<br>
<b><span style="font-weight: bold;">Sent:</span></b> lunedì 12 luglio 2010 21.21<br>
<b><span style="font-weight: bold;">To:</span></b> [email-masked]<br>
<b><span style="font-weight: bold;">Subject:</span></b> IETF 78 Agenda - Take One</span></font><font face="Times New Roman" size="3"><span style="font-size: 12pt; font-family: 'Times New Roman';"></span></font></p>
</div>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">Please find enclosed a draft IETF 78 Agenda for RADEXT WG.&nbsp; If you'd like to propose an agenda item, please contact Mauricio or myself ASAP.
</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">Wednesday, July 28, 2010</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">0900-1015 Morning Session (0.8
Rome)</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">0900 - 0910:&nbsp; Preliminaries</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Blue Sheets</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note takers</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jabber Scribe</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Agenda bash</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Document Status</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">0910 - 0930:&nbsp; RADIUS over TLS, Stefan Winter (20 minutes)</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">http://tools.ietf.org/html/draft-ietf-radext-radsec</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">0930 - 0940:&nbsp; RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">http://tools.ietf.org/html/draft-dekok-radext-dtls</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">0940 - 1000:&nbsp; NAI Discovery, Stefan Winter (20 minutes)</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">1000 - 1015:&nbsp;&nbsp; Discussion</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">1030 - 1130 Morning Session II (0.8
Rome)</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">1030 - 1040:&nbsp; Preliminaries</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Blue Sheets</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note takers</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jabber Scribe</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Agenda bash</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">1040 - 1110:&nbsp; Extended Attributes, Avi Lior and Alan DeKok (30 minutes)</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
<p class="ecxMsoNormal"><font face="Calibri" size="2"><span style="font-size: 11pt;">&nbsp;</span></font></p>
</div>
<style>
.ExternalClass span.ecxGramE
{;}
</style>
<table style="width: 600px;">
<tbody>
<tr>
<td style="width: 585px; font-family: Verdana,Arial; font-size: 12px; color: rgb(0, 0, 0); text-align: justify;" width="395">
<div align="justify"><span class="ecxMsoNormal" style="text-align: justify; line-height: normal;"><span style="font-size: 7.5pt; font-family: Verdana;">Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi
 altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
</span></span></div>
<p align="justify"><span class="ecxMsoNormal" style="text-align: justify; line-height: normal;"><i><span style="font-size: 7.5pt; font-family: Verdana;" lang="EN-GB">This e-mail and any attachments</span></i><i><span style="font-size: 7.5pt; font-family: Verdana;" lang="EN-GB">&nbsp;<span class="ecxGramE">is</span>&nbsp;</span></i><i><span style="font-size: 7.5pt; font-family: Verdana;" lang="EN-GB">confidential
 and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender
 by return e-mail, Thanks.</span></i><span style="" lang="EN-GB">
</span></span></p>
<b><span style="font-size: 7.5pt; font-family: Verdana;"><img src="cid:[email-masked]" alt="rispetta l'ambiente" height="40" width="26">Rispetta l'ambiente. Non stampare questa mail se non è necessario.</span></b>
<BR>
</td>
</tr>
</tbody>
</table> 		 	   		  </body>
</html>
--_b2dab9e1-0ef4-4748-ab50-d9f8c9023087_--

--_8d873d67-2c1d-4547-9a48-dbf87af462c8_
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
Content-ID: [email-masked]
Content-Disposition: attachment; filename="logo Ambiente_foglia.jpg"

--_8d873d67-2c1d-4547-9a48-dbf87af462c8_--

Delivery-date: Wed, 21 Jul 2010 03:50:54 +0000
Date: Mon, 12 Jul 2010 13:03:30 +0200
From: Klaas Wierenga <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Cc: Moonshot community list <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements

On 7/9/10 7:30 PM, Hannes Tschofenig wrote:

Hi Hannes,

> sorry for the late response.

np

>
> Interesting statement.
>
> I agree that there are other approaches (and probably everyone would
> agree with that; we could even list Kerberos).
>
> However, the MOONSHOT BOF is (if I understood it correctly)
> constraint to the mentioned constraints.

hmm, afaik it is a federated authentication BoF, not a Moonshot BoF

>
> The usage of OpenID in SASL/GSS-API (like you pointed out) will be
> done in KITTEN independently and has different design constraints.

I think there is a bit of misunderstanding, I gave those just as an 
example because I happen to be familiar with them. I am happy with those 
drafts being in KITTEN, if only to speed things up. So that is not the 
point.

My point is that I'd like the BoF to start open-minded. I believe 
federated authentication for non-Web is a large and interesting area. I 
would like to make sure that we don't rule out beforehand alternative 
approaches. I am happy with a charter as outcome that specifies that the 
WG is going to take the Moonshot approach, but imo that should be the 
*result* of the BoF, not a *precondition*.

Hope this clarifies the misunderstanding.

Klaas

>
> Ciao Hannes
>
>> On 7/6/10 11:15 AM, Hannes Tschofenig wrote:
>>
>> Hi Hannes,
>>
>>> at the next IETF meeting we are going to have a BOF about
>>> "Federated
>> Authentication Beyond The Web". In case you have not noticed the
>> work relates to RADIUS and Diameter.
>>>
>>> I wrote this very short problem statement document to explain
>>> the
>> purpose of the BOF:
>>> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
>>>
>>>
>>>
Let me know if you find the description useful. Feedback about the BOF
>> topic would also be appreciated.
>>
>> I find the description useful, however I would like to challenge
>> the MUST for RADIUS and/or Diamter. There are a number of
>> Federated Authentication for applications access protocols out
>> there, SAML, OpenID and others. RADIUS and Diamter are typically
>> associated with network access. And while I do see the
>> attractiveness of marrying the two (and thus leveraging existing
>> trust fabrics), I wonder why you want to restrict a priori to just
>> those. As an example draft-cantor-ietf-sasl-saml-ec-00.txt,
>> draft-lear-ietf-sasl-openid-00, and
>> draft-wierenga-ietf-sasl-saml-00 specify the use of federated
>> authentication in a SASL context. And services like eduroam are an
>> example of the use of just RADIUS to implement federated
>> authentication for non-web applications. I do understand that it is
>> not possible nor desirable to take on everything, but let's at
>> least have this scoping discussion in the BoF.
>>
>> Klaas
>>
>> -- to unsubscribe send a message to [email-masked]
>> with the word 'unsubscribe' in a single line as the message text
>> body. archive:<http://psg.com/lists/radiusext/>

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

Delivery-date: Wed, 21 Jul 2010 03:50:46 +0000
Date: Tue, 06 Jul 2010 12:40:16 +0200
From: Klaas Wierenga <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements

On 7/6/10 11:15 AM, Hannes Tschofenig wrote:

Hi Hannes,

> at the next IETF meeting we are going to have a BOF about "Federated Authentication Beyond The Web". In case you have not noticed the work relates to RADIUS and Diameter.
>
> I wrote this very short problem statement document to explain the purpose of the BOF:
> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
>
> Let me know if you find the description useful. Feedback about the BOF topic would also be appreciated.

I find the description useful, however I would like to challenge the 
MUST for RADIUS and/or Diamter. There are a number of Federated 
Authentication for applications access protocols out there, SAML, OpenID 
and others. RADIUS and Diamter are typically associated with network 
access. And while I do see the attractiveness of marrying the two (and 
thus leveraging existing trust fabrics), I wonder why you want to 
restrict a priori to just those. As an example 
draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, 
and draft-wierenga-ietf-sasl-saml-00 specify the use of federated 
authentication in a SASL context. And services like eduroam are an 
example of the use of just RADIUS to implement federated authentication 
for non-web applications.
I do understand that it is not possible nor desirable to take on 
everything, but let's at least have this scoping discussion in the BoF.

Klaas
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

Delivery-date: Tue, 20 Jul 2010 20:31:34 +0000
Date: Tue, 06 Jul 2010 12:40:16 +0200
From: Klaas Wierenga <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements

On 7/6/10 11:15 AM, Hannes Tschofenig wrote:

Hi Hannes,

> at the next IETF meeting we are going to have a BOF about "Federated Authentication Beyond The Web". In case you have not noticed the work relates to RADIUS and Diameter.
>
> I wrote this very short problem statement document to explain the purpose of the BOF:
> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
>
> Let me know if you find the description useful. Feedback about the BOF topic would also be appreciated.

I find the description useful, however I would like to challenge the 
MUST for RADIUS and/or Diamter. There are a number of Federated 
Authentication for applications access protocols out there, SAML, OpenID 
and others. RADIUS and Diamter are typically associated with network 
access. And while I do see the attractiveness of marrying the two (and 
thus leveraging existing trust fabrics), I wonder why you want to 
restrict a priori to just those. As an example 
draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, 
and draft-wierenga-ietf-sasl-saml-00 specify the use of federated 
authentication in a SASL context. And services like eduroam are an 
example of the use of just RADIUS to implement federated authentication 
for non-web applications.
I do understand that it is not possible nor desirable to take on 
everything, but let's at least have this scoping discussion in the BoF.

Klaas
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

Delivery-date: Sat, 17 Jul 2010 17:45:46 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Sat, 17 Jul 2010 17:44:14 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #55: Disconnect-Request

#55: Disconnect-Request
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  enhancement                |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------

Comment(by bernard_aboba@â€¦):

 Recommendation is to change the text as follows:

 Change:
     Documents which include provisioning of services within an Access-
     Reject are inherently incompatible with RADIUS, and SHOULD be
     redesigned.

 To:

     Documents which include provisioning of services within an Access-
     Reject or Disconnect-Request are inherently incompatible with RADIUS
     and need to be redesigned.

 for A.4, proposed text is:

     * Provisioning of service in an Access-Reject. Such provisioning is
 not permitted by RFC 2865. If limited access needs to be provided, then an
 Access-Accept with appropriate authorizations can be used instead.

     * Provisioning of service in a Disconnect-Request. Such provisioning
 is not permitted, by RFC 5176. If limited access needs to be provided,
 then a CoA-Request with appropriate authorizations can be used instead.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/55#comment:3>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 16 Jul 2010 04:03:36 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Slides
Date: Thu, 15 Jul 2010 21:02:39 -0700

--_b9a04bc5-70c0-4d98-b38d-bc916df070a7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, it seems like only yesterday (and in fact, it was just last week) when the RADEXT WG met virtually, but the time for our face to face meeting at IETF 78 is rolling around soon,  this time in beautiful scenic Maastricht, Netherlands.  If you have figured out how to get there (I'm still working on it) and are on the agenda, or if you want to be on the agenda, please send slides to myself and Mauricio.  One of us is bound to make it in order to chair the meeting. 

And if you don't plan to attend but would like to present anyway, also drop us a line.  Even though WebEx presentation is no longer supported, there are some ways to do it (e.g. Skype) that may work. 
 		 	   		  
--_b9a04bc5-70c0-4d98-b38d-bc916df070a7_
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'>
Yes, it seems like only yesterday (and in fact, it was just last week) when the RADEXT WG met virtually, but the time for our face to face meeting at IETF 78 is rolling around soon,&nbsp; this time in beautiful scenic Maastricht, Netherlands.&nbsp; If you have figured out how to get there (I'm still working on it) and are on the agenda, or if you want to be on the agenda, please send slides to myself and Mauricio.&nbsp; One of us is bound to make it in order to chair the meeting. <br><br>And if you don't plan to attend but would like to present anyway, also drop us a line.&nbsp; Even though WebEx presentation is no longer supported, there are some ways to do it (e.g. Skype) that may work. <br> 		 	   		  </body>
</html>
--_b9a04bc5-70c0-4d98-b38d-bc916df070a7_--

Delivery-date: Tue, 13 Jul 2010 08:56:35 +0000
Date: Tue, 13 Jul 2010 10:55:23 +0200
From: "Hannes Tschofenig" <[email-masked]>
Subject: Updated draft about "Federated Authentication Beyond The Web:  Problem Statement and Requirements"
To: [email-masked], [email-masked], [email-masked]

--====GMX107941279011323929753
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi all, 

I updated the draft based on the received feedback (but missed the submission deadline). Please find it attached to this mail. 

Let me know if you think the writeup useful. 

Ciao
Hannes

--====GMX107941279011323929753
Content-Type: text/plain;
 charset="iso-8859-15";
 name="draft-tschofenig-moonshot-ps-01.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="draft-tschofenig-moonshot-ps-01.txt"

MOONSHOT                                                   H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                           July 13, 2010
Expires: January 14, 2011

     Federated Authentication Beyond The Web: Problem Statement and
                              Requirements
                  draft-tschofenig-moonshot-ps-01.txt

Abstract

   It is quite common that application developers and system architects
   are in need for authentication and authorization support in a
   distributed environment.  At least three parties need to cooperate,
   namely the end host, the identity provider, and the relying party.
   At the end of the exchange the identity provider asserts identity
   information or certain attributes to the relying party without
   exposing the user's long-term secret to the relying party.

   Although the problem sounds challenging and interesting, it is not
   new.  In fact, various IETF groups have produced specifications to
   solve this problem, such as Kerberos, RADIUS, and Diameter.  Outside
   the IETF various Single-Sign-On solution for HTTP-based applications
   have been developed as well.

   The reader might therefore wonder about the need for new work given
   the existence of readily available solutions.  This document tries to
   answer this question in a compact fashion.  Note that the description
   in this document focuses on the scope of the new work as part of the
   "Federated Authentication Beyond The Web" BOF being proposed rather
   than what could be theoretically done.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Tschofenig              Expires January 14, 2011                [Page 1]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

   This Internet-Draft will expire on January 14, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Tschofenig              Expires January 14, 2011                [Page 2]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Assumptions and Requirements . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14

Tschofenig              Expires January 14, 2011                [Page 3]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

1.  Introduction

   The typical setup for a three party protocol involves the End-host,
   the identity-provider and relying party as illustrated in Figure 1.
   It might be of surprise that there are actually four parties shown in
   Figure 1; we will address the invisible party in the middle a little
   bit later.

   With three party protocols there are a number of different protocol
   variants possible, as the available crypto-literature shows.  We will
   not discuss the different options in this document.  What is relevant
   is that a real world entity is behind the end host and responsible
   for establishing some form of contract with the identity provider,
   even if it is only as weak as completing a web form and confirming
   the verification email.  The outcome of this initial registration
   step is that credentials are made available to the identity provider
   and to the end host (or the user).  It is important to highlight that
   in some scenarios there might indeed be a human behind the device
   denoted as end host and in other cases there is no human involved in
   the actual protocol execution.

   We assume that the identity provider and the relying party belong to
   different administrative domains.  Very often there is some form of
   relationship between the identity provider and the relying party.
   This is particularly important when the relying party wants to use
   information obtained from the identity provider for authorization
   decisions and when the identity provider does not want to release
   information to every relying party (or only under certain
   conditions).  While it is possible to have a bilateral agreement
   between every identity provider and every relying party; on an
   Internet scale this setup does require some intermediary, the "stuff-
   in-the-middle".  Please note that the lack of scalability is not
   caused by technical limitations but rather by business limitations
   since the agreements between identity providers and the relying
   parties are often business contracts that are financially motivated.
   The "stuff-in-the-middle" is a placeholder for technical
   interoperability as well as business practices and operational
   arrangements, many aspects are outside the scope of the IETF.

      Agreed terminology for what is labeled as generically "stuff-in-
      the-middle" is unfortunately not available.  Sometimes the term
      "identity federation", or "trust framework" are used.  To make it
      worse, different terminology is used when looking at specific
      protocols.

Tschofenig              Expires January 14, 2011                [Page 4]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

                            -----
                          /-     -\
                        //         \\
                        /           \
           ----        |             |        ----
       ///-    -\\\   |               |   ///-    -\\\
      /            \  |   Stuff-in-   |  /            \
     |              |-+   the-Middle  +-|              |
     |   Identity   | |               | |  Relying     |
     |   Provider   | |               | |  Party       |
     |              |  |             |  |              |
      \            /    \           /    \            /
       \\\-    -///     \\         //     \\\-    -///
           ----           \-     -/           ----
               <            -----              >
                \                             /
                 \                           /
                  \                         /
                  \                        /
                   \                      /
                    \                    /
                     \  +------------+  /
                      \ |            | /
                       v|  End Host  |v
                        |            |
                        |            |
                        +------------+

              Figure 1: Three Party Authentication Framework

   Designing new three party authentication and authorization protocols
   is hard and cryptographic flaws common in designs.  Achieving
   widespead deployment is even more difficult.  The HTTP-based Web has
   enjoyed a lot of attention from the industry with respect to this
   problem and some amount of success can be noticed even though many of
   the business aspects with the "stuff-in-the-middle" still has to be
   sorted out.  This document does not focus on an HTTP-based
   environment and instead focuses on those protocols where HTTP is not
   used.  Despite the increased excitement for layering every protocol
   on top of HTTP there are still a number of protocols available that
   do not use HTTP-based transports.  Many of these protocols are
   lacking an authentication and authorization framework of the style
   shown in Figure 1.

   Interestingly, for network access authentication the usage of the AAA
   framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite
   successful from a deployment point of view.  To map the terminology
   used in Figure 1 to the AAA framework the identity provider

Tschofenig              Expires January 14, 2011                [Page 5]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

   corresponds to the AAA server, the relying party corresponds to the
   AAA client, and the "stuff-in-the-middle" are AAA proxies and relays
   (particularly if they are operated by third parties, such as AAA
   brokers and clearing houses).  The front-end, i.e. the end host to
   AAA client communication, is in case of network access authentication
   offered by link layer protocols that forward authentication protocol
   exchanges back-and-forth.

   Is it possible to design a system that builds on top of successful
   protocols to offer non-Web-based protocols with a solid starting
   point for authentication and authorization in a distributed system?

Tschofenig              Expires January 14, 2011                [Page 6]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

2.  Terminology

Tschofenig              Expires January 14, 2011                [Page 7]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

3.  Assumptions and Requirements

   Some requirements restrict the solution space more than others.  In
   this particular case the main requirement is to re-use an existing
   infrastructure, namely the AAA framework.  Briefly stated: The
   solution MUST make use of the AAA infrastructure (RADIUS and
   Diameter).  Ideally, modifications at AAA servers SHOULD be kept at a
   minimum.  Modifications to the AAA infrastructure that affect
   operational aspects MUST NOT be made.

   The next requirement concerns security: The relying party MUST NOT
   get in possession of the long-term secret of the entity that is
   authenticated towards the AAA server.  Since there is no single
   authentication mechanism that will be used everywhere there is
   another associated requirement: The authentication framework MUST
   allow for the flexible integration of authentication mechanisms.

      Those who are familiar with the AAA framework might realize that
      the choices are limited.  The standardized Extensible
      Authentication Protocol (EAP) framework [RFC3748] fits the above
      requirements and is widely deployed.

   Assuming that this design decision is taken for granted the remaining
   work is with the integration of the AAA infrastructure into non-Web-
   based application protocols.  Figure 2 illustrates it graphically.

Tschofenig              Expires January 14, 2011                [Page 8]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

                                     +--------------+ business
                                     |AAA Server    | agreements
                                     |(Identity     | <......+
                                     |Provider)     |        .
                                     |              |        .
                                     +------------+-+        .
                                     --^----------|--   .    .
                                /////  |          |  \\\\\   .
                              //       |          |       \\ . ***
                             |         |  AAA     |         |. back-
                             |         | protocol |         |. end
                             |         |          |         |. ***
                              \\       |          |       // .
                                \\\\\  |          |  /////   .
                                     --|----------|--   .    .
                     Authentication    |          |          .
                     and Security      |          v          .
    +-------------+  Layer           +-+----------+--+       .
    |             |<---------------->|               |<-.....+
    | Application |                  | Server Side   |
    | @ End Host  |  Application     | Application   |
    |             |<========>|(Relying Party)|
    +-------------+  Application     +---------------+
                     Data

                     *** front-end ***

                      Figure 2: Front-End Integration

   The front-end (end host to relying party) communication MUST be
   integrated into the authentication framework available to the back-
   end.  As argued previously the end-to-end authentication framework is
   EAP.  Although EAP support is already integrated in AAA systems (see
   [RFC3579] and [RFC4072]) the challenge remains to carry EAP payloads
   from the end host to the relying party using some mechanism.

      For illustrative purposes, some examples of the front-end
      protocols suitable for carrying EAP are "TLS using EAP
      Authentication" [I-D.nir-tls-eap], and GSS-API Mechanism for the
      EAP [I-D.howlett-eap-gss].

   The changes to the end host and the changes to the relying party
   SHOULD be kept at a minimum.  A mechanism that can demonstrate
   deployment benefits (based on ease of update of existing software,
   low implementation effort, etc.)  MUST be preferred.  There MAY be a
   need to specify multiple mechanisms to support the range of different
   deployment scenarios.

Tschofenig              Expires January 14, 2011                [Page 9]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

4.  Security Considerations

   This entire document is about security.

Tschofenig              Expires January 14, 2011               [Page 10]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

5.  IANA Considerations

   This document does not require actions by IANA.

Tschofenig              Expires January 14, 2011               [Page 11]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

6.  Acknowledgments

   The author would like to thank Sam Hartman for a discussion about all
   aspects of the "Federated Authentication Beyond The Web" effort when
   he was visiting MIT in June 2010.

   I would like to thank Mayutan Arumaithurai and Klaas Wierenga for
   their feedback.

Tschofenig              Expires January 14, 2011               [Page 12]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application", RFC 4072,
              August 2005.

7.2.  Informative References

   [I-D.nir-tls-eap]
              Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "TLS
              using EAP Authentication", draft-nir-tls-eap-08 (work in
              progress), July 2010.

   [I-D.howlett-eap-gss]
              Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
              Extensible Authentication Protocol",
              draft-howlett-eap-gss-00 (work in progress), March 2010.

Tschofenig              Expires January 14, 2011               [Page 13]

Internet-Draft     Federated Auth. Beyond The Web: PS          July 2010

Author's Address

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: [email-masked]
   URI:   http://www.tschofenig.priv.at

Tschofenig              Expires January 14, 2011               [Page 14]


--====GMX107941279011323929753--

Delivery-date: Mon, 12 Jul 2010 23:51:15 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Draft minutes of the RADEXT Virtual Interim Meeting of July 12, 2010
Date: Mon, 12 Jul 2010 16:50:18 -0700

--_5afc3166-8322-4850-be41-c72f23329b95_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT Virtual Interim Meeting
Monday, July 12, 2010
Meeting starts:  11:10 AM Pacific Time

Chairs:  Bernard Aboba <[email-masked]>
Mauricio Sanchez <[email-masked]>

Minutes

Attendees: 
Dan Romascanu
Dave Mitton
Avi Lior
Stefan Winter
Alan DeKok
W. Dec
Bernard Aboba
Mauricio Sanchez

Agenda

Document Status

The Status-Server draft is now in the RFC Editor Queue.
Dan Romascanu:  Is there a dependency preventing it from being published as an RFC?
Bernard Aboba:  The draft entered the queue on June 7, 2010.  There is no indication of a 
dependency or other holdup.  

Design Guidelines has completed IETF last call and is awaiting resolution of the remaining
issues submitted during the WG "Last Look".   We will discuss the status of the remaining issues today.

The RADIUS over TCP draft is now in state IESG Evaluation: AD Followup, after submission of
the recent update to address IESG comments. 

The IPv6 Access document has now completed WG last call and resolved all open issues. 

The RADSEC document has completed WG last call, but issues remain open. 
 
RADIUS over TCP, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp

A new draft has been submitted that is believed to address IESG comments.
Dan Romascanu:  Has Ralph Drom's DISCUSS comment been addressed? 
Alan DeKok:  I think that all IESG comments have been addressed including Ralph's. 
Dan Romascanu:  I will bring the new version to the attention of the IESG and we will see where we stand.

Design Guidelines, Alan DeKok (30 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-guidelines

The RADEXT WG "Last Look" completed on June 28, 2010 and a summary was sent to the list:
http://ops.ietf.org/lists/radiusext/2010/msg00493.html
Since then a -15 and a -16 have been submitted to address the vast majority of the issues submitted. 

The intent is to submit a -17 version of the document, addressing outstanding issues still open in the 
tracker.  This includes cleanup of Section 3.3.2 and some redundancy removal.
Bernard Aboba:  One thing I noticed is that a number of section references are wrong due to the reorganization. 
For example, Section 2.1 is still being referred to in a number of places as containing advice on complex attributes, but
that advice is now in Section 3.3.2.  So that still needs to be cleaned up. 
Alan DeKok:  I will read through the document once again.  
Avi Lior: It's not really fair to say that the document doesn't forbid or require anything.  It does contain
normative language:  MUST, SHOULD, etc. right? 
Alan:  All the MUST and MUST NOT uses either represent quotes from existing RFCs, or represent requirements
to follow the IETF process.  There have been some remaining questions on the list relating to assumptions
about implementations (dictionaries, policy languages, data entry, etc.).  

Extended RADIUS Attributes, Alan DeKok (30 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes

Alan DeKok:  The current Extended Attributes draft has failed to gain critical mass (shows slide of a car that has fallen down an escalator). 
Multiple attempts to use the current format have been unsuccessful, and there has been 
resistance among multiple authors to creating a dependency on the document.  Yet, the
problems addressed in the document still exist:

* Exhaustion of the RADIUS standard attribute space still looms
* Several SDOs (such as 3GPP2 and WiMAX) in addition to deployed spec (Sterman) have used grouping. 

What do we do next? 
What are the requirements? (Shows a slide of a person in a Chicken Suit)

Bernard Aboba: It seems that the draft attempted to solve at least two problems at once, attribute
exhaustion and the grouping issue.  Did it need to attempt both in the same document?
Avi Lior:  It was decided to solve both problems, but they didn't necessarily have to be solved in the
same document. 
Alan DeKok:  In understanding how to move forward it is useful to understand the requirements. 
In my opinion, supporting multiple levels of grouping is horrendously useful.
Avi Lior:  I agree.   Could you come up with a proposal on a napkin?
Alan DeKok:  I've been doing some thinking about it. 
Bernard Aboba:  Can you work on a proposal for presentation at IETF 78? 
Alan DeKok:  Yes.

IPv6 Access, W. Dec (15 minutes)
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

The WG last call comments (Issues #2 and 5) have been addressed in -02.  There are no open
issues at the moment. 
Bernard Aboba:  Next step is another (and hopefully last) WG last call. 

Wrapup

Discussion of IETF 78 Agenda

Bernard Aboba:  The RADEXT WG has secured two slots at IETF 78, each roughly an hour.  Unfortunately, the
first slot overlaps with EMU, which is co-chaired by Alan DeKok. 
Alan DeKok:  EMU has a very full agenda, so I won't be able to run out of the EMU meeting to present in RADEXT.
Bernard Aboba:  We can spend the first hour on RADSEC, NAI Discovery and perhaps RADIUS over DTLS. 
Stefan -- can you present those documents?
Stefan Winter:  I can present my drafts.  With some help from Alan, I can also present RADIUS/DTLS. 

Bernard Aboba:  In the second hour starting at 10:30 AM, we can handle the rest of the items,
such as additional discussion of Extended attributes, individual submissions, etc. 
I will post a strawman agenda to the list. 

Meeting Adjourned:  12:05 PM Pacific Time
 		 	   		  
--_5afc3166-8322-4850-be41-c72f23329b95_
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'>
RADEXT Virtual Interim Meeting<br>Monday, July 12, 2010<br>Meeting starts:&nbsp; 11:10 AM Pacific Time<br><br>Chairs:&nbsp; Bernard Aboba &lt;[email-masked]&gt;<br>Mauricio Sanchez &lt;[email-masked]&gt;<br><br>Minutes<br><br>Attendees: <br>Dan Romascanu<br>Dave Mitton<br>Avi Lior<br>Stefan Winter<br>Alan DeKok<br>W. Dec<br>Bernard Aboba<br>Mauricio Sanchez<br><br>Agenda<br><br>Document Status<br><br>The Status-Server draft is now in the RFC Editor Queue.<br>Dan Romascanu:&nbsp; Is there a dependency preventing it from being published as an RFC?<br>Bernard Aboba:&nbsp; The draft entered the queue on June 7, 2010.&nbsp; There is no indication of a <br>dependency or other holdup. &nbsp;<br><br>Design Guidelines has completed IETF last call and is awaiting resolution of the remaining<br>issues submitted during the WG "Last Look". &nbsp; We will discuss the status of the remaining issues today.<br><br>The RADIUS over TCP draft is now in state IESG Evaluation: AD Followup, after submission of<br>the recent update to address IESG comments. <br><br>The IPv6 Access document has now completed WG last call and resolved all open issues. <br><br>The RADSEC document has completed WG last call, but issues remain open. <br>&nbsp;<br>RADIUS over TCP, Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-tcp<br><br>A new draft has been submitted that is believed to address IESG comments.<br>Dan Romascanu:&nbsp; Has Ralph Drom's DISCUSS comment been addressed? <br>Alan DeKok:&nbsp; I think that all IESG comments have been addressed including Ralph's. <br>Dan Romascanu:&nbsp; I will bring the new version to the attention of the IESG and we will see where we stand.<br><br>Design Guidelines, Alan DeKok (30 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-design-guidelines<br><br>The RADEXT WG "Last Look" completed on June 28, 2010 and a summary was sent to the list:<br>http://ops.ietf.org/lists/radiusext/2010/msg00493.html<br>Since then a -15 and a -16 have been submitted to address the vast majority of the issues submitted. <br><br>The intent is to submit a -17 version of the document, addressing outstanding issues still open in the <br>tracker.&nbsp; This includes cleanup of Section 3.3.2 and some redundancy removal.<br>Bernard Aboba:&nbsp; One thing I noticed is that a number of section references are wrong due to the reorganization. <br>For example, Section 2.1 is still being referred to in a number of places as containing advice on complex attributes, but<br>that advice is now in Section 3.3.2.&nbsp; So that still needs to be cleaned up. <br>Alan DeKok:&nbsp; I will read through the document once again.&nbsp; <br>Avi Lior: It's not really fair to say that the document doesn't forbid or require anything.&nbsp; It does contain<br>normative language:&nbsp; MUST, SHOULD, etc. right? <br>Alan:&nbsp; All the MUST and MUST NOT uses either represent quotes from existing RFCs, or represent requirements<br>to follow the IETF process.&nbsp; There have been some remaining questions on the list relating to assumptions<br>about implementations (dictionaries, policy languages, data entry, etc.). &nbsp;<br><br>Extended RADIUS Attributes, Alan DeKok (30 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-extended-attributes<br><br>Alan DeKok:&nbsp; The current Extended Attributes draft has failed to gain critical mass (shows slide of a car that has fallen down an escalator). <br>Multiple attempts to use the current format have been unsuccessful, and there has been <br>resistance among multiple authors to creating a dependency on the document.&nbsp; Yet, the<br>problems addressed in the document still exist:<br><br>* Exhaustion of the RADIUS standard attribute space still looms<br>* Several SDOs (such as 3GPP2 and WiMAX) in addition to deployed spec (Sterman) have used grouping. <br><br>What do we do next? <br>What are the requirements? (Shows a slide of a person in a Chicken Suit)<br><br>Bernard Aboba: It seems that the draft attempted to solve at least two problems at once, attribute<br>exhaustion and the grouping issue.&nbsp; Did it need to attempt both in the same document?<br>Avi Lior:&nbsp; It was decided to solve both problems, but they didn't necessarily have to be solved in the<br>same document. <br>Alan DeKok:&nbsp; In understanding how to move forward it is useful to understand the requirements. <br>In my opinion, supporting multiple levels of grouping is horrendously useful.<br>Avi Lior:&nbsp; I agree.&nbsp;&nbsp; Could you come up with a proposal on a napkin?<br>Alan DeKok:&nbsp; I've been doing some thinking about it. <br>Bernard Aboba:&nbsp; Can you work on a proposal for presentation at IETF 78? <br>Alan DeKok:&nbsp; Yes.<br><br>IPv6 Access, W. Dec (15 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-ipv6-access<br><br>The WG last call comments (Issues #2 and 5) have been addressed in -02.&nbsp; There are no open<br>issues at the moment. <br>Bernard Aboba:&nbsp; Next step is another (and hopefully last) WG last call. <br><br>Wrapup<br><br>Discussion of IETF 78 Agenda<br><br>Bernard Aboba:&nbsp; The RADEXT WG has secured two slots at IETF 78, each roughly an hour.&nbsp; Unfortunately, the<br>first slot overlaps with EMU, which is co-chaired by Alan DeKok. <br>Alan DeKok:&nbsp; EMU has a very full agenda, so I won't be able to run out of the EMU meeting to present in RADEXT.<br>Bernard Aboba:&nbsp; We can spend the first hour on RADSEC, NAI Discovery and perhaps RADIUS over DTLS. <br>Stefan -- can you present those documents?<br>Stefan Winter:&nbsp; I can present my drafts.&nbsp; With some help from Alan, I can also present RADIUS/DTLS. <br><br>Bernard Aboba:&nbsp; In the second hour starting at 10:30 AM, we can handle the rest of the items,<br>such as additional discussion of Extended attributes, individual submissions, etc. <br>I will post a strawman agenda to the list. <br><br>Meeting Adjourned:&nbsp; 12:05 PM Pacific Time<br> 		 	   		  </body>
</html>
--_5afc3166-8322-4850-be41-c72f23329b95_--

Delivery-date: Mon, 12 Jul 2010 19:21:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: IETF 78 Agenda - Take One
Date: Mon, 12 Jul 2010 12:21:24 -0700

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

Please find enclosed a draft IETF 78 Agenda for RADEXT WG.  If you'd like to
propose an agenda item, please contact Mauricio or myself ASAP. 

Wednesday, July 28, 2010

0900-1015 Morning Session (0.8 Rome)

0900 - 0910:  Preliminaries

                                Blue Sheets

                                Note takers

                                Jabber Scribe

                                Agenda bash

                                Document Status

0910 - 0930:  RADIUS over TLS, Stefan Winter (20 minutes)

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

0930 - 0940:  RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-dekok-radext-dtls

0940 - 1000:  NAI Discovery, Stefan Winter (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery

1000 - 1015:   Discussion

1030 - 1130 Morning Session II (0.8 Rome)

1030 - 1040:  Preliminaries

                                Blue Sheets

                                Note takers

                                Jabber Scribe

                                Agenda bash

1040 - 1110:  Extended Attributes, Avi Lior and Alan DeKok (30 minutes)

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

------=_NextPart_000_05B1_01CB21BC.BEA8C190
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;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</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=WordSection1>

<p class=MsoNormal>Please find enclosed a draft IETF 78 Agenda for RADEXT
WG.&nbsp; If you'd like to propose an agenda item, please contact Mauricio or
myself ASAP. <o:p></o:p></p>

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

<p class=MsoNormal>Wednesday, July 28, 2010<o:p></o:p></p>

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

<p class=MsoNormal>0900-1015 Morning Session (0.8 Rome)<o:p></o:p></p>

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

<p class=MsoNormal>0900 - 0910:&nbsp; Preliminaries<o:p></o:p></p>

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

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

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

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

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

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

<p class=MsoNormal>0910 - 0930:&nbsp; RADIUS over TLS, Stefan Winter (20
minutes)<o:p></o:p></p>

<p class=MsoNormal>http://tools.ietf.org/html/draft-ietf-radext-radsec<o:p></o:p></p>

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

<p class=MsoNormal>0930 - 0940:&nbsp; RADIUS over DTLS, Alan DeKok or Stefan
Winter (10 minutes)<o:p></o:p></p>

<p class=MsoNormal>http://tools.ietf.org/html/draft-dekok-radext-dtls<o:p></o:p></p>

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

<p class=MsoNormal>0940 - 1000:&nbsp; NAI Discovery, Stefan Winter (20 minutes)<o:p></o:p></p>

<p class=MsoNormal>http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery<o:p></o:p></p>

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

<p class=MsoNormal>1000 - 1015:&nbsp;&nbsp; Discussion<o:p></o:p></p>

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

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

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

<p class=MsoNormal>1030 - 1130 Morning Session II (0.8 Rome)<o:p></o:p></p>

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

<p class=MsoNormal>1030 - 1040:&nbsp; Preliminaries<o:p></o:p></p>

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

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

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

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

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

<p class=MsoNormal>1040 - 1110:&nbsp; Extended Attributes, Avi Lior and Alan
DeKok (30 minutes)<o:p></o:p></p>

<p class=MsoNormal>http://tools.ietf.org/html/draft-ietf-radext-extended-attributes<o:p></o:p></p>

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

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

</div>

</body>

</html>

------=_NextPart_000_05B1_01CB21BC.BEA8C190--

Delivery-date: Mon, 12 Jul 2010 19:03:12 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 12 Jul 2010 19:02:11 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #5: Gen-ART Review

#5: Gen-ART Review
---------------------------------------+------------------------------------
 Reporter:  Francis.Dupont@â€¦           |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  minor                      |    Milestone:  milestone1               
Component:  status-server              |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/5#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 12 Jul 2010 19:03:05 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 12 Jul 2010 19:02:25 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #10: Editorial Issues

#10: Editorial Issues
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  minor                      |    Milestone:  milestone1               
Component:  status-server              |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/10#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 12 Jul 2010 13:49:34 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 12 Jul 2010 13:49:23 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #4: Editorial comments

#4: Editorial comments
---------------------------------------+------------------------------------
 Reporter:  aland@â€¦                    |        Owner:  stefan.winter@â€¦         
     Type:  defect                     |       Status:  closed                  
 Priority:  minor                      |    Milestone:  milestone1              
Component:  radsec                     |      Version:  1.0                     
 Severity:  In WG Last Call            |   Resolution:  fixed                   
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/4#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 12 Jul 2010 13:48:44 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 12 Jul 2010 13:48:20 -0000
Reply-To: [email-masked]
Subject: [radext] #56: Review

#56: Review
---------------------------------------+------------------------------------
 Reporter:  aland@â€¦                    |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  radsec                     |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------
 I'd also suggest auditing it for "RADIUS over FOO".  That should be
 changed to "RADIUS/Foo", e.g.

 2.  Normative: Transport Layer Security for RADIUS over TCP

   to

 2.  Normative: Transport Layer Security for RADIUS/TCP

   and

 8.  Acknowledgements

    RADIUS over TLS ...

 to

    RADIUS/TLS

   and

 RADIUS has no notion of negotiating TLS in an established connection.
 Servers and clients need to be preconfigured to use RADIUS/TLS for a
 given endpoint.

    to

 RADIUS/TLS has no notion of ....

   Also, the reference names could be changed:

 [I-D.dekok-radext-tcp-transport]  is now "draft-ietf".  Not a big issue,
 but useful to change.

   There should also be an RFC editor note that the draft has a normative
 requirement on the TCP transport draft.

   The "connection backoff" algorithm should really be standardized:

    The proxy will at startup try to establish a TLS connection to each
    (if any) of the configured RadSec (TLS) servers.  If it fails to
    connect to a server, it will retry regularly.  There is some back-off
    where it will retry quickly at first, and with longer intervals
    later.

   See the Status-Server draft, which had a lot of feedback over the
 backoff algorithms it discussed.  I'm not proposing to use the same
 method here.  I'm suggesting that *something* should be defined,
 otherwise other reviewers will suggest defining the backoff algorithm.

   The backoff algorithm should also be mentioned in the "Security
 Considerations" section.  Bad clients that hammer a server can result in
 a DoS attack.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/56>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 12 Jul 2010 13:34:16 +0000
Date: Mon, 12 Jul 2010 15:33:59 +0200
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-radext-radsec-07.txt

Stefan Winter wrote:
> this rev should fix trac item #4, and all except two points in #3:

  I'd also suggest auditing it for "RADIUS over FOO".  That should be
changed to "RADIUS/Foo", e.g.

2.  Normative: Transport Layer Security for RADIUS over TCP

  to

2.  Normative: Transport Layer Security for RADIUS/TCP

  and

8.  Acknowledgements

   RADIUS over TLS ...

to

   RADIUS/TLS

  and

RADIUS has no notion of negotiating TLS in an established connection.
Servers and clients need to be preconfigured to use RADIUS/TLS for a	
given endpoint.

   to

RADIUS/TLS has no notion of ....

  Also, the reference names could be changed:

[I-D.dekok-radext-tcp-transport]  is now "draft-ietf".  Not a big issue,
but useful to change.

  There should also be an RFC editor note that the draft has a normative
requirement on the TCP transport draft.

  The "connection backoff" algorithm should really be standardized:

   The proxy will at startup try to establish a TLS connection to each
   (if any) of the configured RadSec (TLS) servers.  If it fails to
   connect to a server, it will retry regularly.  There is some back-off
   where it will retry quickly at first, and with longer intervals
   later.

  See the Status-Server draft, which had a lot of feedback over the
backoff algorithms it discussed.  I'm not proposing to use the same
method here.  I'm suggesting that *something* should be defined,
otherwise other reviewers will suggest defining the backoff algorithm.

  The backoff algorithm should also be mentioned in the "Security
Considerations" section.  Bad clients that hammer a server can result in
a DoS attack.

Delivery-date: Mon, 12 Jul 2010 13:28:01 +0000
Date: Mon, 12 Jul 2010 15:27:08 +0200
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-radext-radsec-07.txt

Stefan Winter wrote:
> this rev should fix trac item #4, and all except two points in #3:

  I'd also suggest auditing it for "RADIUS over FOO".  That should be
changed to "RADIUS/Foo"

  e.g.

Delivery-date: Mon, 12 Jul 2010 12:21:47 +0000
Date: Mon, 12 Jul 2010 14:21:24 +0200
From: Stefan Winter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-radext-radsec-07.txt

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB2930346F28752BC82A92B7E
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi,

this rev should fix trac item #4, and all except two points in #3:

- Client identity: which parts of a certificate are relevant
- RADIUS/TLS cleint vs. server: packet type restrictions

(the caption of  #3 suggests that there is a "Part 2" of the review
pending?)

Greetings,

Stefan Winter

> 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           : TLS encryption for RADIUS
> 	Author(s)       : S. Winter, et al.
> 	Filename        : draft-ietf-radext-radsec-07.txt
> 	Pages           : 18
> 	Date            : 2010-07-12
>
> This document specifies security on the transport layer (TLS) for the
> RADIUS protocol when transmitted over TCP.  This enables dynamic
> trust relationships between RADIUS servers.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-07.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.
>   

-- 
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: +352 424409 1
Fax: +352 422473

--------------enigB2930346F28752BC82A92B7E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigB2930346F28752BC82A92B7E--

Delivery-date: Mon, 12 Jul 2010 12:15:48 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-radsec-07.txt 
Date: Mon, 12 Jul 2010 05:15:01 -0700 (PDT)

--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           : TLS encryption for RADIUS
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-07.txt
	Pages           : 18
	Date            : 2010-07-12

This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP.  This enables dynamic
trust relationships between RADIUS servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-07.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-radsec-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Mon, 12 Jul 2010 11:13:39 +0000
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 12 Jul 2010 13:13:14 +0200
From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: Federated Authentication Beyond The Web: Problem Statement and Requirements
To: Klaas Wierenga <[email-masked]>

> My point is that I'd like the BoF to start open-minded. I believe 
> federated authentication for non-Web is a large and interesting area. I 
> would like to make sure that we don't rule out beforehand alternative 
> approaches. I am happy with a charter as outcome that specifies that the 
> WG is going to take the Moonshot approach, but imo that should be the 
> *result* of the BoF, not a *precondition*.

I understand your thinking. I actually had the same concerns initially but a more focused discussion really helps. Additionally, nothing prevents someone else to propose another activity (either in form of a BOF, or by submitting drafts to a working group).

I am quite happy with the scope of the work as being proposed. 

Ciao
Hannes

Delivery-date: Mon, 12 Jul 2010 11:04:24 +0000
Date: Mon, 12 Jul 2010 13:03:30 +0200
From: Klaas Wierenga <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked], [email-masked],  Moonshot community list <[email-masked]>
Subject: Re: Federated Authentication Beyond The Web: Problem Statement and Requirements

On 7/9/10 7:30 PM, Hannes Tschofenig wrote:

Hi Hannes,

> sorry for the late response.

np

>
> Interesting statement.
>
> I agree that there are other approaches (and probably everyone would
> agree with that; we could even list Kerberos).
>
> However, the MOONSHOT BOF is (if I understood it correctly)
> constraint to the mentioned constraints.

hmm, afaik it is a federated authentication BoF, not a Moonshot BoF

>
> The usage of OpenID in SASL/GSS-API (like you pointed out) will be
> done in KITTEN independently and has different design constraints.

I think there is a bit of misunderstanding, I gave those just as an 
example because I happen to be familiar with them. I am happy with those 
drafts being in KITTEN, if only to speed things up. So that is not the 
point.

My point is that I'd like the BoF to start open-minded. I believe 
federated authentication for non-Web is a large and interesting area. I 
would like to make sure that we don't rule out beforehand alternative 
approaches. I am happy with a charter as outcome that specifies that the 
WG is going to take the Moonshot approach, but imo that should be the 
*result* of the BoF, not a *precondition*.

Hope this clarifies the misunderstanding.

Klaas

>
> Ciao Hannes
>
>> On 7/6/10 11:15 AM, Hannes Tschofenig wrote:
>>
>> Hi Hannes,
>>
>>> at the next IETF meeting we are going to have a BOF about
>>> "Federated
>> Authentication Beyond The Web". In case you have not noticed the
>> work relates to RADIUS and Diameter.
>>>
>>> I wrote this very short problem statement document to explain
>>> the
>> purpose of the BOF:
>>> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
>>>
>>>
>>>
Let me know if you find the description useful. Feedback about the BOF
>> topic would also be appreciated.
>>
>> I find the description useful, however I would like to challenge
>> the MUST for RADIUS and/or Diamter. There are a number of
>> Federated Authentication for applications access protocols out
>> there, SAML, OpenID and others. RADIUS and Diamter are typically
>> associated with network access. And while I do see the
>> attractiveness of marrying the two (and thus leveraging existing
>> trust fabrics), I wonder why you want to restrict a priori to just
>> those. As an example draft-cantor-ietf-sasl-saml-ec-00.txt,
>> draft-lear-ietf-sasl-openid-00, and
>> draft-wierenga-ietf-sasl-saml-00 specify the use of federated
>> authentication in a SASL context. And services like eduroam are an
>> example of the use of just RADIUS to implement federated
>> authentication for non-web applications. I do understand that it is
>> not possible nor desirable to take on everything, but let's at
>> least have this scoping discussion in the BoF.
>>
>> Klaas
>>
>> -- to unsubscribe send a message to [email-masked]
>> with the word 'unsubscribe' in a single line as the message text
>> body. archive:<http://psg.com/lists/radiusext/>

Delivery-date: Mon, 12 Jul 2010 06:05:53 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Slides
Date: Sun, 11 Jul 2010 23:04:54 -0700

--_8206b4b9-3bd8-4c8a-a3ba-b1027090e195_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you are presenting at the RADEXT Virtual Interim meeting tomorrow, please send your slides to myself and Mauricio ASAP, so that we can get them up on the archive in time for the meeting. 
 		 	   		  
--_8206b4b9-3bd8-4c8a-a3ba-b1027090e195_
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'>
If you are presenting at the RADEXT Virtual Interim meeting tomorrow, please send your slides to myself and Mauricio ASAP, so that we can get them up on the archive in time for the meeting. <br> 		 	   		  </body>
</html>
--_8206b4b9-3bd8-4c8a-a3ba-b1027090e195_--

Delivery-date: Sat, 10 Jul 2010 01:29:46 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Sat, 10 Jul 2010 01:29:27 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #55: Disconnect-Request

#55: Disconnect-Request
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  enhancement                |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------

Comment(by bernard_aboba@â€¦):

 Just noticed the incompatibility between the language in Section 3.1
 (SHOULD be redesigned) and the language in A.4:  MUST NOT be used.  Given
 that this is a prohibition in RFC 2865 and 5176, I think that the SHOULD
 is inappropriate (e.g. needs to be stronger).

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/55#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 10 Jul 2010 01:26:43 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Sat, 10 Jul 2010 01:26:28 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #55: Disconnect-Request

#55: Disconnect-Request
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  enhancement                |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------

Comment(by bernard_aboba@â€¦):

 Also in A.4:

       * Provisioning of service in an Access-Reject.  Such provisioning
         is not permitted, and MUST NOT be used.  If limited access needs
         to be provided, then an Access-Accept with appropriate
         authorizations can be used instead.

 Please add after this:

       * Provisioning of service in a Disconnect-Request.
         Such provisioning is not permitted, and MUST NOT be used.
         If limited access needs to be provided, then a CoA-Request
         with appropriate authorizations can be used instead.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/55#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Sat, 10 Jul 2010 01:23:07 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Sat, 10 Jul 2010 01:22:05 -0000
Reply-To: [email-masked]
Subject: [radext] #55: Disconnect-Request

#55: Disconnect-Request
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:  aland@â€¦                  
     Type:  enhancement                |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  design                     |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
 Section 3.1

       * Provisioning of services is not possible within an
         Access-Reject;

 [BA] This should say "Access-Reject or Disconnect-Request;"

    As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
    to deny access to the requested service.  As a result, RADIUS does
    not allow the provisioning of services within an Access-Reject.
    Documents which include provisioning of services within an Access-
    Reject are inherently incompatible with RADIUS, and SHOULD be
    redesigned.

 [BA] Recommend adding a paragraph on Disconnect-Request after this one:

    As noted in [RFC5176] Section 3:

    A Disconnect-Request MUST contain only NAS and session identification
    attributes.  If other attributes are included in a Disconnect-
    Request, implementations MUST send a Disconnect-NAK; an Error-Cause
    Attribute with value "Unsupported Attribute" MAY be included.

    As a result, documents which include provisioning of services
    within a Disconnect-Request are inherently incompatible with RADIUS,
    and SHOULD be redesigned.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/55>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:40:53 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 09 Jul 2010 17:40:36 -0000
Reply-To: [email-masked]
Subject: [radext] #54: Editorial Nits

#54: Editorial Nits
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  trivial                    |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Section B.6

 of opaque data whose definition

 [BA] should be "of as opaque data whose definition"

    reasons identical to those given for Egress-VLANID.
 B.10. Digest-*

 [BA] Insert a blank line before section B.10.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/54>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:35:04 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 09 Jul 2010 17:34:50 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #51: Repetition

#51: Repetition
---------------------------------------+------------------------------------
 Reporter:  Hannes.Tschofenig@â€¦        |        Owner:            
     Type:  defect                     |       Status:  closed    
 Priority:  minor                      |    Milestone:  milestone1
Component:  design                     |      Version:  1.0       
 Severity:  Submitted WG Document      |   Resolution:  fixed     
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I believe that this issue was resolved in -16.

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/51#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:33:03 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 09 Jul 2010 17:32:50 -0000
Reply-To: [email-masked]
Subject: [radext] #53: Notes

#53: Notes
---------------------------------------+------------------------------------
 Reporter:  Hannes.Tschofenig@â€¦        |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Additionally there are a few minor notes:

 a) What is a "service definition"? (see Section 2.3)

 A reference to an example would help to understand what is actually meant
 (and what isn't). The term "service" is so generic that it has to lead to
 confusion. For example, is the recently proposed SAML messaging work over
 RADIUS a negative example for this?

 b) Section 3.2.3:

 "
       * it is easier for the user to enter the data as well-known
         types, rather than complex structures;
 "

 please replace the term "user" with something else, particularly since the
 rest of the document talks about the user in the sense of the person
 gaining access to the network. here we are talking about the person doing
 the system administration.

 c) Section 3.2.3: A general comment

 With the following bullets I would like to have a sentence added that this
 is very implementation specific:

 "
       * it is easier for the user to enter the data as well-known
         types, rather than complex structures;

       * it enables additional error checking by leveraging the
         parsing and validation routines for well-known types;

       * it simplifies implementations by eliminating special-case
         attribute-specific parsing.

 "

 Regarding the first item: It depends how you provision the data. if you
 type them with an ASCII editor then I fully agree. If you have tools then
 I disagree. For larger systems you are not using an ASCII editor, IMHO.

 Regarding the second item: It depends when you do the error checking. If
 you do it as post-processing (for example, when the data ends up in the
 database) then there isn't an issue at all. if you do it in real-time when
 you get the data provided then you will in many cases have to have a more
 sophisticated policy language; the capabilities of the policy language has
 never been clearly described nor investigated as part of a survey of
 available implementations.

 Regarding item three: I agree with this item to some extend but splitting
 attributes into multiple attributes (or even multiple messages, as
 suggested in the text) requires some mechanism to correlate them. This
 also requires code and potentially state to be maintained.

 I would encourage the group to investigate the existing RADIUS server
 implementation features (independently of the document; certainly not
 blocking the progress of the document) because it could lead to
 interesting insights. I would also be in favor of suggesting that people
 think about how they are going to process attributes (on the sending and
 on the receiving side and what the required code changes are). Being
 explicit about these aspects would improve the quality of the
 specification IMHO.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/53>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:31:27 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 09 Jul 2010 17:31:17 -0000
Reply-To: [email-masked]
Subject: [radext] #52: Basic vs. Complex Attributes

#52: Basic vs. Complex Attributes
---------------------------------------+------------------------------------
 Reporter:  Hannes.Tschofenig@â€¦        |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 The line drawn between the basic and the complex data types is still
 arbitrarily, which leaves a bad taste behind.

 2) Inconsistent story

 To avoid complex attributes the document argues to split them. But then
 the document furthermore argues that the attribute code space is going to
 be exhausted pretty soon.

 The story from the RADEXT group, at least if I understood it correctly,
 was the extended attribute format, see http://datatracker.ietf.org/doc
 /draft-ietf-radext-extended-attributes/. This would solve the "exhaustion"
 issue. However, it does not nicely fit in the story of basic vs. complex
 attributes since the extended attribute format is a complex attribute that
 by definition in the document has to be avoided at all cost (because of
 security vulnerabilities, etc.).

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/52>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:30:34 +0000
Cc: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 19:30:23 +0200
From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: Federated Authentication Beyond The Web: Problem Statement and Requirements
To: Klaas Wierenga <[email-masked]>

Hi Klaas, 

sorry for the late response. 

Interesting statement. 

I agree that there are other approaches (and probably everyone would agree with that; we could even list Kerberos). 

However, the MOONSHOT BOF is (if I understood it correctly) constraint to the mentioned constraints. 

The usage of OpenID in SASL/GSS-API (like you pointed out) will be done in KITTEN independently and has different design constraints. 

Ciao
Hannes

> On 7/6/10 11:15 AM, Hannes Tschofenig wrote:
> 
> Hi Hannes,
> 
> > at the next IETF meeting we are going to have a BOF about "Federated
> Authentication Beyond The Web". In case you have not noticed the work relates
> to RADIUS and Diameter.
> >
> > I wrote this very short problem statement document to explain the
> purpose of the BOF:
> > http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
> >
> > Let me know if you find the description useful. Feedback about the BOF
> topic would also be appreciated.
> 
> I find the description useful, however I would like to challenge the 
> MUST for RADIUS and/or Diamter. There are a number of Federated 
> Authentication for applications access protocols out there, SAML, OpenID 
> and others. RADIUS and Diamter are typically associated with network 
> access. And while I do see the attractiveness of marrying the two (and 
> thus leveraging existing trust fabrics), I wonder why you want to 
> restrict a priori to just those. As an example 
> draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, 
> and draft-wierenga-ietf-sasl-saml-00 specify the use of federated 
> authentication in a SASL context. And services like eduroam are an 
> example of the use of just RADIUS to implement federated authentication 
> for non-web applications.
> I do understand that it is not possible nor desirable to take on 
> everything, but let's at least have this scoping discussion in the BoF.
> 
> Klaas
> 
> --

Delivery-date: Fri, 09 Jul 2010 17:30:04 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 09 Jul 2010 17:29:44 -0000
Reply-To: [email-masked]
Subject: [radext] #51: Repetition

#51: Repetition
---------------------------------------+------------------------------------
 Reporter:  Hannes.Tschofenig@â€¦        |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Section 2.1 lists the basic data types. Section 3.2.1 lists them again.
 And so does Appendix A.1.1.

 I would argue that we should only have them once listed in the document
 (at least I would argue to get rid of A.1.1). Appendix A in general
 repeats what was said in the previous section again. Appendix B is good
 since it shows some of the examples.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/51>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:27:46 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 17:27:32 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #11: Review

#11: Review
-----------------------------------+----------------------------------------
 Reporter:  jsalowey@â€¦             |        Owner:  aland@â€¦                  
     Type:  defect                 |       Status:  closed                   
 Priority:  blocker                |    Milestone:  milestone1               
Component:  design                 |      Version:  1.0                      
 Severity:  Submitted WG Document  |   Resolution:  fixed                    
 Keywords:                         |  
-----------------------------------+----------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/11#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:26:23 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 17:26:13 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #49: B.10

#49: B.10
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  critical                   |    Milestone:  milestone1               
Component:  design                     |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/49#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:24:58 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 17:24:43 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #48: B.6

#48: B.6
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  major                      |    Milestone:  milestone1               
Component:  design                     |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/48#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:22:33 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 17:22:21 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #31: Section 2.1

#31: Section 2.1
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  minor                      |    Milestone:  milestone1               
Component:  design                     |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/31#comment:3>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:20:36 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 17:20:24 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #47: A.4 Reference

#47: A.4 Reference
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  minor                      |    Milestone:  milestone1               
Component:  design                     |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/47#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 17:18:11 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 17:17:26 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #50: Section 2

#50: Section 2
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â€¦            |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  minor                      |    Milestone:  milestone1               
Component:  design                     |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/50#comment:1>
radext <http://tools.ietf.org/radext/>

Delivery-date: Fri, 09 Jul 2010 15:09:53 +0000
Date: Fri, 09 Jul 2010 17:09:29 +0200
From: Alan DeKok <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked]
Subject: Re: Design Guidelines draft

Hannes Tschofenig wrote:
>>   I agree.  I'll delete the list in A.1.1, and incorporate the text from
>> Section 3.2.1 into Section 2.1.
> 
> OK. 

  After some review, I decided to simplify the text in 3.2.1 rather than
incorporating it into 2.1.  The sections have different purposes.  2.1
describes what the data types are.  3.2.1 describes why the data types
are confusing.

> What I mean is that IPv6 address and IPv6 prefix is considered as a basic data type (even though it was standardized much later with RFC3162) although one can not really speak about widespread deployment given the deployment status of IPv6 in general. 

  I think most widely used RADIUS servers support IPv6 transport, along
with the IPv6 data types.  Many switches and NAS equipment does, too.  I
don't think it's *used* that much, but they are deployed and inter-operable.

> The tagging mechanism, described in Section 3.2.2, falls somewhere between the basic (Section 3.2.1) and complex (Section 3.2.3) data types -- based on the old draft version; version -15. 

  Yes.  It's awkward, but is grandfathered in.

> That's what I meant with "drawing an arbitrary line". 

  It's RADIUS. :(  Nothing is simple.

>>   The existing RFCs are vague on what "services" mean.  This spec isn't
>> the place to define them.
> 
> Hmmm.  

  If you have suggestions...

> But you understand what I mean. For example, with location information I could imagine that one uses a nice map and draw a circle there and then the software would provision that information into the database (in the right format for distribution within RADIUS). Now, assuming that an administrator would enter the data in the cryptic format defined by the RADIUS GEOPRIV RFC wouldn't probably work all that well. 

  Sure.  Many systems support automatic IP address allocation, where the
data sent in a packet is created from an SQL procedure.  But I think the
general text still applies.  At some point, an administrator often has
to enter data.  Leveraging existing data entry methods is preferable to
creating unnecessary new ones.

>>   That investigation is out of scope for this document.
> 
> The problem is that it impacts the content of the document. 
> Out of scope is what the editor and the group consider out of scope. 

  I think a survey of server functionality is an admirable goal.  I
don't think that any survey would make a substantial difference in this
document.

>>   Potentially.  However, most RADIUS implementations should already have
>> the ability to send multiple attributes at once.  That functionality can
>> be leveraged to send "logically" correlated attributes.
> 
> These assumptions are not stated in the document. 

  Stating them is not required, I think.

  Alan DeKok.

Delivery-date: Fri, 09 Jul 2010 14:53:45 +0000
Cc: [email-masked]
Date: Fri, 09 Jul 2010 16:53:05 +0200
From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: Design Guidelines draft
To: Alan DeKok <[email-masked]>

Hi Alan, 

thanks for the super-quick response. 

See inline. 

-------- Original-Nachricht --------
> Datum: Fri, 09 Jul 2010 14:18:13 +0200
> Von: Alan DeKok <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: [email-masked]
> Betreff: Re: Design Guidelines draft

> Hannes Tschofenig wrote:
> > I had a brief look again at the latest version of the design guidelines
> draft and noticed 2 points that I would like to highlight: 
> > 
> > 1) Repetition
> > 
> > Section 2.1 lists the basic data types. Section 3.2.1 lists them again.
> And so does Appendix A.1.1.
> > 
> > I would argue that we should only have them once listed in the document
> (at least I would argue to get rid of A.1.1). Appendix A in general repeats
> what was said in the previous section again. Appendix B is good since it
> shows some of the examples. 
> 
>   I agree.  I'll delete the list in A.1.1, and incorporate the text from
> Section 3.2.1 into Section 2.1.

OK. 

> 
> > The line drawn between the basic and the complex data types is still
> arbitrarily, which leaves a bad taste behind. 
> 
>   I'm not sure how it's arbitrary.  The basic data types are "integer",
> "Ip address", etc.  The tagging mechanism is allowed because it's widely
> used.  Any grouping, nesting, structed types are "complex".

What I mean is that IPv6 address and IPv6 prefix is considered as a basic data type (even though it was standardized much later with RFC3162) although one can not really speak about widespread deployment given the deployment status of IPv6 in general. 

The tagging mechanism, described in Section 3.2.2, falls somewhere between the basic (Section 3.2.1) and complex (Section 3.2.3) data types -- based on the old draft version; version -15. 

That's what I meant with "drawing an arbitrary line". 

> 
> > 2) Inconsistent story
> > 
> > To avoid complex attributes the document argues to split them. But then
> the document furthermore argues that the attribute code space is going to
> be exhausted pretty soon. 
> 
>   Yes.  It's hoped that the attribute space exhaustion will be fixed in
> a future spec.  Given the current rate of assignment, I think we have a
> few years left before the RFC space is full.
> 
> > However, it does not nicely fit in the story of basic vs. complex
> attributes since the extended attribute format is a complex attribute
> that by definition in the document has to be avoided at all cost
> (because of security vulnerabilities, etc.).
> 
>   No.  The document RECOMMENDS that complex types be avoided.  It allows
> later documents to update this one.  If the WG decides that the extended
> format is an allowable "complex" type, then *nothing* in this document
> forbids that.
> 
>   I'll repeat, because that point has come up many, many, times.
> NOTHING in this document forbids or prohibits the WG from defining the
> extended attributes to be of complex types.
> 

Interesting. 

> > Additionally there are a few minor notes: 
> > 
> > a) What is a "service definition"? (see Section 2.3)
> 
>   A "service being provisioned".
> 
> > A reference to an example would help to understand what is actually
> meant (and what isn't). The term "service" is so generic that it has to lead to
> confusion. For example, is the recently proposed SAML messaging work over
> RADIUS a negative example for this?
> 
>   The existing RFCs are vague on what "services" mean.  This spec isn't
> the place to define them.

Hmmm. 

> 
> > b) Section 3.2.3: 
> > 
> > "
> >       * it is easier for the user to enter the data as well-known
> >         types, rather than complex structures;
> > "
> > 
> > please replace the term "user" with something else, particularly since
> the rest of the document talks about the user in the sense of the person
> gaining access to the network. here we are talking about the person doing the
> system administration. 
> 
>   OK.  That could be "an administrator" instead of "a user"

Yup

> 
> > c) Section 3.2.3: A general comment
> > 
> > With the following bullets I would like to have a sentence added that
> this is very implementation specific: 
> >
> > "
> >       * it is easier for the user to enter the data as well-known
> >         types, rather than complex structures;
> > 
> >       * it enables additional error checking by leveraging the
> >         parsing and validation routines for well-known types;
> > 
> >       * it simplifies implementations by eliminating special-case
> >         attribute-specific parsing.
> > 
> > "
> > 
> > Regarding the first item: It depends how you provision the data. if you
> type them with an ASCII editor then I fully agree. If you have tools then I
> disagree. For larger systems you are not using an ASCII editor, IMHO. 
> 
>   The data can be entered in ASCII in a text editor, into a form field
> of a GUI, etc.  The data does not magically "know" what value it should
> have.  That information has to come from somewhere.  That "somewhere"
> *always* leads back to a human being.

But you understand what I mean. For example, with location information I could imagine that one uses a nice map and draw a circle there and then the software would provision that information into the database (in the right format for distribution within RADIUS). Now, assuming that an administrator would enter the data in the cryptic format defined by the RADIUS GEOPRIV RFC wouldn't probably work all that well. 

> 
> > Regarding the second item: It depends when you do the error checking. If
> you do it as post-processing (for example, when the data ends up in the
> database) then there isn't an issue at all. if you do it in real-time when
> you get the data provided then you will in many cases have to have a more
> sophisticated policy language; the capabilities of the policy language has
> never been clearly described nor investigated as part of a survey of available
> implementations. 
> 
>   That investigation is out of scope for this document.

The problem is that it impacts the content of the document. 
Out of scope is what the editor and the group consider out of scope. 

> 
>   And even when the data comes from a database, the RADIUS server nearly
> always does some parsing of it.  i.e. the DB can do syntax checking on
> IP addresses, but the SQL queries can return the IPs as either a
> "native" 4 octet blob, or as a string.  When the SQL query returns a
> string, the RADIUS server needs to parse it.
> 
> > Regarding item three: I agree with this item to some extend but
> splitting attributes into multiple attributes (or even multiple messages, as
> suggested in the text) requires some mechanism to correlate them. This also
> requires code and potentially state to be maintained. 
> 
>   Potentially.  However, most RADIUS implementations should already have
> the ability to send multiple attributes at once.  That functionality can
> be leveraged to send "logically" correlated attributes.

These assumptions are not stated in the document. 

> 
> > I would encourage the group to investigate the existing RADIUS server
> implementation features (independently of the document; certainly not
> blocking the progress of the document) because it could lead to interesting
> insights. I would also be in favor of suggesting that people think about how they
> are going to process attributes (on the sending and on the receiving side
> and what the required code changes are). Being explicit about these aspects
> would improve the quality of the specification IMHO. 
> 
>   That's a great idea.  I'm not going to do it, however.

I already thought that you would say so. 

Ciao
Hannes

>   Alan DeKok.

Delivery-date: Fri, 09 Jul 2010 13:00:40 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-16.txt 
Date: Fri,  9 Jul 2010 06:00:02 -0700 (PDT)

--NextPart

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

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-16.txt
	Pages           : 38
	Date            : 2010-07-09

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-16.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-design-16.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Fri, 09 Jul 2010 12:18:56 +0000
Date: Fri, 09 Jul 2010 14:18:13 +0200
From: Alan DeKok <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked]
Subject: Re: Design Guidelines draft

Hannes Tschofenig wrote:
> I had a brief look again at the latest version of the design guidelines draft and noticed 2 points that I would like to highlight: 
> 
> 1) Repetition
> 
> Section 2.1 lists the basic data types. Section 3.2.1 lists them again. And so does Appendix A.1.1.
> 
> I would argue that we should only have them once listed in the document (at least I would argue to get rid of A.1.1). Appendix A in general repeats what was said in the previous section again. Appendix B is good since it shows some of the examples. 

  I agree.  I'll delete the list in A.1.1, and incorporate the text from
Section 3.2.1 into Section 2.1.

> The line drawn between the basic and the complex data types is still arbitrarily, which leaves a bad taste behind. 

  I'm not sure how it's arbitrary.  The basic data types are "integer",
"Ip address", etc.  The tagging mechanism is allowed because it's widely
used.  Any grouping, nesting, structed types are "complex".

> 2) Inconsistent story
> 
> To avoid complex attributes the document argues to split them. But then the document furthermore argues that the attribute code space is going to be exhausted pretty soon. 

  Yes.  It's hoped that the attribute space exhaustion will be fixed in
a future spec.  Given the current rate of assignment, I think we have a
few years left before the RFC space is full.

> However, it does not nicely fit in the story of basic vs. complex
attributes since the extended attribute format is a complex attribute
that by definition in the document has to be avoided at all cost
(because of security vulnerabilities, etc.).

  No.  The document RECOMMENDS that complex types be avoided.  It allows
later documents to update this one.  If the WG decides that the extended
format is an allowable "complex" type, then *nothing* in this document
forbids that.

  I'll repeat, because that point has come up many, many, times.
NOTHING in this document forbids or prohibits the WG from defining the
extended attributes to be of complex types.

> Additionally there are a few minor notes: 
> 
> a) What is a "service definition"? (see Section 2.3)

  A "service being provisioned".

> A reference to an example would help to understand what is actually meant (and what isn't). The term "service" is so generic that it has to lead to confusion. For example, is the recently proposed SAML messaging work over RADIUS a negative example for this?

  The existing RFCs are vague on what "services" mean.  This spec isn't
the place to define them.

> b) Section 3.2.3: 
> 
> "
>       * it is easier for the user to enter the data as well-known
>         types, rather than complex structures;
> "
> 
> please replace the term "user" with something else, particularly since the rest of the document talks about the user in the sense of the person gaining access to the network. here we are talking about the person doing the system administration. 

  OK.  That could be "an administrator" instead of "a user"

> c) Section 3.2.3: A general comment
> 
> With the following bullets I would like to have a sentence added that this is very implementation specific: 
>
> "
>       * it is easier for the user to enter the data as well-known
>         types, rather than complex structures;
> 
>       * it enables additional error checking by leveraging the
>         parsing and validation routines for well-known types;
> 
>       * it simplifies implementations by eliminating special-case
>         attribute-specific parsing.
> 
> "
> 
> Regarding the first item: It depends how you provision the data. if you type them with an ASCII editor then I fully agree. If you have tools then I disagree. For larger systems you are not using an ASCII editor, IMHO. 

  The data can be entered in ASCII in a text editor, into a form field
of a GUI, etc.  The data does not magically "know" what value it should
have.  That information has to come from somewhere.  That "somewhere"
*always* leads back to a human being.

> Regarding the second item: It depends when you do the error checking. If you do it as post-processing (for example, when the data ends up in the database) then there isn't an issue at all. if you do it in real-time when you get the data provided then you will in many cases have to have a more sophisticated policy language; the capabilities of the policy language has never been clearly described nor investigated as part of a survey of available implementations. 

  That investigation is out of scope for this document.

  And even when the data comes from a database, the RADIUS server nearly
always does some parsing of it.  i.e. the DB can do syntax checking on
IP addresses, but the SQL queries can return the IPs as either a
"native" 4 octet blob, or as a string.  When the SQL query returns a
string, the RADIUS server needs to parse it.

> Regarding item three: I agree with this item to some extend but splitting attributes into multiple attributes (or even multiple messages, as suggested in the text) requires some mechanism to correlate them. This also requires code and potentially state to be maintained. 

  Potentially.  However, most RADIUS implementations should already have
the ability to send multiple attributes at once.  That functionality can
be leveraged to send "logically" correlated attributes.

> I would encourage the group to investigate the existing RADIUS server implementation features (independently of the document; certainly not blocking the progress of the document) because it could lead to interesting insights. I would also be in favor of suggesting that people think about how they are going to process attributes (on the sending and on the receiving side and what the required code changes are). Being explicit about these aspects would improve the quality of the specification IMHO. 

  That's a great idea.  I'm not going to do it, however.

  Alan DeKok.

Delivery-date: Fri, 09 Jul 2010 10:36:34 +0000
Date: Fri, 09 Jul 2010 12:35:37 +0200
From: "Hannes Tschofenig" <[email-masked]>
Subject: Design Guidelines draft
To: [email-masked]

Hi all, 

thanks for improving the document. 

I had a brief look again at the latest version of the design guidelines draft and noticed 2 points that I would like to highlight: 

1) Repetition

Section 2.1 lists the basic data types. Section 3.2.1 lists them again. And so does Appendix A.1.1.

I would argue that we should only have them once listed in the document (at least I would argue to get rid of A.1.1). Appendix A in general repeats what was said in the previous section again. Appendix B is good since it shows some of the examples. 

The line drawn between the basic and the complex data types is still arbitrarily, which leaves a bad taste behind. 

2) Inconsistent story

To avoid complex attributes the document argues to split them. But then the document furthermore argues that the attribute code space is going to be exhausted pretty soon. 

The story from the RADEXT group, at least if I understood it correctly, was the extended attribute format, see http://datatracker.ietf.org/doc/draft-ietf-radext-extended-attributes/. This would solve the "exhaustion" issue. However, it does not nicely fit in the story of basic vs. complex attributes since the extended attribute format is a complex attribute that by definition in the document has to be avoided at all cost (because of security vulnerabilities, etc.). 

Additionally there are a few minor notes: 

a) What is a "service definition"? (see Section 2.3)

A reference to an example would help to understand what is actually meant (and what isn't). The term "service" is so generic that it has to lead to confusion. For example, is the recently proposed SAML messaging work over RADIUS a negative example for this?

b) Section 3.2.3: 

"
      * it is easier for the user to enter the data as well-known
        types, rather than complex structures;
"

please replace the term "user" with something else, particularly since the rest of the document talks about the user in the sense of the person gaining access to the network. here we are talking about the person doing the system administration. 

c) Section 3.2.3: A general comment

With the following bullets I would like to have a sentence added that this is very implementation specific: 

"
      * it is easier for the user to enter the data as well-known
        types, rather than complex structures;

      * it enables additional error checking by leveraging the
        parsing and validation routines for well-known types;

      * it simplifies implementations by eliminating special-case
        attribute-specific parsing.

"

Regarding the first item: It depends how you provision the data. if you type them with an ASCII editor then I fully agree. If you have tools then I disagree. For larger systems you are not using an ASCII editor, IMHO. 

Regarding the second item: It depends when you do the error checking. If you do it as post-processing (for example, when the data ends up in the database) then there isn't an issue at all. if you do it in real-time when you get the data provided then you will in many cases have to have a more sophisticated policy language; the capabilities of the policy language has never been clearly described nor investigated as part of a survey of available implementations. 

Regarding item three: I agree with this item to some extend but splitting attributes into multiple attributes (or even multiple messages, as suggested in the text) requires some mechanism to correlate them. This also requires code and potentially state to be maintained. 

I would encourage the group to investigate the existing RADIUS server implementation features (independently of the document; certainly not blocking the progress of the document) because it could lead to interesting insights. I would also be in favor of suggesting that people think about how they are going to process attributes (on the sending and on the receiving side and what the required code changes are). Being explicit about these aspects would improve the quality of the specification IMHO. 

Ciao
Hannes

Delivery-date: Thu, 08 Jul 2010 20:59:53 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT Virtual Interim Agenda:  July 12, 2010
Date: Thu, 8 Jul 2010 13:59:41 -0700

--_af036ff2-d6ab-4659-9fa5-793a4add849e_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

RADEXT WG Virtual Interim Agenda

Monday, July 12, 2010

11 AM - 1:30 PM Pacific Time

Presentations:  http://www.drizzle.com/~aboba/RADEXT/July-Interim/

Jabber room:  radext
at jabber.ietf.org

Conference parameters: http://ops.ietf.org/lists/radiusext/2010/msg00502.html

Chairs

        Bernard Aboba
<bernard_aboba at hotmail.com> 

        Mauricio
Sanchez <mauricio.sanchez at hp.com>

Agenda

11:00 AM – 11:10 AM PT Preliminaries (10 minutes)

     Attendance

     Note takers

     Agenda bash

     Document Status

Documents Completing IETF Last Call (40 minutes)

11:20 AM – 11:30 AM PT RADIUS over TCP, Alan DeKok (10
minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp

11:30 – 12:00 PM PT Design Guidelines, Alan DeKok (30
minutes)

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

Documents Completing RADEXT WG Last Call

12:00 PM – 12:15 PM PT IPv6 Access, W. Dec (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

RADEXT WG Work Items (30 minutes)

12:15 PM PT – 12:45 PM PT Extended RADIUS Attributes, Alan
DeKok (30 minutes)

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

--_af036ff2-d6ab-4659-9fa5-793a4add849e_
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:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 14"><meta name="Originator" content="Microsoft Word 14"><link rel="File-List" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><link rel="themeData" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-alt:"Electra LH Regular";
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	font-family:"Times New Roman","serif";
	mso-bidi-font-family:"Times New Roman";
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	mso-themecolor:followedhyperlink;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle16
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:Calibri;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:Calibri;}
.MsoPapDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
-->
</style><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
</style>
<![endif]-->

<p class="MsoNormal">RADEXT WG Virtual Interim Agenda<o:p></o:p></p>

<p class="MsoNormal">Monday, July 12, 2010<o:p></o:p></p>

<p class="MsoNormal">11 AM - 1:30 PM Pacific Time<o:p></o:p></p>

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

<p class="MsoNormal">Presentations:<span style="">&nbsp; </span><a href="http://www.drizzle.com/%7Eaboba/RADEXT/July-Interim/">http://www.drizzle.com/~aboba/RADEXT/July-Interim/</a><o:p></o:p></p>

<p class="MsoNormal">Jabber room:<span style="">&nbsp; </span>radext
at jabber.ietf.org<o:p></o:p></p>

<p class="MsoNormal">Conference parameters: <a href="http://ops.ietf.org/lists/radiusext/2010/msg00502.html">http://ops.ietf.org/lists/radiusext/2010/msg00502.html</a><o:p></o:p></p>

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

<p class="MsoNormal">Chairs<o:p></o:p></p>

<p class="MsoNormal"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Bernard Aboba
&lt;bernard_aboba at hotmail.com&gt; <o:p></o:p></p>

<p class="MsoNormal"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Mauricio
Sanchez &lt;mauricio.sanchez at hp.com&gt;<o:p></o:p></p>

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

<p class="MsoNormal">Agenda<o:p></o:p></p>

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

<p class="MsoNormal">11:00 AM – 11:10 AM PT Preliminaries (10 minutes)<o:p></o:p></p>

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

<p class="MsoNormal"><span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>Attendance<o:p></o:p></p>

<p class="MsoNormal"><span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>Note takers<o:p></o:p></p>

<p class="MsoNormal"><span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>Agenda bash<o:p></o:p></p>

<p class="MsoNormal"><span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>Document Status<o:p></o:p></p>

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

<p class="MsoNormal">Documents Completing IETF Last Call (40 minutes)<o:p></o:p></p>

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

<p class="MsoNormal">11:20 AM – 11:30 AM PT RADIUS over TCP, Alan DeKok (10
minutes)<o:p></o:p></p>

<p class="MsoNormal"><a href="http://tools.ietf.org/html/draft-ietf-radext-tcp">http://tools.ietf.org/html/draft-ietf-radext-tcp</a><o:p></o:p></p>

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

<p class="MsoNormal">11:30 – 12:00 PM PT Design Guidelines, Alan DeKok (30
minutes)<o:p></o:p></p>

<p class="MsoNormal"><a href="http://tools.ietf.org/html/draft-ietf-radext-design-guidelines">http://tools.ietf.org/html/draft-ietf-radext-design-guidelines</a><o:p></o:p></p>

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

<p class="MsoNormal">Documents Completing RADEXT WG Last Call<o:p></o:p></p>

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

<p class="MsoNormal">12:00 PM – 12:15 PM PT IPv6 Access, W. Dec (15 minutes)<o:p></o:p></p>

<p class="MsoNormal"><a href="http://tools.ietf.org/html/draft-ietf-radext-ipv6-access">http://tools.ietf.org/html/draft-ietf-radext-ipv6-access</a><o:p></o:p></p>

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

<p class="MsoNormal">RADEXT WG Work Items (30 minutes)<o:p></o:p></p>

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

<p class="MsoNormal">12:15 PM PT – 12:45 PM PT Extended RADIUS Attributes, Alan
DeKok (30 minutes)<o:p></o:p></p>

<p class="MsoNormal"><a href="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes">http://tools.ietf.org/html/draft-ietf-radext-extended-attributes</a><o:p></o:p></p>

<p class="MsoNormal" style=""><span style="font-size: 12pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"><o:p>&nbsp;</o:p></span></p>

 		 	   		  </body>
</html>
--_af036ff2-d6ab-4659-9fa5-793a4add849e_--

Delivery-date: Thu, 08 Jul 2010 20:58:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Henry Ptasinski'" <[email-masked]>, <[email-masked]>, "'Tal Givoly'" <[email-masked]>, "'Wojciech Dec \(wdec\)'" <[email-masked]>
Subject: RADEXT Virtual Interim Meeting
Date: Thu, 8 Jul 2010 13:58:31 -0700

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 14.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16011104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="Avi Lior";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Romascanu, Dan (Dan)";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Henry Ptasinski";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN=[email-masked];RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Tal Givoly";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Wojciech Dec (wdec)";RSVP=TRUE:mailto:[email-masked]
CLASS:PUBLIC
CREATED:20100708T205830Z
DESCRIPTION:IETF Secretariat invites you to attend this online meeting. \n\
	nTopic: RADEXT \nDate: Monday\, July 12\, 2010 \nTime: 10:45 am\, Pacific 
	Daylight Time (San Francisco\, GMT-07:00) \nMeeting Number: 961 126 477 \n
	Meeting Password: (This meeting does not require a password.) \n\n\n------
	------------------------------------------------- \nTo join the online mee
	ting (Now from iPhones too!) \n-------------------------------------------
	------------ \n1. Go to https://workgreen.webex.com/workgreen/j.php?ED5
	092087&UID30222477&RT=MiM0 \n2. If requested\, enter your name and emai
	l address. \n3. If a password is required\, enter the meeting password: (T
	his meeting does not require a password.) \n4. Click "Join". \n\nTo view i
	n other time zones or languages\, please click the link: \nhttps://workgre
	en.webex.com/workgreen/j.php?ED5092087&UID30222477&ORT=MiM0 \n\n----
	--------------------------------------------------- \nTo join the audio co
	nference only \n------------------------------------------------------- \n
	To receive a call back\, provide your phone number when you join the meeti
	ng\, or call the number below and enter the access code. \nCall-in toll nu
	mber (US/Canada): 1-408-792-6300 \nGlobal call-in numbers: https://workgre
	en.webex.com/workgreen/globalcallin.php?serviceType=MC&ED5092087&tollFr
	ee=0 \n\nAccess code:961 126 477 \n\n-------------------------------------
	------------------ \nFor assistance \n------------------------------------
	------------------- \n1. Go to https://workgreen.webex.com/workgreen/mc \n
	2. On the left navigation bar\, click "Support". \n\nYou can contact me at
	: \[email-masked] \n1-510-492-4081 \n\nTo add this meeting to your cale
	ndar program (for example Microsoft Outlook)\, click this link: \nhttps://
	workgreen.webex.com/workgreen/j.php?ED5092087&UID30222477&ICS=MI&LD	1&RD=2&ST=1&SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3E-o=&RT=MiM0 \n\n
	The playback of UCF (Universal Communications Format) rich media files req
	uires appropriate players. To view this type of rich media files in the me
	eting\, please check whether you have the players installed on your comput
	er by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php \
	n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfreetri
	al \n\nhttp://www.webex.com \n\n=====================
	==========\nRADEXT WG Virtual Interim Agenda\nMonday\, July 12\,
	 2010\n11 AM - 1:30 PM Pacific Time\n\nPresentations:  http://www.drizzle.
	com/~aboba/RADEXT/July-Interim/\nJabber room:  radext at jabber.ietf.org\n
	Conference parameters: http://ops.ietf.org/lists/radiusext/2010/msg00502.h
	tml\n\nChairs\n        Bernard Aboba <bernard_aboba at hotmail.com> \n    
	    Mauricio Sanchez <mauricio.sanchez at hp.com>\n \nAgenda\n \n11:00 AM 
	â€“ 11:10 AM PT Preliminaries (10 minutes)\n \n     Attendance\n     Note 
	takers\n     Agenda bash\n     Document Status\n \nDocuments Completing IE
	TF Last Call (40 minutes)\n \n11:20 AM â€“ 11:30 AM PT RADIUS over TCP\, A
	lan DeKok (10 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-tcp\n
	 \n11:30 â€“ 12:00 PM PT Design Guidelines\, Alan DeKok (30 minutes)\nhttp
	://tools.ietf.org/html/draft-ietf-radext-design-guidelines\n \nDocuments C
	ompleting RADEXT WG Last Call\n\n12:00 PM â€“ 12:15 PM PT IPv6 Access\, W.
	 Dec (15 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-ipv6-acces
	s\n\nRADEXT WG Work Items (30 minutes)\n \n12:15 PM PT â€“ 12:45 PM PT Ext
	ended RADIUS Attributes\, Alan DeKok (30 minutes)\nhttp://tools.ietf.org/h
	tml/draft-ietf-radext-extended-attributes\n\n
DTEND;TZID="Pacific Standard Time":20100712T133000
DTSTAMP:20100708T205830Z
DTSTART;TZID="Pacific Standard Time":20100712T110000
LAST-MODIFIED:20100708T205830Z
LOCATION:Teleconference
ORGANIZER;CN="Bernard Aboba":mailto:[email-masked]
PRIORITY:5
SEQUENCE:2
SUMMARY;LANGUAGE=en-us:RADEXT Virtual Interim Meeting
TRANSP:OPAQUE
UID:040000008200E00074C5B7101A82E00800000000804B061CD916CB01000000000000000
	010000000183AD543CB686B41B739B4F5CD5A595D
X-ALT-DESC;FMTTYPE=text/html:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//E
	N">\n<HTML>\n<HEAD>\n<META NAME="Generator" CONTENT="MS Exchange Server ve
	rsion 08.01.0240.003">\n<TITLE></TITLE>\n</HEAD>\n<BODY>\n<!-- Converted f
	rom text/rtf format -->\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><SPAN LANG
	="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma">IETF Secreta
	riat invites you to attend this online meeting.<BR>\n<BR>\nTopic: RADEXT<B
	R>\nDate: Monday\, July 12\, 2010<BR>\nTime: 10:45 am\, Pacific Daylight T
	ime (San Francisco\, GMT-07:00)<BR>\nMeeting Number: 961 126 477<BR>\nMeet
	ing Password: (This meeting does not require a password.)<BR>\n<BR>\n<BR>\
	n-------------------------------------------------------<BR>\nTo join the 
	online meeting (Now from iPhones too!)<BR>\n------------------------------
	-------------------------<BR>\n1. Go to</FONT></SPAN><SPAN LANG="en-us"> <
	/SPAN><A HREF="https://workgreen.webex.com/workgreen/j.php?ED5092087&am
	p\;UID30222477&amp\;RT=MiM0"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-u
	s"></SPAN><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma"
	>https://workgreen.webex.com/workgreen/j.php?ED5092087&amp\;UID30222
	477&amp\;RT=MiM0</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG
	="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 
	FACE="Tahoma"><BR>\n2. If requested\, enter your name and email address.<B
	R>\n3. If a password is required\, enter the meeting password: (This meeti
	ng does not require a password.)<BR>\n4. Click &quot\;Join&quot\;.<BR>\n<B
	R>\nTo view in other time zones or languages\, please click the link:<BR>\
	n</FONT></SPAN><SPAN LANG="en-us"></SPAN><A HREF="https://workgreen.webex.
	com/workgreen/j.php?ED5092087&amp\;UID30222477&amp\;ORT=MiM0"><SPAN 
	LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U><FONT 
	COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/workgreen
	/j.php?ED5092087&amp\;UID30222477&amp\;ORT=MiM0</FONT></U></SPAN><SP
	AN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></
	SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma"><BR>\n<BR>\n-----------
	--------------------------------------------<BR>\nTo join the audio confer
	ence only<BR>\n-------------------------------------------------------<BR>
	\nTo receive a call back\, provide your phone number when you join the mee
	ting\, or call the number below and enter the access code.<BR>\nCall-in to
	ll number (US/Canada): 1-408-792-6300<BR>\nGlobal call-in numbers:</FONT><
	/SPAN><SPAN LANG="en-us"> </SPAN><A HREF="https://workgreen.webex.com/work
	green/globalcallin.php?serviceType=MC&amp\;ED5092087&amp\;tollFree=0"><
	SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U><
	FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/work
	green/globalcallin.php?serviceType=MC&amp\;ED5092087&amp\;tollFree=0</F
	ONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SP
	AN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma"><BR>\
	n<BR>\nAccess code:961 126 477<BR>\n<BR>\n--------------------------------
	-----------------------<BR>\nFor assistance<BR>\n-------------------------
	------------------------------<BR>\n1. Go to</FONT></SPAN><SPAN LANG="en-u
	s"> </SPAN><A HREF="https://workgreen.webex.com/workgreen/mc"><SPAN LANG="
	en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U><FONT COLOR	"#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/workgreen/mc</F
	ONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SP
	AN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma"><BR>\
	n2. On the left navigation bar\, click &quot\;Support&quot\;.<BR>\n<BR>\nY
	ou can contact me at:<BR>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><A HREF
	="mailto:[email-masked]"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></
	SPAN><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">amor
	[email-masked]</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en
	-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE
	="Tahoma"><BR>\n1-510-492-4081<BR>\n<BR>\nTo add this meeting to your cale
	ndar program (for example Microsoft Outlook)\, click this link:<BR>\n</FON
	T></SPAN><SPAN LANG="en-us"></SPAN><A HREF="https://workgreen.webex.com/wo
	rkgreen/j.php?ED5092087&amp\;UID30222477&amp\;ICS=MI&amp\;LD=1&amp\;
	RD=2&amp\;ST=1&amp\;SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3E-o=&amp\
	;RT=MiM0"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="
	en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.web
	ex.com/workgreen/j.php?ED5092087&amp\;UID30222477&amp\;ICS=MI&amp\;L
	D=1&amp\;RD=2&amp\;ST=1&amp\;SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3
	E-o=&amp\;RT=MiM0</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LAN
	G="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2
	 FACE="Tahoma"><BR>\n<BR>\nThe playback of UCF (Universal Communications F
	ormat) rich media files requires appropriate players. To view this type of
	 rich media files in the meeting\, please check whether you have the playe
	rs installed on your computer by going to</FONT></SPAN><SPAN LANG="en-us">
	 </SPAN><A HREF="https://workgreen.webex.com/workgreen/systemdiagnosis.php
	"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><
	U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/w
	orkgreen/systemdiagnosis.php</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></
	A><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><
	FONT SIZE=2 FACE="Tahoma"><BR>\n<BR>\nSign up for a free trial of WebEx<BR
	>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><A HREF="http://www.webex.com/g
	o/mcemfreetrial"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN
	 LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">http://www.web
	ex.com/go/mcemfreetrial</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SP
	AN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT 
	SIZE=2 FACE="Tahoma"><BR>\n<BR>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><
	A HREF="http://www.webex.com"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"
	></SPAN><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">h
	ttp://www.webex.com</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN L
	ANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE
	=2 FACE="Tahoma"><BR>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG	"en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">
	===============================</FONT></SPA
	N><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><
	SPAN LANG="en-us"><FONT FACE="Calibri">RADEXT WG Virtual Interim Agenda</F
	ONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">Mond
	ay\, July 12\, 2010</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FO
	NT FACE="Calibri">11 AM - 1:30 PM Pacific Time</FONT></SPAN></P>\n\n<P DIR
	=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">Presentations:&nbsp\;</FONT><
	/SPAN><SPAN LANG="en-us"> </SPAN><A HREF="http://www.drizzle.com/~aboba/RA
	DEXT/July-Interim/"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" FACE="Cali
	bri">http://www.drizzle.com/~aboba/RADEXT/July-Interim/</FONT></U></SPAN><
	SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR>
	<SPAN LANG="en-us"><FONT FACE="Calibri">Jabber room:&nbsp\; radext at jabb
	er.ietf.org</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPA
	N LANG="en-us"><FONT FACE="Calibri">Conference parameters:</FONT></SPAN><S
	PAN LANG="en-us"> </SPAN><A HREF="http://ops.ietf.org/lists/radiusext/2010
	/msg00502.html"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" FACE="Calibri"
	>http://ops.ietf.org/lists/radiusext/2010/msg00502.html</FONT></U></SPAN><
	SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR>
	<SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE
	="Calibri">Chairs</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT
	 FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\;&nbsp\;&nbsp\;&nbsp\; Bernard 
	Aboba &lt\;bernard_aboba at hotmail.com&gt\; </FONT></SPAN></P>\n\n<P DIR	LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\;&n
	bsp\;&nbsp\;&nbsp\; Mauricio Sanchez &lt\;mauricio.sanchez at hp.com&gt\;<
	/FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&n
	bsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calib
	ri">Agenda</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="
	Calibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT 
	FACE="Calibri">11:00 AM â€“ 11:10 AM PT Preliminaries (10 minutes)</FONT><
	/SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;</
	FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nb
	sp\;&nbsp\;&nbsp\;&nbsp\; Attendance</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN
	 LANG="en-us"><FONT FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\; Note taker
	s</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">
	&nbsp\;&nbsp\;&nbsp\;&nbsp\; Agenda bash</FONT></SPAN></P>\n\n<P DIR=LTR><
	SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\; Docume
	nt Status</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="C
	alibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT F
	ACE="Calibri">Documents Completing IETF Last Call (40 minutes)</FONT></SPA
	N></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;</FONT
	></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">11:20 A
	M â€“ 11:30 AM PT RADIUS over TCP\, Alan DeKok (10 minutes)</FONT></SPAN><
	/P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><A HREF="http://tools.ietf.org
	/html/draft-ietf-radext-tcp"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" F
	ACE="Calibri">http://tools.ietf.org/html/draft-ietf-radext-tcp</FONT></U><
	/SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN></P>\n\n<P D
	IR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;</FONT></SPAN></P>\n
	\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">11:30 â€“ 12:00 PM PT
	 Design Guidelines\, Alan DeKok (30 minutes)</FONT></SPAN></P>\n\n<P DIR=L
	TR><SPAN LANG="en-us"></SPAN><A HREF="http://tools.ietf.org/html/draft-iet
	f-radext-design-guidelines"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" FA
	CE="Calibri">http://tools.ietf.org/html/draft-ietf-radext-design-guideline
	s</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN
	></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;</FONT>
	</SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">Document
	s Completing RADEXT WG Last Call</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LAN
	G="en-us"><FONT FACE="Calibri">12:00 PM â€“ 12:15 PM PT IPv6 Access\, W. D
	ec (15 minutes)</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN>
	<A HREF="http://tools.ietf.org/html/draft-ietf-radext-ipv6-access"><SPAN L
	ANG="en-us"><U><FONT COLOR="#0000FF" FACE="Calibri">http://tools.ietf.org/
	html/draft-ietf-radext-ipv6-access</FONT></U></SPAN><SPAN LANG="en-us"></S
	PAN></A><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><F
	ONT FACE="Calibri">RADEXT WG Work Items (30 minutes)</FONT></SPAN></P>\n\n
	<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;</FONT></SPAN></
	P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">12:15 PM PT â€“ 1
	2:45 PM PT Extended RADIUS Attributes\, Alan DeKok (30 minutes)</FONT></SP
	AN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><A HREF="http://tools.ietf
	.org/html/draft-ietf-radext-extended-attributes"><SPAN LANG="en-us"><U><FO
	NT COLOR="#0000FF" FACE="Calibri">http://tools.ietf.org/html/draft-ietf-ra
	dext-extended-attributes</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><S
	PAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><SPAN
	 LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>\n\n</BODY>\n</HTML>
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-DISALLOW-COUNTER:TRUE
X-MS-OLK-APPTLASTSEQUENCE:1
X-MS-OLK-APPTSEQTIME:20100708T205651Z
X-MS-OLK-AUTOSTARTCHECK:FALSE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR

Delivery-date: Thu, 08 Jul 2010 20:57:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Henry Ptasinski'" <[email-masked]>, <[email-masked]>, "'Tal Givoly'" <[email-masked]>, "'Wojciech Dec \(wdec\)'" <[email-masked]>
Subject: RADEXT Virtual Interim Meeting
Date: Thu, 8 Jul 2010 13:56:51 -0700

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 14.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16011104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="Avi Lior";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Romascanu, Dan (Dan)";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Henry Ptasinski";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN=[email-masked];RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Tal Givoly";RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN="Wojciech Dec (wdec)";RSVP=TRUE:mailto:[email-masked]
CLASS:PUBLIC
CREATED:20100708T205651Z
DESCRIPTION:IETF Secretariat invites you to attend this online meeting. \n\
	nTopic: RADEXT \nDate: Monday\, July 12\, 2010 \nTime: 10:45 am\, Pacific 
	Daylight Time (San Francisco\, GMT-07:00) \nMeeting Number: 961 126 477 \n
	Meeting Password: (This meeting does not require a password.) \n\n\n------
	------------------------------------------------- \nTo join the online mee
	ting (Now from iPhones too!) \n-------------------------------------------
	------------ \n1. Go to https://workgreen.webex.com/workgreen/j.php?ED5
	092087&UID30222477&RT=MiM0 \n2. If requested\, enter your name and emai
	l address. \n3. If a password is required\, enter the meeting password: (T
	his meeting does not require a password.) \n4. Click "Join". \n\nTo view i
	n other time zones or languages\, please click the link: \nhttps://workgre
	en.webex.com/workgreen/j.php?ED5092087&UID30222477&ORT=MiM0 \n\n----
	--------------------------------------------------- \nTo join the audio co
	nference only \n------------------------------------------------------- \n
	To receive a call back\, provide your phone number when you join the meeti
	ng\, or call the number below and enter the access code. \nCall-in toll nu
	mber (US/Canada): 1-408-792-6300 \nGlobal call-in numbers: https://workgre
	en.webex.com/workgreen/globalcallin.php?serviceType=MC&ED5092087&tollFr
	ee=0 \n\nAccess code:961 126 477 \n\n-------------------------------------
	------------------ \nFor assistance \n------------------------------------
	------------------- \n1. Go to https://workgreen.webex.com/workgreen/mc \n
	2. On the left navigation bar\, click "Support". \n\nYou can contact me at
	: \[email-masked] \n1-510-492-4081 \n\nTo add this meeting to your cale
	ndar program (for example Microsoft Outlook)\, click this link: \nhttps://
	workgreen.webex.com/workgreen/j.php?ED5092087&UID30222477&ICS=MI&LD	1&RD=2&ST=1&SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3E-o=&RT=MiM0 \n\n
	The playback of UCF (Universal Communications Format) rich media files req
	uires appropriate players. To view this type of rich media files in the me
	eting\, please check whether you have the players installed on your comput
	er by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php \
	n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfreetri
	al \n\nhttp://www.webex.com \n\n=====================
	==========\n\nRADEXT Virtual Interm Meeting \nJuly 12\, 2010\n11
	 AM â€“ 1:30 PM Pacific Time\n\nChairs\n        Bernard Aboba <bernard_abo
	ba at hotmail.com> \n        Mauricio Sanchez <mauricio.sanchez at hp.com>
	\n \nAgenda\n \n11:00 AM â€“ 11:10 AM PT Preliminaries (10 minutes)\n \n  
	   Attendance\n     Note takers\n     Agenda bash\n     Document Status\n 
	\nDocuments Completing IETF Last Call (40 minutes)\n \n11:20 AM â€“ 11:30 
	AM PT RADIUS over TCP\, Alan DeKok (10 minutes)\nhttp://tools.ietf.org/htm
	l/draft-ietf-radext-tcp\n \n11:30 â€“ 12:00 PM PT Design Guidelines\, Alan
	 DeKok (30 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-design-g
	uidelines\n \nDocuments Completing RADEXT WG Last Call\n\n12:00 PM â€“ 12:
	15 PM PT IPv6 Access\, W. Dec (15 minutes)\nhttp://tools.ietf.org/html/dra
	ft-ietf-radext-ipv6-access\n\nRADEXT WG Work Items (30 minutes)\n \n12:15 
	PM PT â€“ 12:45 PM PT Extended RADIUS Attributes\, Alan DeKok (30 minutes)
	\nhttp://tools.ietf.org/html/draft-ietf-radext-extended-attributes\n\n
DTEND;TZID="Pacific Standard Time":20100712T133000
DTSTAMP:20100708T205651Z
DTSTART;TZID="Pacific Standard Time":20100712T110000
LAST-MODIFIED:20100708T205651Z
LOCATION:Teleconference
ORGANIZER;CN="Bernard Aboba":mailto:[email-masked]
PRIORITY:5
SEQUENCE:1
SUMMARY;LANGUAGE=en-us:RADEXT Virtual Interim Meeting
TRANSP:OPAQUE
UID:040000008200E00074C5B7101A82E00800000000804B061CD916CB01000000000000000
	010000000183AD543CB686B41B739B4F5CD5A595D
X-ALT-DESC;FMTTYPE=text/html:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//E
	N">\n<HTML>\n<HEAD>\n<META NAME="Generator" CONTENT="MS Exchange Server ve
	rsion 08.01.0240.003">\n<TITLE></TITLE>\n</HEAD>\n<BODY>\n<!-- Converted f
	rom text/rtf format -->\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><SPAN LANG
	="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma">IETF Secreta
	riat invites you to attend this online meeting.<BR>\n<BR>\nTopic: RADEXT<B
	R>\nDate: Monday\, July 12\, 2010<BR>\nTime: 10:45 am\, Pacific Daylight T
	ime (San Francisco\, GMT-07:00)<BR>\nMeeting Number: 961 126 477<BR>\nMeet
	ing Password: (This meeting does not require a password.)<BR>\n<BR>\n<BR>\
	n-------------------------------------------------------<BR>\nTo join the 
	online meeting (Now from iPhones too!)<BR>\n------------------------------
	-------------------------<BR>\n1. Go to</FONT></SPAN><SPAN LANG="en-us"> <
	/SPAN><A HREF="https://workgreen.webex.com/workgreen/j.php?ED5092087&am
	p\;UID30222477&amp\;RT=MiM0"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-u
	s"></SPAN><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma"
	>https://workgreen.webex.com/workgreen/j.php?ED5092087&amp\;UID30222
	477&amp\;RT=MiM0</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG
	="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 
	FACE="Tahoma"><BR>\n2. If requested\, enter your name and email address.<B
	R>\n3. If a password is required\, enter the meeting password: (This meeti
	ng does not require a password.)<BR>\n4. Click &quot\;Join&quot\;.<BR>\n<B
	R>\nTo view in other time zones or languages\, please click the link:<BR>\
	n</FONT></SPAN><SPAN LANG="en-us"></SPAN><A HREF="https://workgreen.webex.
	com/workgreen/j.php?ED5092087&amp\;UID30222477&amp\;ORT=MiM0"><SPAN 
	LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U><FONT 
	COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/workgreen
	/j.php?ED5092087&amp\;UID30222477&amp\;ORT=MiM0</FONT></U></SPAN><SP
	AN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></
	SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma"><BR>\n<BR>\n-----------
	--------------------------------------------<BR>\nTo join the audio confer
	ence only<BR>\n-------------------------------------------------------<BR>
	\nTo receive a call back\, provide your phone number when you join the mee
	ting\, or call the number below and enter the access code.<BR>\nCall-in to
	ll number (US/Canada): 1-408-792-6300<BR>\nGlobal call-in numbers:</FONT><
	/SPAN><SPAN LANG="en-us"> </SPAN><A HREF="https://workgreen.webex.com/work
	green/globalcallin.php?serviceType=MC&amp\;ED5092087&amp\;tollFree=0"><
	SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U><
	FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/work
	green/globalcallin.php?serviceType=MC&amp\;ED5092087&amp\;tollFree=0</F
	ONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SP
	AN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma"><BR>\
	n<BR>\nAccess code:961 126 477<BR>\n<BR>\n--------------------------------
	-----------------------<BR>\nFor assistance<BR>\n-------------------------
	------------------------------<BR>\n1. Go to</FONT></SPAN><SPAN LANG="en-u
	s"> </SPAN><A HREF="https://workgreen.webex.com/workgreen/mc"><SPAN LANG="
	en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><U><FONT COLOR	"#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/workgreen/mc</F
	ONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN><SP
	AN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE="Tahoma"><BR>\
	n2. On the left navigation bar\, click &quot\;Support&quot\;.<BR>\n<BR>\nY
	ou can contact me at:<BR>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><A HREF
	="mailto:[email-masked]"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></
	SPAN><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">amor
	[email-masked]</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en
	-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2 FACE
	="Tahoma"><BR>\n1-510-492-4081<BR>\n<BR>\nTo add this meeting to your cale
	ndar program (for example Microsoft Outlook)\, click this link:<BR>\n</FON
	T></SPAN><SPAN LANG="en-us"></SPAN><A HREF="https://workgreen.webex.com/wo
	rkgreen/j.php?ED5092087&amp\;UID30222477&amp\;ICS=MI&amp\;LD=1&amp\;
	RD=2&amp\;ST=1&amp\;SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3E-o=&amp\
	;RT=MiM0"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="
	en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.web
	ex.com/workgreen/j.php?ED5092087&amp\;UID30222477&amp\;ICS=MI&amp\;L
	D=1&amp\;RD=2&amp\;ST=1&amp\;SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3
	E-o=&amp\;RT=MiM0</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LAN
	G="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE=2
	 FACE="Tahoma"><BR>\n<BR>\nThe playback of UCF (Universal Communications F
	ormat) rich media files requires appropriate players. To view this type of
	 rich media files in the meeting\, please check whether you have the playe
	rs installed on your computer by going to</FONT></SPAN><SPAN LANG="en-us">
	 </SPAN><A HREF="https://workgreen.webex.com/workgreen/systemdiagnosis.php
	"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><
	U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/w
	orkgreen/systemdiagnosis.php</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></
	A><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><
	FONT SIZE=2 FACE="Tahoma"><BR>\n<BR>\nSign up for a free trial of WebEx<BR
	>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><A HREF="http://www.webex.com/g
	o/mcemfreetrial"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN
	 LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">http://www.web
	ex.com/go/mcemfreetrial</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SP
	AN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT 
	SIZE=2 FACE="Tahoma"><BR>\n<BR>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><
	A HREF="http://www.webex.com"><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"
	></SPAN><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">h
	ttp://www.webex.com</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN L
	ANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"><FONT SIZE
	=2 FACE="Tahoma"><BR>\n</FONT></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG	"en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">
	===============================</FONT></SPA
	N><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><
	SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPA
	N LANG="en-us"><FONT FACE="Calibri">RADEXT Virtual Interm Meeting </FONT><
	/SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">July 12\,
	 2010</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calib
	ri">11 AM â€“ 1:30 PM Pacific Time</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN L
	ANG="en-us"><FONT FACE="Calibri">Chairs</FONT></SPAN></P>\n\n<P DIR=LTR><S
	PAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\;&nbsp\;&
	nbsp\;&nbsp\; Bernard Aboba &lt\;bernard_aboba at hotmail.com&gt\; </FONT>
	</SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;&
	nbsp\;&nbsp\;&nbsp\;&nbsp\;&nbsp\;&nbsp\; Mauricio Sanchez &lt\;mauricio.s
	anchez at hp.com&gt\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><
	FONT FACE="Calibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en
	-us"><FONT FACE="Calibri">Agenda</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LAN
	G="en-us"><FONT FACE="Calibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SP
	AN LANG="en-us"><FONT FACE="Calibri">11:00 AM â€“ 11:10 AM PT Preliminarie
	s (10 minutes)</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FA
	CE="Calibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><F
	ONT FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\; Attendance</FONT></SPAN></
	P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;&nbsp\;&nb
	sp\;&nbsp\; Note takers</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"
	><FONT FACE="Calibri">&nbsp\;&nbsp\;&nbsp\;&nbsp\; Agenda bash</FONT></SPA
	N></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp\;&nbsp\
	;&nbsp\;&nbsp\; Document Status</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG
	="en-us"><FONT FACE="Calibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPA
	N LANG="en-us"><FONT FACE="Calibri">Documents Completing IETF Last Call (4
	0 minutes)</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="
	Calibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT 
	FACE="Calibri">11:20 AM â€“ 11:30 AM PT RADIUS over TCP\, Alan DeKok (10 m
	inutes)</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><A HREF	"http://tools.ietf.org/html/draft-ietf-radext-tcp"><SPAN LANG="en-us"><U><
	FONT COLOR="#0000FF" FACE="Calibri">http://tools.ietf.org/html/draft-ietf-
	radext-tcp</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-u
	s"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&nbsp
	\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri"
	>11:30 â€“ 12:00 PM PT Design Guidelines\, Alan DeKok (30 minutes)</FONT><
	/SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><A HREF="http://tools.i
	etf.org/html/draft-ietf-radext-design-guidelines"><SPAN LANG="en-us"><U><F
	ONT COLOR="#0000FF" FACE="Calibri">http://tools.ietf.org/html/draft-ietf-r
	adext-design-guidelines</FONT></U></SPAN><SPAN LANG="en-us"></SPAN></A><SP
	AN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="C
	alibri">&nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT F
	ACE="Calibri">Documents Completing RADEXT WG Last Call</FONT></SPAN></P>\n
	\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">12:00 PM â€“ 12:15 PM
	 PT IPv6 Access\, W. Dec (15 minutes)</FONT></SPAN></P>\n\n<P DIR=LTR><SPA
	N LANG="en-us"></SPAN><A HREF="http://tools.ietf.org/html/draft-ietf-radex
	t-ipv6-access"><SPAN LANG="en-us"><U><FONT COLOR="#0000FF" FACE="Calibri">
	http://tools.ietf.org/html/draft-ietf-radext-ipv6-access</FONT></U></SPAN>
	<SPAN LANG="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR
	><SPAN LANG="en-us"><FONT FACE="Calibri">RADEXT WG Work Items (30 minutes)
	</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Calibri">&
	nbsp\;</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"><FONT FACE="Cali
	bri">12:15 PM PT â€“ 12:45 PM PT Extended RADIUS Attributes\, Alan DeKok (
	30 minutes)</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-us"></SPAN><A H
	REF="http://tools.ietf.org/html/draft-ietf-radext-extended-attributes"><SP
	AN LANG="en-us"><U><FONT COLOR="#0000FF" FACE="Calibri">http://tools.ietf.
	org/html/draft-ietf-radext-extended-attributes</FONT></U></SPAN><SPAN LANG
	="en-us"></SPAN></A><SPAN LANG="en-us"></SPAN></P>\n\n<P DIR=LTR><SPAN LAN
	G="en-us"></SPAN><SPAN LANG="en-us"></SPAN><SPAN LANG="en-us"></SPAN></P>\
	n\n</BODY>\n</HTML>
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-DISALLOW-COUNTER:TRUE
X-MS-OLK-APPTSEQTIME:20100628T224723Z
X-MS-OLK-AUTOSTARTCHECK:FALSE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR

Delivery-date: Thu, 08 Jul 2010 20:53:52 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RADEXT Virtual Interim:  July 12, 2010
Date: Thu, 8 Jul 2010 13:52:57 -0700

--_7c266c1b-e105-49d6-a6b2-270eb46ebb20_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADEXT Virtual Interim meeting will take place on Monday, July 12, 2010 from 11 AM to 1:30 PM Pacific Time. 

--_7c266c1b-e105-49d6-a6b2-270eb46ebb20_
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 Virtual Interim meeting will take place on Monday, July 12, 2010 from 11 AM to 1:30 PM Pacific Time. <br><br><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 14"><meta name="Originator" content="Microsoft Word 14"><link rel="File-List" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><link rel="themeData" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
   <w:SplitPgBreakAndParaMark/>
   <w:EnableOpenTypeKerning/>
   <w:DontFlipMirrorIndents/>
   <w:OverrideTableStyleHps/>
  </w:Compatibility>
  <m:mathPr>
   <m:mathFont m:val="Cambria Math"/>
   <m:brkBin m:val="before"/>
   <m:brkBinSub m:val="&#45;-"/>
   <m:smallFrac m:val="off"/>
   <m:dispDef/>
   <m:lMargin m:val="0"/>
   <m:rMargin m:val="0"/>
   <m:defJc m:val="centerGroup"/>
   <m:wrapIndent m:val="1440"/>
   <m:intLim m:val="subSup"/>
   <m:naryLim m:val="undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
  DefSemiHidden="true" DefQFormat="false" DefPriority="99"
  LatentStyleCount="267">
  <w:LsdException Locked="false" Priority="0" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
  <w:LsdException Locked="false" Priority="9" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
  <w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 1"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 2"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 3"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 4"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 5"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 6"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 7"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 8"/>
  <w:LsdException Locked="false" Priority="39" Name="toc 9"/>
  <w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
  <w:LsdException Locked="false" Priority="10" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Title"/>
  <w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
  <w:LsdException Locked="false" Priority="11" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
  <w:LsdException Locked="false" Priority="22" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
  <w:LsdException Locked="false" Priority="20" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
  <w:LsdException Locked="false" Priority="59" SemiHidden="false"
   UnhideWhenUsed="false" Name="Table Grid"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
  <w:LsdException Locked="false" Priority="1" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 1"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
  <w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
  <w:LsdException Locked="false" Priority="34" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
  <w:LsdException Locked="false" Priority="29" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
  <w:LsdException Locked="false" Priority="30" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 1"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 2"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 2"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 3"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 3"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 4"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 4"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 5"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 5"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
  <w:LsdException Locked="false" Priority="60" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="61" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light List Accent 6"/>
  <w:LsdException Locked="false" Priority="62" SemiHidden="false"
   UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="63" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="64" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="65" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="66" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="67" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
  <w:LsdException Locked="false" Priority="68" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
  <w:LsdException Locked="false" Priority="69" SemiHidden="false"
   UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
  <w:LsdException Locked="false" Priority="70" SemiHidden="false"
   UnhideWhenUsed="false" Name="Dark List Accent 6"/>
  <w:LsdException Locked="false" Priority="71" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
  <w:LsdException Locked="false" Priority="72" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
  <w:LsdException Locked="false" Priority="73" SemiHidden="false"
   UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
  <w:LsdException Locked="false" Priority="19" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
  <w:LsdException Locked="false" Priority="21" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
  <w:LsdException Locked="false" Priority="31" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
  <w:LsdException Locked="false" Priority="32" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
  <w:LsdException Locked="false" Priority="33" SemiHidden="false"
   UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
  <w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
  <w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-alt:"Times New Roman";
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-alt:"Arial Black";
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520081665 -1073717157 41 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	mso-themecolor:followedhyperlink;
	text-decoration:underline;
	text-underline:single;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
-</style><span style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;">IETF Secretariat
invites you to attend this online meeting. <br>
<br>
Topic: RADEXT <br>
Date: Monday, July 12, 2010 <br>
Time: 10:45 am, Pacific Daylight Time (San Francisco, GMT-07:00) <br>
Meeting Number: 961 126 477 <br>
Meeting Password: (This meeting does not require a password.) <br>
<br>
<br>
------------------------------------------------------- <br>
To join the online meeting (Now from iPhones too!) <br>
------------------------------------------------------- <br>
1. Go to <a href="https://workgreen.webex.com/workgreen/j.php?ED=135092087&amp;UID=1130222477&amp;RT=MiM0" target="_blank">https://workgreen.webex.com/workgreen/j.php?ED=135092087&amp;UID=1130222477&amp;RT=MiM0</a>
<br>
2. If requested, enter your name and email address. <br>
3. If a password is required, enter the meeting password: (This meeting does
not require a password.) <br>
4. Click "Join". <br>
<br>
To view in other time zones or languages, please click the link: <br>
<a href="https://workgreen.webex.com/workgreen/j.php?ED=135092087&amp;UID=1130222477&amp;ORT=MiM0" target="_blank">https://workgreen.webex.com/workgreen/j.php?ED=135092087&amp;UID=1130222477&amp;ORT=MiM0</a>
<br>
<br>
------------------------------------------------------- <br>
To join the audio conference only <br>
------------------------------------------------------- <br>
To receive a call back, provide your phone number when you join the meeting, or
call the number below and enter the access code. <br>
Call-in toll number (US/Canada): 1-408-792-6300 <br>
Global call-in numbers: <a href="https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&amp;ED=135092087&amp;tollFree=0" target="_blank">https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&amp;ED=135092087&amp;tollFree=0</a>
<br>
<br>
Access code:961 126 477 <br>
<br>
------------------------------------------------------- <br>
For assistance <br>
------------------------------------------------------- <br>
1. Go to <a href="https://workgreen.webex.com/workgreen/mc" target="_blank">https://workgreen.webex.com/workgreen/mc</a>
<br>
2. On the left navigation bar, click "Support". <br>
<br>
You can contact me at: <br>
<a href="mailto:[email-masked]">[email-masked]</a> <br>
1-510-492-4081 <br>
<br>
To add this meeting to your calendar program (for example Microsoft Outlook),
click this link: <br>
<a href="https://workgreen.webex.com/workgreen/j.php?ED=135092087&amp;UID=1130222477&amp;ICS=MI&amp;LD=1&amp;RD=2&amp;ST=1&amp;SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3E-o=&amp;RT=MiM0" target="_blank">https://workgreen.webex.com/workgreen/j.php?ED=135092087&amp;UID=1130222477&amp;ICS=MI&amp;LD=1&amp;RD=2&amp;ST=1&amp;SHA2=NpYdJfLdEYNJZYv1EaVNce5rK9lmwkoi3FECZsU3E-o=&amp;RT=MiM0</a>
<br>
<br>
The playback of UCF (Universal Communications Format) rich media files requires
appropriate players. To view this type of rich media files in the meeting,
please check whether you have the players installed on your computer by going
to <a href="https://workgreen.webex.com/workgreen/systemdiagnosis.php" target="_blank">https://workgreen.webex.com/workgreen/systemdiagnosis.php</a> <br>
<br>
Sign up for a free trial of WebEx <br>
<a href="http://www.webex.com/go/mcemfreetrial" target="_blank">http://www.webex.com/go/mcemfreetrial</a>
<br>
<br>
<a href="http://www.webex.com/" target="_blank">http://www.webex.com</a> <br style="">
<!--[if !supportLineBreakNewLine]--><br style="">
<!--[endif]--></span><br> 		 	   		  </body>
</html>
--_7c266c1b-e105-49d6-a6b2-270eb46ebb20_--

Delivery-date: Tue, 06 Jul 2010 17:45:22 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-ipv6-access-02.txt 
Date: Tue,  6 Jul 2010 10:45:02 -0700 (PDT)

--NextPart

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

	Title           : RADIUS attributes for IPv6 Access Networks
	Author(s)       : B. Lourdelet, et al.
	Filename        : draft-ietf-radext-ipv6-access-02.txt
	Pages           : 14
	Date            : 2010-07-06

This document specifies IPv6 RADIUS attributes, which complement
those of RFC3162, and are intended to be used in residential
broadband networks, where specific user configuration information is
expected to be passed as part of the AAA process between a NAS and an
AAA server.  The attributes cover the assignment or reporting of the
following; a specific host IPv6 address; a recursive DNS IPv6 server
address; a specific IPv6 route announced to a host; a named IPv6
delegated prefix pool to be used for assignments to an accessing
host.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-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-ipv6-access-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Delivery-date: Tue, 06 Jul 2010 17:40:01 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked]
Date: Tue, 06 Jul 2010 17:39:13 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #2: comments on draft-ietf-radext-ipv6-access-01

#2: comments on draft-ietf-radext-ipv6-access-01
-------------------------------------+--------------------------------------
 Reporter:  msmith@â€¦                 |        Owner:  wdec@â€¦        
     Type:  defect                   |       Status:  closed        
 Priority:  major                    |    Milestone:  milestone1    
Component:  ipv6-access              |      Version:  1.0           
 Severity:  In WG Last Call          |   Resolution:  fixed         
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by wdec@â€¦):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Changes/resolution in draft-02.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/2#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Tue, 06 Jul 2010 10:40:56 +0000
Date: Tue, 06 Jul 2010 12:40:16 +0200
From: Klaas Wierenga <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Federated Authentication Beyond The Web: Problem Statement and Requirements

On 7/6/10 11:15 AM, Hannes Tschofenig wrote:

Hi Hannes,

> at the next IETF meeting we are going to have a BOF about "Federated Authentication Beyond The Web". In case you have not noticed the work relates to RADIUS and Diameter.
>
> I wrote this very short problem statement document to explain the purpose of the BOF:
> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
>
> Let me know if you find the description useful. Feedback about the BOF topic would also be appreciated.

I find the description useful, however I would like to challenge the 
MUST for RADIUS and/or Diamter. There are a number of Federated 
Authentication for applications access protocols out there, SAML, OpenID 
and others. RADIUS and Diamter are typically associated with network 
access. And while I do see the attractiveness of marrying the two (and 
thus leveraging existing trust fabrics), I wonder why you want to 
restrict a priori to just those. As an example 
draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, 
and draft-wierenga-ietf-sasl-saml-00 specify the use of federated 
authentication in a SASL context. And services like eduroam are an 
example of the use of just RADIUS to implement federated authentication 
for non-web applications.
I do understand that it is not possible nor desirable to take on 
everything, but let's at least have this scoping discussion in the BoF.

Klaas

Delivery-date: Tue, 06 Jul 2010 09:16:05 +0000
Date: Tue, 06 Jul 2010 11:15:19 +0200
From: "Hannes Tschofenig" <[email-masked]>
Subject: Federated Authentication Beyond The Web: Problem Statement and Requirements
To: [email-masked], [email-masked]

Hi all, 

at the next IETF meeting we are going to have a BOF about "Federated Authentication Beyond The Web". In case you have not noticed the work relates to RADIUS and Diameter. 

I wrote this very short problem statement document to explain the purpose of the BOF:
http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt

Let me know if you find the description useful. Feedback about the BOF topic would also be appreciated. 

Ciao
Hannes

Delivery-date: Tue, 06 Jul 2010 08:02:08 +0000
Date: Tue, 06 Jul 2010 16:01:21 +0800
From: Sheng Jiang <[email-masked]>
Subject: FW: New Version Notification for draft-guo-radext-softwire-concentrator-00
To: [email-masked], [email-masked]
Cc: 'Dayong Guo' <[email-masked]>

A new draft draft-guo-radext-softwire-concentrator-00.txt has been successfully submitted. It
defines several RADIUS attributes that carries softwire concentrator information.These attributes
serve DS-Lite or 6rd scenarios.

http://tools.ietf.org/html/draft-guo-radext-softwire-concentrator-00

Best regards,

Sheng 

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Monday, July 05, 2010 5:44 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for 
> draft-guo-radext-softwire-concentrator-00
> 
> 
> A new version of I-D, 
> draft-guo-radext-softwire-concentrator-00.txt has been 
> successfully submitted by Sheng Jiang and posted to the IETF 
> repository.
> 
> Filename:	 draft-guo-radext-softwire-concentrator
> Revision:	 00
> Title:		 RADIUS Attribute for Softwire 
> Concentrator in IPv6 Transition
> Creation_date:	 2010-07-05
> WG ID:		 Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> 6rd and DS-Lite are two most popular methods to provide both IPv4 and
> IPv6 connectivity services simultaneously during the 
> IPv4/IPv6 co- existing period. Both mechanisms need to 
> configure the softwire concentrator information on the host. 
> In many networks, the information may be stored in AAA 
> servers while user configuration is mainly through DHC 
> protocol. This document defines several RADIUS attributes 
> that carries softwire concentrator information.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 

Delivery-date: Tue, 06 Jul 2010 04:48:11 +0000
Date: Tue, 06 Jul 2010 06:47:22 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Conclusion of "Last Look" at RADIUS Design Guidelines document

Bernard Aboba wrote:
> 25 issues were submitted, all but six of which have been resolved in -15
> (http://tools.ietf.org/html/draft-ietf-radext-design):
> issues 11, 31, 47, 48, 49 and 50. 

  Updates should be available this week.

  Alan DeKok.

Delivery-date: Mon, 05 Jul 2010 20:43:31 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 05 Jul 2010 20:43:22 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #8: AD review (Editorial)

#8: AD review (Editorial)
-----------------------------------+----------------------------------------
 Reporter:  dromasca@â€¦             |        Owner:  aland@â€¦                  
     Type:  defect                 |       Status:  closed                   
 Priority:  minor                  |    Milestone:  milestone1               
Component:  tcp-transport          |      Version:  1.0                      
 Severity:  Submitted WG Document  |   Resolution:  fixed                    
 Keywords:                         |  
-----------------------------------+----------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Addressed in -08.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/8#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 05 Jul 2010 20:42:54 +0000
From: "radext issue tracker" <[email-masked]>
Cc: [email-masked]
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Mon, 05 Jul 2010 20:42:42 -0000
Reply-To: [email-masked]
Subject: Re: [radext] #24: GEN-ART review of draft-ietf-radext-tcp-transport

#24: GEN-ART review of draft-ietf-radext-tcp-transport
---------------------------------------+------------------------------------
 Reporter:  aland@â€¦                    |        Owner:  aland@â€¦                  
     Type:  defect                     |       Status:  closed                   
 Priority:  minor                      |    Milestone:  milestone1               
Component:  tcp-transport              |      Version:  1.0                      
 Severity:  Submitted WG Document      |   Resolution:  fixed                    
 Keywords:  GEN-ART                    |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@â€¦):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Comments addressed in -08.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/24#comment:2>
radext <http://tools.ietf.org/radext/>

Delivery-date: Mon, 05 Jul 2010 20:41:07 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Conclusion of "Last Look" at RADIUS Design Guidelines document
Date: Mon, 5 Jul 2010 13:40:16 -0700

--_a8c39829-3cbd-40d7-b172-0049e749876f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The "Last Look" at the RADIUS Design Guidelines document concluded on June 28, 2010:
http://ops.ietf.org/lists/radiusext/2010/msg00486.html

25 issues were submitted, all but six of which have been resolved in -15 (http://tools.ietf.org/html/draft-ietf-radext-design): 
issues 11, 31, 47, 48, 49 and 50.  

Open issues on RADEXT documents can be viewed here:
http://trac.tools.ietf.org/wg/radext/trac/report/1

--_a8c39829-3cbd-40d7-b172-0049e749876f_
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 "Last Look" at the RADIUS Design Guidelines document concluded on June 28, 2010:<br>http://ops.ietf.org/lists/radiusext/2010/msg00486.html<br><br>25 issues were submitted, all but six of which have been resolved in -15 (http://tools.ietf.org/html/draft-ietf-radext-design): <br>issues 11, 31, 47, 48, 49 and 50.&nbsp; <br><br>Open issues on RADEXT documents can be viewed here:<br>http://trac.tools.ietf.org/wg/radext/trac/report/1<br><br><br><br><br> 		 	   		  </body>
</html>
--_a8c39829-3cbd-40d7-b172-0049e749876f_--

Delivery-date: Thu, 01 Jul 2010 14:16:09 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-tcp-transport-08.txt 
Date: Thu,  1 Jul 2010 07:15:01 -0700 (PDT)

--NextPart

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

	Title           : RADIUS Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-08.txt
	Pages           : 18
	Date            : 2010-07-01

The Remote Authentication Dial In User Server (RADIUS) Protocol has
until now required the User Datagram Protocol (UDP) as the underlying
transport layer.  This document defines RADIUS over the Transmission
Control Protocol (RADIUS/TCP), in order to address handling issues
related to RADIUS over Transport Layer Security (RADIUS/TLS).  It
permits TCP to be used as a transport protocol for RADIUS only when a
transport layer such as TLS or IPsec provides confidentialy and
security.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-tcp-transport-08.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-tcp-transport-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--