Re: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2

[Alan DeKok <[e-mail]>]

Romascanu, Dan (Dan) wrote:
> Actually the whole section 8 is about 'Considerations about RADIUS
> Integration' so this needs review.. 

  I agree with Bernard here.  The document isn't in good shape, and the
I-D's it references require drastic changes to the RADIUS protocol.

  Alan DeKok.

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

Envelope-to: [e-mail]
Delivery-date: Sun, 25 Jan 2009 17:23:45 +0000
Message-ID: <[e-mail]>
Date: Sun, 25 Jan 2009 18:22:40 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <[e-mail]>
CC: Dave Nelson <[e-mail]>, [e-mail],  [e-mail]
Subject: Re: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Romascanu, Dan (Dan) wrote:
> Actually the whole section 8 is about 'Considerations about RADIUS
> Integration' so this needs review.. 

  I agree with Bernard here.  The document isn't in good shape, and the
I-D's it references require drastic changes to the RADIUS protocol.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jan 2009 18:24:34 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Thu, 22 Jan 2009 13:22:58 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <B35AB9B01B9640D697CB232F2B74503E@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl8pdHq2XWpw/81TC2YHwC/WWQ7wAAGItmw

>   Any comments?  A number of people have read the pages, but the list
> stays quiet...

The changes look good to me.



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


Envelope-to: [e-mail]
Delivery-date: Thu, 22 Jan 2009 15:23:11 +0000
Message-ID: <[e-mail]>
Date: Thu, 22 Jan 2009 16:22:00 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Issue:  Use of the term "extended" within the Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alan DeKok wrote:
>   Please see http://ietf.freeradius.org for some proposed changes.

  Any comments?  A number of people have read the pages, but the list
stays quiet...

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 19:52:57 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: Copyright issues affecting current Internet-Drafts
Date: Wed, 14 Jan 2009 14:52:48 -0500
Message-ID: <5C1E69B1A83140798F31A19FEFA14769@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl2fTF8EcY7EhAkQnGtbOyw5hhCAAAAOUmg

The IETF Chair has requested that all Working Groups be notified of an
intellectual property rights / copyright "brou-ha-ha" that is being
currently discussed on the IETF General Discussion List.

As I understand it, there is a minor defect in RFC 5378, the document that
currently governs rights in IETF submissions and publications.
Specifically, this has to do with rights for derivative works outside of the
IETF standards process.

There is also ongoing discussion of a workaround for this problem.  If you
are interested, please consult the IETF General Discussion mailing list
archives.  Any discussion of the issue should occur on that list.

One potential impact to the Working Groups is that revised boilerplate text
is likely to be required for submission of I-Ds.  That revised text is
expected to be in place well before the I-D submission cut-off date prior to
IETF-74.  There may be some confusion during the transition, however.

A second potential impact is that any material that has been derived from a
document published prior to the effective date RFC 5378 (November 11, 2008)
may require special restrictions to be listed in the boilerplate, as to
rights for derivative works outside the IETF standards process.

The "fair use doctrine" would seem to apply to small sections of properly
quoted and cited text from older documents.  The issue arises with any
modifications to such text.  We have seen such re-use of modified text
proposed in recent WG list discussions on open RADEXT Issues.

All I-D authors need to be generally aware of this issue, and anyone wishing
to include substantial sections of text or any sections of modified text
from a "pre-5378" document need to be particular aware.  It does not appear
that this issue will impact our work, if we pay attention to the details.

Following is the details of the issue, as summarized in an announcement from
the Trustees of the IETF Trust (the agency that holds IETF IPR).

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

The purpose of this message is twofold:

1) To summarize the issues that some members of our community 
   have experienced since the publication of RFC 5378 in November 2008, 
   and
2) To invite community review and discussion on a potential work-around 
   being considered by the IETF Trustees.

Some I-D authors are having difficulty implementing RFC 5378.  An  
example of the difficulty is as follows:

  - an author wants to include pre-5378 content in a new submission
    or contribution to the IETF, but
  - s/he is not certain that all of the author(s) of the earlier  
    material have agreed to license it to the IETF Trust according
    to RFC 5378.

If an I-D author includes pre-5378 material in a new document, then s/he
must represent or warrant that all of the authors who created the  
pre-5378 material have granted rights for that material to the IETF Trust.
If s/he cannot make this assertion, then s/he has a problem.

This situation has halted the progression of some Internet-Drafts and  
interrupted the publication of some RFCs.  The Trustees of the IETF Trust
are investigating ways to implement a temporary work-around so that IETF
work can continue to progress.  A permanent solution to this "pre-5378
problem" may require an update to RFC 5378, for example new work by the
community to create a 5378-bis document.

The remainder of this message provides an outline of the temporary work- 
around being considered by the Trustees.

RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the  
authority to develop legend text for authors to use in situations where
they wish to limit the granting of rights to modify and prepare
derivatives of the documents they submit.  The Trustees used this
authority in 2008 to develop and adopt the current "Legal Provisions
Relating to IETF Documents" which are posted at:
http://trustee.ietf.org/license-info/.

The Trustees are now considering the creation of optional new legend text  
which could be used by authors experiencing the "pre-5378 problem".

The new legend text, if implemented, would do the following:

  a. Provide Authors and Contributors with a way to identify (to the
     IETF Trust) that their contributions contain material from pre-5378  
     documents for which RFC 5378 rights to modify the material outside
     the IETF standards process may not have been granted, and

  b. Provide the IETF Trust and the community with a clear indication 
     of every document containing pre-5378 content and having the
     "pre-5378 problem".

So, how could the creation and use of some new legend text help people
work-around the pre-5378 problem?

