RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt

["Glen Zorn" <[e-mail]>]

Alan DeKok [mailto:[e-mail]] writes:
> Glen Zorn wrote:
> > Uh-huh...what's your point?  Everything that is copyrighted is also
> subject
> > to "fair use", at least in the US, & this would certainly constitute
> fair
> > use.
> 
>  "cut and paste" of the pages is fair use only if *quotes* are
> included.
>  Including the pages verbatim would likely not fall under fair use
> guidelines.

First, man pages are portions of a larger document (the manual) and as such
reproducing one is by definition a quotation from the full document.  Be
that as it may, however, see
http://www.freebsd.org/copyright/freebsd-doc-license.html &
http://www.freebsd.org/copyright/freebsd-license.html for the ability to
reproduce BSD man pages (the most likely candidate for rcp, anyway).  

> 
>   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, 30 Jun 2008 18:43:59 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Mon, 30 Jun 2008 14:42:22 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <CE0B079CF5E14C278A99372FCB903001@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XAAEX7N4A==

Glen Zorn writes...

> > I've been searching for a stable reference that discusses rcp, 
> > scp and sftp.  Certainly, the man pages of many UNIX-style 
> > systems, but I don't think that qualifies as a "stable 
> > reference" for RFC purposes.
> 
> It would if you copied them into appendices...

Well, yes.  I suppose there is no copyright issue with cut and paste of UNIX
"man" pages into an RFC.

OTOH, that verges on defining the underlying service that we are attempting
to authorize/provision using RADIUS in the RADIUS document itself.  That's a
practice I've often advised authors to avoid.

Does anyone else on the list think that including "man" pages in appendices
is the best way to go?



--
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, 30 Jun 2008 10:20:49 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Mon, 30 Jun 2008 17:18:38 +0700
Message-ID: <000601c8da9a$b1bc8540$15358fc0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XA=
Content-Language: en-us

David B. Nelson [[e-mail]] writes:

> > You probably have to reference some 4.2BSD software documentation.
> > There might be something suitable in the classic BSD daemon books, I
> > unfortunately do not have access to these classics anymore.
> 
> I've been searching for a stable reference that discusses rcp, scp and
> sftp.
> Certainly, the man pages of many UNIX-style systems, but I don't think
> that
> qualifies as a "stable reference" for RFC purposes.  

It would if you copied them into appendices...

...



--
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, 30 Jun 2008 09:02:31 +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: Call for Agenda Items for IETF 72
Date: Mon, 30 Jun 2008 10:58:10 +0200
Message-ID: <[e-mail]>
Thread-Topic: Call for Agenda Items for IETF 72
Thread-Index: AcjVt6BR+cXCkG4pS+m03+ehrMl8lQE1mw4A
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Richard Gayraud (rgayraud)" <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1039; t=1214816440; x=1215680440; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20<blourdel@ cisco.com> |Subject:=20RE=3A=20Call=20for=20Agenda=20Items=20for=20IET F=2072 |Sender:=20; bh=XyrWvjc/OU5zIKIniBq6gDYfXjBEuGccjA+Lfu0UsWY=; b=Fa4I2a2ep3oLy4G6oQDpfdRfkhbMGfrc5hbYkIh+Fihxd/mR+m/5yvOeik r2mcEhlX4ZTW/0k53xfkc+q1OLn1fWUxepGaf7yIpTKT89ioyuhiGMM4mLbf 8RumwG1Mmk;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );

Hello,

I'd like a 10 min slot to discuss  the following draft :=20

http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.
txt

As it includes RADIUS and DHCP concepts, It would request a slots in DHC
and RADEXT groups if that is the commonly accepted procedure.

Regards

Benoit

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Bernard Aboba
Sent: Tuesday, June 24, 2008 7:02 AM
To: [e-mail]
Subject: Call for Agenda Items for IETF 72

This is a call for agenda items for the RADEXT WG meeting at IETF 72 in
Dublin.  The meeting is tentatively scheduled for Wednesday, July 30,
2008 from 9 AM - 11:30 AM. =20

If you have an item you'd like to put on the agenda, please contact
myself
([e-mail]) or Dave.=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/>

--
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, 29 Jun 2008 04:03:31 +0000
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-radext-design-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 25 Jun 2008 03:00:02 -0700 (PDT)
Cc: [e-mail]
Reply-To: [e-mail]

--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, et al.
	Filename        : draft-ietf-radext-design-03.txt
	Pages           : 31
	Date            : 2008-06-25

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-03.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-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--

--
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, 26 Jun 2008 21:35:19 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Thu, 26 Jun 2008 17:33:30 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopew

> You probably have to reference some 4.2BSD software documentation.
> There might be something suitable in the classic BSD daemon books, I
> unfortunately do not have access to these classics anymore.

I've been searching for a stable reference that discusses rcp, scp and sftp.
Certainly, the man pages of many UNIX-style systems, but I don't think that
qualifies as a "stable reference" for RFC purposes.  I've "found" one book
in my web searches that seems to cover the material (although I don't
actually have a copy).  It is as follows:

Section 3.7 SSH and File Transfers in
SSH, the Secure Shell: The Definitive Guide, Second Edition
D. Barrett, R. Silverman, R. Byrnes
O'Reilly and Associates, May 2005

If anyone has a better reference to cite, to close the issue raised by
Barnard, please let me know.  Thanks!  If I don't "get a better offer" I
propose to use this reference for RCP, SCP and SFTP.



--
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, 25 Jun 2008 19:19:59 +0000
Date: Wed, 25 Jun 2008 12:18:43 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Issue 259:  Extended Type Field Length
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Issue 259: Extended Type Field Length
Submitter name: Bernard Aboba
Submitter email address: [e-mail]
Date first submitted:  June 25, 2008
Reference: http://ops.ietf.org/lists/radiusext/2008/msg00321.html
Document: 
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-03.txt
Comment type: Technical
Priority: S
Section:  5
Rationale/Explanation of issue:

The -03 version of this document contains the following TLV format: 
                        1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Ext-Type   |    Ext-Len    |    Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, the RADEXT WG Consensus from IETF 71, and as confirmed on the 
RADEXT WG mailing list, was that the Ext-Type field should be 2 octets in 
length, not 1.  Also, the Consensus of the WG was that Extended Attributes 
would not be applied to existing RADIUS standard attributes. 

Here is the summary of the Consensus Call Determination:
http://ops.ietf.org/lists/radiusext/2008/msg00321.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, 25 Jun 2008 18:58:20 +0000
Date: Wed, 25 Jun 2008 11:56:40 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: RADEXT WG Last Call on RADIUS Design Guidelines
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is an announcement of RADEXT WG Last Call on "RADIUS Design 
Guidelines" prior to requesting that the IESG publish it as a Best
Current Practice RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt
 
WG Last Call will last until July 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 


--
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, 25 Jun 2008 15:52:20 +0000
Date: Wed, 25 Jun 2008 17:50:27 +0200
From: Juergen Schoenwaelder <[e-mail]>
To: "David B. Nelson" <[e-mail]>
Cc: [e-mail]
Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mail-Followup-To: "David B. Nelson" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)

On Wed, Jun 25, 2008 at 09:45:48AM -0400, David B. Nelson wrote:
 
> So, that leads me to ask what's the difference between SCP and SFTP?

SFTP is really pretty much like FTP in the sense that it provides a
protocol allowing you to send commands from a rather rich set of
primitives to an SFTP server that are then executed by the server. Scp
is much simpler and usually does just one thing, namely transferring
files.

With SFTP, you can implement a filesystem that allows to mount an SFTP
server. This won't really work with scp since you lack primitives to
read directories, to create, modify or delete directories, to handle
symbolic links, to play with file attributes and so on.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

--
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, 25 Jun 2008 13:47:13 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Wed, 25 Jun 2008 09:45:48 -0400
Message-ID: <015101c8d6c9$c8272bc0$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWqMniqm/ACsB6TFezWcamBUG+dAAIHRUg

> You probably have to reference some 4.2BSD software documentation.
> There might be something suitable in the classic BSD daemon books, I
> unfortunately do not have access to these classics anymore.

Nor do I, but that's an idea for me to pursue.  Thanks.

> The scp program is a simple wrapper around ssh.

So, that leads me to ask what's the difference between SCP and SFTP?

> Finding official stable documentation for this will be difficult I
> assume.

That's what I was afraid of...  :-(



--
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, 25 Jun 2008 10:01:13 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-design-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 25 Jun 2008 03: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, et al.
	Filename        : draft-ietf-radext-design-03.txt
	Pages           : 31
	Date            : 2008-06-25

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-03.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-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 25 Jun 2008 09:46:11 +0000
Date: Wed, 25 Jun 2008 11:44:33 +0200
From: Juergen Schoenwaelder <[e-mail]>
To: "David B. Nelson" <[e-mail]>
Cc: [e-mail], 'Bernard Aboba' <[e-mail]>
Subject: Re: Additional comments on draft-ietf-radext-management-authorization-03.txt
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mail-Followup-To: "David B. Nelson" <[e-mail]>, [e-mail], 'Bernard Aboba' <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)

On Tue, Jun 24, 2008 at 02:28:05PM -0400, David B. Nelson wrote:

> > RCP: Can you add a reference?
> 
> I'd have to find a suitable one.  :-)  Can someone help me out here?  All I
> can find is UNIX/LINUX man pages references.  Can someone point me to a
> suitable, stable reference that can be included in an I-D / RFC?

You probably have to reference some 4.2BSD software documentation.
There might be something suitable in the classic BSD daemon books, I
unfortunately do not have access to these classics anymore.
 