The proposed answer is as follows:

  1. Anyone having a contribution with the "pre-5378" problem should add
     new legend text to the contribution, to clearly flag that it includes
     pre-5378 material for which all of the rights needed under RFC 5378
     may not have been granted, and

  2. The IETF Trust will consider authors and contributors (with the  
     pre-5378 problem) to have met their RFC 5378 obligations if the
     new legend text appears on their documents, and

  3. Authors and contributors should only resort to adding the new  
     legend text to their documents (per #1) if they cannot develop  
     certainty that all of the author(s) of pre-5378 material in
     their documents have agreed to license the pre-5378 content to
     the IETF Trust according to RFC 5378.

The proposed wording for the new legend text is now available for your
review and comments in section 6.c.iii of a draft revision to the
IETF Trust's "Legal Provisions Relating to IETF Documents" located at
http://trustee.ietf.org/policyandprocedures.html.

Please note that the above document also contains new text in section 5.c
dealing with "License Limitations".

If your review and feedback on this proposed work-around is positive,
then the new text may be adopted by the Trustees in early February 2009,
and then be published as an official revision to the Legal Provisions
document.  If so adopted, Internet-Drafts with pre-5378 material may 
advance within the Internet standards process and get published as RFCs
where otherwise qualified to do so.  Unless covered by sections 6.c.i or
6.c.ii, authors of documents in which there is no pre-5378
material must provide a RFC 5378 license with no limitation on
modifications outside the IETF standards process.

The IETF Trust will not grant the right to modify or prepare derivative
works of any specific RFC or other IETF Contribution outside the IETF
standards process until RFC 5378 rights pertaining to that document have
been obtained from all authors and after compliance by the IETF Trust
with RFC 5377.  The Trustees will establish one or more mechanisms by
which authors of pre-5378 documents may grant RFC 5378 rights.

The Trustees hereby invite your review, comments and suggestions on this
proposed work-around to the "pre-5378 problem".  The period for this review
is 30 days.  Microsoft WORD and PDF versions of the proposed revisions are
attached to this message.  Copies are also available on the IETF Trust
website under the heading "DRAFT Policy and Procedures Being Developed" at:
http://trustee.ietf.org/policyandprocedures.html 

All feedback submitted before the end of February 7th will be considered by
the Trustees.  A decision on whether to move forward with this proposal will
be made and communicated to you before the end of February 15th.

Please give this your attention.

Regards and Happy New Year !

Ed Juskevicius, on behalf of the IETF Trustees
edj.etc at gmail.com



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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 19:50:22 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: RFC 5378 Implications
Date: Wed, 14 Jan 2009 11:49:42 -0800
Message-ID: <003101c97681$3e57a5c0$bb06f140$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nAAAB01gAABhNswAAKPi7A=
Content-Language: en-us

As some of you may know, as a result of the publication of RFC 5378, the
IETF
has changed the boilerplate required for Internet-Draft submissions.   

It is important that all contributors know the terms under which
contributions are made,
and to understand the requirements imposed by RFC 5378, as well as the
problems that
some people have had with it. 

Currently, a discussion is underway on the IETF Discuss mailing list
relating to the 
implications of RFC 5378, as well as potential fixes to it.  

If you are a contributor or potential contributor within the RADEXT WG,  and
are
interested in understanding your obligations and responsibilities under the
new
policies, please consult the IETF Discussion archive:
http://www.ietf.org/mail-archive/web/ietf/current/maillist.html

Discussion of this topic on individual Working Group mailing lists is
discouraged. 

Some recent postings on the IETF Discussion list:
IETF Trustee Request for Review:
http://www.ietf.org/mail-archive/web/ietf/current/msg54839.html
IAD statement:
http://www.ietf.org/mail-archive/web/ietf/current/msg54691.html
IETF Chair statement:
http://www.ietf.org/mail-archive/web/ietf/current/msg54502.html






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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 18:54:05 +0000
From: "Dave Nelson" <[e-mail]>
To: "'Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 13:53:44 -0500
Message-ID: <F9E7E3A7C2FA47998471893A05FAC94D@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAHyK3AAATAt0A==

> Actually the whole section 8 is about 'Considerations about RADIUS
> Integration' so this needs review.

Sorry, it would have behooved me to read the document rather than simply
checking the sections you called out.  Too much multi-tasking today.  It
looks like Bernard has covered this section in his post.



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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 18:41:34 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Dave Nelson'" <[e-mail]>, "'Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 10:40:52 -0800
Message-ID: <002c01c97677$a060bd10$e1223730$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nAAAB01gAABhNsw
Content-Language: en-us

Presently, not all the scenarios described in the document are properly 
supported by AAA.  As a result, the document redefines existing uses
of RADIUS standard attributes, as well as suggesting implementation
of documents that are currently still Internet Drafts. 

Section 8 updates several existing RADIUS standards RFCs, including:

* RFC 2868, by defining new interpretations of the
Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations
where addressing attributes are not present.  

* RFC 2865, by defining new interpretations of the Framed-IP-Address and
Framed-IP-Netmask attributes. 

* RFC 2866, by referencing draft-stevant-softwire-accounting, which
redefines
the format of the NAS-IP-Address attribute (which only supports
IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses). 

Is this really appropriate for a framework document?

>From draft-stevant-software-accounting-01.txt:

   A RADIUS accounting entry, as defined in [RFC2867], also includes the
   NASIPAddress attribute, which gives the IP address of the NAS used as
   the softwire endpoint.  Based on this information, an operator can
   decide if this softwire is based on IPv4 or IPv6.  In the case of
   provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires,
   the nature of the traffic reported in the accounting information
   depends of the address family of NASIPAddress (if NASIPAddress is
   IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted
   traffic is IPv4).  However, this solution requires extra checking
   when building accounting report and obviously does not work in case
   of IPvX over IPvX softwires.


8.1.  Softwire Endpoints

8.1.1.  IPv6 Softwires

   If the RADIUS server includes a Framed-Interface-Id attribute
   [RFC3162], the Softwire Concentrator must send it to the Softwire
   Initiator in the Interface-Identifier field of its IPV6CP
   Configuration Request message.

   If the Framed-IPv6-Prefix attribute [RFC3162] is included, that
   prefix must be used in the router advertisements sent to the SI.  If
   Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
   must choose a prefix with that pool to send RAs.

   If none of the attributes above are included but the AAA server
   returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
   attributes [RFC2868] with the correct address family, these must be
   used in the IPV6CP Interface-Identifier and for the Router
   Advertisements.

[BA] The above paragraph defines new interpretations of these attributes. 

8.1.2.  IPv4 Softwires

   If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
   Concentrator must provide that address to the Softwire Initiator
   during IPCP address negotiation.  That is, when the Softwire
   Initiator requests an IP address from the Softwire Concentrator, the
   address provided should be the Framed-IP-Address.

   If the Framed-IP-Address attribute is not present and the Tunnel-
   Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
   present and of the correct address family, these should be used in
   the IPCP IP-Address configuration option.

[BA] The above paragraph defines new interpretations of these attributes.

8.2.  Delegated Prefixes

8.2.1.  IPv6 Prefixes

   If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the
   RADIUS Access-Accept message, it must be used by the Softwire
   Concentrator for the delegation of the IPv6 prefix.  Since the prefix
   delegation is performed by DHCPv6 and the attribute is linked to a
   username, the SC must associate the DHCP Unique Identifier (DUID) of
   a DHCPv6 request to the tunnel it came from and its user.

   Interaction between RADIUS, PPP and DHCPv6 server may follow the
   mechanism proposed in [I-D.ietf-dhc-v6-relay-radius].  In this case,
   during the Softwire authentication phase, PPP collects the RADIUS
   attributes for the user such as Delegated-IPv6-Prefix.  A specific
   DHCPv6 relay is assigned to the Softwire.  The DHCPv6 relay fills in
   these attributes in the Relay agent RADIUS Attribute Option (RRAO)
   DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6
   server.

[BA] The above paragraph makes what would appear to be a normative reference
to an I-D. 

8.2.2.  IPv4 Prefixes

   The combination of the Framed-IP-Address and Framed-IP-Netmask
   attributes [RFC2865] may be used by the Softwire Concentrator to
   delegate an IPv4 prefix to the Softwire Initiator.

[BA] The above paragraph defines new interpretations of these attributes.



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Dave Nelson
Sent: Wednesday, January 14, 2009 9:45 AM
To: 'Romascanu, Dan (Dan)'; [e-mail]; [e-mail]
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content
indraft-ietf-softwire-hs-framework-l2tpv2

> See also section 2.5 in the document.

2.5.  Authentication, Authorization and Accounting (AAA)

   L2TPv2 supports optional mutual Control Channel authentication and
   leverages the optional mutual PPP per-session authentication.  L2TPv2
   is well integrated with AAA solutions (such as RADIUS) for both
   authentication and authorization.  Most L2TPv2 implementations
   available in the market support logging of authentication and
   authorization events.

DBN:  This paragraph contains an assertion about the integration of existing
L2TPv2 implementations with RADIUS implementations.  I'm not in a position
to validate or refute that assertion from personal knowledge, but it seems
reasonable on its face.

   L2TPv2 integration with RADIUS accounting (RADIUS Accounting
   extension for tunnel [RFC2867]) allows the collection and reporting
   of L2TPv2 Softwire usage statistics.

DBN:  Sure.  RADIUS Accounting does support usage statistics reporting for
all kinds of provisioned sessions, based on connect time and data transfer.



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


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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 18:19:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 19:19:08 +0100
Message-ID: <[e-mail]>
Thread-Topic: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAHyK3A=
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Dave Nelson" <[e-mail]>, <[e-mail]>, <[e-mail]>

Actually the whole section 8 is about 'Considerations about RADIUS
Integration' so this needs review..=20

Dan
=20

> -----Original Message-----
> From: Dave Nelson [mailto:[e-mail]]=20
> Sent: Wednesday, January 14, 2009 7:33 PM
> To: Romascanu, Dan (Dan); [e-mail]; [e-mail]
> Subject: RE: [AAA-DOCTORS] AAA / RADIUS content=20
> indraft-ietf-softwire-hs-framework-l2tpv2
>=20
> Dan Romascanu writes...
>=20
> > Can somebody please have a look to the content of these sections?
>=20
>=20
> 4.3.  Authentication Authorization Accounting
>=20
>    RFC 2865   "Remote Authentication Dial In User Service (RADIUS)"
>               [RFC2865].
>=20
> DBN: Current document.  Updated by RFC2868, RFC3575, RFC5080.
>=20
>    RFC 2867   "RADIUS Accounting Modifications for Tunnel Protocol
>               Support" [RFC2867].
>=20
> DBN: Current document.
>=20
>    RFC 2868   "RADIUS Attributes for Tunnel Protocol Support"=20
> [RFC2868].
>=20
> DBN: Current document.
>=20
>    RFC 3162   "RADIUS and IPv6" [RFC3162].
>=20
> DBN: Current document.
>=20
> DBN: I can't attest that this list of references is necessary=20
> and sufficient to the requirements of Softwires, however.=20
>=20
>=20
> 9.1.  RADIUS Accounting
>=20
>    RADIUS Accounting for L2TP and PPP are documented (see=20
> Section 4.3).
>=20
>    When deploying Softwire solutions, operators may experience
>    difficulties to differentiate the address family of the traffic
>    reported in accounting information from RADIUS.  This problem and
>    some potential solutions are described in
>    [I-D.stevant-softwire-accounting].
>=20
> DBN: I have not reviewed the referenced I-D, but it's quite=20
> likely that a lack of (standardized) RADIUS attributes=20
> capable of representing address families might inhibit the=20
> straightforward application of RADIUS Accounting.
>=20
>=20
>=20
>=20

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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 17:45:11 +0000
From: "Dave Nelson" <[e-mail]>
To: "'Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 12:44:57 -0500
Message-ID: <C0479961AE354C81B3B4A39CD65498D6@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nAAAB01gA==

> See also section 2.5 in the document.

2.5.  Authentication, Authorization and Accounting (AAA)

   L2TPv2 supports optional mutual Control Channel authentication and
   leverages the optional mutual PPP per-session authentication.  L2TPv2
   is well integrated with AAA solutions (such as RADIUS) for both
   authentication and authorization.  Most L2TPv2 implementations
   available in the market support logging of authentication and
   authorization events.

DBN:  This paragraph contains an assertion about the integration of existing
L2TPv2 implementations with RADIUS implementations.  I'm not in a position
to validate or refute that assertion from personal knowledge, but it seems
reasonable on its face.

   L2TPv2 integration with RADIUS accounting (RADIUS Accounting
   extension for tunnel [RFC2867]) allows the collection and reporting
   of L2TPv2 Softwire usage statistics.

DBN:  Sure.  RADIUS Accounting does support usage statistics reporting for
all kinds of provisioned sessions, based on connect time and data transfer.



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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 17:36:57 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 18:36:31 +0100
Message-ID: <[e-mail]>
Thread-Topic: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nA=
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Dave Nelson" <[e-mail]>, <[e-mail]>, <[e-mail]>

See also section 2.5 in the document.=20

Dan
=20

> -----Original Message-----
> From: Dave Nelson [mailto:[e-mail]]=20
> Sent: Wednesday, January 14, 2009 7:33 PM
> To: Romascanu, Dan (Dan); [e-mail]; [e-mail]
> Subject: RE: [AAA-DOCTORS] AAA / RADIUS content=20
> indraft-ietf-softwire-hs-framework-l2tpv2
>=20
> Dan Romascanu writes...
>=20
> > Can somebody please have a look to the content of these sections?
>=20
>=20
> 4.3.  Authentication Authorization Accounting
>=20
>    RFC 2865   "Remote Authentication Dial In User Service (RADIUS)"
>               [RFC2865].
>=20
> DBN: Current document.  Updated by RFC2868, RFC3575, RFC5080.
>=20
>    RFC 2867   "RADIUS Accounting Modifications for Tunnel Protocol
>               Support" [RFC2867].
>=20
> DBN: Current document.
>=20
>    RFC 2868   "RADIUS Attributes for Tunnel Protocol Support"=20
> [RFC2868].
>=20
> DBN: Current document.
>=20
>    RFC 3162   "RADIUS and IPv6" [RFC3162].
>=20
> DBN: Current document.
>=20
> DBN: I can't attest that this list of references is necessary=20
> and sufficient to the requirements of Softwires, however.=20
>=20
>=20
> 9.1.  RADIUS Accounting
>=20
>    RADIUS Accounting for L2TP and PPP are documented (see=20
> Section 4.3).
>=20
>    When deploying Softwire solutions, operators may experience
>    difficulties to differentiate the address family of the traffic
>    reported in accounting information from RADIUS.  This problem and
>    some potential solutions are described in
>    [I-D.stevant-softwire-accounting].
>=20
> DBN: I have not reviewed the referenced I-D, but it's quite=20
> likely that a lack of (standardized) RADIUS attributes=20
> capable of representing address families might inhibit the=20
> straightforward application of RADIUS Accounting.
>=20
>=20
>=20
>=20

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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 17:34:52 +0000
From: "Dave Nelson" <[e-mail]>
To: "'Romascanu, Dan \(Dan\)'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 12:33:08 -0500
Message-ID: <B35DAB7F475E4FB88832D945B2165A35@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+w

Dan Romascanu writes...

> Can somebody please have a look to the content of these sections?


4.3.  Authentication Authorization Accounting

   RFC 2865   "Remote Authentication Dial In User Service (RADIUS)"
              [RFC2865].

DBN: Current document.  Updated by RFC2868, RFC3575, RFC5080.

   RFC 2867   "RADIUS Accounting Modifications for Tunnel Protocol
              Support" [RFC2867].

DBN: Current document.

   RFC 2868   "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].

DBN: Current document.

   RFC 3162   "RADIUS and IPv6" [RFC3162].

DBN: Current document.

DBN: I can't attest that this list of references is necessary and sufficient
to the requirements of Softwires, however. 


9.1.  RADIUS Accounting

   RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).

   When deploying Softwire solutions, operators may experience
   difficulties to differentiate the address family of the traffic
   reported in accounting information from RADIUS.  This problem and
   some potential solutions are described in
   [I-D.stevant-softwire-accounting].

DBN: I have not reviewed the referenced I-D, but it's quite likely that a
lack of (standardized) RADIUS attributes capable of representing address
families might inhibit the straightforward application of RADIUS Accounting.




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


Envelope-to: [e-mail]
Delivery-date: Wed, 14 Jan 2009 17:14:30 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AAA / RADIUS content in draft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 18:13:37 +0100
Message-ID: <[e-mail]>
Thread-Topic: AAA / RADIUS content in draft-ietf-softwire-hs-framework-l2tpv2
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZg==
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

The Softwire Hub & Spoke Deployment Framework with L2TPv2 I-D
http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t
pv2-10.txt is on the agenda of the IESG telechat tomorrow for approval
as a Proposed Standard. This document has a couple of sections (4.3,
9.1) that refer to AAA and RADIUS. Can somebody please have a look to
the content of these sections?=20

Thanks and Regards,

Dan

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


Envelope-to: [e-mail]
Delivery-date: Sat, 10 Jan 2009 14:48:55 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate?
Date: Sat, 10 Jan 2009 09:48:39 -0500
Message-ID: <281A3B25382A4F96A5204602866D7501@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4AAACuiOAAAHxgMAAAqDRg

Hannes Tschofenig writes...
 
> There isn't too much space left in the <255 ID space and hence
> that consideration might not be too relevant in the future.

But it's another reason to restrict it right now -- to conserve such space
for RADIUS applications.  Unless, of course, the issues you've enumerated do
not apply in a specific use case, for example when no new Diameter
application is required and simple RADIUS data types suffice to the use
case.

> I would not restrict the possibility to allocate RADIUS attributes
> (for example from the extended attribute space) in a Diameter 
> document or todo Diameter AVP code allocation in a RADIUS document.

Well, RADIUS Extended Attributes is a different case to consider.  Given the
impedance mismatch between the Diameter AVP data model and the more
restricted RADIUS Extended Attribute data model, there are some serious
design issues.  For example, to share these EAs/APVs the Diameter solution
must be designed to fit within the RADIUS data model restrictions.

> The problem is that a more detailed investigation about this
> subject will take some time.