> > SCP: Please add a reference...
> 
> Ditto.  Need assistance here, too.
> 
> > ...(doesn't this also use the services of SSH?)
> 
> AFAIK, it does not.  You may be thinking of SFTP, (SSH File Transfer
> Protocol, which does.)  Can anyone clarify this?

The scp program is a simple wrapper around ssh. The first comment in
the scp.c source file (openssh) says:

 * scp - secure remote copy.  This is basically patched BSD rcp which
 * uses ssh to do the data transfer (instead of using rcmd).

Finding official stable documentation for this will be difficult I
assume.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

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


Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jun 2008 18:29:35 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Tue, 24 Jun 2008 14:28:05 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWDNpFBM9lW8yqTripxrKpZlc0EgAGgyiA

Skipping over most of the editorial issues for now, I'll highlight the items
for which I need assistance from the list members.

> "http://www.w3.org/TR/html": Please add this to the reference
> section, and refer to it in Section 8.1.

I'll have to figure out how to manually craft reference anchors in xml2rfc,
but I think this can be done.

> "(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)"
> Please add this in the reference section.

Ditto.

> RCP: Can you add a reference?

I'd have to find a suitable one.  :-)  Can someone help me out here?  All I
can find is UNIX/LINUX man pages references.  Can someone point me to a
suitable, stable reference that can be included in an I-D / RFC?

> SCP: Please add a reference...

Ditto.  Need assistance here, too.

> ...(doesn't this also use the services of SSH?)

AFAIK, it does not.  You may be thinking of SFTP, (SSH File Transfer
Protocol, which does.)  Can anyone clarify this?



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


Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jun 2008 15:10:49 +0000
Date: Tue, 24 Jun 2008 08:08:14 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Additional comments on draft-ietf-radext-management-authorization-03.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Section 8.1

"Service-Type of Framed-Management" -> "Service-Type Attribute 
with the value Framed-Management"

"in Access-Request packet" -> "in an Access-Request packet"

"MAY use these hint attributes" -> "may use these attributes as a hint"

"MUST treat the response" -> "MUST treat the Access-Accept"

"http://www.w3.org/TR/html": Please add this to the reference
section, and refer to it in Section 8.1. 

"(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)"
Please add this in the reference section. 

RCP: Can you add a reference?

SCP: Please add a reference (doesn't this also use the services of SSH?)

Section 8.2

   The Management-Transport-Protection Attribute specifies whether a
   secure transport protocol (e.g.  SSH, TLS, DTLS, etc.) is required
   for use with the associated framed or non-framed management access
   session.  The value of this attribute specifies the minimum level of
   protection that is required from the protected transport.  The
   protected transport MAY provide a greater level of protection than is
   called for by the value of Management-Transport-Protection.

[BA] The second sentence is more on target.  How about this? 

   The Management-Transport-Protection Attribute specifies the minimum
   level of protection that is required for a protected transport used
   with the framed or non-framed management access session.  The protected
   transport used by the NAS MAY provide a greater level of protection, 
   but MUST NOT provide a lower level of protection. 

"in Access-Request packet" -> "in an Access-Request packet"
"RADIUS Client" -> "RADIUS clent"
"RADIUS Server" -> "RADIUS server"
"MAY use this hint attribute" -> "may use this attribute as a hint"

Section 8.3

"application to SMNP services" -> "SNMP"
"NAS behavior in such cases is not predictable." -> "The behavior of the 
NAS in this case is undefined."
"a single service provisioning message, such as" -> "an Access-Accept or 
CoA-Request". 

", within a flat namespace of significance to the NAS"

[BA] Are you saying that "." can't be used?  Can this be deleted? 

"Overloading or subdividing this flat name with" ->
"Overloading or subdividing this attribute with"

"If a simple flat policy name" -> "If a simple policy name"
"sufficient to the anticipated use case" -> "sufficient"

Section 12

Within the document, the CoA-Request is mentioned, but the table does not 
describe which attributes can be included in CoA or Disconnect Request, 
ACK or NAK packets.  Is it accurate to assume that none of the attributes
defined in this document can be contained in a CoA or Disconnect packet?

Section 14

   Any of the attributes described in this memo, with the exception of
   Service-Type, may not be understood by the NAS which receives it.  A
   legacy NAS not compliant with this specification may silently discard
   these attributes while permitting the user to access the management
   interface(s) of the NAS.  This can lead to users improperly receiving
   unauthorized management access to the NAS, or access with greater
   levels of access rights than were intended.  RADIUS servers SHOULD
   attempt to ascertain whether or not the NAS supports these attributes
   before sending them in an Access-Accept. 

[BA] This paragraph could be more clear.  There are really two cases. 
When a Service-Type value of Framed-Management is used, I'd assume that a
NAS implementing this specification would be required to behave as 
specified (e.g. treat the Access-Accept as an Access-Reject if the
attribute or value wasn't supported).  

I think that an issue could occur when a legacy Service-Type value
is used though, since then the NAS might ignore the new attributes instead 
of treating the Access-Accept like an Access-Reject.  

I don't think you need to talk about the potential behavior of an 
implementation that claims to conform to the spec, but doesn't do what it 
says.  



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


Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jun 2008 14:34:11 +0000
Date: Tue, 24 Jun 2008 07:31:11 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Editorial review of draft-ietf-radext-management-authorization-03.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Abstract

   This document describes Remote Authentication Dial-In User Service
   (RADIUS) attributes for the authorization and service provisioning of
   Network Access Servers (NASes).  Both local and remote management are
   supported, with granular access rights and management privileges.
   Specific provisions are made for remote management via framed
   management protocols, and for specification of a protected transport
   protocol.

[BA] This document is about NAS management authorization, not 
authorization of NASes.  Suggest the following:

   This document specifies Remote Authentication Dial-In User Service   
   (RADIUS) attributes for Network Access Server (NAS) management. 
   Both local and remote management are
   supported, with granular access rights and management privileges.
   Specific provisions are made for remote management via framed
   management protocols, which may run over a secure transport
   protocol. 

2. Introduction and Rationale

[BA] How about combining Sections 2, part of 3 and 6 into a Section 1 that
reads as follows?  The Terminology section can then be Section 1.1. 

1. Introduction

   RFC 2865 [RFC 2865] defines the NAS-Prompt and Administrative values of 
   the Service-Type Attribute.   Both of these values provide access to 
   the interactive, text-based Command Line Interface (CLI) of the NAS, 
   and were originally developed to control access to the physical
   console port of the NAS, most often a serial port.  
  
   Remote access to the CLI of the NAS has been available in NAS 
   implementations for many years, using protocols such as Telnet,
   Rlogin and the remote terminal service of SSH.  In order to distinguish
   local, physical, console access from remote access, the NAS-Port-Type
   Attribute is generally included in Access-Request and Access-Accept
   messages, along with the Service-Type Attribute, to indicate the form 
   of access.  A NAS-Port-Type of Async (0) is used to signify a local
   serial port connection, while a value of Virtual (5) is used to
   signify a remote connection, via a remote terminal protocol.  This
   usage provides no selectivity among the various available remote
   terminal protocols (e.g.  Telnet, Rlogin, SSH, etc.).

   Today, it is common for network devices to support more than two
   privilege levels for management access than just NAS-Prompt
   (non-privileged) and Administrative (privileged).  Also, other 
   management mechanisms may be used, such as Web-based management,
   Simple Network Management Protocol (SNMP) and NETCONF.  
   To provide support for these additional features, this specification 
   defines attributes for framed management protocols, management protocol 
   security, and management access privilege levels. 

   Remote management via the command line is carried over protocols
   such as Telnet, Rlogin and the remote terminal service of SSH.  Since
   these protocols are primarily for the delivery of terminal or 
   pseudo-TTY services,  the term "Framed Management" is used to describe
   management protocols supporting techniques other than the command-line.
   Typically these mechanisms format management information in a binary or
   textual encoding such as HTML, XML or ASN.1/BER.  Examples include
   web-based management (HTML over HTTP or HTTPS), NETCONF (XML over
   SSH/BEEP/SOAP) and SNMP (SMI over ASN.1/BER).  Command line 
   interface, menu interface or other text-based (e.g. ASCII or UTF-8)
   terminal emulation services are not considered to be Framed Management
   protocols.

[BA] How about combining part of Section 3, as well as 4, 5 and 6 into
a Section 2 that reads as follows? 

2. Overview

   To support the authorization and provisioning of Framed Management
   access to managed entities, this document introduces a new value for
   the Service-Type Attribute [RFC2865], and one new attribute.  The new
   value for the Service-Type Attribute is Framed-Management, used for
   remote device management via a Framed Management Protocol.  The new
   attribute is Framed-Management-Protocol, the value of which specifies a 
   particular protocol for use in the remote management session.

   Two new attributes are introduced in this document in support of
   granular management access rights or command privilege levels.
   The Management-Policy-Id Attribute provides a text string
   specifying  a policy name of local scope, that is assumed to have
   been pre-provisioned on the NAS.  This use of an attribute to 
   specify use of a pre-provisioned policy is similar to 
   the Filter-Id Attribute defined in [RFC2865] Section 5.11. 

   The local application of the Management-Policy-Id within the managed
   entity may take the form of (a) one of an enumeration of command
   privilege levels, (b) a mapping into an SNMP Access Control Model,
   such as the View Based Access Control Model (VACM) [RFC3415], or (c)
   some other set of management access policy rules that is mutually
   understood by the managed entity and the remote management
   application.  Examples are given in Section X.

   The Management-Privilege-Level Attribute contains an
   integer-valued management privilege level indication.  This attribute
   serves to modify or augment the management permissions provided by
   the NAS-Prompt value of the Service-Type Attribute, and thus applies to 
   CLI management.

   To enable management security requirements to be specified, the
   Management-Transport-Protection Attribute is introduced.  The value 
   of this attribute indicates the minimum level of secure transport 
   protocol protection required for the provisioning of NAS-Prompt,
   Administrative or Framed-Management service.   


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


Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jun 2008 05:04:14 +0000
Date: Mon, 23 Jun 2008 22:03:25 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER:  WG Last call in progress: RADIUS Authorization for NAS Management
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a reminder of RADEXT WG Last Call on "RADIUS Authorization 
for NAS Management" prior to sending it on to the IESG for consideration 
as a Proposed Standard.
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-03.txt
 
WG Last Call will last until June 30, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 




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


Envelope-to: [e-mail]
Delivery-date: Tue, 24 Jun 2008 05:03:04 +0000
Date: Mon, 23 Jun 2008 22:01:39 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Call for Agenda Items for IETF 72
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a call for agenda items for the RADEXT WG meeting at IETF 72 in 
Dublin.  The meeting is tentatively scheduled for Wednesday, July 30, 
2008 from 9 AM - 11:30 AM.  

If you have an item you'd like to put on the agenda, please contact myself 
([e-mail]) or Dave. 

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


Envelope-to: [e-mail]
Delivery-date: Sat, 21 Jun 2008 16:49:25 +0000
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-radext-radsec-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 17 Jun 2008 15:45:02 -0700 (PDT)
Cc: [e-mail]
Reply-To: [e-mail]

--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 over TCP (RadSec)
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-00.txt
	Pages           : 14
	Date            : 2008-06-17

This document specifies security on the transport layer (TLS) for the
RADIUS protocol [2] when transmitted over TCP [9].  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-00.txt

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

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

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

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


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--

--
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, 18 Jun 2008 20:30:42 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 Jun 2008 22:29:58 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-radext-radsec-00.txt
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

[e-mail] schrieb:
> 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 over TCP (RadSec)
> 	Author(s)       : S. Winter, et al.
> 	Filename        : draft-ietf-radext-radsec-00.txt
> 	Pages           : 14
> 	Date            : 2008-06-17
>
> This document specifies security on the transport layer (TLS) for the
> RADIUS protocol [2] when transmitted over TCP [9].  This enables
> dynamic trust relationships between RADIUS servers.
>
>   
This document has the TCP transport part chopped out, as that part goes 
into a separate document. The according reference [9] will come into 
existence in the coming weeks.
Apart from that, the title, abstract, some sections in the main body 
were updated to reflect the splitting. No real content changes in it.

Greetings,

Stefan Winter

--
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, 18 Jun 2008 18:07:03 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 Jun 2008 20:00:38 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-radext-status-server-00.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
> 
> 	Title		: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
> 	Author(s)	: A. DeKok
> 	Filename	: draft-ietf-radext-status-server-00.txt

  FYI: The only change between this document and
draft-dekok-radext-status-server-02.txt is the name, submission date,
and expiration date.

  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, 18 Jun 2008 17:02:43 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-radext-status-server-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 18 Jun 2008 10: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		: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
	Author(s)	: A. DeKok
	Filename	: draft-ietf-radext-status-server-00.txt
	Pages		: 27
	Date		: 2008-6-17
	
RFC 2865 defines a Status-Server code for use in RADIUS, but labels
   it as "Experimental" without further discussion.  This document
   describes a practical use for the Status-Server packet code, which is
   to let clients query the status of a RADIUS server.  These queries,
   and responses (if any) enable the client to make more informed
   decisions.  The result is a more stable, and more robust RADIUS
   architecture.



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

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-status-server-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--


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


Envelope-to: [e-mail]
Delivery-date: Tue, 17 Jun 2008 22:47:03 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-radsec-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 17 Jun 2008 15: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           : TLS encryption for RADIUS over TCP (RadSec)
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-00.txt
	Pages           : 14
	Date            : 2008-06-17

This document specifies security on the transport layer (TLS) for the
RADIUS protocol [2] when transmitted over TCP [9].  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-00.txt

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

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

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

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 17 Jun 2008 22:19:35 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Sanchez, Mauricio \(ProCurve\)'" <[e-mail]>, <[e-mail]>
Subject: RE: Request for review of RADIUS Attributes for IEEE 802 Networks
Date: Tue, 17 Jun 2008 15:18:03 -0700
Message-ID: <005f01c8d0c8$029efe70$07dcfb50$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcgmODLyeeG1TRSFS16Yc4EGw4p4CgQuU01gAAAEyGAmdZn3wA==
Content-Language: en-us

I also support this document as a RADEXT WG item. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Sanchez, Mauricio (ProCurve)
Sent: Tuesday, December 04, 2007 7:48 PM
To: [e-mail]
Subject: Request for review of RADIUS Attributes for IEEE 802 Networks


I support this document as a RADEXT WG item.

Cheers,
MS

> -----Original Message-----
> From: [e-mail] [mailto:owner-
> [e-mail]] On Behalf Of David B. Nelson
> Sent: Tuesday, November 13, 2007 1:00 PM
> To: [e-mail]
> Subject: Request for review of RADIUS Attributes for IEEE 802 Networks
> 
> The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was
> revised on
> July 30, 2007, after incorporating review from the IEEE 802.11 WG.
> This
> document appears on the RADEXT WG charter as a June 2006 milestone
> "WLAN
> Attributes draft submitted as a Proposed Standard RFC".  It would be
> good to
> make additional progress on this document.  It appears that all the
> required
> external (i.e. IEEE) review has been completed.
> 
> Please review this draft to determine if it is ready to be taken on as
> a
> RADEXT WG work item.  The draft is to be found at:
> 
> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt
> 
> In light of the upcoming IETF-70 meeting, this request for review will
> last
> until December 7, 2007, i.e. approximately four weeks, including the
> IETF
> week.
> 
> Please indicate whether you would like this document to be taken on as
> a WG
> work item. Please respond even if you have no issues with the document.
> If
> you have comments, please send the issues to the RADEXT WG mailing list
> in
> the format provided here:
> 
> http://www.drizzle.com/~aboba/RADEXT/
> 
> Thanks!
> 
> Regards,
> 
> Dave Nelson
> 
> 
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 16 Jun 2008 20:34:35 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS Management"
Date: Mon, 16 Jun 2008 16:32:59 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <9B9F3669FCE44E24AFEEC3F456870385@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcjP7oMtbwAqQuoxRMaIGZvyuOFXPgAASCaw

Forwarding on behalf of Bernard...  (transient e-mail issues)

From: [e-mail]
To: [e-mail]
Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS =
Management"
Date: Mon, 16 Jun 2008 13:03:40 -0700

This is an announcement of RADEXT WG Last Call on "RADIUS Authorization =
for
NAS Management" prior to sending it on to the IESG for consideration as =
a
Proposed Standard.
=A0
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authoriz=
ati
on-03.txt
=A0
WG Last Call will last until June 30, 2008.=A0=A0 Please review the =
document and
post your comments to the RADEXT WG mailing list =
([e-mail]) in
the format described on the RADEXT WG Issues list
(http://www.drizzle.com/~aboba/RADEXT/).=A0=A0=20
=A0
If you have read the document and approve of its publication, but have =
no
comments, please also post this to the list.=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: Mon, 16 Jun 2008 15:04:13 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'David Harrington'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>
Subject: RE: I-D Action:draft-ietf-radext-management-authorization-03.txt 
Date: Mon, 16 Jun 2008 11:02:14 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <2CC84668FF754256BF8B344763BBC412@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjM/HXJa+rVnKQxSOiWb39rs4zW1gCwsnfg

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

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

I would like to call the WG's attention to this recently posted draft
revision.  This version addresses WGLC Issues 253-256, as discussed in
recent mailing list threads.

A summary of the technical (non-editorial) changes is as follows:

Section 8.1:

Added text describing the use of the Framed-Management-Protocol Attribute by
the NAS in Access-Request packets as a "hint", by the server in
Access-Accept packets as an expression of the server's policy and by the NAS
in Access-Accept packets in the case when the value does not match with the
requested access or the NAS's supported protocols.

Clarified that "CP" means "RCP" and added "SCP" and "SFTP".

Section 8.2:

Added text describing the use the Management-Transport-Protection Attribute
similar to that described above.

Section 9:

Fixed some inconsistencies in the examples.

Please take a moment to review all of the changes in this revision.

Bernard, were you planning to initiate a second WGLC on this draft prior to
IETF-72?



--
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, 16 Jun 2008 05:14:52 +0000
Message-ID: <[e-mail]>
Date: Mon, 16 Jun 2008 07:08:36 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Wasn't Status-Server first implemented by Ascend Communications in the
> mid-1990s?

  It's certainly possible.  I don't recall, and I don't have access to a
source tree to check.

  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, 16 Jun 2008 01:08:09 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Request for Review: Status Server Document
Date: Sun, 15 Jun 2008 18:06:28 -0700
Message-ID: <001d01c8cf4d$34fbd590$9ef380b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjPIPljHhjompzOTriON6OR8Wk57gAKw5rw
Content-Language: en-us

Alan DeKok said:

"  The only part of the Status-Server behavior that does not go back to
2001 is the suggestion that it contain a Message-Authenticator
attribute.  That requirement was added to FreeRADIUS in Feb 2007, before
the RADEXT WG discussion on re-chartering."

Wasn't Status-Server first implemented by Ascend Communications in the
mid-1990s?




--
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, 15 Jun 2008 19:45:48 +0000
Message-ID: <[e-mail]>
Date: Sun, 15 Jun 2008 21:39:19 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Romascanu, Dan (Dan) wrote:
> My understanding from the discussions that preceded the rechartering
> approval was that we are indeed documenting current practices based on
> implementations and deployment without defining anything new. It's OK
> (actually more than OK - required) to put text that makes this
> crystal-clear. 

  The only part of the Status-Server behavior that does not go back to
2001 is the suggestion that it contain a Message-Authenticator
attribute.  That requirement was added to FreeRADIUS in Feb 2007, before
the RADEXT WG discussion on re-chartering.

  This appears to fall with the "documenting current practices" guidelines.

  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, 15 Jun 2008 09:30:07 +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: Request for Review: Status Server Document
Date: Sun, 15 Jun 2008 11:28:36 +0200
Message-ID: <[e-mail]>
Thread-Topic: Request for Review: Status Server Document
Thread-Index: AcjONKB44MDqFmiKTKirxjFV1SoB7AAlSHgA
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Alan DeKok" <[e-mail]>, "David B. Nelson" <[e-mail]>
Cc: <[e-mail]>

Alan,

I have a different view.=20

This is what the charter says about this work item:=20

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

My understanding from the discussions that preceded the rechartering
approval was that we are indeed documenting current practices based on
implementations and deployment without defining anything new. It's OK
(actually more than OK - required) to put text that makes this
crystal-clear.=20

If the working group believes that the implementations are wrong it
needs to say it clearly in this document. If the WG believes that there
need to be fixes in the protocol, it needs to recharter this work item.
Actually we can create new RADIUS codes according to the new charter,
but not for this work item.=20

Dan

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Alan DeKok
> Sent: Saturday, June 14, 2008 6:31 PM
> To: David B. Nelson
> Cc: [e-mail]
> Subject: Re: Request for Review: Status Server Document
>=20
> David B. Nelson wrote:
> > That makes review of this document in RADEXT a little bit=20
> challenging.
> > We can, of course, polish the prose and make sure that the=20
> > descriptions are self-consistent and clear and that the=20
> organization=20
> > is logical.  I guess only those who have access to the "historical=20
> > implementation" can discern whether the descriptions are=20
> accurate and correct.
>=20
>   See ftp://ftp.cistron.nl/pub/radius.  Open Source =3D=3D full =
access.
>=20
>   Version 1.6.5 has the first public implementation of Status-Server.
> CVS indicates that the change was January 21, by Miquel Van=20
> Smoorenburg.
>  FreeRADIUS added support for Status-Server on Oct 17, 2002,=20
> "stolen shamelessly from Cistron", according to the commit message.
>=20
>   I believe that Radiator also added it around the same time.=20
>  I don't know which was first, because I don't have access to=20
> the Radiator CVS tree.
>=20
>   The intent of the document is most definitely *not* to=20
> document historical implementations... and leave it at that. =20
> The original implementation in Cistron did NOT validate=20
> Status-Server packets, so they could be trivially forged.
>=20
>   As a result, the document is rather longer than I had=20
> originally intended.  I expected that simply documenting the=20
> practice would be 3-4 pages, at most.  Upon writing it, there=20
> were a number of loose ends that had to be cleared up, such=20
> as security.  Hence the additional text.
>=20
> > The IESG, and the IETF at large, hold the WG, in general,=20
> and the WG=20
> > Chairs and/or Document Shepherd, in particular, accountable=20
> to assert=20
> > that the submitted draft meets certain protocol quality standards. =20
> > Now, I suppose that the quality of protocols is somewhat subjective.
> > Nonetheless, its uncomfortable to be held accountable for=20
> the quality=20
> > of a design that you are not able to affect in any way.
>=20
>   I expect the WG to complain loudly if there are any=20
> problems.  This seems to be historical practice in RADEXT. :)
>=20
>   Much of the text in the document discusses security issues=20
> around the use of Status-Server, and recommended practices. =20
> I expect full review of both the security implications and=20
> recommended practices.
>=20
>   The document is partly about historical implementations. =20
> But if those implementations are wrong, the standard should=20
> reflect that, and should standardize the correct behavior. =20
> e.g. It recommends adding Message-Authenticator to=20
> Status-Server, which Cistron did not enforce in 2001, and=20
> which FreeRADIUS did not enforce until a few years ago.
>=20
> > I think that we need to be clear in publishing this draft=20
> and an RFC=20
> > that the *protocol* it documents was *not* the work product of the=20
> > RADEXT WG, but rather of various historic implementors.  Truth in=20
> > advertising.  There are some hints at that already.  I'll=20
> propose some=20
> > more explicit text as a formal RADEXT Issue.
>=20
>   Thanks.  The choice of (some) contents, response packet=20
> codes, and use of Status-Server as a "ping" are historical. =20
> Much of the rest of the document is discussion surrounding the topic.
>=20
> >>   RADIUS has traditionally used separate status codes for requests=20
> >> and replies.  Using the same code for both is about as bad=20
> (IMHO) as=20
> >> overloading Access-Accept.
> >=20
> > I think you're probably right.  Sigh.
>=20
>   I'll add some test to the document to this effect. =20
> "Overloading Access-Accept is horrible.  RADIUS would=20
> normally use something like Ping-Check and Ping-Ack, but=20
> implementations exist..."
>=20
>   And the charter prevents us from creating more RADIUS=20
> codes, so it would have been problematic to create Ping-Check=20
> and Ping-Ack now.
> Overloading Access-Accept seems to make the best of a bad situation.
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> [e-mail] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=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: Sun, 15 Jun 2008 07:53:01 +0000
Message-ID: <[e-mail]>
Date: Sun, 15 Jun 2008 09:47:11 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail],  "'David B. Nelson'" <[e-mail]>
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Existing implementations or not, RADIUS "ping" is just as wasteful of
> processing power & bandwidth as it was 10 years ago.

  It's not a "keep-alive".  That's bad.  It is the watchdog timer
recommended in RFC 3539.  The draft discusses why using existing RADIUS
codes such as Access-Request is not a good idea.  It also discusses why
it's useful, and why it's not a "keep-alive".

>  A far better idea IMHO
> is to have the server tell its clients when it recovers from a failure/admin
> reboot/etc.

  I agree, mostly.  Some complications:

- clients don't historically listen on a port for unsolicited RADIUS
packets (RFC 5176 is not widely deployed)

- clients may be behind NATs or firewalls.   The forward path is well
tested, deployed, with firewall traversal rules.  The backwards path is not.

- this would involve defining a new port (maybe), new packet codes
(could we re-use Status-Server?), and new behavior.  The existing
practice has multiple implementations, is widely used, and meets most of
the needs for client to server status checking.

  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, 15 Jun 2008 07:41:19 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>, "'David B. Nelson'" <[e-mail]>
Subject: RE: Request for Review: Status Server Document
Date: Sun, 15 Jun 2008 14:38:34 +0700
Message-ID: <001501c8ceba$db05d2d0$91117870$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AcjORLUCxGUYP/aBSEq/Jkajt8aXSQAdaJFA
Content-Language: en-us

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

> David B. Nelson wrote:
> >>   And the charter prevents us from creating more RADIUS codes...
> >
> > Not anymore!  :-)  Here are the only restrictions in the *revised*
> charter:
> 
>   Temptation...
> 
>   Adding Ping-Check and Ping-Ack would be nice in theory.  But given
> existing implementations, I'm not sure there's any benefit in doing so.

Existing implementations or not, RADIUS "ping" is just as wasteful of
processing power & bandwidth as it was 10 years ago.  A far better idea IMHO
is to have the server tell its clients when it recovers from a failure/admin
reboot/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: Sat, 14 Jun 2008 23:07:26 +0000
From: Mike McCauley <[e-mail]>
To: Alan DeKok <[e-mail]>
Subject: Re: Request for Review: Status Server Document
Date: Sun, 15 Jun 2008 09:05:43 +1000
User-Agent: KMail/1.8.2
Cc: "David B. Nelson" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>

On Sunday 15 June 2008 01:30, Alan DeKok wrote:
> David B. Nelson wrote:
> > That makes review of this document in RADEXT a little bit challenging.
> > We can, of course, polish the prose and make sure that the descriptions
> > are self-consistent and clear and that the organization is logical.  I
> > guess only those who have access to the "historical implementation" can
> > discern whether the descriptions are accurate and correct.
>
>   See ftp://ftp.cistron.nl/pub/radius.  Open Source == full access.
>
>   Version 1.6.5 has the first public implementation of Status-Server.
> CVS indicates that the change was January 21, by Miquel Van Smoorenburg.
>  FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen
> shamelessly from Cistron", according to the commit message.
>
>   I believe that Radiator also added it around the same time.  I don't
> know which was first, because I don't have access to the Radiator CVS tree.

Radiator had support for Status-Server from version 1.9 on 20/1/98.



-- 
Mike McCauley                               [e-mail]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone [phone]                       Fax   [phone]

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare 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: Sat, 14 Jun 2008 17:30:11 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Jun 2008 19:24:07 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
>>   And the charter prevents us from creating more RADIUS codes...
> 
> Not anymore!  :-)  Here are the only restrictions in the *revised* charter:

  Temptation...

  Adding Ping-Check and Ping-Ack would be nice in theory.  But given
existing implementations, I'm not sure there's any benefit in doing so.

  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: Sat, 14 Jun 2008 15:51:18 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Jun 2008 11:50:06 -0400
From: "David B. Nelson" <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alan DeKok wrote:

>   I'll add some text to the document to this effect.  "Overloading
> Access-Accept is horrible.  RADIUS would normally use something like
> Ping-Check and Ping-Ack, but implementations exist..."

That would help to put the base protocol around Server-Status into 
historical perspective.

>   And the charter prevents us from creating more RADIUS codes...

Not anymore!  :-)  Here are the only restrictions in the *revised* charter:

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All documents produced MUST specify means of interoperation with
legacy RADIUS and, if possible, be backward
compatible with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.
Transport profiles should, if possible, be compatible with RFC 3539.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.