Correct.

> Do you have that time?

Probably not.  Nor do I have the required Diameter expertise.  That's why I
suggested a stop-gap "fix" in the form "just don't do that".  :-)



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


Envelope-to: [e-mail]
Delivery-date: Sat, 10 Jan 2009 14:30:08 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'Dave Nelson'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate?
Date: Sat, 10 Jan 2009 16:30:13 +0200
Message-ID: <023c01c9732f$f3654fd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4AAACuiOAAAHxgMA==

Hi Dave, 

There isn't too much space left in the <255 ID space and hence that
consideration might not be too relevant in the future. 

I would not restrict the possibility to allocate RADIUS attributes (for
example from the extended attribute space) in a Diameter document or todo
Diameter AVP code allocation in a RADIUS document. 

The problem is that a more detailed investigation about this subject will
take some time. Do you have that time? 

Ciao
Hannes

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Dave Nelson
>Sent: 10 January, 2009 16:18
>To: [e-mail]; [e-mail]; [e-mail]
>Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter 
>compatibilityboilerplate?
>
>Hi Hannes,
>
>I've added RADEXT to the distribution, as well.
>
>I agree, based on your summary of the state of the art of 
>translation gateways and the other issues you highlight, that 
>the simple Diameter Considerations text that we've been using, 
>modeled after the assumptions of the Diameter NAS Application 
>(RFC 4005), is a bit misleading.
>
>If the recommendation turns out to be that there should not be 
>simplistic RADIUS to Diameter interoperability, then I think 
>there are two follow up
>issues:
>
>(1) Guidance on when Diameter clients and servers can and 
>cannot use (or
>re-use) RADIUS attributes in the legacy <255 ID space.
>
>(2) A prohibition on Diameter documents defining and new AVPs 
>in the legacy
><255 ID space.
>
>I think there was an assumption that any attributes/AVPs in 
>the legacy ID space would be interchangeable, is a simple fashion.
>
>Regards,
>
>Dave
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Hannes Tschofenig
>Sent: Saturday, January 10, 2009 9:03 AM
>To: 'David B. Nelson'; Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [e-mail]; [e-mail]
>Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter 
>compatibilityboilerplate?
>
>Hi Dave, 
>
>Thanks for the reminder. 
>
>Based on the discussion we had with Pasi in context of the 
>MIPv6 integrated document I tried to figure out how far we are 
>with the deployment of RADIUS
>- Diameter translation agents. 
>
>I got feedback, which I will try to summarize (as mentioned in 
>my recent DIME status update message).
>
>Why does that activity relate to the issue of the boilerplate? 
>We are writing something in our documents with a certain model 
>of interworking in mind. For some reason, this interworking 
>does not exist in today's deployment (based on the feedback I 
>received) and so far I haven't received evidence that it will 
>exist in the future. 
>
>So, here is my thinking: 
>
>* RADIUS and Diameter are different protocols with different 
>deployment stories. 
>
>* The data types in RADIUS and Diameter are different. There 
>is overlap but RADIUS offers fewer data types than Diameter.
>
>* The design considerations in Diameter are different to the 
>one in RADIUS.
>A big difference is the fact that Diameter has the concept of 
>applications and RADIUS doesn't have those (ignoring some tiny 
>details). 
>
>The above-mentioned aspect might lead to different designs in 
>RADIUS and in Diameter when considering the deployment 
>environment and the available protocol mechanisms. 
>
>This makes translation more complex. Since there is very 
>little translation done (other with legacy systems) this does 
>not really matter that much. 
>
>This makes me believe that there should not be a requirement 
>to write RADIUS Diameter consideration sections in the document. 
>
>If document authors want to include Diameter solution aspects 
>into the same document then they can obviously do that. This 
>is a pure document management task. However, they have to 
>consider the entire range of Diameter design considerations 
>and this may lead to the need to define a Diameter application 
>and hence the previously short section might be rather long. 
>
>In any case, a WGLC should be posted to the DIME mailing list 
>if there are Diameter considerations in the document. 
>
>Does this make sense? Feedback from the DIME group? 
>
>Ciao
>Hannes
>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of David B. Nelson
>>Sent: 08 January, 2009 17:59
>>To: 'Tschofenig, Hannes (NSN - FI/Espoo)'
>>Cc: [e-mail]
>>Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate?
>>
>>Hi Hannes,
>>
>>During the AAA Doctors lunch at IETF-73 you volunteered for 
>the action 
>>item of drafting some boilerplate / template text for the required 
>>Diameter Considerations section of RADIUS I-Ds and RFCs.  How is that 
>>coming along?
>
>
>_______________________________________________
>DiME mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dime
>


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


Envelope-to: [e-mail]
Delivery-date: Sat, 10 Jan 2009 14:18:55 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate?
Date: Sat, 10 Jan 2009 09:17:58 -0500
Message-ID: <D61F367A6A9A42D59A148E1D293F0AD6@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Aclxqf2p8QFE/3aeSwOxYd7pwwXjNwBgAV4AAACuiOA=

Hi Hannes,

I've added RADEXT to the distribution, as well.

I agree, based on your summary of the state of the art of translation
gateways and the other issues you highlight, that the simple Diameter
Considerations text that we've been using, modeled after the assumptions of
the Diameter NAS Application (RFC 4005), is a bit misleading.

If the recommendation turns out to be that there should not be simplistic
RADIUS to Diameter interoperability, then I think there are two follow up
issues:

(1) Guidance on when Diameter clients and servers can and cannot use (or
re-use) RADIUS attributes in the legacy <255 ID space.

(2) A prohibition on Diameter documents defining and new AVPs in the legacy
<255 ID space.

I think there was an assumption that any attributes/AVPs in the legacy ID
space would be interchangeable, is a simple fashion.

Regards,

Dave

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Hannes Tschofenig
Sent: Saturday, January 10, 2009 9:03 AM
To: 'David B. Nelson'; Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [e-mail]; [e-mail]
Subject: Re: [Dime] [AAA-DOCTORS] RADIUS / Diameter
compatibilityboilerplate?

Hi Dave, 

Thanks for the reminder. 

Based on the discussion we had with Pasi in context of the MIPv6 integrated
document I tried to figure out how far we are with the deployment of RADIUS
- Diameter translation agents. 

I got feedback, which I will try to summarize (as mentioned in my recent
DIME status update message).

Why does that activity relate to the issue of the boilerplate? We are
writing something in our documents with a certain model of interworking in
mind. For some reason, this interworking does not exist in today's
deployment (based on the feedback I received) and so far I haven't received
evidence that it will exist in the future. 

So, here is my thinking: 

* RADIUS and Diameter are different protocols with different deployment
stories. 

* The data types in RADIUS and Diameter are different. There is overlap but
RADIUS offers fewer data types than Diameter.

* The design considerations in Diameter are different to the one in RADIUS.
A big difference is the fact that Diameter has the concept of applications
and RADIUS doesn't have those (ignoring some tiny details). 

The above-mentioned aspect might lead to different designs in RADIUS and in
Diameter when considering the deployment environment and the available
protocol mechanisms. 

This makes translation more complex. Since there is very little translation
done (other with legacy systems) this does not really matter that much. 

This makes me believe that there should not be a requirement to write RADIUS
Diameter consideration sections in the document. 

If document authors want to include Diameter solution aspects into the same
document then they can obviously do that. This is a pure document management
task. However, they have to consider the entire range of Diameter design
considerations and this may lead to the need to define a Diameter
application and hence the previously short section might be rather long. 

In any case, a WGLC should be posted to the DIME mailing list if there are
Diameter considerations in the document. 

Does this make sense? Feedback from the DIME group? 