--
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, 14 Jun 2008 15:36:57 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Jun 2008 17:30:42 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> That makes review of this document in RADEXT a little bit challenging.
> We can, of course, polish the prose and make sure that the descriptions
> are self-consistent and clear and that the organization is logical.  I
> guess only those who have access to the "historical implementation" can
> discern whether the descriptions are accurate and correct.

  See ftp://ftp.cistron.nl/pub/radius.  Open Source == full access.

  Version 1.6.5 has the first public implementation of Status-Server.
CVS indicates that the change was January 21, by Miquel Van Smoorenburg.
 FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen
shamelessly from Cistron", according to the commit message.

  I believe that Radiator also added it around the same time.  I don't
know which was first, because I don't have access to the Radiator CVS tree.

  The intent of the document is most definitely *not* to document
historical implementations... and leave it at that.  The original
implementation in Cistron did NOT validate Status-Server packets, so
they could be trivially forged.

  As a result, the document is rather longer than I had originally
intended.  I expected that simply documenting the practice would be 3-4
pages, at most.  Upon writing it, there were a number of loose ends that
had to be cleared up, such as security.  Hence the additional text.

> The IESG, and the IETF at large, hold the WG, in general, and the WG
> Chairs and/or Document Shepherd, in particular, accountable to assert
> that the submitted draft meets certain protocol quality standards.  Now,
> I suppose that the quality of protocols is somewhat subjective.
> Nonetheless, its uncomfortable to be held accountable for the quality of
> a design that you are not able to affect in any way.

  I expect the WG to complain loudly if there are any problems.  This