Ciao
Hannes

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of David B. Nelson
>Sent: 08 January, 2009 17:59
>To: 'Tschofenig, Hannes (NSN - FI/Espoo)'
>Cc: [e-mail]
>Subject: [AAA-DOCTORS] RADIUS / Diameter compatibility boilerplate?
>
>Hi Hannes,
>
>During the AAA Doctors lunch at IETF-73 you volunteered for 
>the action item of drafting some boilerplate / template text 
>for the required Diameter Considerations section of RADIUS 
>I-Ds and RFCs.  How is that coming along?



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


Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2009 10:45:27 +0000
Message-ID: <[e-mail]>
Date: Thu, 08 Jan 2009 11:45:11 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Data Type Advice
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> Much of this is already in the document. What can we do to clarify
>> the text to avoid repeated questions?
> 
> I'd suggest that a revision of Section 1.1 is needed to clarify this. 
> Right now,
> this section seems to suggest that SDO specifications utilizing existing
> RADIUS standard data types can avail themselves of IETF review.  Also,
> as David notes, the document can be read as suggesting IETF review
> of all SDO RADIUS attribute documents. 

  I've updated the document, and put suggested text on
http://ietf.freeradius.org.

>> The most I would do is to provide horrific examples of what *not* to
>> do. i.e. putting arbitrary text strings into the "data" portion of a
>> VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)
> 
> Describing why this is a bad idea would probably be useful.

  I will add that to my "to do" list, and then update the web site with
suggested text.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 08 Jan 2009 10:44:57 +0000
Message-ID: <[e-mail]>
Date: Thu, 08 Jan 2009 11:43:43 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Issue 298
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> How about this?

  ... it looks pretty good to me.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jan 2009 11:31:22 +0000
Message-ID: <[e-mail]>
Date: Mon, 05 Jan 2009 12:30:51 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Issue:  Use of the term "extended" within the Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
> After some offline discussion with our AD, Dan Romascanu, it seems the path
> we take will depend on the complexity of the changes.  Minor edits to add
> clarification can be done as part of the IESG review process, e.g. handled
> by RFC Editor Notes.
> 
> I think before pulling the draft back, let's see a proposed set of editing
> instructions on the list, e.g. s/foo/bar, and see how bad the damage is.

  Please see http://ietf.freeradius.org for some proposed changes.  I've
started from the current IETF draft, and modified it from there.  The
changes are grouped conceptually:

  (a) external review
  (b) applicability
  (c) clarification on data types

  There are 3 proposed drafts, with HTML diffs between them.

  If the changes are acceptable, we can merge them into a -06 version.
Otherwise, we can discuss the changes until they are acceptable.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jan 2009 10:42:51 +0000
Message-ID: <[e-mail]>
Date: Mon, 05 Jan 2009 11:41:40 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Data Type Advice
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> The document doesn't specifically discuss sub-TLV's (i.e. TLV's as a
>> data type for the "data" portion of an attribute, other than
>> Vendor-Specific)
> 
> That might be worth adding (maybe in the Extended Attributes section?)

  I'll add some text in the "what not do to" section (A.2.1).

  I think calling these "nested AVP's" may make the most sense.

  When I have some more edits done, I'll post a URL to the documents
with suggested text.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 05 Jan 2009 02:05:52 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_961781f1-6b72-43ef-bd2d-74a3d50ef443_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Sun, 4 Jan 2009 18:04:46 -0800
MIME-Version: 1.0

--_961781f1-6b72-43ef-bd2d-74a3d50ef443_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   The document doesn't specifically discuss sub-TLV's (i.e. TLV's as a
> data type for the "data" portion of an attribute=2C other than
> Vendor-Specific)

That might be worth adding (maybe in the Extended Attributes section?)

--_961781f1-6b72-43ef-bd2d-74a3d50ef443_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   The document doesn't specifically discuss sub-TLV's (i.e. TLV's as=
 a<br>&gt=3B data type for the "data" portion of an attribute=2C other than=
<br>&gt=3B Vendor-Specific)<br><br>That might be worth adding (maybe in the=
 Extended Attributes section?)<br></body>
</html>=

--_961781f1-6b72-43ef-bd2d-74a3d50ef443_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 21:09:03 +0000
Message-ID: <[e-mail]>
Date: Sun, 04 Jan 2009 22:08:21 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Issue:  Data Type Advice
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> [BA] I would agree that a comprehensive survey is not needed.  However,
> it would seem useful to go over the above types and advise how they
> can be dealt with.   For example, "byte" and "short" could be 
> replaced by the Integer type; tlvs can be accommodated in Extended 
> Attributes;  ipv4 & ipv6 types should be dealt with separately, etc. 

  The document already discusses signed, byte, short, and polymorphic types:

A.2.1
...
      * Signed integers of any size.
        SHOULD NOT be used.  SHOULD be replaced with one or more
        unsigned integer attributes.  The definition of the attribute
        can contain information that would otherwise go into the sign
        value of the integer.
      * 8 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save three bytes.
      * 16 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save two bytes.
...
      * Polymorphic attributes.
        Multiple attributes, each with a static data type SHOULD be
        defined instead.


  The "abinary" type is covered in A.2.2.:

A.2.2. Complex Data Types

   Does the attribute define a complex data type for purposes other than
   authentication or security?  If so, this data type SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.


  The document doesn't specifically discuss sub-TLV's (i.e. TLV's as a
data type for the "data" portion of an attribute, other than
Vendor-Specific)

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 19:36:10 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_9143efb7-218f-44c1-87eb-6034844b93ad_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Review of "Software Hub and Spoke Framework"?
Date: Sun, 4 Jan 2009 11:35:41 -0800
MIME-Version: 1.0

--_9143efb7-218f-44c1-87eb-6034844b93ad_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The document "'Softwire Hub & Spoke Deployment Framework with L2TPv2" has g=
one
to IETF last call:
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05459.html
=20
Has anyone taken a look at this document?  It is available here:
http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2
=20
The document does seem to deal with a number of AAA-related issues=2C inclu=
ding
limitations in RADIUS accounting. =20
 =

--_9143efb7-218f-44c1-87eb-6034844b93ad_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
The document "'Softwire Hub &amp=3B Spoke Deployment Framework with L2TPv2"=
 has gone<BR>
to IETF last call:<BR>
<A href=3D"http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05=
459.html">http://www.ietf.org/mail-archive/web/ietf-announce/current/msg054=
59.html</A><BR>
&nbsp=3B<BR>
Has anyone taken&nbsp=3Ba look at this document?&nbsp=3B It is available he=
re:<BR>
<A href=3D"http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tp=
v2">http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2</A><=
BR>
&nbsp=3B<BR>
The document does seem to deal with a number of AAA-related issues=2C inclu=
ding<BR>
limitations in RADIUS accounting. &nbsp=3B<BR>
<BR><BR><BR>&nbsp=3B<BR></body>
</html>=

--_9143efb7-218f-44c1-87eb-6034844b93ad_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 19:24:32 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Sun, 4 Jan 2009 11:24:02 -0800
Message-ID: <000401c96ea2$004eeea0$00eccbe0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclunV5uakhiEABBSuu+3WN/YlN8agAAuQmg
Content-Language: en-us

Alan DeKok said:

"The data model applies to VSA's, too.  Looking at the dictionaries I have
access to, I see:

  * ~4K VSA definitions
  * 3 vendors with non-standard data types
  * 7 non-standard data types of
     * abinary
     * byte
     * short
     * polymorphic ipv4/ipv6 address
     * signed
     * tlv  (e.g. 3GPP2 && WiMAX)

  The "abinary" is the old Ascend binary filter attribute.  Everything
else is used by the WiMAX standards, though other vendors use some of
the types, too.

  This last survey isn't *quite* accurate, as a number of non-standard
types are treated as "string" in the dictionaries."

  I would prefer to not survey the ad-hoc extensions to the data model.
 There may be a fair number. "

[BA] I would agree that a comprehensive survey is not needed.  However,
it would seem useful to go over the above types and advise how they
can be dealt with.   For example, "byte" and "short" could be 
replaced by the Integer type; tlvs can be accommodated in Extended 
Attributes;  ipv4 & ipv6 types should be dealt with separately, etc. 




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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 18:54:00 +0000
Message-ID: <[e-mail]>
Date: Sun, 04 Jan 2009 19:53:46 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Extended Attributes Dependency
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> This text includes normative statements relating to the Extended
> Attributes document, and yet [EXTEN] is only listed as an
> Informative reference.  Either a normative reference needs to be
> added, or this section needs to be removed. 

  I suggest adding [EXTEN] as a normative reference.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 18:51:19 +0000
Message-ID: <[e-mail]>
Date: Sun, 04 Jan 2009 19:50:52 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Data Type Advice
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Section A.1.1 reads:
> 
>    Does the data fit within the existing RADIUS data model, as outlined
>    below?  If so, it SHOULD be encapsulated in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS
>    attribute, or in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS VSA.
> 
> As noted in an earlier issue, Appendix B does not cover data types
> utilized within RADIUS VSAs,
> only the data types in standard RADIUS attributes.

  When the VSAs use standard data types, they are compatible with the
RADIUS data model.  This practice should be encouraged.

>   Therefore the
> "existing RADIUS data model
> as outlined below" is really just the data model for standard RADIUS
> attributes.

  And a RECOMMENDED one for VSAs.  Non-standard data types can be
problematic.

>   On that basis
> the sentence might better read:
> 
>    Does the data fit within the RADIUS standard attribute data model, as outlined
>    below?  If so, it MAY be encapsulated either in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS
>    attribute, or in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS VSA.

  I'm not sure that change is necessary.  The data model applies to
VSA's, too.  Looking at the dictionaries I have access to, I see:

  * ~4K VSA definitions
  * 3 vendors with non-standard data types
  * 7 non-standard data types of
     * abinary
     * byte
     * short
     * polymorphic ipv4/ipv6 address
     * signed
     * tlv  (e.g. 3GPP2 && WiMAX)

  The "abinary" is the old Ascend binary filter attribute.  Everything
else is used by the WiMAX standards, though other vendors use some of
the types, too.

  This last survey isn't *quite* accurate, as a number of non-standard
types are treated as "string" in the dictionaries.

> Assuming that the promised survey of ad-hoc data model extensions is
> actually included in the
> document, then this could be referenced to in a subsequent sentence:

  I would prefer to not survey the ad-hoc extensions to the data model.
 There may be a fair number, and I would conjecture that most offer

  I think we should recommend that VSAs use the existing data types.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 18:38:31 +0000
Message-ID: <[e-mail]>
Date: Sun, 04 Jan 2009 19:37:34 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Attribute Usage
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Section 1 of the document reads:
> 
> 
>    In order to characterize current attribute usage, both the basic and
>    complex data types defined in the existing RADIUS RFCs are reviewed,
>    together with the ad-hoc extensions to that data model that have been
>    used in Vendor-Specific Attributes.
> 
> 
> Appendix B covers only data types used in existing RADIUS RFCs.   As far
> as I can tell,
> the document does not catalog the ad-hoc extensions that have been used in
> Vendor-Specific Attributes.

  IMHO, we should avoid discussing ad-hoc extensions to VSA's.  They are
either horrible (as noted before), or simply new data types.

  The new data types aren't compatible with traditional RADIUS, but if
the SDOs want them for their own specifications, that's fine.

> Either the document needs to add material relating to ad-hoc extensions,
> or this
> portion of the sentence needs to be removed.

  That portion of the sentence needs to be removed.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 09:31:44 +0000
Message-ID: <[e-mail]>
Date: Sun, 04 Jan 2009 10:31:30 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: 'Dave Nelson' <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-zorn-radius-pkmv1-03.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> No. The Design Guidelines document was written in part to dispel
> this misconception.  VSAs (specifically those allocated to
> SDOs such as IEEE 802) are not only technically appropriate 
> for this use, they are the recommended approach for use
> in documents (such as this one) which describe SDO-specific
> uses of RADIUS.  
> 
> If this point is not being made crystal clear in the Design
> Guidelines document, then we need to change the text until
> it is. 

  I will add clarifying text to the document, and post an update.

> Forcing SDOs to put documents on the IETF standards track
> merely so that they can obtain request allocation of standard RADIUS
> attributes for SDO-specific uses of RADIUS makes no sense. 

  I agree.  This point needs to be reiterated in the guidelines document.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 04 Jan 2009 09:28:09 +0000
Message-ID: <[e-mail]>
Date: Sun, 04 Jan 2009 10:26:50 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: Hannes Tschofenig <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: philosophy of the Design Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> For example, the Design Guidelines document, by articulating the RADIUS Design Guidelines,
> allows, and even *encourages* SDOs to create their own RADIUS attribute specifications.  

  I think this philosophy needs to be articulated more strongly in the
document.  I will post suggested text.

> So, as I read it, the goal of the Design Guidelines document isn't to lead to further ossification
> of the IETF process  -- but rather to a more productive and cooperative relationship
> between the IETF and SDOs.   For example. the guidelines on complex attributes only 
> apply to the RADIUS standard attribute space, not to the Extended Attribute space, or 
> to SDO-Specific attributes.   So as I read it, the document isn't saying "you can't do 
> this for an SDO-specific purpose", but rather, "if you wish to create attributes that are 
> unlikely to be widely deployed outside your SDO, do so using SDO-specific attributes 
> so as to to minimize impact on existing implementations". 

  I will make that point more strongly in the document.

> Discussion of Extended Attribute design is out of scope of the Design Guidelines
> document.  However, it *is* in scope for the Extended Attributes document.

  We could make it clearer that the this document allows [EXTENDED]
attributes, too.

> By looking at all existing RADIUS implementations, I am sure we could find 
> support for a considerable number of additional data types.  However, the
> question being considered by this document is not "what is the union of
> all implemented RADIUS datatypes", but rather "what is the likely 
> intersection of data types used in RADIUS standard attributes".  
> That question has been answered by examining existing RADIUS RFCs. 

  I agree.  Implementations use other data types primarily for
compliance with non-IETF RADIUS specifications.  I don't see anyone
implementing data types that aren't necessary.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 22:44:50 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_3a88b90a-3d54-4856-92cf-234472ae82e4_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue 298
Date: Fri, 2 Jan 2009 14:44:10 -0800
MIME-Version: 1.0

--_3a88b90a-3d54-4856-92cf-234472ae82e4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Ultimately=2C it's the NAS that has to provision services based on the co=
ntent
> of the Extended Attributes=2C so the fact that the NAS understands them i=
s of
> prime importance. =20

I agree.=20

> The fact the proxies understand them is only of
> importance if the proxies are expected to be "editing" the attributes pas=
sed
> to and from the NAS.  If a particular proxy is know to indiscriminately
> discard VSAs=2C then knowing it supports Extended Attributes may be of gr=
eater
> importance that otherwise might be the case.

RFC 2865 Section 5.26 states that robust implementation should treat the=20
values of VSAs as opaque text.  So a proxy complying with that recommendati=
on=20
should be able to pass Extended Attributes in either direction without=20
corrupting them.=20

Such an existing proxy should also be able to remove or add VSAs by treatin=
g them=20
as opaque blobs.  However=2C this wouldn't necessarily allow proxies to rem=
ove or add=20
individual Extended Attributes=2C just to selectively add or remove VSAs=20
within which Extended Attributes are encapsulated.=20

For a proxy to be able to add=2C remove or modify specific Extended Attribu=
tes would=20
require parsing the Extended Attribute format.=20

--_3a88b90a-3d54-4856-92cf-234472ae82e4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B Ultimately=2C it's the NAS that has to provision services based on t=
he content<br>&gt=3B of the Extended Attributes=2C so the fact that the NAS=
 understands them is of<br>&gt=3B prime importance.  <br><br>I agree. <br><=
br>&gt=3B The fact the proxies understand them is only of<br>&gt=3B importa=
nce if the proxies are expected to be "editing" the attributes passed<br>&g=
t=3B to and from the NAS.  If a particular proxy is know to indiscriminatel=
y<br>&gt=3B discard VSAs=2C then knowing it supports Extended Attributes ma=
y be of greater<br>&gt=3B importance that otherwise might be the case.<br><=
br>RFC 2865 Section 5.26 states that robust implementation should treat the=
 <br>values of VSAs as opaque text.&nbsp=3B So a proxy complying with that =