seems to be historical practice in RADEXT. :)

  Much of the text in the document discusses security issues around the
use of Status-Server, and recommended practices.  I expect full review
of both the security implications and recommended practices.

  The document is partly about historical implementations.  But if those
implementations are wrong, the standard should reflect that, and should
standardize the correct behavior.  e.g. It recommends adding
Message-Authenticator to Status-Server, which Cistron did not enforce in
2001, and which FreeRADIUS did not enforce until a few years ago.

> I think that we need to be clear in publishing this draft and an RFC
> that the *protocol* it documents was *not* the work product of the
> RADEXT WG, but rather of various historic implementors.  Truth in
> advertising.  There are some hints at that already.  I'll propose some
> more explicit text as a formal RADEXT Issue.

  Thanks.  The choice of (some) contents, response packet codes, and use
of Status-Server as a "ping" are historical.  Much of the rest of the
document is discussion surrounding the topic.

>>   RADIUS has traditionally used separate status codes for requests and
>> replies.  Using the same code for both is about as bad (IMHO) as
>> overloading Access-Accept.
> 
> I think you're probably right.  Sigh.

  I'll add some test to the document to this effect.  "Overloading
Access-Accept is horrible.  RADIUS would normally use something like
Ping-Check and Ping-Ack, but implementations exist..."

  And the charter prevents us from creating more RADIUS codes, so it
would have been problematic to create Ping-Check and Ping-Ack now.
Overloading Access-Accept seems to make the best of a bad situation.

  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: Sat, 14 Jun 2008 14:55:16 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RADEXT WG meeting at IETF-72 in Dublin
Date: Sat, 14 Jun 2008 10:53:47 -0400
Message-ID: <000001c8ce2e$751fe0a0$011716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjOLnLOw6vZAxwtSX2n8UgCWuHrqA==

The current *draft* schedule for the upcoming IETF-72 meeting is online at:

https://datatracker.ietf.org/meeting/72/agenda.html

As of today, a 2.5 hour slot has been scheduled for RADEXT to meet on
Wednesday morning (0900-1130), July 30, 2008.  Please note that the meeting
agenda is not yet final and is subject to change.

It's not too early to request agenda items for the RADEXT WG meeting.
Please send your request to the chairs, indicating the subject, the I-D (if
any) and the amount of time requested.

Thanks!



--
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, 14 Jun 2008 13:58:24 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Jun 2008 09:56:40 -0400
From: "David B. Nelson" <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alan DeKok writes...

>> Why is the Server-Status "query" packet responded to by an Access-Accept
>> "reply" packet?  It seems to me that were over-loading the semantics of
>> Access-Accept by using it in this way.  Maybe that's not particularly
>> harmful -- I don't know for sure -- but over-loading always seems like a Bad
>> Idea (tm) to me.
> 
>   Yes it's not ideal.  It's a historical practice.

Yes, so Bernard has explained.

That makes review of this document in RADEXT a little bit challenging. 
We can, of course, polish the prose and make sure that the descriptions 
are self-consistent and clear and that the organization is logical.  I 
guess only those who have access to the "historical implementation" can 
discern whether the descriptions are accurate and correct.

The IESG, and the IETF at large, hold the WG, in general, and the WG 
Chairs and/or Document Shepherd, in particular, accountable to assert 
that the submitted draft meets certain protocol quality standards.  Now, 
I suppose that the quality of protocols is somewhat subjective. 
Nonetheless, its uncomfortable to be held accountable for the quality of 
a design that you are not able to affect in any way.

Bernard raises the example of RFC 5176, which was a "bis" revision of 
RFC 3576.  The former was not the product of any working group, AFAICT, 
and was not labeled as such when it was published.  The RADIUS WG had 
closed and the RADEXT WG had not yet been conceived.  I'm not sure 
that's an appropriate analogy.

I think that we need to be clear in publishing this draft and an RFC 
that the *protocol* it documents was *not* the work product of the 
RADEXT WG, but rather of various historic implementors.  Truth in 
advertising.  There are some hints at that already.  I'll propose some 
more explicit text as a formal RADEXT Issue.

>> Wouldn't it have been possible to use the same Command Code (Server-Status)
>> for *both* the query and response, with the context coming from who's doing
>> the receiving?  I think that would be preferable, in a number of ways.
> 
>   RADIUS has traditionally used separate status codes for requests and
> replies.  Using the same code for both is about as bad (IMHO) as
> overloading Access-Accept.

I think you're probably right.  Sigh.




--
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, 14 Jun 2008 08:33:25 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Jun 2008 10:26:59 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Why is the Server-Status "query" packet responded to by an Access-Accept
> "reply" packet?  It seems to me that were over-loading the semantics of
> Access-Accept by using it in this way.  Maybe that's not particularly
> harmful -- I don't know for sure -- but over-loading always seems like a Bad
> Idea (tm) to me.

  Yes it's not ideal.  It's a historical practice.

> Wouldn't it have been possible to use the same Command Code (Server-Status)
> for *both* the query and response, with the context coming from who's doing
> the receiving?  I think that would be preferable, in a number of ways.

  RADIUS has traditionally used separate status codes for requests and
replies.  Using the same code for both is about as bad (IMHO) as
overloading Access-Accept.

  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, 13 Jun 2008 22:31:15 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Request for Review: Status Server Document
Date: Fri, 13 Jun 2008 15:30:01 -0700
Message-ID: <000e01c8cda5$04934f40$0db9edc0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjFIxb4UokZVUeIQY20g6mdhMf0ZAIehPBgAAHZHiA=
Content-Language: en-us

>I did see the not-so-subtle hint that this document is describing
*existing*
>implementations, much as we did in the original RADIUS WG.  

The goal of the Status-Server specification is to document an existing 
protocol, much as RFC 5176 documented an existing protocol for dynamic
authorization.  

That said, if there are improvements that can be made within the protocol
while maintaining backward compatibility, then they should be considered. 




--
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, 13 Jun 2008 21:46:07 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Request for Review: Status Server Document
Date: Fri, 13 Jun 2008 17:44:19 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <F660C647399C4EBA8235C8B4B8B87F3F@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjFIxb4UokZVUeIQY20g6mdhMf0ZAIehPBg

I have a "big picture" question to ask before I delve into further levels of
detailed review and questions.

Why is the Server-Status "query" packet responded to by an Access-Accept
"reply" packet?  It seems to me that were over-loading the semantics of
Access-Accept by using it in this way.  Maybe that's not particularly
harmful -- I don't know for sure -- but over-loading always seems like a Bad
Idea (tm) to me.

Wouldn't it have been possible to use the same Command Code (Server-Status)
for *both* the query and response, with the context coming from who's doing
the receiving?  I think that would be preferable, in a number of ways.

I did see the not-so-subtle hint that this document is describing *existing*
implementations, much as we did in the original RADIUS WG.  The inference I
draw is that redesign (i.e. helpful suggestions for alternate choices, such
as the one my question raises) is not solicited or welcomed.  Of course,
maybe I'm simply reading too much into that wording. 

Anyway, why couldn't Server-Status be the RADIUS Command Code used for both
queries and replies?

Regards,

Dave Nelson



--
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, 13 Jun 2008 02:17:03 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-management-authorization-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 12 Jun 2008 19: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           : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)       : D. Nelson, G. Weber
	Filename        : draft-ietf-radext-management-authorization-03.txt
	Pages           : 24
	Date            : 2008-06-12

This document describes Remote Authentication Dial-In User Service
(RADIUS) attributes for the authorization and service provisioning of
Network Access Servers (NASes).  Both local and remote management are
supported, with granular access rights and management privileges.
Specific provisions are made for remote management via framed
management protocols, and for specification of a protected transport
protocol.

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

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 12 Jun 2008 12:32:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: draft-lourdelet-radext-ipv6-dhcp-00 published
Date: Thu, 12 Jun 2008 14:31:10 +0200
Message-ID: <[e-mail]>
Thread-Topic: draft-lourdelet-radext-ipv6-dhcp-00 published
Thread-Index: AcjMiDIFvS34EaIwTtaapCJ0oDmg4Q==
From: "Benoit Lourdelet (blourdel)" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1049; t=1213273850; x=1214137850; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20<blourdel@ cisco.com> |Subject:=20draft-lourdelet-radext-ipv6-dhcp-00=20published |Sender:=20; bh=jKyR5AUN4QatFAkwDOeFyvUb00SQ2CDqsfnIG56Fpds=; b=TIJJ+cCufGgP/V4gSZBJrVzUEwJuKE2EJuH2AfBLbuy4OFdlzAxYQ4W5xa INiHk7dg7+KJzlDkgxs/QpNhVMdrRhUW35visL0ctZgAqdXKtxprNbWFPIn6 pzv0bYbD7s;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );

Hello,

I published a document specifying new RADIUS  attributes supporting IPv6
network access to complement [RFC3162] in DHCP environments. It
addresses the need to dynamically advertise DNS Server addresses and one
or multiple IPv6 addresses via DHCPv6.

It is available here :
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.
txt

Comments are welcome.

Regards

Benoit Lourdelet



A new version of I-D, draft-lourdelet-radext-ipv6-dhcp-00.txt has been
successfuly submitted by Benoit Lourdelet and posted to the IETF
repository.

Filename: draft-lourdelet-radext-ipv6-dhcp

Revision: 00

Title: IPv6 RADIUS attributes for DHCP based networks

Creation_date: 2008-06-12

WG ID: Independent Submission

Number_of_pages: 8

Abstract:

This document specifies RADIUS [RFC2865] attributes supporting IPv6
network access to complement [RFC3162] in DHCP environments. It
addresses the need to dynamically advertise DNS Server addresses and one
or multiple IPv6 addresses via DHCPv6.


--
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, 12 Jun 2008 11:58:07 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RADEXT Issue 256 (NAS management Authorization)
Date: Thu, 12 Jun 2008 18:56:35 +0700
Message-ID: <00ae01c8cc83$6524ed00$2f6ec700$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sAAATV2IAAAUj4A
Content-Language: en-us

David B. Nelson [mailto:[e-mail]] writes:

> > Does it really matter?
> 
> If a protocol is no longer used, why bother include it in the list?

I'm sure somebody somewhere is using rcp (possibly even Kerberized) for
example, esp. if their NAS is *nix-based.  Why not?

> 
> > If they will be included in the list, just include them w/o editorial
> > comment...
> 
> Yeah, that sounds like good advice.
> 




--
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, 12 Jun 2008 11:47:38 +0000
From: "David B. Nelson" <[e-mail]>
To: "'Glen Zorn'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RADEXT Issue 256 (NAS management Authorization)
Date: Thu, 12 Jun 2008 07:46:49 -0400
Message-ID: <015f01c8cc82$017a0d90$011716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sAAATV2IA==

> Does it really matter?

If a protocol is no longer used, why bother include it in the list?

> If they will be included in the list, just include them w/o editorial
> comment...

Yeah, that sounds like good advice.



--
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, 12 Jun 2008 11:34:22 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'Bernard Aboba'" <[e-mail]>
Subject: RE: RADEXT Issue 256 (NAS management Authorization)
Date: Thu, 12 Jun 2008 18:32:23 +0700
Message-ID: <00aa01c8cc80$06ecedd0$14c6c970$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sA=
Content-Language: en-us

David B. Nelson <mailto://[e-mail]> writes:

> > I am not sure there is evidence that scp has been largely replaced by
> > sftp. I suggest to simply remove the last sentence.
> 
> What about RCP?  It is still in use, or has it been [somewhat |
> largely]
> replaced by {SCP | SFTP}?

Does it really matter?  If they will be included in the list, just include
them w/o editorial comment (especially based upon a source like Wikipedia
;-).

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



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


Envelope-to: [e-mail]
Delivery-date: Thu, 12 Jun 2008 11:02:13 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Bernard Aboba'" <[e-mail]>
Subject: RE: RADEXT Issue 256 (NAS management Authorization)
Date: Thu, 12 Jun 2008 07:00:51 -0400
Message-ID: <015501c8cc7b$9594a690$011716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4ow

> I am not sure there is evidence that scp has been largely replaced by
> sftp. I suggest to simply remove the last sentence.

What about RCP?  It is still in use, or has it been [somewhat | largely]
replaced by {SCP | SFTP}?



--
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, 12 Jun 2008 04:25:11 +0000
Date: Thu, 12 Jun 2008 06:23:53 +0200
From: Juergen Schoenwaelder <[e-mail]>
To: "David B. Nelson" <[e-mail]>
Cc: [e-mail], 'Bernard Aboba' <[e-mail]>
Subject: Re: RADEXT Issue 256 (NAS management Authorization)
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mail-Followup-To: "David B. Nelson" <[e-mail]>, [e-mail], 'Bernard Aboba' <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

On Wed, Jun 11, 2008 at 08:34:23PM -0400, David B. Nelson wrote:

>    o  SCP: Secure CoPy file copy utility (Unix-based), used to transfer
>       configuration files to and from the NAS.  SCP has been largely
>       replaced by SFTP.

I am not sure there is evidence that scp has been largely replaced by
sftp. I suggest to simply remove the last sentence.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

--
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, 12 Jun 2008 00:35:50 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: RADEXT Issue 256 (NAS management Authorization)
Date: Wed, 11 Jun 2008 20:34:23 -0400
Message-ID: <010c01c8cc24$11205640$011716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcjL36U2arTmS5tUSDGUWXJpwz7AOQAQy87w

One of the comments in Issue 256 was to add references for all of the
management protocols (methods?) enumerated for the
Framed-Management-Protocol Attribute in Section 8.1

In researching stable references, I discovered two issues:

(1) Some of these don't have good, stable references, such as standards
documents, but seem to be documented by UNIX "man pages".

(2) Some of these have supposedly been largely replaced in common usage.

The straw-man text that I now have looks like this:

   o  SNMP: Simple Network Management Protocol.  [RFC3411], [RFC3412],
      [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418]

   o  Web-based: Use of an embedded web server in the NAS for management
      via a generic web browser client.  The interface presented to the
      administrator may be graphical, tabular or textual.  The protocol
      is HTML over HTTP.  The protocol may optionally be HTML over
      HTTPS, i.e. using HTTP over TLS.

   o  NETCONF: Management via the NETCONF protocol using XML over
      supported transports (e.g.  SSH, BEEP, SOAP).  As secure transport
      profiles are defined for NETCONF, the list of transport options
      may expand.  [RFC4741], [RFC4742], [RFC4743], [RFC4744]

   o  FTP: File Transfer Protocol, used to transfer configuration files
      to and from the NAS.  [RFC0959]

   o  TFTP: Trivial File Transfer Protocol, used to transfer
      configuration files to and from the NAS.  [RFC1350]

   o  SFTP: SSH File Transfer Protocol, used to securely transfer
      configuration files to and from the NAS.  SFTP uses the services
      of SSH. (http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)

   o  RCP: Remote CoPy file copy utility (Unix-based), used to transfer
      configuration files to and from the NAS.  RCP has bee largely
      replaced by SFTP.

   o  SCP: Secure CoPy file copy utility (Unix-based), used to transfer
      configuration files to and from the NAS.  SCP has been largely
      replaced by SFTP.

IIRC, RCP and TFTP were added to a previous draft version to resolve
previous review comments.  It is reported (e.g. Wikipedia) that SFTP is now
preferred to both RCP and SCP.

I would like to get some feedback from the WG prior to submitting the -03
version, as to whether:

(1) Are all of these methods of copying configuration files to a NAS in
current use?

(2) Are the cited references (or lack thereof) sufficient to our needs?



--
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, 11 Jun 2008 16:20:07 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, <[e-mail]>
Subject: RE: RADEXT Issue 256 (NAS management Authorization)
Date: Wed, 11 Jun 2008 09:18:39 -0700
MIME-Version: 1.0

--_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> When a NAS receives a Framed-Management-Protocol attribute in an
> Access-Accept packet, it MUST deliver that specified form of management
> access or disconnect the session.  If the NAS does not support the
> provisioned management application-layer protocol, or the management acce=
ss
> protocol requested by the user does not match that of the
> Framed-Management-Protocol attribute in the Access-Accept packet, the NAS
> must treat the response packet as if it had been an Access-Reject.

[BA] Should this be "MUST"?  Presumably if the NAS supports the new Service=
-Type,
then it is also required to understand the Framed-Management-Protocol attri=
bute
and take the above action in response to an unsupportable value. =20

> It is RECOMMENDED that the NAS include an appropriately valued
> Management-Transport-Protection attribute in Access-Request packet,
                                                                     ^an

> indicating the level of transport protection for the management access be=
ing
> requested, when that information is available to the RADIUS Client.  The
> RADIUS Server MAY use this hint attribute in making its authorization
> decision.
>=20
> The RADIUS Server MAY include a Management-Transport-Protection attribute=
 in
> an Access-Accept packet that also includes a Service-Type attribute with =
a
> value of Framed-Management, when the RADIUS Server chooses to enforce an
> management access security policy for the authenticated user, that dictat=
es
> a minimum level of transport security.
>=20
> When a NAS receives a Management-Transport-Protection attribute in an
> Access-Accept packet, it MUST deliver the management access over a transp=
ort
> with equal or better protection characteristics or disconnect the session=
.
> If the NAS does not support protected management transport protocols, or =
the
> level of protection available does not match that of the
> Management-Transport-Protection attribute in the Access-Accept packet, th=
e
> NAS must treat the response packet as if it had been an Access-Reject.

"must" -> "MUST" as above.=20

Also, I'd suggest capitalizing the word "Attribute" when referring to a spe=
cific
attribute, as was the custom in RFC 2865.=20


> So, you're suggesting that I not expect IANA to search through the docume=
nt
> for all the (TBA) placeholders, but rather enumerate all the requests her=
e?
> OK, I can do that in version -03.

Yes.  This makes it easier for them.=20

--_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
<br>&gt; When a NAS receives a Framed-Management-Protocol attribute in an<b=
r>&gt; Access-Accept packet, it MUST deliver that specified form of managem=
ent<br>&gt; access or disconnect the session.  If the NAS does not support =
the<br>&gt; provisioned management application-layer protocol, or the manag=
ement access<br>&gt; protocol requested by the user does not match that of =
the<br>&gt; Framed-Management-Protocol attribute in the Access-Accept packe=
t, the NAS<br>&gt; must treat the response packet as if it had been an Acce=
ss-Reject.<br><br>[BA] Should this be "MUST"?&nbsp; Presumably if the NAS s=
upports the new Service-Type,<br>then it is also required to understand the=
 Framed-Management-Protocol attribute<br>and take the above action in respo=
nse to an unsupportable value.&nbsp; <br><br>&gt; It is RECOMMENDED that th=
e NAS include an appropriately valued<br>&gt; Management-Transport-Protecti=
on attribute in Access-Request packet,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 ^an<br><br>&gt; indicating the level of transport protection for the manag=
ement access being<br>&gt; requested, when that information is available to=
 the RADIUS Client.  The<br>&gt; RADIUS Server MAY use this hint attribute =
in making its authorization<br>&gt; decision.<br>&gt; <br>&gt; The RADIUS S=
erver MAY include a Management-Transport-Protection attribute in<br>&gt; an=
 Access-Accept packet that also includes a Service-Type attribute with a<br=
>&gt; value of Framed-Management, when the RADIUS Server chooses to enforce=
 an<br>&gt; management access security policy for the authenticated user, t=
hat dictates<br>&gt; a minimum level of transport security.<br>&gt; <br>&gt=
; When a NAS receives a Management-Transport-Protection attribute in an<br>=
&gt; Access-Accept packet, it MUST deliver the management access over a tra=
nsport<br>&gt; with equal or better protection characteristics or disconnec=
t the session.<br>&gt; If the NAS does not support protected management tra=
nsport protocols, or the<br>&gt; level of protection available does not mat=
ch that of the<br>&gt; Management-Transport-Protection attribute in the Acc=
ess-Accept packet, the<br>&gt; NAS must treat the response packet as if it =
had been an Access-Reject.<br><br>"must" -&gt; "MUST" as above. <br><br>Als=
o, I'd suggest capitalizing the word "Attribute" when referring to a specif=
ic<br>attribute, as was the custom in RFC 2865. <br><br><br>&gt; So, you're=
 suggesting that I not expect IANA to search through the document<br>&gt; f=
or all the (TBA) placeholders, but rather enumerate all the requests here?<=
br>&gt; OK, I can do that in version -03.<br><br>Yes.&nbsp; This makes it e=
asier for them. <br></body>
</html>=

--_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_--

--
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, 11 Jun 2008 11:56:40 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'David Harrington'" <[e-mail]>
Subject: RE: RADEXT Issue 255 (NAS Management Authorization)
Date: Wed, 11 Jun 2008 07:55:24 -0400
Message-ID: <004501c8cbba$09f66f40$011716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQAcRMqgAAgOVmA=

Glen Zorn writes...

> It's not at all clear to me that "Web services" qualifies as any type
> of protocol at all.

I wasn't proposing that we formally characterize embedded web management, as
it's deployed in many NASes today, as "web services".  There is something of
a nomenclature issue here, though, specifically how best to "name" the form
of management that uses an embedded web server to serve up web pages (HTML
content) over the HTTP application-layer protocol to a web browser
application?  The issue is not that HTML/HTTP fails describe the protocol,
but rather that other things besides management can be served in this
fashion. It's my understanding that lots of things are "tunneled" in HTTP
these days, firewall avoidance being but one reason.

What's important, at the end of the day, is that there be an unambiguous
binding between the values of this attribute and the framed (i.e.
non-textual) management mechanisms they represent.

> I think that the Attribute needs to be renamed -- maybe 
> "Framed-Management-Method"?

I have no objection to that choice of attribute name, but I'm wondering if
it really addresses the underlying issue.  The issue is to pick one
identifying characteristic of framed management to serve as the "name".  The
application layer protocol seemed a logical choice.

Does anyone else have thoughts to share on this, one way or another?



--
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, 11 Jun 2008 08:08:44 +0000
Date: Wed, 11 Jun 2008 10:07:45 +0200
From: Juergen Schoenwaelder <[e-mail]>
To: Glen Zorn <[e-mail]>
Cc: "'David B. Nelson'" <[e-mail]>, 'David Harrington' <[e-mail]>, [e-mail]
Subject: Re: RADEXT Issue 255 (NAS Management Authorization)
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mail-Followup-To: Glen Zorn <[e-mail]>, "'David B. Nelson'" <[e-mail]>, 'David Harrington' <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

On Wed, Jun 11, 2008 at 02:58:21PM +0700, Glen Zorn wrote:
> David B. Nelson <mailto://[e-mail]> writes:
> 
> > > 8.1 (and elsewhere)
> > > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> > > HTML/HTTP?
> > 
> > The attribute in question, Framed-Management-Protocol, is used to
> > describe a
> > management *application-layer* protocol.  SNMP clearly qualifies.  An
> > integrated web server, providing management via web pages, also
> > qualifies,
> 
> It's not at all clear to me that "Web services" qualifies as any type of
> protocol at all.  W3C defines a "Web service" as ""a software system
> designed to support interoperable Machine to Machine interaction over a
> network."  Certainly, this definition requires the operation of one or more
> network protocols but there is no requirement that HTTP be one of them.  I
> think that the Attribute needs to be renamed -- maybe
> "Framed-Management-Method"?

I had the same reaction but then I read the text that is contained in
the ID and found that rather clear. And yes, it helps to avoid the
phrase "web services".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

--
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, 11 Jun 2008 08:00:51 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>
Cc: "'David Harrington'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: RADEXT Issue 255 (NAS Management Authorization)
Date: Wed, 11 Jun 2008 14:58:21 +0700
Message-ID: <000901c8cb98$f557ab10$e0070130$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQAcRMqg
Content-Language: en-us

David B. Nelson <mailto://[e-mail]> writes:

> > 8.1 (and elsewhere)
> > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> > HTML/HTTP?
> 
> The attribute in question, Framed-Management-Protocol, is used to
> describe a
> management *application-layer* protocol.  SNMP clearly qualifies.  An
> integrated web server, providing management via web pages, also
> qualifies,

It's not at all clear to me that "Web services" qualifies as any type of
protocol at all.  W3C defines a "Web service" as ""a software system
designed to support interoperable Machine to Machine interaction over a
network."  Certainly, this definition requires the operation of one or more
network protocols but there is no requirement that HTTP be one of them.  I
think that the Attribute needs to be renamed -- maybe
"Framed-Management-Method"?

...



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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 20:26:13 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RADEXT Issue 256 (NAS management Authorization)
Date: Tue, 10 Jun 2008 16:24:44 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjLOAUO9iNIu5F7SDe+sKZWp0fiFw==