recommendation <br>should be able to pass Extended Attributes in either dir=
ection without <br>corrupting them. <br><br>Such an existing proxy should a=
lso be able to remove or add VSAs by treating them <br>as opaque blobs.&nbs=
p=3B However=2C this wouldn't necessarily allow proxies to remove or add <b=
r>individual Extended Attributes=2C just to selectively add or remove VSAs =
<br>within which Extended Attributes are encapsulated. <br><br>For a proxy =
to be able to add=2C remove or modify specific Extended Attributes would <b=
r>require parsing the Extended Attribute format. <br></body>
</html>=

--_3a88b90a-3d54-4856-92cf-234472ae82e4_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 22:24:07 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_1f3846bc-cd56-4ca7-8470-ecf5c367ffcc_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Fri, 2 Jan 2009 14:23:50 -0800
MIME-Version: 1.0

--_1f3846bc-cd56-4ca7-8470-ecf5c367ffcc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Ever the optimist=2C I was hoping it might be done much sooner.  :-)

There's no penalty for exceeding expectations :)

--_1f3846bc-cd56-4ca7-8470-ecf5c367ffcc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B Ever the optimist=2C I was hoping it might be done much sooner.  :-)=
<br><br>There's no penalty for exceeding expectations :)<br></body>
</html>=

--_1f3846bc-cd56-4ca7-8470-ecf5c367ffcc_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 22:23:07 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_02ae0eeb-7669-4d4d-845e-4f7fa43bc1e7_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue 298
Date: Fri, 2 Jan 2009 14:22:38 -0800
MIME-Version: 1.0

--_02ae0eeb-7669-4d4d-845e-4f7fa43bc1e7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   Q: What impact does this advertisement have on intermediary proxies?
>=20
>   i.e. Does it signal that the NAS understands Extended-Attributes=2C or
> that the proxy understands them?  Should the proxy filter out the
> advertisement if it doesn't understand Extended-Attributes?
>=20
>   To answer my own question a bit... it's easier to upgrade proxies than
> NASes.  I think it's safe to assume (or require) that proxies be
> upgraded before NASes.

How about this?

<text kyped from RFC 5080 section 2.5 and modified>

   To avoid misinterpretation of service requests encoded within Extended
   Attributes=2C RADIUS servers SHOULD NOT send Extended Attributes contain=
ing=20
   service requests to RADIUS clients that are not known to understand them=
. =20
   For example=2C a RADIUS server should not send an Extended Attribute enc=
oding=20
   a filter without knowledge that the RADIUS client supports Extended Attr=
ibutes
   in general=2C and the filter Extended Attribute in particular.

A NAS supporting the Extended Attribute format MUST include at
 least one Extended Attribute within an Access-Request.  In order
to  be eligible to include at least one Extended Attribute in an
Access-Request=2C a NAS MUST be capable of parsing the Extended=20
Attribute format  (e.g. 2-octet Type-Code=2C grouping=2C  etc.). =20
A RADIUS server that does not receive an Extended Attribute
within an Access-Request SHOULD NOT send Extended Attributes
within an Access-Accept or Access-Challenge packet unless it is=20
prepared for the Extended Attributes to be ignored as described=20
in RFC 2865 Section 5.26. =20

Similarly=2C a Dynamic Authorization Client SHOULD only include=20
Extended Attributes within a CoA-Request or Disconnect-Request
if Extended Attributes were included within an Access-Request
within the referenced session=2C or if the DAC is prepared for the
Extended Attributes to be ignored.=20

As noted in RFC 2865 Section 5.26=2C a robust implementation SHOULD=20
support Extended Attributes as undistinguished octets.  As a result=2C
a RADIUS proxy SHOULD by default pass Extended Attributes unmodified. =20
However=2C if configured to do so=2C a RADIUS proxy MAY add=2C modify or=20
remove Extended Attributes sent within RADIUS packets. =20

RADIUS clients and servers supporting this specification=20
treat Extended Attributes similarly to RADIUS standard attributes as=20
described in RFC 5080 Section 2.5=2C rather than as a VSA.  As
noted in RFC 5080 Section 2.5:=20
   On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service=2C a RADIUS client MUST treat
   it as an Access-Reject=2C as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type=2C a
   RADIUS client SHOULD assume that it is a potential service
   definition=2C and treat it as an Access-Reject...

   On receiving a packet including an attribute of unknown Type=2C RADIUS
   authentication server implementations SHOULD ignore such attributes.
   However=2C RADIUS accounting server implementations typically do not
   need to understand attributes in order to write them to stable
   storage or pass them to the billing engine.  Therefore=2C accounting
   server implementations SHOULD be equipped to handle unknown
   attributes.


--_02ae0eeb-7669-4d4d-845e-4f7fa43bc1e7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Q: What impact does this advertisement have on intermediary proxie=
s?<br>&gt=3B <br>&gt=3B   i.e. Does it signal that the NAS understands Exte=
nded-Attributes=2C or<br>&gt=3B that the proxy understands them?  Should th=
e proxy filter out the<br>&gt=3B advertisement if it doesn't understand Ext=
ended-Attributes?<br>&gt=3B <br>&gt=3B   To answer my own question a bit...=
 it's easier to upgrade proxies than<br>&gt=3B NASes.  I think it's safe to=
 assume (or require) that proxies be<br>&gt=3B upgraded before NASes.<br><b=
r>How about this?<br><br>&lt=3Btext kyped from RFC 5080 section 2.5 and mod=
ified&gt=3B<br><br><pre>   To avoid misinterpretation of service requests e=
ncoded within Extended<br>   Attributes=2C RADIUS servers SHOULD NOT send E=
xtended Attributes containing <br>   service requests to RADIUS clients tha=
t are not known to understand them.  <br>   For example=2C a RADIUS server =
should not send an Extended Attribute encoding <br>   a filter without know=
ledge that the RADIUS client supports Extended Attributes<br>   in general=
=2C and the filter Extended Attribute in particular.<br></pre><br>A NAS sup=
porting the Extended Attribute format MUST include at<br> least one Extende=
d Attribute within an Access-Request.&nbsp=3B In order<br>to&nbsp=3B be eli=
gible to include at least one Extended Attribute in an<br>Access-Request=2C=
 a NAS MUST be capable of parsing the Extended <br>Attribute format&nbsp=3B=
 (e.g. 2-octet Type-Code=2C grouping=2C&nbsp=3B etc.).&nbsp=3B <br>A RADIUS=
 server that does not receive an Extended Attribute<br>within an Access-Req=
uest SHOULD NOT send Extended Attributes<br>within an Access-Accept or Acce=
ss-Challenge packet unless it is <br>prepared for the Extended Attributes t=
o be ignored as described <br>in RFC 2865 Section 5.26.&nbsp=3B <br><br>Sim=
ilarly=2C a Dynamic Authorization Client SHOULD only include <br>Extended A=
ttributes within a CoA-Request or Disconnect-Request<br>if Extended Attribu=
tes were included within an Access-Request<br>within the referenced session=
=2C or if the DAC is prepared for the<br>Extended Attributes to be ignored.=
 <br><br>As noted in RFC 2865 Section 5.26=2C a robust implementation SHOUL=
D <br>support Extended Attributes as undistinguished octets.&nbsp=3B As a r=
esult=2C<br>a RADIUS proxy SHOULD by default pass Extended Attributes unmod=
ified.&nbsp=3B <br>However=2C if configured to do so=2C a RADIUS proxy MAY =
add=2C modify or <br>remove Extended Attributes sent within RADIUS packets.=
&nbsp=3B <br><br>RADIUS clients and servers supporting this specification <=
br>treat Extended Attributes similarly to RADIUS standard attributes as <br=
>described in RFC 5080 Section 2.5=2C rather than as a VSA.&nbsp=3B As<br>n=
oted in RFC 5080 Section 2.5: <br><pre>   On receiving an Access-Accept inc=
luding an attribute of<br>   known Type for an unimplemented service=2C a R=
ADIUS client MUST treat<br>   it as an Access-Reject=2C as directed in [RFC=
2865] Section 1.1.  On<br>   receiving an Access-Accept including an attrib=
ute of unknown Type=2C a<br>   RADIUS client SHOULD assume that it is a pot=
ential service<br>   definition=2C and treat it as an Access-Reject...<br><=
br>   On receiving a packet including an attribute of unknown Type=2C RADIU=
S<br>   authentication server implementations SHOULD ignore such attributes=
.<br>   However=2C RADIUS accounting server implementations typically do no=
t<br>   need to understand attributes in order to write them to stable<br> =
  storage or pass them to the billing engine.  Therefore=2C accounting<br> =
  server implementations SHOULD be equipped to handle unknown<br>   attribu=