> Abstract
> 
> The current text is a bit wordy.  How about this? 
> 
>   This document describes Remote Authentication Dial-In User 
>   Service (RADIUS) attributes for the authorization and service
>   provisioning of Network Access Servers (NASes).  Both local and
>   remote management are supported, with granular access rights
>   and management privileges.  Specific provisions are made for
>   remote management via framed management protocols, and for
>   specification of a protected transport protocol.

Sounds good to me.  Will fix on -03.

> Section 7.1
> 
> I don't think you need to repeat much of Section 5.6 of RFC 2865.
> Why not just reference it instead?  Here is some recommended text
> for this section:
> 
> 7.1.  Service-Type
>
>   The Service-Type attribute is defined in Section 5.6 of RFC 2865
>   [RFC2865].   This document defines a new value of the Service-Type
>   Attribute:
>
>      (TBA)     Framed-Management
>
>      The semantics of the Framed-Management service are as follows:
>
>      Framed-Management   A framed management protocol session should
>                          be started on the NAS.

OK.  Will revise on -03.

> Section 8.1
> 
>   The Framed-Management-Protocol attribute indicates the application-
>   layer management protocol to be used for framed management access.
>   It MAY be used in both Access-Request and Access-Accept packets.
> 
> Please add a sentence explaining the semantics in this usage.  For
> example, in the Access-Request I assume that this Attribute describes
> the protocol that the client is using for remote administration. 

Yes.
 
> What does it mean in an Access-Accept?

The same thing that any other service provisioning attribute means -- start
the described service for the user's connection.  Typically these things are
decided by the RADIUS Server based on the user's account profile information
and any relevant hint attributes.

> For example, what does the NAS do if the value in the Access-
> Accept is different from the protocol that is being used?  Does
> it disconnect?

Yes.  It would also disconnect if the provisioned service is not supported
in the NAS.

How about the following for clarifying text?

It is RECOMMENDED that the NAS include an appropriately valued
Framed-Management-Protocol attribute in Access-Request packet, indicating
the type of access being requested, when the user requests a form of remote
management via a framed management application protocol.  It is further
RECOMMENDED that the NAS include a Service-Type attribute with the value
Framed-Management (TBA) in the same Access-Request packet.  The RADIUS
Server MAY use these hint attributes in making its authorization decision.

The RADIUS Server MAY include a Framed-Management-Protocol attribute in an
Access-Accept packet that also includes a Service-Type attribute with a
value of Framed-Management, when the RADIUS Server chooses to enforce an
management access policy for the authenticated user, that dictates one form
of management access in preference to others.

When a NAS receives a Framed-Management-Protocol attribute in an
Access-Accept packet, it MUST deliver that specified form of management
access or disconnect the session.  If the NAS does not support the
provisioned management application-layer protocol, or the management access
protocol requested by the user does not match that of the
Framed-Management-Protocol attribute in the Access-Accept packet, the NAS
must treat the response packet as if it had been an Access-Reject.

> Section 8.2
> What packets can this attribute be included in?  Access-Request & 
> Access-Accept?

Yes.  Also Accounting-Request for session logging purposes.

> What are the semantics in each case?  For example, in an 
> Access-Request is this the level of protection that is being used?

Yes.  This will be communicated to the RADIUS Client from the respective
management application, to the extent that application is aware of the
protection level of its underlying transport.

> What if the value in an Access-Accept is different (e.g. higher)
> than that in use?  For example, if confidentiality & integrity is 
> being requested, but the session is protected with TLS and an 
> integrity-only ciphersuite?  Is the session dropped?

Yes.  Do we need clarifying text, such as I proposed for the
Framed-Management-Protocol attribute (see above)?

Such clarifying text might read as follows:

It is RECOMMENDED that the NAS include an appropriately valued
Management-Transport-Protection attribute in Access-Request packet,
indicating the level of transport protection for the management access being
requested, when that information is available to the RADIUS Client.  The
RADIUS Server MAY use this hint attribute in making its authorization
decision.

The RADIUS Server MAY include a Management-Transport-Protection attribute in
an Access-Accept packet that also includes a Service-Type attribute with a
value of Framed-Management, when the RADIUS Server chooses to enforce an
management access security policy for the authenticated user, that dictates
a minimum level of transport security.

When a NAS receives a Management-Transport-Protection attribute in an
Access-Accept packet, it MUST deliver the management access over a transport
with equal or better protection characteristics or disconnect the session.
If the NAS does not support protected management transport protocols, or the
level of protection available does not match that of the
Management-Transport-Protection attribute in the Access-Accept packet, the
NAS must treat the response packet as if it had been an Access-Reject.
 
>   o  Confidentiality-Protection: The management session requires
>      protection in a secure or protected transport, that is supported
>      by the management access protocol and implementation.  The secure
>      transport MUST provide Confidentiality Protection.
>
> Does this option really make sense?  When would you want Confidentiality
> but not integrity? Isn't this dangerous?

This was discussed at IETF-71 and the proposal was to remove the
Confidentiality (only) option.  I propose to do that in the -03 version.

> Section 9
> 
> The examples use the Transport-Protocol Attribute, which is not
> defined in this document any more.

Editorial cruft.  Will fix in -03.

>  Also, please include the value of NAS-Port-Type in the examples.

OK.

> Section 11
> 
> I'd recommend moving this to a sub-section under Security 
> Considerations.

Hmmm.  Much of this discussion has impact on security, on the other hand, I
think that Proxy Considerations is a separate topic that justifies treatment
in a separate section, for emphasis.  I don't have a strong opinion on this,
but my initial reaction is to suggest that we leave it in a separate
section.

> Section 13
> 
> This section needs to be rewritten to list the new attribute for which 
> numbers being requested, as well as the new value for Service-Type.

So, you're suggesting that I not expect IANA to search through the document
for all the (TBA) placeholders, but rather enumerate all the requests here?
OK, I can do that in version -03.

All other comments in Issue 256, not otherwise discussed here are accepted
and will appear in the -03 version.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 18:27:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6CdLSnrJCQNHmPUgsNpT8vgHLgf09K3ep9cIOaatS2Y=; b=uM1GO0MekFmzQkwkVcIhX9PV+wBvF+HLW8v/sRME5yI3X/1eunJFeZdnDA8OiJPuNh 4lngjfNiIByLiIAp+/dqGFVezK1EBiERCYjzVBVAAOoHWBQEt+n4ROds8ddRo9o9o82W QOb6AzIwpRcL0SHWDJrh3tOD/EQsvdV/A25K0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=iUXLtwhxVfkU9h63tcYDNEwa+9WenGgcs6bn0a6/QFrPJs5AJ48u9hN5s18MEvS5c6 iWPcFgqR+Wi+Ax9zpQ72C5DMeKU/Zt6SJmknQiyXfcgwoHDBVdmN9UTyYtnaUzbi6Sft lTd8U2c/S+AfSjTv7A5pvf4D5wZ+kLMGGNtjE=
Message-ID: <[e-mail]>
Date: Tue, 10 Jun 2008 14:26:55 -0400
From: "Greg Weber" <[e-mail]>
To: "David B. Nelson" <[e-mail]>
Subject: Re: RADEXT Issue 255 (NAS Management Authorization)
Cc: [e-mail], "David Harrington" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just
>> lump the non-secure and secure versions into Configuration-based, and
>> Polling-based names and so on?
>
> I don't think that this document is the right vehicle to define new
> nomenclature for existing management services and protocols.
>
> I'm open to devising some clarifying text here, but I think we need to keep
> the scope of semantics for this attribute narrow, i.e. limited to indication
> of the management application-layer protocol.

Slightly less diplomatically, RADEXT is having trouble tying its own
shoestrings.  We don't need to worry about the shoes of others...

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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 18:18:21 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'David Harrington'" <[e-mail]>
Subject: RADEXT Issue 255 (NAS Management Authorization)
Date: Tue, 10 Jun 2008 14:17:00 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQ==

> 8.1 (and elsewhere)
> Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP?

The attribute in question, Framed-Management-Protocol, is used to describe a
management *application-layer* protocol.  SNMP clearly qualifies.  An
integrated web server, providing management via web pages, also qualifies,
although a web server is by no means limited to management applications --
all sorts of applications can be implemented using a web services model.
When we get to options such as FTP, which means to describe provisioning of
management information by "file copy", the distinction is even less clear.
File copy operations are used for all sorts of things besides network device
management.

This attribute is not attempting to describe a transport protocol.  We had
one of those in a prior version and it was eliminated based on comments
received.  Attempting to provision the transport protocol was causing
confusion without adding any offsetting value.

The value (2) of the Framed-Management-Protocol means a web-services based
management interface.  Yes, it uses HTTP, but the meaning that is intended
here is restricted to a web server application for the purpose of device
management.

> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just
> lump the non-secure and secure versions into Configuration-based, and
> Polling-based names and so on?

I don't think that this document is the right vehicle to define new
nomenclature for existing management services and protocols.

I'm open to devising some clarifying text here, but I think we need to keep
the scope of semantics for this attribute narrow, i.e. limited to indication
of the management application-layer protocol.

> section 8.2
> "The same "No Protection" semantics are conveyed by omitting this 
> attribute from an Access-Accept packet."
> Why is this the default behavior? Wouldn't it be better to default 
> to full security if the attribute is not present?

I believe that would violate the RADEXT Charter restriction on maintaining
backwards compatibility / interoperability with existing RADIUS standards
and fielded implementations.  I propose to reject this comment.

> Section 8.3
> Paragraph 3 says what to do if one is received; and paragraph talks
> about receiving more than one. What if zero are received?

RADIUS clients and servers must always be prepared to *not* receive any
optional attribute in any message.  There can be no implicit semantics of a
"missing" attribute other than to "do nothing" as regards the semantics of
that particular attribute.  In the case of Management-Policy-Id, the absence
of an attribute means that the NAS applies no management access
control/filtering policy.  This basic to the operation of the RADIUS
protocol, and it is assumed that readers are familiar with that behavior.
Do you think it needs to be reiterated here?

Paragraph 3 says what to do if one is received; and paragraph talks
about receiving more than one. What if zero are received?

> Paragraph 3 says if "the policy rules are incorrectly
> formatted, the NAS MUST treat the packet as if it had been an
> Access-Reject."
>
> Doesn't this potentially override what the management protocol says
> should be done if the rules are incorrectly formatted?

If the underlying management protocol has default rules, in the absence of
any additional provisioning by RADIUS, then these would still apply.

> If the mgmt protocol defines an error condition for incorrectly 
> formatted rules, that error won't be sent because the session is 
> rejected, right?

Yes.  However, I don't think we ought to go down the path of inserting
RADIUS in the middle of a client-server (or peer-peer) applications layer
protocols, management or otherwise.  The standard RAIUS behavior (it has
always been so) is that if the client receives an attribute that it can
interpret, i.e. that it supports, and it cannot decipher or correctly act
upon the value of the attribute, it must "punt" the session, rather than
risk misunderstanding the intent of the system administrator and allowing
more service access than was originally desired.

This is almost always a case of misconfiguration, and it is assumed that
human intervention by the system administrator will be required to resolve
it.

> What happens if it is considered incorrect formatting to have an empty
> table of rules, but the operator is trying to gain mgmt access to set
> the policy rules into the table?  Would RADIUS even know whether the
> rules were incorrectly formatted?

The RADIUS client itself would likely not know, but another portion of the
NAS software that is responsible for making the rules take effect would very
likely know, and would be able to return an error code to the RADIUS client.
This is simply a case of making sure that the security configuration is
valid before you enable security checking.  One more case of "locking the
keys in the car" if you are not careful.  Make sure you have the key before
you push down the lock button.  :-)

I think we could add some sort if "Implementation Note" warning users of the
potential issue. I don't think we want to dilute the security by requiring
that the RADIUS client attempt to "second guess" configuration errors in
favor of granting [greater] access.

> section 8.4
> I don't understand why we need a special Management-Privilege-Level
> attribute. This should be able to specified as a named policy in the
> Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and
> "2" and "3". Implementations simply need to map between the policy
> name and their privilege-level policy implementation.

This attribute was added to support legacy access level mechanisms that are
integer-value based, without conflating them with the newer
text-string-valued, policy-named based mechanism.  In the "green fields"
case, i.e. in the absence of a fairly wide deployment of the legacy
mechanism, I would fully agree with you.  What you suggest *could* be made
to work.  I think it has greater risk because of its interaction with legacy
mechanisms.  I would propose to retain the separate attributes, unless there
is WG consensus to combine them.

> section 9:
> I have a concern about protocol versions. What if I want SSHv2
> because I don't think SSHv1 is adequate? Should I be able to make the
> distinction? or is that simply an operator-provisioning task to
> disallow SSHv1 to the device?

I would argue it ought to be the latter.  It is not always clear where to
draw the line as to how granular AAA-based provisioning ought to be.
AAA-based provisioning is not intended to supplant all operator provisioning
requirements.  I've been attempting to apply the "less is more" philosophy
in the absence of a clear use-case that dictates "more is more".  :-)

> Section 9:
> Example #5 mentions SNMPv3, but the attribute says only SNMP.

Ooops.  Editorial cruft.  Will fix in -03.

> Section 9:
> I would change the paragraph in example #5:
> OLD: Note that there is currently no standardized way of
> implementing this management policy mapping within SNMPv3. Such 
> mechanisms are implementation specific.
> NEW: "A standardized way of mapping from Management-Policy-ID to a
> particular access control policy in SNMP is under research."

OK.  Will fix in -03.

> Section 9:
> Example #6 talks about using the Secure Shell Transport Model,
> but most existing SNMP implementations do not support this yet. 
>The "transport model" approach supports a binding between the SSH
> authenticated identity and the SNMP database access controls. Some
> SNMP implementations support running SNMP (any version) over an
> SSH tunnel, but they provide no such binding. I think it is an 
> SNMP internal matter for SNMP access controls to say "they must 
> use transport model to get database access". So I would remove 
> the mention of the Secure Shell Transport Model from the example:
> OLD: 6. SNMP secure Transport Model access, using the Secure Shell
> Transport Model:
> NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH,
> to an undefined management access level:

OK.  Will fix in -03.

> Section 9:
> Example#8 doesn't mention which transport protocol should be 
> used to provide security services. Should it, or is it intentional
> to allow any transport protocol be used that can provide
> Confidentiality-Protection?

We've previously decided to not provision the specific transport protocol,
but rather to only provision the security properties of the protocol.  This
is another of those "less is more" arguments.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 17:55:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=T8NGMvD3jKyZWQnw4aCOD3Pbqag3gUZpyQ6VraBAN14=; b=QdRRmtjqnPSCxeRXtFpc22rOVQiSDe3PQRykZsLxMOAS1i8a42Nem2KbX0+SBknEQ8 RnkpJja7E1N54f1sdk+F30F10KO/XiFcDYzqvYt6x4ysUnjqQt7V8oaiILdrmgFmjVXi 9UuUcqUyW0qw0dkRwJ4Ws662ZV/SajLBXicxs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=sL39U70UV/u+0gzdnSHcwfV+9SO3bnjBbNBiU5shA/UAqWrigQ13nHqyNL9lhQi1PT ulYWdMHFB+d+Rrdce2Jm1ZaCplQIGhvYLd/3VAhYlH4u9A7JzyIuK5KqY5XABg3QCsC/ pO47JsrpKnGhrU8p99MVW7oOkcZYk2h+C8NQs=
Message-ID: <[e-mail]>
Date: Tue, 10 Jun 2008 13:54:17 -0400
From: "Greg Weber" <[e-mail]>
To: [e-mail]
Subject: [Issue 255]: NAS mgmt author
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have a comment on this subissue from #255 on RADIUS author.
This is from the issue list:

"section 8.4
I don't understand why we need a special Management-Privilege-Level
attribute. This should be able to specified as a named policy in the
Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and
"2" and "3". Implementations simply need to map between the policy
name and their privilege-level policy implementation.

Different implementations might handle priivilege levels differently -
some might use integers internally, others might use a different range
of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply
a mapping exercise. This is a great opportunity to suggest standard
names for privilege levels, and then vendors can map those standard
names to the internal routines. If vendors provide an API, operators
could name the policies as they wanted and map them to the vendors'
APIs for invoking different privilege levels."

--

Actually, I think this is likely to lead to problems.  Conceptually, i agree,
but this privilege level concept is quite entrenched.  And having a language-
specific 'textization' of this is likely to lead to more
incompatibility going fwd.
I also don't think RADEXT is the correct place to "suggest standard
names for privilege levels".

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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 17:08:47 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT Issue 254 (NAS Management Authorization)
Date: Tue, 10 Jun 2008 13:07:54 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <C8DD9C3D4003471C9137A429F6EBD11D@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjLHIWZ1UmIv2vIT1GAl0dTSfdXqg==

All Issue 254 comments are accepted and will appear in the -03 version.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 17:07:48 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT Issue 253 (NAS management Authorization)
Date: Tue, 10 Jun 2008 13:06:13 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <D38514969B664AC2BBE139CD88BFC955@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjLHElvSttDqdaBT++kmr6A4WroWA==

> throughout:
> "Note that" is usually unnecessary. Don't we want readers to note
> everything in the document, or we wouldn't have said it?

Accepted, except for the occurrence within the standard boilerplate text.
:-)

> section 14:
> this mentions accounting, but accounting is explicitly out of scope
> for this document.

I propose to reject this comment.  Nothing in this draft says that
accounting is out of scope.  It is common practice to allow service
provisioning attributes to appear in Accounting-Request messages for the
purpose of session logging and auditing.  The commenter may be thinking of
the RADIUS Usage for SNMP Transport Models document, in which accounting is
out of scope.

All other Issue 253 comments are accepted, and will be reflected in the -03
version.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 10 Jun 2008 05:31:09 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Jun 2008 07:29:20 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: Status Server Document
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

|     This is a request for review of the Status Server document for the
|     purposes of considering it for adoption as a RADEXT WG work item.

I'm in favour of adoption.

Stefan Winter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIThEv+jm90f8eFWYRAorWAJ48jk1VlAvwqMuFeehiij2xAdg0EQCfeezv
vIUvmGv/tsmwEI4102vml8Q=
=viA9
-----END PGP SIGNATURE-----

--
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, 05 Jun 2008 12:15:42 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Request for Review: RADSEC Specification
Date: Thu, 5 Jun 2008 08:14:17 -0400
Message-ID: <042501c8c705$aed779a0$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SAAXjdw4AAIfU1w

Glen Zorn writes...

> Hmm, yes, a policy that has worked wonders in speeding up progress...

RADEXT has been slow in making progress at times, but I think this
particular policy has no direct bearing on that.  It has neither speeded up
nor slowed down the rate of progress.  The root cause of the "rate of
progress" issue lies elsewhere.

> OK, so I thought that the lengthy discussion of whether or not to add
> RadSec as a work item was about the protocol as described in the existing
> draft; we even talked about some of the changes necessary to this 
> document.  Am I to understand that those debates were actually about 
> adopting some theoretical concept of RADIUSoTLS/TCP as a work item?

There is a procedural separation of concerns between adding a work item to a
WG charter and adopting a specific individual draft as the WG's chosen
vehicle to complete that work item.  As a WG chair yourself, I suspect that
you understand that distinction.  I'm not saying that I expect a competing
document to be offered up.  I'm simply answering your process question.
There are separate process steps;  we are following them.



--
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, 05 Jun 2008 08:11:11 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Request for Review: RADSEC Specification
Date: Thu, 5 Jun 2008 15:09:17 +0700
Message-ID: <009801c8c6e3$7b2187d0$71649770$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SAAXjdw4A==
Content-Language: en-us