tes.<br></pre><br></body>
</html>=

--_02ae0eeb-7669-4d4d-845e-4f7fa43bc1e7_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 21:41:51 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Fri, 2 Jan 2009 16:41:38 -0500
Message-ID: <A4F281EAB39F4BD98A12A254A1700B90@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcltIVcidPzkNR1AShumQd/IxuZspgAAVRzg

Bernard Aboba writes...

> The ultimate goal should be to get a new version of the document
> posted to the I-D archive by the IETF 74 deadline (early March).

Ever the optimist, I was hoping it might be done much sooner.  :-)



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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 21:31:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_fd50fba3-bb04-47e3-8ec6-e5134ba2e17b_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Fri, 2 Jan 2009 13:30:29 -0800
MIME-Version: 1.0

--_fd50fba3-bb04-47e3-8ec6-e5134ba2e17b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dave Nelson said:=20

> I think before pulling the draft back=2C let's see a proposed set of edit=
ing
> instructions on the list=2C e.g. s/foo/bar=2C and see how bad the damage =
is.

The best way to go about this is for the editor to post proposed resolution=
s=20
to the list  for the open issues.  We can then see how the discussion
goes=2C and can track the status of the issues and the magnitude of changes
required as things progress.=20

Whether we have to pull the draft back to the WG depends
on the magnitude of the changes and the degree of WG consensus=20
behind them.=20

In order to evaluate this=2C it would be helpful for the editor to maintain
a "strawman" version of the document-in-progress on a public website=20
(I can supply space if required).  The "strawman" can be updated as=20
Issues are closed=2C and we can then judge from the number and=20
substance of the "diffs" what the next step will be.=20

The ultimate goal should be to get a new version of the document posted
to the I-D archive by the IETF 74 deadline (early March).  We can then
go over the next steps at IETF 74.=20

--_fd50fba3-bb04-47e3-8ec6-e5134ba2e17b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Dave Nelson said: <br><br>&gt=3B I think before pulling the draft back=2C l=
et's see a proposed set of editing<br>&gt=3B instructions on the list=2C e.=
g. s/foo/bar=2C and see how bad the damage is.<br><br>The best way to go ab=
out this is for the editor to post proposed resolutions <br>to the list&nbs=
p=3B for the open issues.&nbsp=3B We can then see how the discussion<br>goe=
s=2C and can track the status of the issues and the magnitude of changes<br=
>required as things progress. <br><br>Whether we have to pull the draft bac=
k to the WG depends<br>on the magnitude of the changes and the degree of WG=
 consensus <br>behind them. <br><br>In order to evaluate this=2C it would b=
e helpful for the editor to maintain<br>a "strawman" version of the documen=
t-in-progress on a public website <br>(I can supply space if required).&nbs=
p=3B The "strawman" can be updated as <br>Issues are closed=2C and we can t=
hen judge from the number and <br>substance of the "diffs" what the next st=
ep will be. <br><br>The ultimate goal should be to get a new version of the=
 document posted<br>to the I-D archive by the IETF 74 deadline (early March=
).&nbsp=3B We can then<br>go over the next steps at IETF 74. <br></body>
</html>=

--_fd50fba3-bb04-47e3-8ec6-e5134ba2e17b_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 15:58:22 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Fri, 2 Jan 2009 10:58:16 -0500
Message-ID: <6B5C6269BC904A108D0407FFA484A911@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acls7TnTP8cceCMxQIqDdXHooe3FvgABQ8vA

Alan DeKok writes...

> Given the recent discussion on this document, can we pull it out
> of IETF last call, and edit it within this WG again?

After some offline discussion with our AD, Dan Romascanu, it seems the path
we take will depend on the complexity of the changes.  Minor edits to add
clarification can be done as part of the IESG review process, e.g. handled
by RFC Editor Notes.

I think before pulling the draft back, let's see a proposed set of editing
instructions on the list, e.g. s/foo/bar, and see how bad the damage is.



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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 15:53:27 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue 298
Date: Fri, 2 Jan 2009 10:53:11 -0500
Message-ID: <519D9383DDC5486A9E469B7ADFA5E175@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acls7MA7+ONHzlmuTleB0C825BgRTQABGNsA

Alan DeKok writes...

>  This gets dangerously close to the old "capabilities" argument.

We've not seen fit to standardize "capabilities" in a general way, but there
is precedent for advertising support for a single attribute, as is the case
with Chargeable-User-Identity (CUI). 

>  i.e. Does it signal that the NAS understands Extended-Attributes,
> or that the proxy understands them?  Should the proxy filter out the
> advertisement if it doesn't understand Extended-Attributes?

Ultimately, it's the NAS that has to provision services based on the content
of the Extended Attributes, so the fact that the NAS understands them is of
prime importance.  The fact the proxies understand them is only of
importance if the proxies are expected to be "editing" the attributes passed
to and from the NAS.  If a particular proxy is know to indiscriminately
discard VSAs, then knowing it supports Extended Attributes may be of greater
importance that otherwise might be the case.



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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 15:15:32 +0000
Message-ID: <[e-mail]>
Date: Fri, 02 Jan 2009 16:15:13 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Use of the term "extended" within the Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Given the recent discussion on this document, can we pull it out of
IETF last call, and edit it within this WG again?

  I think there are a fair number of changes to make.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 15:14:15 +0000
Message-ID: <[e-mail]>
Date: Fri, 02 Jan 2009 16:13:59 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "'D. B. Nelson'" <[e-mail]>, [e-mail]
Subject: Re: Issue 298
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> So one question is whether this implies that a NAS should signal its
>> support for Extended Attributes in the Access-Request in some way -- 
>> so as to make it clear to the RADIUS server how those attributes would
>> be interpreted.  
> 
> I think we should make that feature a MUST.
> 
> [BA] That seems sensible to me.  The question is how to do it.  Maybe
> include
> an Extended Attribute of Type 1 with a NUL in it within an Access-Request?

  This gets dangerously close to the old "capabilities" argument.  But I
do agree it would seem to be necessary here.

  Q: What impact does this advertisement have on intermediary proxies?

  i.e. Does it signal that the NAS understands Extended-Attributes, or
that the proxy understands them?  Should the proxy filter out the
advertisement if it doesn't understand Extended-Attributes?

  To answer my own question a bit... it's easier to upgrade proxies than
NASes.  I think it's safe to assume (or require) that proxies be
upgraded before NASes.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 02 Jan 2009 15:05:32 +0000
Message-ID: <[e-mail]>
Date: Fri, 02 Jan 2009 16:04:14 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail], "[e-mail]" <[e-mail]>
Subject: Re: [ISSUE] Status-Server
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> > * I would suggest removing all of section 5. These topics seem related,
>> > but not germane to the purpose and scope of this doc.
> 
> I can see removing all of Section 5, though I would want the material in
> Section 5.2 to end up somewhere (maybe the RADIUS over TCP doc).

  Ok.  I'll review it and update the TCP draft.

> Section 5.1 does seem tangential to the goal of describing how Status-Server
> is used. 

  OK.

> Section 5.2 does seem relevant, since it clarifies the use/limitations of
> Status-Server over reliable transport.  This section could just as easily
> go in the RADIUS over TCP document, though.
> 
> At IETF 73, we talked about removing references to CoA (Section 5.3).

  OK.

  I've deleted all of Section 5.  I'll post an update shortly.

  Alan DeKok.

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