David B. Nelson [mailto://[e-mail]] writes:

> Glen Zorn writes...
> 
> > I'm a little confused: since the recently approved charter lists
> > RadSec as a work item (even calling it out by name: '.specifications
> > for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'),
> > I'm not sure what the point of this is or what the alternatives
> > might be.
> 
> The question is whether the subject individual draft is sufficiently
> complete and well written to become a WG work item.  As you may recall,
> we
> expect WG -00 drafts to be reasonably mature.

Hmm, yes, a policy that has worked wonders in speeding up progress...

> 
> That alternative is that it could stay as an individual draft for more
> polishing, or some alternative draft fulfilling the same WG charter
> milestone could be presented for consideration.

OK, so I thought that the lengthy discussion of whether or not to add RadSec
as a work item was about the protocol as described in the existing draft; we
even talked about some of the changes necessary to this document.  Am I to
understand that those debates were actually about adopting some theoretical
concept of RADIUSoTLS/TCP as a work item?

...



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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 11:10:06 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Request for Review: RADSEC Specification
Date: Tue, 3 Jun 2008 07:08:35 -0400
Message-ID: <014e01c8c56a$2bc93130$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SA=

Glen Zorn writes...

> I'm a little confused: since the recently approved charter lists 
> RadSec as a work item (even calling it out by name: '.specifications
> for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), 
> I'm not sure what the point of this is or what the alternatives 
> might be.

The question is whether the subject individual draft is sufficiently
complete and well written to become a WG work item.  As you may recall, we
expect WG -00 drafts to be reasonably mature.

That alternative is that it could stay as an individual draft for more
polishing, or some alternative draft fulfilling the same WG charter
milestone could be presented for consideration.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 09:41:30 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, <[e-mail]>
Subject: RE: Request for Review: RADSEC Specification
Date: Tue, 3 Jun 2008 16:37:53 +0700
Message-ID: <001e01c8c55d$870fd010$952f7030$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C8C598.336EA810"
thread-index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqg
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_001F_01C8C598.336EA810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba  [mailto:[e-mail]] writes:

 

This is a request for review of the RADSEC specification for the purposes of
considering it for adoption as a RADEXT WG work item. 

 

I'm a little confused: since the recently approved charter lists RadSec as a
work item (even calling it out by name: '.specifications for
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), I'm not sure
what the point of this is or what the alternatives might be. 


 
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt
 
Please respond to the mailing list, indicating whether your are IN FAVOR or
AGAINST adoption of the document as a RADEXT WG work item.  If you have
comments on the document, please post these to the mailing list as well, in
the format described in the RADEXT WG Issues page: 
http://www.drizzle.com/~aboba/RADEXT/
 
This request for review will conclude on June 16, 2008. 


------=_NextPart_000_001F_01C8C598.336EA810
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Bernard
Aboba &nbsp;[mailto:[e-mail]] =
writes:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><o:p>&nbsp;<=
/o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>This
is a request for review of the RADSEC&nbsp;specification for the =
purposes of
considering it for adoption as a RADEXT WG work item. <span =
style=3D'color:#1F497D'><o:p></o:p></span></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:
5.0pt;margin-left:0in'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:
5.0pt;margin-left:0in'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#7030A0'>I'm a little confused: since the recently approved =
charter lists
RadSec as a work item (even calling it out by name: =
'&#8230;specifications for<br>
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), I'm not =
sure what
the point of this is or what the alternatives might be&#8230; =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
&nbsp;<br>
The document is available for inspection here:<br>
<span style=3D'color:#0068CF'><a
href=3D"http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt"
target=3D"_blank">http://www.ietf.org/internet-drafts/draft-winter-radsec=
-01.txt</a></span><br>
&nbsp;<br>
Please respond to the mailing list, indicating whether your are IN FAVOR =
or
AGAINST adoption of the document as a RADEXT WG work item.&nbsp; If you =
have
comments on the document, please post these to the mailing list as well, =
in the
format described in the RADEXT WG Issues page: <br>
<a href=3D"http://www.drizzle.com/~aboba/RADEXT/" =
target=3D"_blank">http://www.drizzle.com/~aboba/RADEXT/</a><br>
&nbsp;<br>
This request for review will conclude on June 16, 2008. =
<o:p></o:p></span></p>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_001F_01C8C598.336EA810--



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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 09:30:08 +0000
Message-ID: <[e-mail]>
Date: Tue, 03 Jun 2008 11:23:51 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Request for Review: RADSEC Specification
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>     This is a request for review of the RADSEC specification for the
>     purposes of considering it for adoption as a RADEXT WG work item.

  I am in favor of adopting it as a WG work item.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 06:33:27 +0000
Message-ID: <[e-mail]>
Date: Tue, 03 Jun 2008 08:31:15 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Request for Review: RADSEC Specification
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

in favor of taking it as a start. Parts of it will need to be taken out
to form the basis of the "Reliable Transport Profile for RADIUS".

|     This is a request for review of the RADSEC specification for the
|     purposes of considering it for adoption as a RADEXT WG work item.
|
|     The document is available for inspection here:
|     http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt
|
<http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-02.txt>
|
|     Please respond to the mailing list, indicating whether your are IN
|     FAVOR or AGAINST adoption of the document as a RADEXT WG work item.
|     If you have comments on the document, please post these to the
|     mailing list as well, in the format described in the RADEXT WG
|     Issues page:
|     http://www.drizzle.com/~aboba/RADEXT/
|
|     This request for review will conclude on June 16, 2008.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIROUz+jm90f8eFWYRAmvgAJ0bYOrW0t2gdn3W0bL7HGi9mIof0QCeI5Vi
KRmrIapopqbXZ53mP3On20M=
=rGqv
-----END PGP SIGNATURE-----

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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 04:52:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wOuuJiKMWrLuug6CHHHFjxumcfoqKA0U2rYXUazNMZU=; b=mPQx4Y7VGFQy9z1nrHWnbFTvIvZA1ijjBQLr99xU/Tugv9mnE5IDfUGbopy3W0LT2uMm4nXvynCbTCm4rEvkvCE/zz+jj3Pwjxvko/5pc+MbOiD7r9W+PSz3Ouw8BomEWnoHz3nF5ss9/cMO+cNpBQDVSZ93oCOuElV8g0EbGxY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a9DJmnQtX2pGU2JPvmL1vDu+CELeeecNwa/Y2RaC4zgqasJjSzjLigaqPOulXxTqL9rCQ02JwB3Yx+cJEoywCgbGAoSzCrFBJRcVU0Mra7QHCyshQ7sqfBpho301vEBQzjNP8P20XUw8Du1wpM8WP5cJQpFuGg3wL6bXCjQqDRQ=
Message-ID: <[e-mail]>
Date: Tue, 3 Jun 2008 01:50:51 -0300
From: "Claudio Lapidus" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>
Subject: Re: Request for Review: RADSEC Specification
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In favor.
--


On Mon, Jun 2, 2008 at 11:35 PM, Bernard Aboba
<[e-mail]> wrote:
>
> This is a request for review of the RADSEC specification for the purposes of considering it for adoption as a RADEXT WG work item.
>
> The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt
>
> Please respond to the mailing list, indicating whether your are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item.  If you have comments on the document, please post these to the mailing list as well, in the format described in the RADEXT WG Issues page:
> http://www.drizzle.com/~aboba/RADEXT/
>
> This request for review will conclude on June 16, 2008.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 03:56:40 +0000
From: Mike McCauley <[e-mail]>
To: Bernard Aboba <[e-mail]>
Subject: Re: Request for Review: RADSEC Specification
Date: Tue, 3 Jun 2008 13:54:50 +1000
User-Agent: KMail/1.8.2
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>

IN FAVOR

On Tuesday 03 June 2008 12:35, Bernard Aboba wrote:
> This is a request for review of the RADSEC specification for the purposes
> of considering it for adoption as a RADEXT WG work item.  The document is
> available for inspection
> here:http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt Please
> respond to the mailing list, indicating whether your are IN FAVOR or
> AGAINST adoption of the document as a RADEXT WG work item.  If you have
> comments on the document, please post these to the mailing list as well, in
> the format described in the RADEXT WG Issues page:
> http://www.drizzle.com/~aboba/RADEXT/ This request for review will conclude
> on June 16, 2008.

-- 
Mike McCauley                               [e-mail]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone [phone]                       Fax   [phone]

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare 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: Tue, 03 Jun 2008 02:36:58 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_cadb739c-bcc2-49b8-b525-dea31c397de5_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Request for Review: RADSEC Specification
Date: Mon, 2 Jun 2008 19:35:44 -0700
MIME-Version: 1.0

--_cadb739c-bcc2-49b8-b525-dea31c397de5_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a request for review of the RADSEC specification for the purposes o=
f considering it for adoption as a RADEXT WG work item.  The document is av=
ailable for inspection here:http://www.ietf.org/internet-drafts/draft-winte=
r-radsec-01.txt Please respond to the mailing list, indicating whether your=
 are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item.=
  If you have comments on the document, please post these to the mailing li=
st as well, in the format described in the RADEXT WG Issues page: http://ww=
w.drizzle.com/~aboba/RADEXT/ This request for review will conclude on June =
16, 2008. =

--_cadb739c-bcc2-49b8-b525-dea31c397de5_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
<BLOCKQUOTE>This is a request for review of the RADSEC&nbsp;specification f=
or the purposes of considering it for adoption as a RADEXT WG work item. <B=
R>&nbsp;<BR>The document is available for inspection here:<BR><FONT color=
=3D#0068cf><A href=3D"http://www.ietf.org/internet-drafts/draft-winter-rads=
ec-01.txt" target=3D_blank>http://www.ietf.org/internet-drafts/draft-winter=
-radsec-01.txt</A></FONT><A href=3D"http://www.ietf.org/internet-drafts/dra=
ft-dekok-radius-status-server-02.txt" target=3D_blank></A><BR>&nbsp;<BR>Ple=
ase respond to the mailing list, indicating whether your are IN FAVOR or AG=
AINST adoption of the document as a RADEXT WG work item.&nbsp; If you have =
comments on the document, please post these to the mailing list as well, in=
 the format described in the RADEXT WG Issues page: <BR><A href=3D"http://w=
ww.drizzle.com/~aboba/RADEXT/" target=3D_blank>http://www.drizzle.com/~abob=
a/RADEXT/</A><BR>&nbsp;<BR>This request for review will conclude on June 16=
, 2008. <BR></BLOCKQUOTE></body>
</html>=

--_cadb739c-bcc2-49b8-b525-dea31c397de5_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 02:36:20 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Request for Review: Status Server Document
Date: Mon, 2 Jun 2008 19:35:04 -0700
MIME-Version: 1.0

--_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a request for review of the Status Server document for the purposes=
 of considering it for adoption as a RADEXT WG work item.  The document is =
available for inspection here:http://www.ietf.org/internet-drafts/draft-dek=
ok-radius-status-server-02.txt Please respond to the mailing list, indicati=
ng whether your are IN FAVOR or AGAINST adoption of the document as a RADEX=
T WG work item.  If you have comments on the document, please post these to=
 the mailing list as well, in the format described in the RADEXT WG Issues =
page: http://www.drizzle.com/~aboba/RADEXT/ This request for review will co=
nclude on June 16, 2008. =

--_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
<BLOCKQUOTE>This is a request for review of the Status Server document for =
the purposes of considering it for adoption as a RADEXT WG work item. <BR>&=
nbsp;<BR>The document is available for inspection here:<BR><A href=3D"http:=
//www.ietf.org/internet-drafts/draft-dekok-radius-status-server-02.txt" tar=
get=3D_blank>http://www.ietf.org/internet-drafts/draft-dekok-radius-status-=
server-02.txt</A><BR>&nbsp;<BR>Please respond to the mailing list, indicati=
ng whether your are IN FAVOR or AGAINST adoption of the document as a RADEX=
T WG work item.&nbsp; If you have comments on the document, please post the=
se to the mailing list as well, in the format described in the RADEXT WG Is=
sues page: <BR><A href=3D"http://www.drizzle.com/~aboba/RADEXT/" target=3D_=
blank>http://www.drizzle.com/~aboba/RADEXT/</A><BR>&nbsp;<BR>This request f=
or review will conclude on June 16, 2008. <BR></BLOCKQUOTE></body>
</html>=

--_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 02:27:55 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Approval of revised RADEXT WG Charter
Date: Mon, 2 Jun 2008 19:26:38 -0700
MIME-Version: 1.0

--_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The updated RADEXT WG charter has been approved by the IESG, and is now pos=
ted on the WG web page:
http://www.ietf.org/html.charters/radext-charter.html
=20
 =

--_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
The updated RADEXT WG charter has been approved by the IESG, and is now pos=
ted on the WG web page:<BR>
<A href=3D"http://www.ietf.org/html.charters/radext-charter.html">http://ww=
w.ietf.org/html.charters/radext-charter.html</A><BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 03 Jun 2008 02:25:15 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Consensus Call Summary:  Changes to Extended Attributes Document
Date: Mon, 2 Jun 2008 19:22:45 -0700
MIME-Version: 1.0

--_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On Wednesday, May 7, a Consensus call was issued to the WG mailing list, in=
 order to confirm acceptance of the consensus call done at IETF 71, with re=
spect to the changes made in the Extended Attributes Document version -01.=
=20
=20
That Consensus call has now concluded.  Based on the minimal mailing list r=
esponse (1 response, in favor of the IETF 71 consensus), the consensus take=
n at IETF 71 is judged to be AFFIRMED. =20
=20
That is:=20
=20
1. The change to the Ext-Type field (2 octets rather than 1) is APPROVED. 2=
. The change to the RADIUS Extended Attribute format in (applied to existin=
g standard RADIUS attributes,  not just extended ones) is REJECTED.
=20
Instructions to the Editor:  Please submit a new document reflecting the RA=
DEXT WG Consensus ASAP.=20


From: [e-mail]: [e-mail]: Consensus=
 call: Changes to Extended Attributes documentDate: Wed, 7 May 2008 18:48:0=
5 -0700At IETF 71, a consensus call was taken regarding changes made in the=
 -01 version of theExtended Attributes document, as compared with -00.   Th=
e changes made were as follows:1. Ext-Type field was changed to 2 octets ra=
ther than 1. 2. The RADIUS Extended Attribute format in -01 applied to exis=
ting standard RADIUS attributes,  not just extended ones. In the RADEXT WG =
meeting at IETF 71, the consensus call was as follows: Change #1 was ADOPTE=
D by a margin of 7-1. Change #2 was REJECTED by a margin of 6-2.  We are no=
w issuing a Consensus Call on the RADEXT WG mailing list in order to verify=
 the consensus of the room at IETF 71.  This Consensus Call will last until=
  May 21, 2008.  Please send email to the list, explicitly stating your pos=
ition on changes #1 and #2, indicating whether you desire to ADOPT or REJEC=
T each change.  For reference, -00 is available here:http://www.waterspring=
s.org/pub/id/draft-ietf-radext-extended-attributes-00.txt -01 is available =
here:http://www.waterspring.org/pub/id/draft-ietf-radext-extended-attribute=
s-01.txt  ______________________



 EMAILING FOR THE GREATER GOOD=

--_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
On Wednesday, May 7, a Consensus call was issued to the WG mailing list, in=
 order to confirm acceptance of the consensus call done at IETF 71, with re=
spect to the changes made&nbsp;in the Extended Attributes Document version =
-01. <BR>
&nbsp;<BR>
That Consensus call has now concluded.&nbsp; Based on the minimal mailing l=
ist response (1 response, in favor of the IETF 71 consensus), the consensus=
 taken at IETF 71 is judged to be AFFIRMED.&nbsp; <BR>
&nbsp;<BR>
That is: <BR>
&nbsp;<BR>
1. The change to the Ext-Type field (2 octets rather than 1) is APPROVED.&n=
bsp;<BR>2. The change to the RADIUS Extended Attribute format in (applied t=
o existing standard RADIUS attributes, &nbsp;not just extended ones) is REJ=
ECTED.<BR>
&nbsp;<BR>
Instructions to the Editor:&nbsp; Please submit a new document reflecting t=
he RADEXT WG Consensus ASAP. <BR><BR>
<BLOCKQUOTE>
<HR>
From: [e-mail]<BR>To: [e-mail]<BR>Subject: C=
onsensus call: Changes to Extended Attributes document<BR>Date: Wed, 7 May =
2008 18:48:05 -0700<BR><BR>At IETF 71, a consensus call was taken regarding=
 changes made in the -01 version of the<BR>Extended Attributes document, as=
 compared with -00.&nbsp; <BR>&nbsp;<BR>The changes made were as follows:<B=
R>1. Ext-Type field was changed to 2 octets rather than 1. <BR>2. The RADIU=
S Extended Attribute format in -01 applied to existing standard RADIUS attr=
ibutes, &nbsp;not just extended ones.<BR>&nbsp;<BR>In the RADEXT WG meeting=
 at IETF 71, the consensus call was as follows:<BR>&nbsp;<BR>Change #1 was =
ADOPTED by a margin of 7-1. <BR>Change #2 was REJECTED by a margin of 6-2. =
<BR>&nbsp;<BR>We are now issuing a Consensus Call on the RADEXT WG mailing =
list in order to verify the consensus of the room at IETF 71. <BR>&nbsp;<BR=
>This Consensus Call will last until&nbsp; May 21, 2008.&nbsp; Please send =
email to the list, explicitly stating your position on changes #1 and #2, i=
ndicating whether you desire to ADOPT or REJECT each change. <BR>&nbsp;<BR>=
For reference, -00 is available here:<BR><A href=3D"http://www.watersprings=
.org/pub/id/draft-ietf-radext-extended-attributes-00.txt" target=3D_blank r=
el=3Dnofollow><U><FONT color=3D#0066cc>http://www.watersprings.org/pub/id/d=
raft-ietf-radext-extended-attributes-00.txt</FONT></U></A><BR>&nbsp;<BR>-01=
 is available here:<BR><A href=3D"http://www.waterspring.org/pub/id/draft-i=
etf-radext-extended-attributes-01.txt" target=3D_blank rel=3Dnofollow><U><F=
ONT color=3D#0066cc>http://www.waterspring.org/pub/id/draft-ietf-radext-ext=
ended-attributes-01.txt</FONT></U></A><BR><BR>&nbsp;<BR>&nbsp;<BR><BR><BR>_=
_____________________<BR>
<TABLE style=3D"FONT-SIZE: 9pt; COLOR: #0099cc; FONT-FAMILY: 'Segoe UI',Tah=
oma,san-serif; HEIGHT: 24px">
<TBODY>
<TR>
<TD><A style=3D"FONT-WEIGHT: bold; COLOR: #339966; TEXT-DECORATION: none" h=
ref=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood"=
 target=3D_blank><IMG style=3D"BORDER-TOP-STYLE: none; BORDER-RIGHT-STYLE: =
none; BORDER-LEFT-STYLE: none; BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=
=3D"http://gfx1.hotmail.com/mail/w2/ltr/i_charity.gif"></A> EMAILING FOR TH=
E GREATER GOOD</TD></TR></TBODY></TABLE></BLOCKQUOTE></body>
</html>=

--_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_--

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