RE: I-D Action:draft-zorn-radius-pkmv1-03.txt

["Dave Nelson" <[e-mail]>]

Alfred Hoenes writes...

> RADIUS was not designed for that kind and degree of extensibility:
>  o  very limited message size, which was ...
>  o  adjusted for, and coupled with, unreliable UDP transport;
>  o  hence a very limited namespace for attributes was good enough;
>  o  poor security.

I think that accurately summarizes the challenges of "classic" RADIUS.

> I already have been beaten in the past for asking questions like:
>  -  do we really need RADIUS Extended Attributes ?

Well, in order to support the use of RADIUS in certain application areas
that developers want to pursue, the answer is apparently yes.  Additionally,
this mechanism addresses the potential exhaustion of the standard RADIUS
attribute ID number-space, which only includes values 1 - 192.

> -  do we really need new transports for RADIUS, RADSEC, etc. ?

Need?  Well, I think that for specialized uses, i.e. large aggregation-proxy
deployments, there is a case to be made.

> -  do we really need to maintain in the IETF
>    a legacy AAA protocol side by side with its successor ?

We used to not think so.  Time has somewhat changed that perception.  RADIUS
continues to be a popular vehicle for implementing AAA solutions.  I have
heard various reasons for this -- none of which are verified, simply
reported as "heard on the street":

-- RADIUS is simple; Diameter is complicated.

-- RADIUS is easy to extend (since there are very few formal extension
rules, almost anything is considered fair game).

-- High-quality open source implementations of RADIUS are freely available.

-- Diameter lacks similar open source support.

-- Diameter has some IPR statements filed against its RFCs.

-- RADIUS is preferred by enterprise and academic market segments.

-- Diameter is preferred by carrier market segments.



--
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, 31 Dec 2008 23:25:23 +0000
From: "Dave Nelson" <[e-mail]>
To: =?iso-8859-1?Q?'Alfred_H=CEnes'?= <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Wed, 31 Dec 2008 18:25:01 -0500
Message-ID: <739418DB05CD43BF92D411E650C89347@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Thread-Index: AclqsuN7WEBC3aHuRUK9qAhFdia7gAA6kNwg

Alfred Hoenes writes...

> RADIUS was not designed for that kind and degree of extensibility:
>  o  very limited message size, which was ...
>  o  adjusted for, and coupled with, unreliable UDP transport;
>  o  hence a very limited namespace for attributes was good enough;
>  o  poor security.

I think that accurately summarizes the challenges of "classic" RADIUS.

> I already have been beaten in the past for asking questions like:
>  -  do we really need RADIUS Extended Attributes ?

Well, in order to support the use of RADIUS in certain application areas
that developers want to pursue, the answer is apparently yes.  Additionally,
this mechanism addresses the potential exhaustion of the standard RADIUS
attribute ID number-space, which only includes values 1 - 192.

> -  do we really need new transports for RADIUS, RADSEC, etc. ?

Need?  Well, I think that for specialized uses, i.e. large aggregation-proxy
deployments, there is a case to be made.

> -  do we really need to maintain in the IETF
>    a legacy AAA protocol side by side with its successor ?

We used to not think so.  Time has somewhat changed that perception.  RADIUS
continues to be a popular vehicle for implementing AAA solutions.  I have
heard various reasons for this -- none of which are verified, simply
reported as "heard on the street":

-- RADIUS is simple; Diameter is complicated.

-- RADIUS is easy to extend (since there are very few formal extension
rules, almost anything is considered fair game).

-- High-quality open source implementations of RADIUS are freely available.

-- Diameter lacks similar open source support.

-- Diameter has some IPR statements filed against its RFCs.

-- RADIUS is preferred by enterprise and academic market segments.

-- Diameter is preferred by carrier market segments.



--
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, 31 Dec 2008 22:51:05 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Wed, 31 Dec 2008 17:50:01 -0500
Message-ID: <6C5FAF4A69244B05A8956B5FFCC9A454@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0AAEgOkwACw2kYAAz8IyIA==

Hannes Tschofenig writes...

> To give you an example: Some time back when RFC 4675 was written it was
> state-of-the-art to define an attribute as:
>
> User-Priority-Table
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |  Length       |          String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                    String
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    String            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>
>
> Where 'String' represented a customing encoding.

OK, let's examine this case a bit further.  The string value is composed as
follows:

      The String field is 8 octets in length and includes a table that
      maps the incoming priority (if it is set -- the default is 0) into
      one of eight regenerated priorities.  The first octet maps to
      incoming priority 0, the second octet to incoming priority 1, etc.

That is to say, it is an octet array -- a singly dimensioned array of
one-octet values.  That seems to me to be the very definition of the base
RADIUS data type "String".  I see no issue here.

> Today, the encoding of RFC 4675 might quite likely be different and 
> there is still a lot of possibility to argue around why this is still
> a good encoding.

I think you need to use a more complex example to illustrate your point.  An
octet array is a base data type.  To stretch the capabilities of "classic"
RADIUS, you need to attempt to encode the equivalent of C-language
structures, arrays of structures, structures of arrays, or structures of
structures.

> Whether the AAA server had to be updated in order to provide additional
> parsing capability depends a lot on the procedure how some of these
> attributes (and the values in them) get introduced into the system in
> the first place.

Well, that sounds like a user interface discussion, and thus out of scope
for RADIUS attribute design.  In the example you have given, the
User-Priority-Table can be treated by the AAA server as a fixed length
string of 8 octets.  Parsing may be required to enter the values into the
local database, but it's not required during authentication request
processing.

> In some systems they might be statically provisioned into a
> database and just retrieved without any additional logic...

Right.

>... and in other systems they would be dynamically generated and there
> might be some logic behind all this stuff. 

Perhaps.  What you are suggesting is that the user interface (UI) of the AAA
server might be replaced or supplemented by an application programming
interface (API).  Sure.  But that doesn't make the needs of the API a matter
of concern for the RADIUS on-the-wire message format.  That's all we
typically standardize, right?  The on-the-wire message format.

I think we need to apply a little judicious software architecture here.
While all sorts of auxiliary policy engines, data base interfaces, proxy
mechanisms, and other added value applications might be utilized by an AAA
server in "fetching" the values to populate attributes (AVPs), that doesn't
mean that those elements are part of the AAA server.  They may be packaged
as one deliverable for engineering or marketing reasons, but architecturally
they are logically separate entities.  If we always attempted to accommodate
complex systems, composed of multiple cooperating components, every time we
designed any component-level on-the-wire protocol in the IETF, we'd never
get anything accomplished.  I think it's a mistake to attempt to do that
here.

Now, there are other reasons that developers want to use complex attributes,
which don't hinge on system integration issues.  There are data objects that
a server may want to provision in a NAS that are inherently multi-part.  One
classic example is cryptographic keys, which often have a cipher-suite name,
a key name, a lifetime, and a scope that need to be attached to each key.
In that example there is no way to get around the need for structured data.
The question is how to achieve the structuring.

Is the existing tagging mechanism of the Extend Attribute draft sufficient?
I think the answer is yes, unless you want to have multiple keys that are
somehow associated with other attributes in the message (which would require
two distinct tag fields).  The question the RADEXT WG has tried to grapple
with is how complicated do we need to get?  What's the simplest attribute
encoding design that covers 80% of the likely use cases?  I, for one, am
willing to relegate the remaining 20% of use cases to Diameter-only
solutions. :-)  YMMV.

> Still, there is this tendency to label custom encoding (like the one
> from above) as really bad (by calling it "interoperability and deployment
> issues" or see the discussion in Section 2.1.4 of draft-ietf-radext-
> design-05.txt regarding "Complex Attributes and Security").

IMHO, the reason that these encodings are "bad" is two fold: (1) they do not
support the needs of data dictionary driven server implementations, and (2)
the technique for encoding them is ad-hoc (based on the personal design
choices of developers), which precludes any single set enhancements to data
dictionary driven server implementations which might allow them to deal with
a broad class of such attributes.



--
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, 31 Dec 2008 00:16:15 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f3d02cac-9e47-451c-b6af-146e5a7e9f24_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 16:15:41 -0800
MIME-Version: 1.0

--_f3d02cac-9e47-451c-b6af-146e5a7e9f24_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Yes=2C but what does that mean?  Designated Expert?  AAA Doctors?  Certai=
nly
> not IETF Last Call.

Why not?  RFC 3580 went through IETF last call=2C when it was included as
an Appendix in IEEE 802.1X-2004.=20

> > Also=2C as David notes=2C the document can be read as suggesting IETF r=
eview
> > of all SDO RADIUS attribute documents.
>=20
> What is the current practice with MIB Modules?  Are MIB Doctors assigned =
to
> assist non-IETF SDOs with authoring/reviewing their MIB Modules?  I bet D=
an
> Romascanu can enlighten us here.

RFC 4663 discusses this.  The short answer I believe is "yes".=20

--_f3d02cac-9e47-451c-b6af-146e5a7e9f24_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B Yes=2C but what does that mean?  Designated Expert?  AAA Doctors?  C=
ertainly<br>&gt=3B not IETF Last Call.<br><br>Why not?&nbsp=3B RFC 3580 wen=
t through IETF last call=2C when it was included as<br>an Appendix in IEEE =
802.1X-2004. <br><br>&gt=3B &gt=3B Also=2C as David notes=2C the document c=
an be read as suggesting IETF review<br>&gt=3B &gt=3B of all SDO RADIUS att=
ribute documents.<br>&gt=3B <br>&gt=3B What is the current practice with MI=
B Modules?  Are MIB Doctors assigned to<br>&gt=3B assist non-IETF SDOs with=
 authoring/reviewing their MIB Modules?  I bet Dan<br>&gt=3B Romascanu can =
enlighten us here.<br><br>RFC 4663 discusses this.&nbsp=3B The short answer=
 I believe is "yes". <br></body>
</html>=

--_f3d02cac-9e47-451c-b6af-146e5a7e9f24_--

--
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, 30 Dec 2008 23:40:30 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 18:39:44 -0500
Message-ID: <7BA264D0F2F24F0EAA818D94277DA046@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Aclqytn96y/F4oHmSoee0/MAe60VQgADH8hw

Bernard Aboba writes...

>=A0Right now, this section seems to suggest that SDO specifications =
utilizing
> existing RADIUS standard data types can avail themselves of IETF =
review.

Yes, but what does that mean?  Designated Expert?  AAA Doctors?  =
Certainly
not IETF Last Call.

> Also, as David notes, the document can be read as suggesting IETF =
review
> of all SDO RADIUS attribute documents.

What is the current practice with MIB Modules?  Are MIB Doctors assigned =
to
assist non-IETF SDOs with authoring/reviewing their MIB Modules?  I bet =
Dan
Romascanu can enlighten us here.



--
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, 30 Dec 2008 22:06:42 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_05b410fd-c509-4915-a81a-03f65da12539_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, "David B. Nelson" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 14:06:21 -0800
MIME-Version: 1.0

--_05b410fd-c509-4915-a81a-03f65da12539_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   It is intended to encourage SDO specifications that re-use existing
> data types.  These specifications should *not* need IETF review.
>=20
>   Specifications that are SDO specific=2C and do *not* re-use existing
> types are SDO specific=2C and do not need IETF review.
>=20
>   Much of this is already in the document.  What can we do to clarify
> the text to avoid repeated questions?

I'd suggest that a revision of Section 1.1 is needed to clarify this.  Righ=
t now=2C
this section seems to suggest that SDO specifications utilizing existing
RADIUS standard data types can avail themselves of IETF review.  Also=2C
as David notes=2C the document can be read as suggesting IETF review
of all SDO RADIUS attribute documents. =20
=20
>   The most I would do is to provide horrific examples of what *not* to
> do.  i.e. putting arbitrary text strings into the "data" portion of a
> VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)

Describing why this is a bad idea would probably be useful.=20

--_05b410fd-c509-4915-a81a-03f65da12539_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   It is intended to encourage SDO specifications that re-use existin=
g<br>&gt=3B data types.  These specifications should *not* need IETF review=
.<br>&gt=3B <br>&gt=3B   Specifications that are SDO specific=2C and do *no=
t* re-use existing<br>&gt=3B types are SDO specific=2C and do not need IETF=
 review.<br>&gt=3B <br>&gt=3B   Much of this is already in the document.  W=
hat can we do to clarify<br>&gt=3B the text to avoid repeated questions?<br=
><br>I'd suggest that a revision of Section 1.1 is needed to clarify this.&=
nbsp=3B Right now=2C<br>this section seems to suggest that SDO specificatio=
ns utilizing existing<br>RADIUS standard data types can avail themselves of=
 IETF review.&nbsp=3B Also=2C<br>as David notes=2C the document can be read=
 as suggesting IETF review<br>of all SDO RADIUS attribute documents.&nbsp=
=3B <br>&nbsp=3B<br>&gt=3B   The most I would do is to provide horrific exa=
mples of what *not* to<br>&gt=3B do.  i.e. putting arbitrary text strings i=
nto the "data" portion of a<br>&gt=3B VSA (no... no VSA-type/VSA-length/VSA=
-data... just Vendor-Id/text..)<br><br>Describing why this is a bad idea wo=
uld probably be useful. <br></body>
</html>=

--_05b410fd-c509-4915-a81a-03f65da12539_--

--
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, 30 Dec 2008 22:03:16 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 14:02:51 -0800
MIME-Version: 1.0

--_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> >   Does the data fit utilize ad-hoc extensions to the RADIUS data model=
=2C
> >   as outlined in below?  If so=2C it SHOULD be encapsulated in a RADIUS=
 VSA=20
> >   or an Extended Attribute [EXTENDED].
>=20
> While it may be feasible to group the ad-hoc extensions into a handful of
> categories=2C I'm not sure what benefit this provides.  Anything *other* =
than
> the (limited) standard data model is automatically an ad-hoc extension=2C
> right?  Do we need to provide examples?

Once the ad-hoc extensions are included in Appendix B=2C as is claimed in
Section 1=2C then several questions arise:

* Which=2C if any=2C of these additional data types are suitable for use in=
 Extended
Attributes?

* Which=2C if any=2C of these additional data types are appropriate for use=
 in=20
SDO-specific attributes?

* Which=2C if any=2C of these additional data types are appropriate for use=
 in VSAs?=20

Presumably=2C the answer to these questions might be different. =20

It is possible that some of these questions may be left to other documents=
=3B
for example=2C the Extended Attributes document could deal with the data
model appropriate to those attributes (incorporating Section A.1.2 from
Design Guidelines=2C for example). =20

It is also possible that some of these questions may be explicitly ruled ou=
t
of scope.  But if so=2C that needs to be made clear within Section 1.1=2C w=
hich
deals with Applicability.=20

--_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B &gt=3B   Does the data fit utilize ad-hoc extensions to the RADIUS d=
ata model=2C<br>&gt=3B &gt=3B   as outlined in below?  If so=2C it SHOULD b=
e encapsulated in a RADIUS VSA <br>&gt=3B &gt=3B   or an Extended Attribute=
 [EXTENDED].<br>&gt=3B <br>&gt=3B While it may be feasible to group the ad-=
hoc extensions into a handful of<br>&gt=3B categories=2C I'm not sure what =
benefit this provides.  Anything *other* than<br>&gt=3B the (limited) stand=
ard data model is automatically an ad-hoc extension=2C<br>&gt=3B right?  Do=
 we need to provide examples?<br><br>Once the ad-hoc extensions are include=
d in Appendix B=2C as is claimed in<br>Section 1=2C then several questions =
arise:<br><br>* Which=2C if any=2C of these additional data types are suita=
ble for use in Extended<br>Attributes?<br><br>* Which=2C if any=2C of these=
 additional data types are appropriate for use in <br>SDO-specific attribut=
es?<br><br>* Which=2C if any=2C of these additional data types are appropri=
ate for use in VSAs? <br><br>Presumably=2C the answer to these questions mi=
ght be different.&nbsp=3B <br><br>It is possible that some of these questio=
ns may be left to other documents=3B<br>for example=2C the Extended Attribu=
tes document could deal with the data<br>model appropriate to those attribu=
tes (incorporating Section A.1.2 from<br>Design Guidelines=2C for example).=
&nbsp=3B <br><br>It is also possible that some of these questions may be ex=
plicitly ruled out<br>of scope.&nbsp=3B But if so=2C that needs to be made =
clear within Section 1.1=2C which<br>deals with Applicability. <br></body>
</html>=

--_9bc80fbb-1f0e-44b1-8b64-72acd47ac735_--

--
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, 30 Dec 2008 21:58:51 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Dec 2008 22:58:19 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Issue:  Data Type Advice
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
> Bernard Aboba writes...
> 
>> Therefore the "existing RADIUS data model as outlined below" is really
>> just the data model for standard RADIUS attributes. 
> 
> Well, characterizing various ad-hoc extensions as part of a data model seems
> to me to de-value the term "data model".  :-)

  Most vendors are smart/lazy enough to re-use the existing data types.
 The guidelines draft is intended to encourage this behavior, and to
discourage "complex" types that are little more than simple collation of
existing data types.

  It is intended to encourage SDO specifications that re-use existing
data types.  These specifications should *not* need IETF review.

  Specifications that are SDO specific, and do *not* re-use existing
types are SDO specific, and do not need IETF review.

  Much of this is already in the document.  What can we do to clarify
the text to avoid repeated questions?

>>   Does the data fit utilize ad-hoc extensions to the RADIUS data model,
>>   as outlined in below?  If so, it SHOULD be encapsulated in a RADIUS VSA 
>>   or an Extended Attribute [EXTENDED].
> 
> While it may be feasible to group the ad-hoc extensions into a handful of
> categories, I'm not sure what benefit this provides.  Anything *other* than
> the (limited) standard data model is automatically an ad-hoc extension,
> right?  Do we need to provide examples?

  I would say no.

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

  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, 30 Dec 2008 21:33:19 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 16:33:04 -0500
Message-ID: <46DAC7232A784B78B58B9FF6D0480BC6@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Aclqvs/VKkdmCm1MQ2eizR7927QNBAABoRcw

Bernard Aboba writes...

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

Well, characterizing various ad-hoc extensions as part of a data model =
seems
to me to de-value the term "data model".  :-)

>   Does the data fit within the RADIUS standard attribute data model,
>   as outlined below?  If so, it MAY be encapsulated either in a =
[RFC2865]
>   format RADIUS attribute, or in a [RFC2865] format RADIUS VSA.

OK.

>   Does the data fit utilize ad-hoc extensions to the RADIUS data =
model,
>   as outlined in below?  If so, it SHOULD be encapsulated in a RADIUS =
VSA=20
>   or an Extended Attribute [EXTENDED].

While it may be feasible to group the ad-hoc extensions into a handful =
of
categories, I'm not sure what benefit this provides.  Anything *other* =
than
the (limited) standard data model is automatically an ad-hoc extension,
right?  Do we need to provide examples?
=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: Tue, 30 Dec 2008 21:23:42 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 16:23:03 -0500
Message-ID: <299DE9D830E2438DBB23450A49E0B966@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclquS/JLYik+g+5TBOSOhDGyuO+EQACu2Cw

Bernard Aboba writes...

> Given the widely divergent interpretations of the document applicability,
> it would seem that we will need to develop an applicability statement 
> section so that the scope (and intent) of the document is clear. 

Uh...  There *is* an applicability statement, Section 1.1 Applicability.
:-)

I previously quoted part of it.  Here's the complete section:

1.1.  Applicability

   As RADIUS has become more widely accepted as a management protocol,
   its usage has become more prevalent, both within the IETF as well as
   within other SDOs.  Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their RADIUS
   work within the IETF is inherently inefficient and unscalable.  By
   articulating guidelines for RADIUS attribute design, this document
   enables SDOs to design their own RADIUS attributes within the Vendor-
   Specific Attribute (VSA) space, seeking review from the IETF.  In
   order to enable IETF review of SDO RADIUS attribute specifications,
   the authors recommend that:

      * SDOs make their RADIUS attribute specifications publicly
      available;

      * SDOs request review of RADIUS attribute specifications by
      sending email to the AAA Doctors [DOCTORS] or equivalent mailing
      list;

      * IETF and SDO RADIUS attribute specifications are reviewed
      according to the guidelines proposed in this document;

      * Reviews of specifications are posted to the RADEXT WG mailing
      list, the AAA Doctors mailing list [DOCTORS] or another IETF
      mailing list suggested by the Operations & Management Area
      Directors of the IETF.

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes (such as Service-Type) that
   can be used to, in effect, provide new RADIUS commands require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3 .  Such changes should
   not be undertaken outside the IETF and when handled within the IETF
   require "IETF Consensus" for adoption, as noted in [RFC3575] Section
   2.1.


--
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, 30 Dec 2008 20:44:28 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_21f4c260-8619-4075-8db7-416223bc7260_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Issue:  Extended Attributes Dependency
Date: Tue, 30 Dec 2008 12:44:05 -0800
MIME-Version: 1.0

--_21f4c260-8619-4075-8db7-416223bc7260_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Issue: Extended Attributes Dependency



Submitter name:  Bernard Aboba



Submitter email address: [e-mail]



Date first submitted: December 30=2C 2008 =20



Reference:=20




Document:  GUIDELINES



Comment type: Technical



Priority:  S



Section:  Appendix A.1.2



Rationale/Explanation of issue:

Section A.1.2 reads:
   Where possible=2C the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types defined in [EXTEN] SHOULD be used
   only where there is no clear method of expressing the data using
   existing types.

   Does the data fit within the extended RADIUS data model=2C as outlined
   below?  If so=2C it SHOULD be encapsulated in a [EXTEN] format RADIUS
   VSA.

      * Attributes grouped into a logical container.
        This does not include nested groups.
      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3=2C below.

This text includes normative statements relating to the Extended
Attributes document=2C and yet [EXTEN] is only listed as an
Informative reference.  Either a normative reference needs to be
added=2C or this section needs to be removed.=20


--_21f4c260-8619-4075-8db7-416223bc7260_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<br><strong>Issue: Extended Attributes Dependency</strong><br>


Submitter name:&nbsp=3B Bernard Aboba<br>


Submitter email address: [e-mail]<br>


Date first submitted: December 30=2C 2008&nbsp=3B <br>


Reference:&nbsp=3B
<br>


Document:&nbsp=3B GUIDELINES<br>


Comment type: Technical<br>


Priority:&nbsp=3B S<br>


Section:&nbsp=3B Appendix A.1.2<br>


Rationale/Explanation of issue:<br><br>Section A.1.2 reads:<pre class=3D"ne=
wpage"><br>   Where possible=2C the data types defined above in Section A.1=
.1 SHOULD<br>   be used.  The extended data types defined in [<a href=3D"ht=
tp://tools.ietf.org/html/draft-ietf-radext-design-05#ref-EXTEN">EXTEN</a>] =
SHOULD be used<br>   only where there is no clear method of expressing the =
data using<br>   existing types.<br><br>   Does the data fit within the ext=
ended RADIUS data model=2C as outlined<br>   below?  If so=2C it SHOULD be =
encapsulated in a [<a href=3D"http://tools.ietf.org/html/draft-ietf-radext-=
design-05#ref-EXTEN">EXTEN</a>] format RADIUS<br>   VSA.<br><br>      * Att=
ributes grouped into a logical container.<br>        This does not include =
nested groups.<br>      * Attributes requiring the transport of more than 2=
47 octets of<br>        Text or String data.  This includes the opaque enca=
psulation<br>        of data structures defined outside of RADIUS.  See als=
o Section<br>        A.1.3=2C below.<br><br>This text includes normative st=
atements relating to the Extended<br>Attributes document=2C and yet [EXTEN]=
 is only listed as an<br>Informative reference.  Either a normative referen=
ce needs to be<br>added=2C or this section needs to be removed. <br></pre><=
table style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-fam=
ily: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbo=
dy></table></body>
</html>=

--_21f4c260-8619-4075-8db7-416223bc7260_--

--
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, 30 Dec 2008 20:33:02 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Issue:  Data Type Advice
Date: Tue, 30 Dec 2008 12:32:30 -0800
MIME-Version: 1.0

--_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue: Data Type Advice


Submitter name:  Bernard Aboba


Submitter email address: [e-mail]


Date first submitted: December 30=2C 2008 =20


Reference:=20



Document:  GUIDELINES


Comment type: Technical


Priority:  S


Section:  Appendix A.1.1


Rationale/Explanation of issue:

Section A.1.1 reads:=20
   Does the data fit within the existing RADIUS data model=2C as outlined
   below?  If so=2C it SHOULD be encapsulated in a [RFC2865] format RADIUS
   attribute=2C or in a [RFC2865] format RADIUS VSA.

As noted in an earlier issue=2C Appendix B does not cover data types utiliz=
ed within RADIUS VSAs=2C=20
only the data types in standard RADIUS attributes.   Therefore the "existin=
g RADIUS data model
as outlined below" is really just the data model for standard RADIUS attrib=
utes.   On that basis
the sentence might better read:

   Does the data fit within the RADIUS standard attribute data model=2C as =
outlined
   below?  If so=2C it MAY be encapsulated either in a [RFC2865] format RAD=
IUS
   attribute=2C or in a [RFC2865] format RADIUS VSA.

Assuming that the promised survey of ad-hoc data model extensions is actual=
ly included in the
document=2C then this could be referenced to in a subsequent sentence:

   Does the data fit utilize ad-hoc extensions to the RADIUS data model=2C =
as outlined
   in below?  If so=2C it SHOULD be encapsulated in a RADIUS VSA or an Exte=
nded
   Attribute [EXTENDED]. =20








Given this=2C it would appear that Section A.1.1 is recommending that RADIU=
S VSAs only


--_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<strong>Issue: Data Type Advice</strong><br>

Submitter name:&nbsp=3B Bernard Aboba<br>

Submitter email address: [e-mail]<br>

Date first submitted: December 30=2C 2008&nbsp=3B <br>

Reference:&nbsp=3B
<br>

Document:&nbsp=3B GUIDELINES<br>

Comment type: Technical<br>

Priority:&nbsp=3B S<br>

Section:&nbsp=3B Appendix A.1.1<br>

Rationale/Explanation of issue:<br><br>Section A.1.1 reads: <br><pre class=
=3D"newpage">   Does the data fit within the existing RADIUS data model=2C =
as outlined<br>   below?  If so=2C it SHOULD be encapsulated in a [<a href=
=3D"http://tools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&=
quot=3B">RFC2865</a>] format RADIUS<br>   attribute=2C or in a [<a href=3D"=
http://tools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&quot=
=3B">RFC2865</a>] format RADIUS VSA.<br><br></pre>As noted in an earlier is=
sue=2C Appendix B does not cover data types utilized within RADIUS VSAs=2C =
<br>only the data types in standard RADIUS attributes.&nbsp=3B&nbsp=3B Ther=
efore the "existing RADIUS data model<br>as outlined below" is really just =
the data model for standard RADIUS attributes.&nbsp=3B&nbsp=3B On that basi=
s<br>the sentence might better read:<br><br><pre class=3D"newpage">   Does =
the data fit within the RADIUS standard attribute data model=2C as outlined=
<br>   below?  If so=2C it MAY be encapsulated either in a [<a href=3D"http=
://tools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&quot=3B"=
>RFC2865</a>] format RADIUS<br>   attribute=2C or in a [<a href=3D"http://t=
ools.ietf.org/html/rfc2865" title=3D"&quot=3B28800 V42BIS/LAPM&quot=3B">RFC=
2865</a>] format RADIUS VSA.</pre>
<br>Assuming that the promised survey of ad-hoc data model extensions is ac=
tually included in the<br>document=2C then this could be referenced to in a=
 subsequent sentence:<br><br><pre class=3D"newpage">   Does the data fit ut=
ilize ad-hoc extensions to the RADIUS data model=2C as outlined<br>   in be=
low?  If so=2C it SHOULD be encapsulated in a RADIUS VSA or an Extended<br>=
   Attribute [EXTENDED].  <br></pre>
<br><br><br><br><br><br><br>Given this=2C it would appear that Section A.1.=
1 is recommending that RADIUS VSAs only<br><table style=3D"border-top: 1px =
solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-=
serif=3B"><tbody><tr><td><br></td></tr></tbody></table></body>
</html>=

--_23f84cdf-de7a-43ea-9a45-e1ccb9d34263_--

--
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, 30 Dec 2008 20:16:45 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f4a2acc9-39be-4a4f-9e82-b56f052c495a_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Issue:  Attribute Usage
Date: Tue, 30 Dec 2008 12:16:15 -0800
MIME-Version: 1.0

--_f4a2acc9-39be-4a4f-9e82-b56f052c495a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue: Attribute Usage

Submitter name:  Bernard Aboba

Submitter email address: [e-mail]

Date first submitted: December 30=2C 2008 =20

Reference:=20


Document:  GUIDELINES

Comment type: Technical

Priority:  S

Section:  1=2C Appendix B

Rationale/Explanation of issue:

Section 1 of the document reads:

   In order to characterize current attribute usage=2C both the basic and
   complex data types defined in the existing RADIUS RFCs are reviewed=2C
   together with the ad-hoc extensions to that data model that have been
   used in Vendor-Specific Attributes.

Appendix B covers only data types used in existing RADIUS RFCs.   As far as=
 I can tell=2C
the document does not catalog the ad-hoc extensions that have been used in
Vendor-Specific Attributes.=20

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












--_f4a2acc9-39be-4a4f-9e82-b56f052c495a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<strong>Issue: Attribute Usage</strong><br>
Submitter name:&nbsp=3B Bernard Aboba<br>
Submitter email address: [e-mail]<br>
Date first submitted: December 30=2C 2008&nbsp=3B <br>
Reference:&nbsp=3B
<br>
Document:&nbsp=3B GUIDELINES<br>
Comment type: Technical<br>
Priority:&nbsp=3B S<br>
Section:&nbsp=3B 1=2C Appendix B<br>
Rationale/Explanation of issue:<br><br>Section 1 of the document reads:<br>=
<pre class=3D"newpage"><br>   In order to characterize current attribute us=
age=2C both the basic and<br>   complex data types defined in the existing =
RADIUS RFCs are reviewed=2C<br>   together with the ad-hoc extensions to th=
at data model that have been<br>   used in Vendor-Specific Attributes.<br><=
/pre><br>Appendix B covers only data types used in existing RADIUS RFCs.&nb=
sp=3B&nbsp=3B As far as I can tell=2C<br>the document does not catalog the =
ad-hoc extensions that have been used in<br>Vendor-Specific Attributes. <br=
><br>Either the document needs to add material relating to ad-hoc extension=
s=2C or this<br>portion of the sentence needs to be removed.<br><br><br><br=
><br><br><br><br><br><br><br><table style=3D"border-top: 1px solid black=3B=
 font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbo=
dy><tr><td><br></td></tr></tbody></table></body>
</html>=

--_f4a2acc9-39be-4a4f-9e82-b56f052c495a_--

--
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, 30 Dec 2008 20:00:41 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_31276e7e-ad26-4f35-8370-6ef8fa8729e4_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 11:59:55 -0800
MIME-Version: 1.0

--_31276e7e-ad26-4f35-8370-6ef8fa8729e4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> That's not what it says.  What it actually says is:
>=20
>    Given the expanded utilization of RADIUS=2C it has
>    become apparent that requiring SDOs to accomplish all their
>    RADIUS work within the IETF is inherently inefficient and=20
>    unscalable.  By articulating guidelines for RADIUS attribute=20
>    design=2C this document enables SDOs to design their own RADIUS=20
>    attributes within the Vendor-Specific Attribute (VSA) space=2C
>    seeking review from the IETF.
>=20
> It specifically indicates that the guidelines apply to SDO-defined
> attributes=2C and I think this was the general intent all along -- to pro=
vide
> design guidance so that high-quality RADUS work could occur both within t=
he
> IETF and within other SDOs.

I think that this may in part explain some of Hannes' (and others) objectio=
ns to the document.=20

Given the widely divergent interpretations of the document applicability=2C=
 it would seem that we
will need to develop an applicability statement section so that the scope (=
and intent) of the
document is clear.=20


--_31276e7e-ad26-4f35-8370-6ef8fa8729e4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B That's not what it says.  What it actually says is:<br>&gt=3B <br>&g=
t=3B    Given the expanded utilization of RADIUS=2C it has<br>&gt=3B    bec=
ome apparent that requiring SDOs to accomplish all their<br>&gt=3B    RADIU=
S work within the IETF is inherently inefficient and <br>&gt=3B    unscalab=
le.  By articulating guidelines for RADIUS attribute <br>&gt=3B    design=
=2C this document enables SDOs to design their own RADIUS <br>&gt=3B    att=
ributes within the Vendor-Specific Attribute (VSA) space=2C<br>&gt=3B    se=
eking review from the IETF.<br>&gt=3B <br>&gt=3B It specifically indicates =
that the guidelines apply to SDO-defined<br>&gt=3B attributes=2C and I thin=
k this was the general intent all along -- to provide<br>&gt=3B design guid=
ance so that high-quality RADUS work could occur both within the<br>&gt=3B =
IETF and within other SDOs.<br><br>I think that this may in part explain so=
me of Hannes' (and others) objections to the document. <br><br>Given the wi=
dely divergent interpretations of the document applicability=2C it would se=
em that we<br>will need to develop an applicability statement section so th=
at the scope (and intent) of the<br>document is clear. <br><br></body>
</html>=

--_31276e7e-ad26-4f35-8370-6ef8fa8729e4_--

--
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, 30 Dec 2008 19:11:33 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 14:11:11 -0500
Message-ID: <E70379A3DD3D46059C771CC0E060B941@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclqQLQrA0/Bxx4HR7eMEPY8e/5NCgAWhsNQAASlU6AAARIfkA==

Bernard Aboba writes...

> The RADIUS design guidelines only apply to documents that are 
> requesting allocation of RADIUS standard attributes.

That's not what it says.  What it actually says is:

   Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their
   RADIUS work within the IETF is inherently inefficient and 
   unscalable.  By articulating guidelines for RADIUS attribute 
   design, this document enables SDOs to design their own RADIUS 
   attributes within the Vendor-Specific Attribute (VSA) space,
   seeking review from the IETF.

It specifically indicates that the guidelines apply to SDO-defined
attributes, and I think this was the general intent all along -- to provide
design guidance so that high-quality RADUS work could occur both within the
IETF and within other SDOs.
 


--
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, 30 Dec 2008 18:38:37 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Dave Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 10:38:21 -0800
Message-ID: <000101c96aad$ca6c2020$5f446060$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AclqQLQrA0/Bxx4HR7eMEPY8e/5NCgAWhsNQAASlU6A=
Content-Language: en-us

David Nelson said:

"Should such a review include analysis of compliance with the RADIUS Design
Guidelines?  Are you assuming that the guidelines apply only after they are
finally published as a BCP?"

The RADIUS design guidelines only apply to documents that are requesting
allocation of RADIUS standard attributes.  If this document were to 
allocate its attributes from the IEEE 802 attribute space, then I don't
believe that conformance to Design Guidelines would be required.  


--
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, 30 Dec 2008 18:33:57 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Dave Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 10:33:07 -0800
Message-ID: <000001c96aad$0f73bee0$2e5b3ca0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezwABBkdzAAG93WkAAXmJjAAAf7LSA=
Content-Language: en-us

> I haven't seen the code so I don't know for sure, but my guess
> is that your presumption would be incorrect.  Since multiple 
> vendors are involved, this is not a technically appropriate 
> use of VSAs.

No. The Design Guidelines document was written in part to dispel
this misconception.  VSAs (specifically those allocated to
SDOs such as IEEE 802) are not only technically appropriate 
for this use, they are the recommended approach for use
in documents (such as this one) which describe SDO-specific
uses of RADIUS.  

If this point is not being made crystal clear in the Design
Guidelines document, then we need to change the text until
it is. 

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



--
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, 30 Dec 2008 16:27:12 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Tue, 30 Dec 2008 11:26:52 -0500
Message-ID: <34494210385D450486A6A2C40E20B356@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclqQLQrA0/Bxx4HR7eMEPY8e/5NCgAWhsNQ

Bernard Aboba writes...

> If the goal here is to publish documentation of an existing 
> implementation of RADIUS attributes for IEEE 802.16a, then a request
> should be sent to the AAA-Doctors list for a review.

Should such a review include analysis of compliance with the RADIUS Design
Guidelines?  Are you assuming that the guidelines apply only after they are
finally published as a BCP?



--
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, 30 Dec 2008 15:58:38 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 10:57:43 -0500
Message-ID: <B25571FAD32844F48C02121EE68E3F0E@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezwABBkdzAAKWki0AALWHNQ

Dan Romascanu writes...

>> And that preference would be that the draft simply be 
>> published as an Informational RFC, via the AD Sponsorship route.
> 
> I will accept taking this path if the WG is OK with it, but I would
> note that I will ask anyway the WG to designate an expert reviewer
> for this document and would expect people to comment at last call
> (or before).

There are two issues which would slow the progress this draft as a RADEXT WG
work item: (1) if the WG members were not sufficiently interested in 802.16
key management to engage in active review and commentary and (2) if the
draft were to be entangled in the debate over whether or not to support
complex, structured attributes.

I can't predict (1) but I can predict (2).  One snippet from the draft
reads:

      The PKM-Config-Settings Attribute is 30 octets in length and
      consists of seven independent fields, each of type integer
      [RFC2865].
 
This tell us right up front that the draft is using complex / structured
attributes, in this case a fixed length array of integer values.  As
currently constituted, the RADIUS Design Guidelines draft discourages such
attribute design for attributes in the "classic" RADIUS attribute ID space.
This draft is requesting allocation from that space.

We had a similar problem with the GEOPRIV Location Attributes draft.  That
document has moved on, but the basic tension between its attribute design
and the recommendations of the Design Guidelines was never fully resolved.

While the Design Guidelines draft is up for IESG approval, and represents
the consensus opinion of the RADEXT WG in the matter of attribute design,
there is still some disquiet.  Most recently, Hannes Tschofenig posted some
commentary regarding the issue of Diameter AVP compatibility that directly
hinges on this thorny issue of complex / structured attributes.

My observation is that there are still drafts being written that do not
follow the RADIUS Design Guidelines, even though that document is basically
a "done deal".  I assume that means that developers find the guidelines too
restrictive for their particular applications or their particular design
preferences.   I can only assume that this will continue, even after the
RADIUS Design Guidelines draft is published as a BCP.  Sigh.

With regard to the example quoted above, the recommended design would be
seven separate attributes of type Integer.  If we take the scarcity issue
off the table for a moment, the only downside would be encoding
inefficiency, i.e. the seven integer values would take up more space in the
RADIUS PDU.  Glen Zorn, in particular, has continually suggested to the WG
that applications are bumping up against the limitation of RADIUS PDU
length.  I suppose an application that is including multiple X.509
certificates in a RADIUS packet may indeed have this problem.

I will take some time to read the current draft and offer some comments.
What am I to do about attributes that don't follow the RADIUS Design
Guidelines?  This promises to be the GEOPRIV debate all over again.  We can
simply turn a blind eye, and let the draft go via the individual submission
route, but what kind of precedent are we setting if we start bypassing
RADIUS Design Guidelines right out of the gate?

If we have design rules or guidelines, they ought to mean something.  That
requires we either reject drafts that don't comply or we enhance the
guidelines so that all reasonable-minded developers can live within their
restrictions.  Anything else is pretty silly, IMHO.

We thought that the RADIUS Extended Attribute format would be a way out of
this mess, i.e. that it would support a sufficient (albeit limited) way to
encode complex / structured attributes.  The Design Guidelines draft is
largely silent on how to design Extended Attributes; that guidance is to be
included in the Extended Attributes draft.

The RADEXT WG consensus of Extended Attributes is that the current tagging
mechanism is sufficient to permit the representation of structured
attributes.  Glen has told us in various postings that that format is not
sufficient (acceptable) to accommodate the need of the PKMV1 draft we are
discussing.  So, we see the draft using "classic" attributes in a way not
supported by the RADIUS Design Guidelines draft.

I think something has to change, or we're in for a lot of future silliness.
I personally have supported a more robust format for Extended Attributes
that would better accommodate the [perceived] need for structured and
complex attribute design.  However, that's not where the WG consensus lies.
That's fine.  But what are we to do with draft submissions that find neither
the Extended Attribute format nor the guidance of the RADIUS Design
Guidelines for "classic" attributes acceptable to their purpose?  Should we
(or some appointed Expert Reviewer) reject those drafts and attempt to block
their publication?

If the motivation in the developer community to design, publish and deploy
complex, structured attributes is sufficiently strong, and the IETF does not
provide a reasonable format or alternative, we're in for a lot more heated
debates.

Let me put it this way: What would MIB Module designers do if there were no
tables available in SMI and there was no SEQUENCE OF syntax?  :-)

I'm seeking suggestions for a way forward, not only for this draft, but for
other similar ones to come.



--
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, 30 Dec 2008 14:50:20 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 09:49:34 -0500
Message-ID: <9B43823DCE15426D8726112612111423@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezwABBkdzAAG93WkAAXmJjA

Glen Zorn writes...

>> I presume the attributes have been deployed as VSAs.  
>
> I haven't seen the code so I don't know for sure, but my guess
> is that your presumption would be incorrect.  Since multiple 
> vendors are involved, this is not a technically appropriate 
> use of VSAs.

So perhaps the implementers used code points in the "Private Use" range (192
- 240)?  Please don't tell me that they poached code points under IANA
control.  :-(  That would be pretty egregious. 

In any event, changes to the code would need to be made, no?


--
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, 30 Dec 2008 10:11:57 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 11:10:51 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezwABBkdzAAKWki0A==
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "D. B. Nelson" <[e-mail]>, <[e-mail]>, "Glen Zorn" <[e-mail]>

=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of D. B. Nelson
> Sent: Monday, December 29, 2008 4:13 PM
> To: [e-mail]
> Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt=20
>=20
> Glen Zorn writes...
>=20
> > Anyway, my preference hasn't changed since I sent my=20
> original request=20
> > (attached) to Dan over 2 months ago.
>=20
> And that preference would be that the draft simply be=20
> published as an Informational RFC, via the AD Sponsorship route.
>=20

I will accept taking this path if the WG is OK with it, but I would note
that I will ask anyway the WG to designate an expert reviewer for this
document and would expect people to comment at last call (or before).=20

Glen, in order to start the AD-sponsoring process you need to find a
shepherd for this document, and he or she will need to submit a PROTO
write-up as per http://www.ietf.org/IESG/content/Indiv-Doc-Writeup.html

Thanks and Regards,

Dan



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


Envelope-to: [e-mail]
Delivery-date: Tue, 30 Dec 2008 07:12:22 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Dec 2008 08:12:02 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: Glen Zorn <[e-mail]>,  Hannes Tschofenig <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Issue:  Use of the term "extended" within the Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Looking at the Design Guidelines document, the term "extended"
> is used in a number of contexts.  This may explain some of the
> questions that Hannes raised. 

  I will update the document to ensure that the "extended" term is used
only in reference to the extended attributes document.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 30 Dec 2008 07:00:39 +0000
From: "Glen Zorn" <[e-mail]>
To: "'D. B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Tue, 30 Dec 2008 13:59:06 +0700
Message-ID: <002d01c96a4c$2b4a05e0$81de11a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezwABBkdzAAG93WkA==
Content-Language: en-us

> Glen Zorn writes...
> 
> > Anyway, my preference hasn't changed since I sent my original
> > request (attached) to Dan over 2 months ago.
> 
> And that preference would be that the draft simply be published as an
> Informational RFC, via the AD Sponsorship route.
> 
> > Furthermore (& I _really_ hate to say this) the attributes as
> > they are have already been implemented by at least 2 vendors
> > and deployed.
> 
> I presume the attributes have been deployed as VSAs.  

I haven't seen the code so I don't know for sure, but my guess is that your
presumption would be incorrect.  Since multiple vendors are involved, this
is not a technically appropriate use of VSAs.

...


--
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, 30 Dec 2008 05:38:48 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_715eaaa2-bd87-4d94-abea-af6997f280c8_"
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt
Date: Mon, 29 Dec 2008 21:37:28 -0800
MIME-Version: 1.0

--_715eaaa2-bd87-4d94-abea-af6997f280c8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> I suppose this draft could be published as documentation of existing
> practice / fielded deployment=2C as an Informational RFC using the fielde=
d VSA
> assignments.

Indeed=2C according to the Design Guidelines document=2C that is the *prefe=
rred*
approach=2C since it maximizes interoperability with existing implementatio=
ns.=20

Of course=2C this raises the question whether the existing attributes are a=
llocated
in the IEEE 802 space (e.g. SDO-specific attributes)=2C or in the Vendor-Sp=
ace.=20

However=2C in terms of the review process described in the Design Guideline=
s
document=2C it does not matter.=20

> Using Extended Attributes was my first choice but it is unfortunately
> impossible to do this in any reasonable fashion using them=3B this was
> established as unchangeable WG Consensus some time ago=2C as announced by=
 Alan
> Dekok=20
Given that this protocol has supposedly already been implemented by 2 vendo=
rs=2C=20
why is the presence or absence of any feature within the Extended Attribute=
s
document relevant?  Presumably a description of an existing implementation =
would
be self-contained=2C not requiring a normative reference to any work-in-pro=
gress=2C
assuming that the protocol is already implemented.=20

> (it _is_ interesting that RFCs can be updated & made obsolete &
> decisions of even the highest courts may be overturned=2C all based on ne=
w
> data=2C but WG Consensus cannot change -- who knew?).

What I don't understand is what "working group consensus" has to do with
publishing documentation of an existing implementation.   Presumably the on=
ly
criteria governing would be whether the document actually describes
what has been implemented.=20

> These spurious claims can't avoid the fact that you haven't succeeded
> in changing the WG consensus to support your position.  Don't blame me.
The "claims" in question here seem to have nothing whatever to do with the =
document
under discussion in this thread:  draft-zorn-radius-pkm1.   So before we ge=
t drawn
into a discussion of the validity of them=2C I'd first like to understand w=
hy they are even=20
relevant.

If the goal here is to publish documentation of an existing implementation =
of RADIUS
attributes for IEEE 802.16a=2C then a request should be sent to the AAA-Doc=
tors list
for a review.  Such a document need not become a RADEXT WG work item to be
eligible for publication.  Certainly that has not been the case for other s=
uch
documents=2C most recently RFC 4679. =20

=20
 =20




--_715eaaa2-bd87-4d94-abea-af6997f280c8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B I suppose this draft could be published as documentation of existing=
<br>&gt=3B practice / fielded deployment=2C as an Informational RFC using t=
he fielded VSA<br>&gt=3B assignments.<br><br>Indeed=2C according to the Des=
ign Guidelines document=2C that is the *preferred*<br>approach=2C since it =
maximizes interoperability with existing implementations. <br><br>Of course=
=2C this raises the question whether the existing attributes are allocated<=
br>in the IEEE 802 space (e.g. SDO-specific attributes)=2C or in the Vendor=
-Space. <br><br>However=2C in terms of the review process described in the =
Design Guidelines<br>document=2C it does not matter. <br><br><pre>&gt=3B Us=
ing Extended Attributes was my first choice but it is unfortunately<br>&gt=
=3B impossible to do this in any reasonable fashion using them=3B this was<=
br>&gt=3B established as unchangeable WG Consensus some time ago=2C as anno=
unced by Alan<br>&gt=3B Dekok <br></pre>Given that this protocol has suppos=
edly already been implemented by 2 vendors=2C <br>why is the presence or ab=
sence of any feature within the Extended Attributes<br>document relevant?&n=
bsp=3B Presumably a description of an existing implementation would<br>be s=
elf-contained=2C not requiring a normative reference to any work-in-progres=
s=2C<br>assuming that the protocol is already implemented. <br><br><pre>&gt=
=3B (it _is_ interesting that RFCs can be updated &amp=3B made obsolete &am=
p=3B<br>&gt=3B decisions of even the highest courts may be overturned=2C al=
l based on new<br>&gt=3B data=2C but WG Consensus cannot change -- who knew=
?).<br></pre><br>What I don't understand is what "working group consensus" =
has to do with<br>publishing documentation of an existing implementation.&n=
bsp=3B&nbsp=3B Presumably the only<br>criteria governing would be whether t=
he document actually describes<br>what has been implemented. <br><br><pre>&=
gt=3B These spurious claims can't avoid the fact that you haven't succeeded=
<br>&gt=3B in changing the WG consensus to support your position.  Don't bl=
ame me.<br></pre>The "claims" in question here seem to have nothing whateve=
r to do with the document<br>under discussion in this thread:&nbsp=3B draft=
-zorn-radius-pkm1. &nbsp=3B So before we get drawn<br>into a discussion of =
the validity of them=2C I'd first like to understand why they are even <br>=
relevant.<br><br>If the goal here is to publish documentation of an existin=
g implementation of RADIUS<br>attributes for IEEE 802.16a=2C then a request=
 should be sent to the AAA-Doctors list<br>for a review.&nbsp=3B Such a doc=
ument need not become a RADEXT WG work item to be<br>eligible for publicati=
on.&nbsp=3B Certainly that has not been the case for other such<br>document=
s=2C most recently RFC 4679.&nbsp=3B <br><br>&nbsp=3B<br>&nbsp=3B <br><br><=
br><br></body>
</html>=

--_715eaaa2-bd87-4d94-abea-af6997f280c8_--

--
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, 29 Dec 2008 14:14:15 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Mon, 29 Dec 2008 09:13:15 -0500
Message-ID: <001A5638AA0F45C899E2E7E5231C06EC@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezwABBkdzA=

Glen Zorn writes...

> Anyway, my preference hasn't changed since I sent my original
> request (attached) to Dan over 2 months ago.

And that preference would be that the draft simply be published as an
Informational RFC, via the AD Sponsorship route.

> Furthermore (& I _really_ hate to say this) the attributes as
> they are have already been implemented by at least 2 vendors
> and deployed.

I presume the attributes have been deployed as VSAs.  This draft requests
that IANA assign standard code space IDs to the attributes. I understand
that changing the deployed code to remove VSA headers and substitute
standard headers is not a lot of work, but it _is_ a code change.  Once you
open up the code for change...  well, change is change.

I suppose this draft could be published as documentation of existing
practice / fielded deployment, as an Informational RFC using the fielded VSA
assignments.


--
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, 29 Dec 2008 09:17:38 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: Glen Zorn <[e-mail]>
CC: Hannes Tschofenig <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Issue:  Use of the term "extended" within the Design Guidelines Document
Date: Mon, 29 Dec 2008 01:16:52 -0800
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> At the risk of putting words in Hannes' mouth=2C I'm pretty sure that the
> draft he believes gives the impression that Extended Attributes can easil=
y
> support the Diameter AVP structure _is_ the Design Guidelines draft=3B as=
 he
> points out=2C it would be impossible for a reasonable person to get that =
idea
> from the Extended Attributes draft.

Looking at the Design Guidelines document=2C the term "extended"
is used in a number of contexts.  This may explain some of the
questions that Hannes raised.=20

For example=2C in Section 2.2=2C the term is used to refer to the Extended =
Attributes document:=20
2.2.  Extended RADIUS Attributes

   The extended RADIUS attribute document [EXTEN] defines a number of
   extensions to RADIUS.  The standard attribute space is extended by
   permitting standard allocations from within a specific subset of the
   VSA space=3B the format of extended attributes is defined=3B and extende=
d
   data types are defined within that format.

   New specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.

In Section 3.1.2=2C the term is used to refer to RADIUS VSAs in general:

   As discussed in [RFC2865] Section 5.26=2C the vendor space is intended
   for vendors to support their own extended attributes not suitable for
   general use.=20

In Section A.1.2=2C the term "Extended" is used to refer to data types.=20
However=2C it is not clear whether this advice is only applicable to
RADIUS standard attributes (which I believe is the case)=2C or whether
it applies to VSAs or SDO-specific attributes.=20

A.1.2. Extended data types

   Where possible=2C the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types defined in [EXTEN] SHOULD be used
   only where there is no clear method of expressing the data using
   existing types.

   Does the data fit within the extended RADIUS data model=2C as outlined
   below?  If so=2C it SHOULD be encapsulated in a [EXTEN] format RADIUS
   VSA.

      * Attributes grouped into a logical container.
        This does not include nested groups.
      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3=2C below.

In Section A.5=2C the term "extended" is used to refer to SDO-specific
data types:

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead=2C they recognize that the RADIUS
   data model has limitations.  In certain situations where
   interoperability can be strongly constrained=2C a data model extended
   by the SDO or vendor MAY be used. =20

The term is also used in Section B.8=2C this time in reference to the
Extended Attributes document:

   Future specifications that attempt to obtain similar
   functionality SHOULD use the extended types from [EXTEN].

Overall=2C in looking over this text=2C there does seem to be some possibil=
ity
of confusion relating to the applicability of the document (which I believe
only applies to attributes within the RADIUS standard attribute space).=20

However=2C none of the above text would seem capable of leading a reader
to believe that the Diameter AVP format was supported.  Or am I missing
something?=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, 29 Dec 2008 07:53:48 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Dec 2008 08:53:21 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: "'D. B. Nelson'" <[e-mail]>,  'Bernard Aboba' <[e-mail]>, [e-mail], "'Romascanu, Dan \(Dan\)'" <[e-mail]>
Subject: Re: I-D Action:draft-zorn-radius-pkmv1-03.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Using Extended Attributes was my first choice but it is unfortunately
> impossible to do this in any reasonable fashion using them; this was
> established as unchangeable WG Consensus some time ago, as announced by Alan
> Dekok 

  I never said any such thing.

  In the past, people rejected the modifications you proposed.  This
forms the "WG consensus" that I have referred to.

  In the present, no one has agreed to make those modifications.

  In the future, if people *do* agree to make those modifications, that
would form "WG consensus", and I would be in no position to oppose it.

> (it _is_ interesting that RFCs can be updated & made obsolete &
> decisions of even the highest courts may be overturned, all based on new
> data, but WG Consensus cannot change -- who knew?).

  These spurious claims can't avoid the fact that you haven't succeeded
in changing the WG consensus to support your position.  Don't blame me.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Dec 2008 07:40:22 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Dec 2008 08:39:46 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Bernard Aboba' <[e-mail]>,  'Hannes Tschofenig' <[e-mail]>, [e-mail]
Subject: Re: philosophy of the Design Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> At the risk of putting words in Hannes' mouth, I'm pretty sure that the
> draft he believes gives the impression that Extended Attributes can easily
> support the Diameter AVP structure _is_ the Design Guidelines draft; as he
> points out, it would be impossible for a reasonable person to get that idea
> from the Extended Attributes draft.

  You must be reading a different version of the Design Guidelines
document than the one I'm editing.

  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, 29 Dec 2008 07:18:01 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: "'Hannes Tschofenig'" <[e-mail]>, <[e-mail]>
Subject: RE: philosophy of the Design Guidelines document
Date: Mon, 29 Dec 2008 14:17:10 +0700
Message-ID: <002701c96985$8009e9f0$801dbdd0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclpY7Siv0t4Ga11TAudZ4vnJL6f2gAINNAw
Content-Language: en-us

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

...

> > At least I am asking to capture these aspects in the draft as there
> are
> > really two types of complex attributes, namely those captured with
> the
> > RADIUS extended attributes draft and then more complex onces that can
> be
> > found also in the Diameter space. Reading through the draft one could
> easily
> > get the impression that that document now allows the Diameter AVP
> structure
> > to be easily supported, which is not true.
> 
> Discussion of Extended Attribute design is out of scope of the Design
> Guidelines
> document.  However, it *is* in scope for the Extended Attributes
> document.  So
> I think you are pointing out an issue with the Extended Attributes
> document here.

At the risk of putting words in Hannes' mouth, I'm pretty sure that the
draft he believes gives the impression that Extended Attributes can easily
support the Diameter AVP structure _is_ the Design Guidelines draft; as he
points out, it would be impossible for a reasonable person to get that idea
from the Extended Attributes draft.

...


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


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Dec 2008 06:29:06 +0000
From: "Glen Zorn" <[e-mail]>
To: "'D. B. Nelson'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>, "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>, "'Romascanu, Dan \(Dan\)'" <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Mon, 29 Dec 2008 13:27:42 +0700
Message-ID: <001401c9697e$99903390$ccb09ab0$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01C969B9.45EF0B90"
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIAB+aezw
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0015_01C969B9.45EF0B90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

> Dan Romascanu writes...
> 
> > I would like to ask the WG chairs and the WG at large what are
> > the plans with this document following the response received from
> > IEEE 802.16.
> 
> We should first ask Glen his intent / preferences.  Glen, what is your
> preferred path to publish this draft?

Sorry for the slow response, I've been occupied with administrivia ;-).
Anyway, my preference hasn't changed since I sent my original request
(attached) to Dan over 2 months ago.

> 
> As this draft has been deemed useful to IEEE 802.16 (at least to
> address
> fielded deployments), the first question to ask is whether this work
> should
> be taken on in the IETF, or whether it should be taken on in the IEEE
> (or as
> a individual submission).  We have created a framework in which RADIUS
> attributes that are of interest to particular SDOs, but not of general
> interest to the Internet community, could be documented as SDO Specific
> Attributes, using the RADIUS Extended Attribute format and the RADIUS
> Design
> Guidelines.  

Using Extended Attributes was my first choice but it is unfortunately
impossible to do this in any reasonable fashion using them; this was
established as unchangeable WG Consensus some time ago, as announced by Alan
Dekok (it _is_ interesting that RFCs can be updated & made obsolete &
decisions of even the highest courts may be overturned, all based on new
data, but WG Consensus cannot change -- who knew?).  Furthermore (& I
_really_ hate to say this) the attributes as they are have already been
implemented by at least 2 vendors and deployed.  

...

------=_NextPart_000_0015_01C969B9.45EF0B90
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12])
          by sccrmxc19.comcast.net (sccrmxc19) with ESMTP
          id <20081018073258s1900f74nle>; Sat, 18 Oct 2008 07:32:58 +0000
Received: from gwzPC ([124.120.231.2])
	by OMTA08.westchester.pa.mail.comcast.net with comcast
	id U7Xo1a00103laUC3U7YRRw; Sat, 18 Oct 2008 07:32:53 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Dan Romascanu'" <[e-mail]>
Cc: "'Glen Zorn'" <[e-mail]>,
	"'Bernard Aboba'" <[e-mail]>,
	"'David B. Nelson'" <[e-mail]>
Subject: FW: I-D Action:draft-zorn-radius-pkmv1-01.txt 
Date: Sat, 18 Oct 2008 14:31:45 +0700
Message-ID: <002001c930f3$a8049ab0$f80dd010$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_000F_01C969B9.45EBFE50"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ackw71BXS4ZhEszZRdiQmMJvRpuY9AAAzhaA
Content-Language: en-us
X-Originating-IP: [76.96.62.12]
X-Authority-Analysis: v=1.0 c=1 a=OaMvhXh4NHQA:10 a=SaCYHdZMcd0A:10 a=48vgC7mUAAAA:8 a=EyauKDqhphLyoA2kpFcA:9 a=5RzFJHGsPNzGbsmeeKAA:7 a=hzt-5UQKDQuD8o3dK0yGeFKVRhgA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=jI3X6DeuhsIo9i47XcYA:9 a=eUx1RORbj5N-cZs5iyZC-etaRMEA:4 a=6bqG61NMjcsA:10 a=wh76t8uYnjVSms9FPiMA:9 a=3mQmABdMVIFtobbOxVbqKt1iqJQA:4 a=61tZBHfzjhcA:10

This is a multipart message in MIME format.

------=_NextPart_000_000F_01C969B9.45EBFE50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C969B9.45EBFE50"


------=_NextPart_001_0010_01C969B9.45EBFE50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi, Dan.  In the interest of timeliness, I'm wondering if I can interest you
in sponsoring this draft for publication.  I'm not at all averse to radext
WG review of the document but publishing it as a WG document would, in all
probability, take years; in fact, it might take years to get it in the
charter.  Thanks for your consideration.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Saturday, October 18, 2008 2:00 PM
To: [e-mail]
Subject: I-D Action:draft-zorn-radius-pkmv1-01.txt 

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

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

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

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

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

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

------=_NextPart_001_0010_01C969B9.45EBFE50
Content-Type: text/html;
	boundary="----=_NextPart_000_0021_01C9312E.546372B0";
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
08.00.0681.000">
<TITLE>FW: I-D Action:draft-zorn-radius-pkmv1-01.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi, Dan.&nbsp; In the interest of timeliness, I'm =
wondering if I can interest you</FONT>

<BR><FONT SIZE=3D2>in sponsoring this draft for publication.&nbsp; I'm =
not at all averse to radext</FONT>

<BR><FONT SIZE=3D2>WG review of the document but publishing it as a WG =
document would, in all</FONT>

<BR><FONT SIZE=3D2>probability, take years; in fact, it might take years =
to get it in the</FONT>

<BR><FONT SIZE=3D2>charter.&nbsp; Thanks for your consideration.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:i-d-announce-bounces=
@ietf.org</A>]</FONT>

<BR><FONT SIZE=3D2>On Behalf Of [e-mail]</FONT>

<BR><FONT SIZE=3D2>Sent: Saturday, October 18, 2008 2:00 PM</FONT>

<BR><FONT SIZE=3D2>To: [e-mail]</FONT>

<BR><FONT SIZE=3D2>Subject: I-D Action:draft-zorn-radius-pkmv1-01.txt =
</FONT>
</P>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts</FONT>

<BR><FONT SIZE=3D2>directories.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; : RADIUS Attributes for IEEE 802.16 Privacy Key</FONT>

<BR><FONT SIZE=3D2>Management Version 1 (PKMv1) Protocol Support</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : G. Zorn</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-zorn-radius-pkmv1-01.txt</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; : 14</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; : 2008-10-17</FONT>
</P>

<P><FONT SIZE=3D2>This document defines a set of RADIUS Attributes which =
are designed to</FONT>

<BR><FONT SIZE=3D2>provide RADIUS support for IEEE 802.16 Privacy Key =
Management Version 1.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.tx=
t">http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt</A>=
</FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP =
at:</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-=
drafts/</A></FONT>
</P>

<P><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>

<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>

<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_001_0010_01C969B9.45EBFE50--

------=_NextPart_000_000F_01C969B9.45EBFE50
Content-Type: Message/External-body;
	name="draft-zorn-radius-pkmv1-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-zorn-radius-pkmv1-01.txt"

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


------=_NextPart_000_000F_01C969B9.45EBFE50
Content-Type: text/plain;
	name="ATT00016.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00016.txt"

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

------=_NextPart_000_000F_01C969B9.45EBFE50--

------=_NextPart_000_0015_01C969B9.45EF0B90--


--
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, 29 Dec 2008 03:11:03 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: philosophy of the Design Guidelines document
Date: Sun, 28 Dec 2008 19:09:47 -0800
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

"There are more things in
heaven and earth=2C Horatio=2C

Than are dreamt of in your philosophy."=20
WILLIAM SHAKESPEARE / Hamlet Act 1.
Scene V abt. 1601
> No. I am asking for considering the needs of some of the other usage envi=
ronments as well.

At the risk of offending Shakespeare=2C perhaps its time to talk about the =
philosophy of the Design
Guidelines document.=20

The Design Guidelines document has two major aspects to it:

  1. Articulating Design Guidelines for RADIUS standard attributes (e.g. no=
t Extended Attributes).=20
  2. Improving the efficiency and scalability of the standardization proces=
s for RADIUS attributes=2C
    both within the IETF as well as in other SDOs.=20

Through aspects #1 and 2=2C the goal is to be able to address a wide range =
of needs in an
efficient way. =20

> If you believe that different requirements may lead to different results =
then you are essentially with me.

By recognizing the unique needs of SDOs=2C and by establishing a new proces=
s for the creation and
review of RADIUS attribute document=2C the Design Guidelines document would=
 seem
to be in agreement with this philosophy.=20

For example=2C the Design Guidelines document=2C by articulating the RADIUS=
 Design Guidelines=2C
allows=2C and even *encourages* SDOs to create their own RADIUS attribute s=
pecifications. =20
As we learned in the process of developing RFC 4663 (and also to some exten=
t after long=20
experience with RFC 3427)=2C it is becoming increasingly difficult for SDO =
participants to attend=20
both SDO and IETF meetings in order to complete management (MIB or AAA) doc=
ument. =20
These documents are more efficiently done in only one SDO=2C and if the doc=
ument doesn't=20
involve protocol changes=2C  then the work can most efficiently be done out=
side the IETF.=20

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

The overall philosophy that the IETF needs to focus its energy on the
*intersection* of requirements (including those from SDOs)=2C not on the *u=
nion*
of requirements.  At the same time=2C the IETF needs to provide the mechani=
sms
by which SDOs that need work done can do that work themselves.  In principl=
e
this approach enables design coherence to be maintained while at the same t=
ime
getting the IETF out of the critical path for much of the work that the SDO=
s need
to get done.=20

> At least I am asking to capture these aspects in the draft as there are
> really two types of complex attributes=2C namely those captured with the
> RADIUS extended attributes draft and then more complex onces that can be
> found also in the Diameter space. Reading through the draft one could eas=
ily
> get the impression that that document now allows the Diameter AVP structu=
re
> to be easily supported=2C which is not true.

Discussion of Extended Attribute design is out of scope of the Design Guide=
lines
document.  However=2C it *is* in scope for the Extended Attributes document=
.  So
I think you are pointing out an issue with the Extended Attributes document=
 here.=20

> It is fine not to align it 100% with Diameter. I just want the difference=
s
> to be documented in the document.

This is indeed a valid concern -- with respect to the Extended Attributes d=
ocument.=20

> Using a dictionary based approach is not a bad thing and will work for ma=
ny
> cases. The question is only how powerful the language for the dictionary =
has to be.
> It could be just a "attribute name"=2C "attribute code" and "data type".
>
> Regarding the "data type: Looking at the dictionary provided with FreeRAD=
IUS
> I noticed that there are datatypes support that are not listed in the RAD=
IUS
> Design Guidelines document.

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

However=2C the question of addition of data types *would* be relevant
to the Extended Attributes document=2C where presumably we are not
as concerned with backward compatibility.=20

> BUT:
>
> * If I take certain Diameter documents and I want to provide the
> same/similar functionality in RADIUS then I cannot use the "simple"
> attribute encoding. Example: Diameter QoS attribute. In that case I have =
to
> come up with my own RADIUS attribute encoding for this purpose.

I do think this is a useful question to consider -- but I think that questi=
on
should be considered in the context of the Extended Attributes document=2C
not the Design Guidelines document.=20

> Even though these cases seem to be implicitly covered by the RADIUS desig=
n
> guidelines document I still got beaten up with the RADIUS GEOPRIV documen=
t.

If you have suggestions for clarifying the language=2C feel free to submit =
an issue.=20
However=2C in general=2C IETF beatings do not have to be linked to an offen=
se=2C real
or imagined.  Rather the general philosophy seems to be "beatings will cont=
inue
until morale improves". :)

> I believe there is value in documenting what the perceived mode of operat=
or
> for a protocol is.

Sure.  The WMF has produced hundreds=2C even thousands of pages of
documentation=2C most of which is publicly available.  That they have
been able to utilize RADIUS for this purpose without changing the
protocol seems like a good example of the approach advocated by
the Design Guidelines document.=20

> I think that's a Very Bad Idea (tm) and falls under the recommendation ag=
ainst
> polymorphic attribute design.

It should be noted that the Design Guidelines document is a BCP=2C and the
IETF is not the protocol police.  As a result=2C  SDOs are free to create
polymorphic attributes within their SDO-specific attribute spaces.  =20

>I believe that the argument that complex
>attributes lead to interoperability=2C deployment and security
>issues as stated in the draft is incorrect and can of course happen
>from certain implementation choices.

I would agree that a greenfield implementation could indeed support
a wider range of attribute complexity with little ill effects.  For example=
=2C
most Diameter implementations support a considerably wider range
of data types=2C grouping formats=2C etc. than most RADIUS implementations
do=2C because they were designed from the start to do this.

Where greenfield capabilities are being created (such as in the Extended
Attributes work)=2C these arguments can and should be entertained.  However=
=2C
where we are talking about a protocol with dozens of legacy implementations=
=2C
the bar is set much higher=2C because the WG not only has to take into=20
account the interests of those who want to do new things=2C but also the
impact on existing deployments.  Manding a forklist upgrade for existing
RADIUS servers which may be long off maintenance in order to add modest
new capabilities is not something that network administrators will apprecia=
te.=20

> As an example: Consider the work in the NEA working group that has an imp=
act
> to the AAA server. Simple? Not really. Will people use and deploy it? Who=
 knows.

As far as I can tell=2C the "statements of health"/"posture attributes"
that are being designed in NEA WG fit within the "opaque blob" concept
articulated in the Design Guidelines document.  That is=2C there is no requ=
irement
that a AAA server not implementing NEA change a single line of code. =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, 28 Dec 2008 04:20:14 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Hannes Tschofenig'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>, "'D. B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sun, 28 Dec 2008 11:17:52 +0700
Message-ID: <004f01c968a3$58065de0$081319a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0AAEgOkwACw2kYAAEtIfoA==
Content-Language: en-us

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

...

> Instead, I am asking for something different. I would like to have a
> bit more reality touch 

I wish you luck, but I'm afraid you're in the wrong WG for that...



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


Envelope-to: [e-mail]
Delivery-date: Sat, 27 Dec 2008 22:59:12 +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=pBOIq83hFJ4JYOJZH1Llm43smajMNO+aYT7UXre5Ors=; b=I1oOfFw8q2cOfgcO/LqssaYXhHpV1CTZFjXNGFY440e+VFrVVN9tUisenUGLmWG0O1 UP39SCvQI56sn3kfzp+G3g9/LSoezuqstZRPgofsZ1mJsH6w0z5OpHzjgRZ47JEZdw3j EuH9pp0UzDUJVP1VxjY8UGPMzx0tXcTLAbMhI=
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=x/W+817qPrs4NXJQqZrlHkbwdwfZ58ERkgJA1g8lBUDFCb2AuM1nffz0m9eU4o9cBF B7TfbZLKF8A46LH0zJacdVmTAPU1sSbLN9EA2o1WfIQosMTypclXjXEUDi7QPfjl9E1w mTFbTpQnJbzDWkQDIbu7gGP30OzmHz3gczeTo=
Message-ID: <[e-mail]>
Date: Sat, 27 Dec 2008 17:58:36 -0500
From: "Greg Weber" <[e-mail]>
To: "D. B. Nelson" <[e-mail]>
Subject: Re: Question regarding draft-ietf-radext-design-05.txt
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sat, Dec 27, 2008 at 5:02 PM, D. B. Nelson <[e-mail]> wrote:
> Greg Weber writes...
>
>> ...I'd like to remind that the original submission of the
>> Design Guidelines was back in July '05...
>
> True enough.  As I've said very recently, the debate over complex attributes
> dates all the way back to the chartering of RADEXT.

I've read all the recent list traffic, but I'm not sure it's fair to
characterize this as an SDO run-around as opposed to a
failure of IETF process.  So, I'd be a bit careful about that.  :-)

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


Envelope-to: [e-mail]
Delivery-date: Sat, 27 Dec 2008 22:32:15 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 17:32:17 -0500
Message-ID: <81396BAAD8D946D484D97C0F6E33537B@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0AAEgOkwACw2kYAABwCI4A==

Hannes Tschofenig writes...

> Given the available data types this was essentially the only 
> choice to comply with the idea of the data dictionary and the
> desire to have everything be covered under the available data
> types.

Yes.  The current RADIUS data types are very limiting, in that they
represent only scalars and octet arrays (strings).  I once suggested that we
try to address this in a fashion similar to the way SMI (SNMP) handles this
issue, i.e. to allow sequences of basic types to be encoded in an attribute
to form a complex type.  That went over like a lead balloon. :-(

> Whether the AAA server had to be updated in order to provide
> additional parsing capability depends a lot on the procedure how
> some of these attributes (and the values in them) get introduced
> into the system in the first place.

Sure.  The problem is, I suspect, that if one developer gets to standardize
attributes that were designed based on _his_ server implementation, that may
have impact on everyone else whose server is implemented differently.  What
turns out to be a natural encoding representation for a given implementation
/ system design may be cumbersome for another design, even though both are
fully "compliant" with the feature requirements.  Standards have to serve
the least (reasonable) common denominator.



--
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, 27 Dec 2008 22:02:37 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 17:02:20 -0500
Message-ID: <91B5F64EEDA6406C98E8BFE5D7FB8438@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: Acloaq8VcfRKItoiRPi7aHH2V4yHjgAAtIiA

Greg Weber writes...

> ...I'd like to remind that the original submission of the 
> Design Guidelines was back in July '05...

True enough.  As I've said very recently, the debate over complex attributes
dates all the way back to the chartering of RADEXT.

> And the SDOs have business issues that must be addressed in
> a more timely fashion.

This is more an issue of style that substance.  The work could easily have
been done in "classic" RADIUS attributes, albeit less elegantly.  There's a
school of AAA design style that wants to encapsulate the complex C-language
(or similar) "structs" that are used in the client and server code into
RADIUS attributes, as if RADIUS were some form of RPC mechanism.  :-)  The
debate is about whether or not that's a good idea.  It's certainly a valid
design approach -- the question is whether or not it fits well within
RADIUS.  If you view RADIUS as little more that a convenient transport for
application data, maybe it does.


--
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, 27 Dec 2008 21:33:22 +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=EsnBtHIP5VPlrzLOj2jIGWGkxp7rR5frnj2gevt5kEM=; b=CBpPGxs2kCrKvN8jdX8WHKw9XSReuHn4DdvtfNQpAztzrMjjPmwjevxEdD1nKKwSPQ sf7YtEEwhI+uEGxwu3TEvyVzoGgt0MRxXtsa8YPaLxxkY6Y+V3RADEaxsV2Aavx/w42h 72+oOJypFfIuQ2fEWJ6Cam4RvvVdQyh9s19nw=
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=FwycVKGdgzpzi1l07KWB+0MvB+QbW/aYyne34TBMxCchDbsqLVKrtsbhr+Y2L/tFBT a+cmLxNUrsXTP/06yBU+5U8ZYO5KOq9VnJyHoyE7JY5PlITTiw/dnGS76RKq34Fly3+J 9HLNUPQ1l5jmJrwgZOBFyZm7YOfWhf2nwCo6E=
Message-ID: <[e-mail]>
Date: Sat, 27 Dec 2008 16:32:56 -0500
From: "Greg Weber" <[e-mail]>
To: "D. B. Nelson" <[e-mail]>
Subject: Re: Question regarding draft-ietf-radext-design-05.txt
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sat, Dec 27, 2008 at 4:09 PM, D. B. Nelson <[e-mail]> wrote:
> Yeah.  Some of the folks in WiMAX were among those who were early advocates
> of deeply complex attribute encodings in RADIUS.  When the RADEXT WG didn't
> embrace that design philosophy, the work got done outside the IETF.  If you
> don't like the consensus you find here, you take the work elsewhere.  :-)

I'm not sure if that accurately captures the chronological sequence of events,
but I'd like to remind that the original submission of the Design Guidelines
was back in July '05;  three & a half years back.
The WG has had trouble embracing _any_ design philosophy.
And the SDOs have business issues that must be addressed in a more
timely fashion.

--
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, 27 Dec 2008 21:21:31 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Date: Sat, 27 Dec 2008 16:21:29 -0500
Message-ID: <9173F5229EC642BF9FDE909B85DBEED7@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcloPXtvYPpp/nXcQ7mHZYBs9phL8wAKgl2w

Alan DeKok writes...

>> My immediate suggestion: Don't put a RADIUS / Diameter compatibility
>> considerations section into the document as it is almost always wrong. 
>
>  I'll have to ask the chairs about this...

<Chair Hat = on>

I don't think it's OK to simply "punt" on Diameter interoperability
considerations in RADIUS extensions work.  It's in the RADEXT charter, for
good reason.

I agree that the boilerplate text we've been using recently is flawed.  It's
not enough to effectively say "just follow NASreq".  There are a number of
issues to address, with complex AVP encoding and Application IDs being top
of mind.  It seems to me that the authors so RFC 4005 thought about
importing all of the RADIUS attributes that existed at the time that
document was published under the NASreq Application ID, but not about future
RADIUS extensions.  The whole mandatory attributes vs. new application IDs
thing is a major headache that, IMHO, DIME needs to solve.

We need tome assistance from folks in DIME, and we may need them to create
an RFC 4005bis, or some such.

I don't think we can simply omit discussing Diameter compatibly and
interoperability.

If there is a good reason why Diameter interoperability (ease of gateway) is
not required for a given application area, then we can simply say that in
the document -- don't bother trying to import these attributes into
Diameter.

<Chair Hat = off>



--
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, 27 Dec 2008 21:09:59 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 16:09:59 -0500
Message-ID: <9F761C14C3A34A2CAEEDC5A4F2B08EF9@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcloLX5i4T2PFLWtQXWl2akwu0ph+gAOUTMg

Alan DeKok writes...

>> Regarding the "data type: Looking at the dictionary provided
>> with FreeRADIUS I noticed that there are datatypes support that
>> are not listed in the RADIUS Design Guidelines document.
>
>  Yes.  One word: WiMAX.

Yeah.  Some of the folks in WiMAX were among those who were early advocates
of deeply complex attribute encodings in RADIUS.  When the RADEXT WG didn't
embrace that design philosophy, the work got done outside the IETF.  If you
don't like the consensus you find here, you take the work elsewhere.  :-)



--
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, 27 Dec 2008 20:44:31 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Date: Sat, 27 Dec 2008 15:44:13 -0500
Message-ID: <CE9FC801D39D4323A7868DE17CA3BF03@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcloPXtvYPpp/nXcQ7mHZYBs9phL8wAJMQ8g

Alan DeKok writes...

>>> "Can lead ...".  The text is describing common practices and 
>>> deployments.  The only reason to change the text is if those 
>>> practices are not, in fact, in common use.
>> 
>> But these type of statements are used against draft authors who
>> decided to pick a different format and then we have all these
>> discussions. 
>> 
>> I think it would be useful to provide a bit more context, as 
>> argued a few paragraphs above. 
>
>  Ok.  We should be able to make it clearer that the opinions
> against complex attributes are SHOULD NOT.

Hmmm...  Two thoughts on this:

(1) Since the Design Guidelines are to be a BCP, guidance about design
choices, short of a major security flaw or a redesign of the RADIUS base
protocol, will end up being a SHOULD or SHOULD NOT.  MUST and MUST NOT will
be rare.

(2) At some level, RADIUS Design Guidelines will likely be as popular with
certain developers as corporate coding style guidelines.  :-)  That's the
nature of the beast.  Having said that, if the guidelines value everyone's
individual design styles equally, then the guidelines serve no purpose.  The
value in creating a RECOMMENED design style is in achieving a certain level
of uniformity.  There is a fine balance to be struck between standardization
and creative expression.



--
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, 27 Dec 2008 19:33:25 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, "'D. B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 21:32:45 +0200
Message-ID: <00a101c96859$e5267290$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0AAEgOkwACw2kYA=

Hi Bernard, 

Maybe I was misunderstood. 

I am not asking for RADIUS to become Diameter (even though the group is
heading into that direction in a step-by-step fashion already). 

Instead, I am asking for something different. I would like to have a bit
more reality touch regarding what can be done with the encoding in RADIUS
today and where custom encoding is necessary. 

To give you an example: Some time back when RFC 4675 was written it was
state-of-the-art to define an attribute as:

User-Priority-Table

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |          String
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    String
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    String            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where 'String' represented a customing encoding. Other attributes in the
same document followed the same format. 

Given the available data types this was essentially the only choice to
comply with the idea of the data dictionary and the desire to have
everything be covered under the available data types. 

The dictionary might look like: 

ATTRIBUTE      User-Priority-Table     59         String 

Today, the encoding of RFC 4675 might quite likely be different and there is
still a lot of possibility to argue around why this is still a good
encoding. 

Whether the AAA server had to be updated in order to provide additional
parsing capability depends a lot on the procedure how some of these
attributes (and the values in them) get introduced into the system in the
first place. In some systems they might be statically provisioned into a
database and just retrieved without any additional logic and in other
systems they would be dynamically generated and there might be some logic
behind all this stuff. 

Now, the extended attributes draft extends the limits a bit. 

Still, there is this tendency to label custom encoding (like the one from
above) as really bad (by calling it "interoperability and deployment issues"
or see the discussion in Section 2.1.4 of draft-ietf-radext-design-05.txt
regarding "Complex Attributes and Security"). 

I guess nobody would argue that attributes that can have a simple encoding
are supposed to get unnecessarily complex. 

However, I would like to present the story in a way that custom encoding is
a side-effect of the design constraints that are introduced by the work the
group did. If you want something that does not fall into the "simple scheme"
(which btw happens quite often these days) then a custom encoding is more
difficult to avoid. 

There is nothing bad about this. The reason for this is largely based on the
fact that implementers have seen custom encoding already for a while and
hence they have found ways to deal with it.

Maybe what I should be doing is to go through the RADIUS Design Guidelines
draft and to make detailed text proposals to make it clearer what I actually
mean. 

Ciao
Hannes

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Bernard Aboba
>Sent: 27 December, 2008 00:18
>To: 'D. B. Nelson'; [e-mail]
>Subject: RE: Question regarding draft-ietf-radext-design-05.txt
>
>"I think that the basic issues here is that there is a 
>disconnect between the consensus position of the RADEXT WG (to 
>keep things pretty simple) and need you are describing to 
>provide [near] capability parity with Diameter."
>
>To quote the conclusions of the AAA protocol Evaluation team 
>(RFC 3127) with
>
>respect to the prospects for enhancing RADIUS so as to meet the AAA
>requirements:
>
>"  Radius++ is not considered acceptable as an AAA protocol.  
>There is a
>   fairly substantial amount of engineering required to make 
>it meet all
>   requirements, and that engineering would most likely result in
>   something close to the functionality of Diameter." 
>
>Indeed, at various points with the RADEXT WG, questions have 
>come up relating to adoption of one or more features of 
>Diameter, and WG consensus has lined up with the RFC 3127 assessment:
>
>1) during the discussion on Extended Attributes, the question 
>arose as to whether RADIUS should adopt the Diameter AVP 
>format.  The WG consensus was against this, and as a result 
>only modest extensions (for tagging and additional attribute 
>space) were adopted. 
>
>2) during the transport work, questions have arisen about the 
>suitability of the RFC 3539 watchdog timer and failover logic. 
> Again, WG sentiment does not appear to support a strict port 
>of the Diameter functionality to RADIUS.  
>
>So while it is possible (and potentially desirable) for RADEXT 
>to develop enhancements (such as Extended Attributes and 
>RADSEC), this falls considerably short of providing the full 
>functionality of Diameter. 
>
>
>
>
>
>
>--
>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: Sat, 27 Dec 2008 16:07:24 +0000
Message-ID: <[e-mail]>
Date: Sat, 27 Dec 2008 17:07:12 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: 'Glen Zorn' <[e-mail]>,  "'David B. Nelson'" <[e-mail]>, [e-mail]
Subject: Re: Issues with draft-ietf-radext-extended-attributes-05.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> There are multiple issues here, I think:
> 
> a. Whether existing implementations will have a problem with a vendor-id
> of zero, regardless of the size of the type code space, and the attribute
> numbering;  

  I can think of at least one that does.  I'm not sure anyone else is
going to admit that their implementation is less than perfect. :)

> b. Whether the *combination* of a vendor-id of zero along with attribute
> usage 1-255 can cause problems; 
>
> If we have problem a, then the fix would be to assign the IETF a non-zero
> Vendor-Id; merely prohibiting attributes 1-255 would not do the trick. 
> 
> If we only have problem b, then we could prohibit attributes 1-255 from
> being assigned. 

  That would be the solution with the minimum changes.

  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, 27 Dec 2008 16:06:10 +0000
Message-ID: <[e-mail]>
Date: Sat, 27 Dec 2008 17:05:19 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Hannes Tschofenig <[e-mail]>
CC: [e-mail]
Subject: Re: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hannes Tschofenig wrote:
>>  Yes.  Some RADIUS servers also support complex attribute 
>> decoding through simple scripting languages.  But this has not 
>> been historically wide-spread.
> 
> These assumptions have been built-into the draft and it would be good to be
> explicit what type of RADIUS server you are talking about when you argue
> that complex attributes lead to implementation, deployment and security
> problems. This may very well be true be true for some of these servers but
> certainly not true for many others. Maybe these older servers don't even
> care about the functionality we are specifying today. 

  That's a good point.

  Can you suggest updated text for the draft?

> My immediate suggestion: Don't put a RADIUS / Diameter compatibility
> considerations section into the document as it is almost always wrong. 

  I'll have to ask the chairs about this...

>> "Can lead ...".  The text is describing common practices and 
>> deployments.  The only reason to change the text is if those 
>> practices are not, in fact, in common use.
> 
> But these type of statements are used against draft authors who decided to
> pick a different format and then we have all these discussions. 
> 
> I think it would be useful to provide a bit more context, as argued a few
> paragraphs above. 

  Ok.  We should be able to make it clearer that the opinions against
complex attributes are SHOULD NOT.

>>>> Btw, has the draft been sent to other SDOs for review?
>>  Suggestions?
> Almost all the major SDOs have to deal with RADIUS in some form:
> Wimax Forum, Broadband Forum, 3GPP, 3GPP2, CableLabs

  I think the chairs should ask for official statements from the other SDOs.

  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, 27 Dec 2008 14:15:43 +0000
Message-ID: <[e-mail]>
Date: Sat, 27 Dec 2008 15:14:52 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Hannes Tschofenig <[e-mail]>
CC: "'D. B. Nelson'" <[e-mail]>, [e-mail]
Subject: Re: Question regarding draft-ietf-radext-design-05.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hannes Tschofenig wrote:
> Two examples: 
> 
> * EAP Channel Bindings: I mentioned that I was not able to find anyone in
> the cellular industry that was interested in this. 
> Does it mean that the work will not be done? No, because folks argue that in
> the university space and enterprise environment it could be useful. 

  The WiFi roaming people are interested in this.  It permits them to
extend the enterprise environment across global roaming consortia.

> * TLS and TCP for RADIUS: Most folks in the cellular space don't care about
> this because they are specifying Diameter all over the place. 
> As we have learned, folks working at the universities have different
> constraints and needs (e.g., using software that is downloadable for free
> from the Internet as a basis for their AAA deployment). As such, they like
> this new work as it will solve their problem without switching to commercial
> solutions or to switch to OpenDiameter etc. 

  The WiFi roaming people are also interested in this, especially to
simplify connections (avoiding IPSec), and to minimize lost packets in
EAP sessions.

>> Otherwise, why maintain both AAA protocols going forward.  :-)
> 
> There are many reasons -- none of them have anything todo with technical
> arguments. 

  "Install base". :)

> Using a dictionary based approach is not a bad thing and will work for many
> cases. 
> The question is only how powerful the language for the dictionary has to be.
> It could be just a "attribute name", "attribute code" and "data type".  
> 
> Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
> I noticed that there are datatypes support that are not listed in the RADIUS
> Design Guidelines document.

  Yes.  One word: WiMAX.

> Additionally, FreeRADIUS support some form of scripting also in addition the
> to the dictionary, see http://wiki.freeradius.org/Configuration. 

  It has a simple policy language that is not Turing complete.  The
policy language also cannot (currently) decode attributes of complex
format.  The data types are still dictionary driven.

> I believe there is value in documenting what the perceived mode of operator
> for a protocol is. 

  I agree.

> Folks use the protocol they are familiar with for their favorite purpose
> (even if it has nothing todo with AAA anymore). There are certain groups
> that are more familiar with RADIUS and other's that bought into Diameter. It
> is just a protocol and both of them are not difficult to implement. 

  Hmm.... I would beg to differ. But that's not part of this discussion.

> Well. I would like to hear from other folks in the group whether they think
> RADIUS server implements deployed in larger networks are so simple.

  Yes.

> A
> Diameter implementation can also be pretty simple if you don't make use of
> certain features and extensions. 

  No opinion... I lack sufficient experience.

> As such, this is very little todo with the protocol itself rather with the
> features that folks want to accomplish. 
> 
> As an example: Consider the work in the NEA working group that has an impact
> to the AAA server. Simple? Not really. Will people use and deploy it? Who
> knows. 

  NEA is complicated.  See the NEA list archives for my opinions.

  That being said, it will likely get implemented... like WiMAX.

  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, 27 Dec 2008 11:25:07 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'D. B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Sat, 27 Dec 2008 13:24:23 +0200
Message-ID: <009901c96815$acb5b040$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0AAdWivA

Hi David, 

>Hannes Tschofenig writes...
>
>>> The issue is whether extensions to the RADIUS on-the-wire protocol 
>>> should be designed to accommodate the traditional, 
>>> data-dictionary-driven RADIUS server, or not.  I think what we are 
>>> saying is that, while complex RADIUS server implementations exist, 
>>> RADIUS protocol enhancements should not be at the expense of the 
>>> simple implementations.
>> 
>> I think it is not a question of simple or complex implementation.
>> The main issue is what the specific customers want. AAA servers are 
>> used by different clusters of customers (different types of 
>> enterprises, WLAN hotspots, universities, ISPs, cellular operators, 
>> etc). These customers have different needs but the guidelines do not 
>> acknowledge that there are different classes of customers and hence 
>> the design guidelines are often applied without considering 
>these aspects.
>
>Certainly there are different classes of customers, different 
>market segments, different use cases, etc.  Does that mean 
>that the protocol has to differ to address each?

No. I am asking for considering the needs of some of the other usage
environments as well. 

>IMHO, that's 
>not a formal "protocol" if it differs depending on who's using 
>it.  The syntax, i.e. message format, of a protocol needs to 
>be invariant; only the content of the messages should be variable.

I am not sure I fully understand what you are saying. 

If you believe that different requirements may lead to different results
then you are essentially with me. 

Two examples: 

* EAP Channel Bindings: I mentioned that I was not able to find anyone in
the cellular industry that was interested in this. 
Does it mean that the work will not be done? No, because folks argue that in
the university space and enterprise environment it could be useful. 

* TLS and TCP for RADIUS: Most folks in the cellular space don't care about
this because they are specifying Diameter all over the place. 
As we have learned, folks working at the universities have different
constraints and needs (e.g., using software that is downloadable for free
from the Internet as a basis for their AAA deployment). As such, they like
this new work as it will solve their problem without switching to commercial
solutions or to switch to OpenDiameter etc. 


>
>> I believe I can say that because I was a victim of "strictly 
>applying"
>> the guidelines as they are, despite the examples provided in the 
>> document on EAP etc.
>
>This harkens back to the age old debate on whether RADIUS 
>should provide facilities to encode complex / structured data. 
> This debate is as old as
>the RADEXT WG itself.   The current RADEXT WG consensus is that RADIUS
>doesn't need extensive "structuring" facilities, and that the 
>simple "grouping" facilities, e.g. of the Extended Attributed 
>draft, is sufficient.

At least I am asking to capture these aspects in the draft as there are
really two types of complex attributes, namely those captured with the
RADIUS extended attributes draft and then more complex onces that can be
found also in the Diameter space. Reading through the draft one could easily
get the impression that that document now allows the Diameter AVP structure
to be easily supported, which is not true. 

>Yes, this is far short of Diameter's capabilities, but we 
>decided that RADIUS should not be extended to maintain feature 
>parity with Diameter.

It is fine not to align it 100% with Diameter. I just want the differences
to be documented in the document. 

>Otherwise, why maintain both AAA protocols going forward.  :-)

There are many reasons -- none of them have anything todo with technical
arguments. 

>
>>>> I am not even sure that it is always the right way to put such a 
>>>> section in a RADIUS document when they authors do not envision 
>>>> Diameter to be used in their specific environment.
>>>
>>>What do you suggest?
>>
>> Based on the discussion we had at the AAA doctors meeting I 
>will think 
>> about some way forward.
>
>Thanks!
>
>>> Please elaborate...
>>
>> The above statement makes the assumption that the parsing happens in 
>> some C-alike language that was used to implement the entire RADIUS 
>> server. There are indeed issues when you touch this code.
>>
>> However, most AAA servers have an abstract language they use for 
>> handling of msg processing. This language is typically not C and 
>> written in a way that it does not lead to security issues. As such, 
>> even additional parsing that has to be implemented it does 
>not lead to 
>> any interoperability or security problems.
>
>Hmmm...  "Most"?  The metric we have been using is the "data 
>dictionary driven" server, which is admittedly a fairly old 
>implementation technique.

Using a dictionary based approach is not a bad thing and will work for many
cases. 
The question is only how powerful the language for the dictionary has to be.
It could be just a "attribute name", "attribute code" and "data type".  

Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
I noticed that there are datatypes support that are not listed in the RADIUS
Design Guidelines document.

Additionally, FreeRADIUS support some form of scripting also in addition the
to the dictionary, see http://wiki.freeradius.org/Configuration. 


>Such servers may have auxiliary "policy servers" that make 
>more complex decisions about authorization data than is 
>possible with simple attribute matching schemes or user group 
>membership schemes.  The relevant point of discussion, 
>however, is the on-the-wire RADIUS message format.

I am not saying that everyone should come up with the most complex attribute
formats. 
If one can avoid a custom attribute format then this is certainly
appreciated as it will lower the time it takes to implement a specific
functionality.

BUT: 

* If I take certain Diameter documents and I want to provide the
same/similar functionality in RADIUS then I cannot use the "simple"
attribute encoding. Example: Diameter QoS attribute. In that case I have to
come up with my own RADIUS attribute encoding for this purpose. 

* If I have features that already require additional code at the AAA server
(like the location stuff) then it does not make a big difference whether I
have to write a few lines more or less -- I have to touch the code base
already anyway. 

Even though these cases seem to be implicitly covered by the RADIUS design
guidelines document I still got beaten up with the RADIUS GEOPRIV document. 


>
>RADIUS was designed to provision pretty simple things.  It 
>originally envisioned each attribute as having an "atomic" 
>value, not some complex, structured message.  I understand 
>that AAA servers today attempt to provision more complex 
>things, and this is wherein the friction results.
>Should RADIUS be extended, much as Diameter has, to support a 
>more complex and nuanced set of provisioning capabilities? 

RADIUS has already been extended to provide more than "simple things". 
Example: Key distribution in Wimax. 


I believe there is value in documenting what the perceived mode of operator
for a protocol is. 


> If 
> so, then why do we need Diameter? :-)

Folks use the protocol they are familiar with for their favorite purpose
(even if it has nothing todo with AAA anymore). There are certain groups
that are more familiar with RADIUS and other's that bought into Diameter. It
is just a protocol and both of them are not difficult to implement. 

So, I don't see a problem with regard to this aspect. 

>
>>> So, what you are suggesting is that the syntax and semantics of 
>>> RADIUS attributes are contextually dependent on some policy 
>decision 
>>> that is opaque to the RADIUS client, proxies, etc?  I think 
>that's a 
>>> Very Bad Idea (tm) and falls under the recommendation against 
>>> polymorphic attribute design.
>>
>> No, my argument is different. I believe that the argument 
>that complex 
>> attributes lead to interoperability, deployment and security 
>issues as 
>> stated in the draft is incorrect and can of course happen 
>from certain 
>> implementation choices.
>
>I see.  I guess I still disagree.  Yes, anything, no matter 
>how complex, convoluted and baroque can be made to 
>interoperate with sufficient attention to detail.  A pig, 
>given sufficient thrust, can be made to fly.  :-)
>
>> Most AAA server do not have these issues as they are providing an 
>> abstract language for the developer for business logic, parsing, msg 
>> handling, etc.
>
>So, you're saying that today's AAA Servers are really Policy Servers?

Yes. 

>
>I think that the basic issues here is that there is a 
>disconnect between the consensus position of the RADEXT WG (to 
>keep things pretty simple) and need you are describing to 
>provide [near] capability parity with Diameter.  
Well. I would like to hear from other folks in the group whether they think
RADIUS server implements deployed in larger networks are so simple. A
Diameter implementation can also be pretty simple if you don't make use of
certain features and extensions. 
As such, this is very little todo with the protocol itself rather with the
features that folks want to accomplish. 

As an example: Consider the work in the NEA working group that has an impact
to the AAA server. Simple? Not really. Will people use and deploy it? Who
knows. 

Ciao
Hannes

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


--
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, 26 Dec 2008 23:26:11 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue 290
Date: Fri, 26 Dec 2008 18:25:44 -0500
Message-ID: <F2FD28F2CE654E6E9CD060EA74B5A024@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBLtlfgAAVJvUAAA1i4IA==

Bernard Aboba writes...

> Is there an IETF last call comment on the Guidelines document relating
> to this?

Yes.  I believe Hannes raised the issue.  Maybe others.

> Since Extended Attributes uses Attribute 26, I had assumed that it
> inherits all the capabilities of that attribute.

Yes and no.  Basically, RFC 2865 allows VSAs to contain _anything_ in the
"value" portion of the attribute that will fit into 253 (more or less)
octets.  There is a recommended format, and multiple instances in the
recommended format may be included, but so may anything else.

For the purpose of the Extended Attribute, I think we absolutely must
retract the "but so may anything else" portion, and stick to the format as
defined in the Extended Attributes draft.

Of course, I suppose that one could have a Vendor Specific Extended
Attribute.  :-)



--
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, 26 Dec 2008 22:18:23 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'D. B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Fri, 26 Dec 2008 14:17:51 -0800
Message-ID: <000701c967a7$caa61090$5ff231b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0AAEgOkw
Content-Language: en-us

"I think that the basic issues here is that there is a disconnect between
the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter."

To quote the conclusions of the AAA protocol Evaluation team (RFC 3127) with

respect to the prospects for enhancing RADIUS so as to meet the AAA
requirements:

"  Radius++ is not considered acceptable as an AAA protocol.  There is a
   fairly substantial amount of engineering required to make it meet all
   requirements, and that engineering would most likely result in
   something close to the functionality of Diameter." 

Indeed, at various points with the RADEXT WG, questions have come up
relating
to adoption of one or more features of Diameter, and WG consensus has lined
up
with the RFC 3127 assessment:

1) during the discussion on Extended Attributes, the question arose
as to whether RADIUS should adopt the Diameter AVP format.  The WG
consensus was against this, and as a result only modest extensions
(for tagging and additional attribute space) were adopted. 

2) during the transport work, questions have arisen about the
suitability of the RFC 3539 watchdog timer and failover logic.  Again,
WG sentiment does not appear to support a strict port of the
Diameter functionality to RADIUS.  

So while it is possible (and potentially desirable) for RADEXT to
develop enhancements (such as Extended Attributes and RADSEC), this 
falls considerably short of providing the full functionality of 
Diameter. 






--
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, 26 Dec 2008 21:53:52 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'D. B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Issue 298
Date: Fri, 26 Dec 2008 13:53:31 -0800
Message-ID: <000601c967a4$646492a0$2d2db7e0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBMNclgAAUcDbA=
Content-Language: en-us

David Nelson said:

"I think we want to be very careful here.  The correct behavior for
implementations that have not included the Extended Attribute =
functionality
is to treat them as unrecognized / unknown VSAs, and to ignore them.  =
They
may be logged in some fashion, of course.  Whether they should be =
included
in RADIUS Accounting or Dynamic RADIUS packets as "unknown attributes" =
is
open to debate.

What I think should not happen is for Extended Attributes to be
"selectively" understood.  The implementation either "groks" the =
Extended
Attribute format, in which case the rules for standard attributes (or =
SDO
Specific Attributes) apply, or it simply sees them as unrecognized / =
unknown
VSAs, in which case the rules for unknown attributes apply.  We should =
not
encourage implementations to treat them as unknown for one purpose but =
known
for another."

[BA] Very well put.  Care to take a shot at providing text to resolve =
the
issue?

> So one question is whether this implies that a NAS should signal its
> support for Extended Attributes in the Access-Request in some way --=20
> so as to make it clear to the RADIUS server how those attributes would
> be interpreted.=A0=A0

I think we should make that feature a MUST.

[BA] That seems sensible to me.  The question is how to do it.  Maybe
include
an Extended Attribute of Type 1 with a NUL in it within an =
Access-Request?


--
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, 26 Dec 2008 21:51:38 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'D. B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Issue 290
Date: Fri, 26 Dec 2008 13:51:14 -0800
Message-ID: <000501c967a4$12e00ae0$38a020a0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBLtlfgAAVJvUA=
Content-Language: en-us

David Nelson said:

"Would that be a RADEXT or DIME work item?"

It would probably be a DIME WG work item, assuming that they are willing to
take it.
However, before making progress on that we would need a viable proposal (and
a document 
that references it). 

David Nelson also said:

"There is a larger issue here, currently being discussed as part of the
RADIUS Design Guidelines commentary."

Is there an IETF last call comment on the Guidelines document relating to
this? 
I've been trying to keep the tracker up to date on the last call issues, but
I suspect I may be missing some. 

"I think we need to nail down that issue before we can effectively
close on the Design Guidelines and Extended Attributes drafts"

Since Extended Attributes uses Attribute 26, I had assumed that it
inherits all the capabilities of that attribute.  RFC 2865, Section
5.26 says:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.


--
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, 26 Dec 2008 21:42:55 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: "'Glen Zorn'" <[e-mail]>, "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Fri, 26 Dec 2008 13:42:02 -0800
Message-ID: <000401c967a2$ca01ac80$5e050580$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclnPkT/uDSURugXS62C+vaznOHnjAAY1t0g
Content-Language: en-us

Alan DeKok said:

"I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals."

There are multiple issues here, I think:

a. Whether existing implementations will have a problem with a vendor-id
of zero, regardless of the size of the type code space, and the attribute
numbering;  

b. Whether the *combination* of a vendor-id of zero along with attribute
usage 1-255 can cause problems; 

If we have problem a, then the fix would be to assign the IETF a non-zero
Vendor-Id; merely prohibiting attributes 1-255 would not do the trick. 

If we only have problem b, then we could prohibit attributes 1-255 from
being assigned. 



--
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, 26 Dec 2008 20:34:43 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue 278
Date: Fri, 26 Dec 2008 15:34:41 -0500
Message-ID: <E17677D29E89483F963A7560621290C1@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclnPZeM2N6hgugMQVaqoGzV63gIGAAWsUyg

Alan DeKok writes...
 
>  I was thinking also API's.  Some systems have internal API's that
> add/delete/lookup attributes based on a key.  The key is (vendor-id,
> attribute).  The problem is that looking up traditional RFC attributes
> is often done by setting vendor-id=0.

In hind sight, that was a very inconvenient thing for implements to have
done, although I can see its attraction in terms of abstracting properties
of various classes of attributes.

>  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
> something new, this will cause problems for many implementations.

I suggested at two different IETF meetings that using a Vendor ID of 0 might
be problematic.  I envisioned just this sort of scenario.  No one seemed to
see the same issues, since my suggestion gathered no support.  :-)  We could
revisit the use of 0 and assign some other, non-zero, PEN.

>  Using 1..255 also prevents the grouping of standard RFC attributes
> into the extended-attribute format, which was one of Glens goals.

Or we could reserve the legacy values 0..255.



--
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, 26 Dec 2008 20:17:13 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Fri, 26 Dec 2008 15:16:51 -0500
Message-ID: <E93C26F4734B42469081CE9DD5EBBEC1@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWAAQUde0A==

Hannes Tschofenig writes...

>> The issue is whether extensions to the RADIUS on-the-wire
>> protocol should be designed to accommodate the traditional,
>> data-dictionary-driven RADIUS server, or not.  I think what we 
>> are saying is that, while complex RADIUS server 
>> implementations exist, RADIUS protocol enhancements should not 
>> be at the expense of the simple implementations.
> 
> I think it is not a question of simple or complex implementation.
> The main issue is what the specific customers want. AAA servers are
> used by different clusters of customers (different types of enterprises,
> WLAN hotspots, universities, ISPs, cellular operators, etc). These
> customers have different needs but the guidelines do not acknowledge
> that there are different classes of customers and hence the design
> guidelines are often applied without considering these aspects.

Certainly there are different classes of customers, different market
segments, different use cases, etc.  Does that mean that the protocol has to
differ to address each?  IMHO, that's not a formal "protocol" if it differs
depending on who's using it.  The syntax, i.e. message format, of a protocol
needs to be invariant; only the content of the messages should be variable.

> I believe I can say that because I was a victim of "strictly applying"
> the guidelines as they are, despite the examples provided in the document
> on EAP etc. 

This harkens back to the age old debate on whether RADIUS should provide
facilities to encode complex / structured data.  This debate is as old as
the RADEXT WG itself.   The current RADEXT WG consensus is that RADIUS
doesn't need extensive "structuring" facilities, and that the simple
"grouping" facilities, e.g. of the Extended Attributed draft, is sufficient.
Yes, this is far short of Diameter's capabilities, but we decided that
RADIUS should not be extended to maintain feature parity with Diameter.
Otherwise, why maintain both AAA protocols going forward.  :-)

>>> I am not even sure that it is always the right way to put such a 
>>> section in a RADIUS document when they authors do not envision 
>>> Diameter to be used in their specific environment.
>>
>>What do you suggest?
>
> Based on the discussion we had at the AAA doctors meeting I will
> think about some way forward.

Thanks!

>> Please elaborate...
>
> The above statement makes the assumption that the parsing happens
> in some C-alike language that was used to implement the entire RADIUS 
> server. There are indeed issues when you touch this code.
>
> However, most AAA servers have an abstract language they use for
> handling of msg processing. This language is typically not C and 
> written in a way that it does not lead to security issues. As such,
> even additional parsing that has to be implemented it does not lead
> to any interoperability or security problems.

Hmmm...  "Most"?  The metric we have been using is the "data dictionary
driven" server, which is admittedly a fairly old implementation technique.
Such servers may have auxiliary "policy servers" that make more complex
decisions about authorization data than is possible with simple attribute
matching schemes or user group membership schemes.  The relevant point of
discussion, however, is the on-the-wire RADIUS message format.

RADIUS was designed to provision pretty simple things.  It originally
envisioned each attribute as having an "atomic" value, not some complex,
structured message.  I understand that AAA servers today attempt to
provision more complex things, and this is wherein the friction results.
Should RADIUS be extended, much as Diameter has, to support a more complex
and nuanced set of provisioning capabilities?  If so, then why do we need
Diameter? :-)

>> So, what you are suggesting is that the syntax and semantics 
>> of RADIUS attributes are contextually dependent on some policy 
>> decision that is opaque to the RADIUS client, proxies, etc?  I 
>> think that's a Very Bad Idea (tm) and falls under the 
>> recommendation against polymorphic attribute design. 
>
> No, my argument is different. I believe that the argument that
> complex attributes lead to interoperability, deployment and 
> security issues as stated in the draft is incorrect and can of
> course happen from certain implementation choices.

I see.  I guess I still disagree.  Yes, anything, no matter how complex,
convoluted and baroque can be made to interoperate with sufficient attention
to detail.  A pig, given sufficient thrust, can be made to fly.  :-)

> Most AAA server do not have these issues as they are providing an
> abstract language for the developer for business logic, parsing,
> msg handling, etc.

So, you're saying that today's AAA Servers are really Policy Servers?

I think that the basic issues here is that there is a disconnect between the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter.  



--
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, 26 Dec 2008 19:36:30 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue 298
Date: Fri, 26 Dec 2008 14:36:18 -0500
Message-ID: <CA94B0A93CF844989E0D87A5304EB991@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBMNclg

> Issue 298 -- This issue relates to whether Extended Attributes are
> treated like VSAs or not.=A0 For implementations of this document, the
answer
> is probably "no" -- they are treated like any other standard =
attribute.

I heartily agree!

> However, for implementations that don't support Extended Attributes,
> the answer is probably "yes" -- which has implications for=20
> Accounting-Responses (where VSAs are permitted, but few standard
attributes)
> and=A0Disconnect-Responses (where VSAs may only be used for session
identification).

I think we want to be very careful here.  The correct behavior for
implementations that have not included the Extended Attribute =
functionality
is to treat them as unrecognized / unknown VSAs, and to ignore them.  =
They
may be logged in some fashion, of course.  Whether they should be =
included
in RADIUS Accounting or Dynamic RADIUS packets as "unknown attributes" =
is
open to debate.

What I think should not happen is for Extended Attributes to be
"selectively" understood.  The implementation either "groks" the =
Extended
Attribute format, in which case the rules for standard attributes (or =
SDO
Specific Attributes) apply, or it simply sees them as unrecognized / =
unknown
VSAs, in which case the rules for unknown attributes apply.  We should =
not
encourage implementations to treat them as unknown for one purpose but =
known
for another.

> So one question is whether this implies that a NAS should signal its
> support for Extended Attributes in the Access-Request in some way --=20
> so as to make it clear to the RADIUS server how those attributes would
> be interpreted.=A0=A0

I think we should make that feature a MUST.



--
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, 26 Dec 2008 19:24:33 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue 290
Date: Fri, 26 Dec 2008 14:24:32 -0500
Message-ID: <4D4E9A23A67548DB84A7E7E68733E115@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBLtlfg

> Issue 290 -- This relates to the issue of Diameter support for=20
> non-standard VSA formats (which this document now uses).=A0=A0 During =
IETF 73,
> we discussed one potential avenue for addressing this, which would be
> to update RFC 4005 to enable use of Diameter AVP 26 for translation of
> RADIUS VSAs of non-standard type.

Would that be a RADEXT or DIME work item?

There is a larger issue here, currently being discussed as part of the
RADIUS Design Guidelines commentary.  That issue revolves around the use =
of
complex / structured data in the value field of attributes, i.e. the V =
of
the TLV.  I think we need to nail down that issue before we can =
effectively
close on the Design Guidelines and Extended Attributes drafts, as well =
as
recommended practice for Diameter Compatibility and the related text =
that
should accompany the definition of new RADIUS [Extended] Attributes.  =
There
was discussion of this issue in the RADEXT and DIME WG meetings at =
IETF-73
and in the AAA Doctors lunch meeting.  Amazingly, this "larger issue" =
topic
has been hotly debated, on and off, as far back as the original =
discussion
on chartering RADEXT, back around time of IETF-56 (or so)!

I'll pick that discussion up in another thread.

Suffice it to say that the "consensus of record" of the RADEXT WG on =
this
issue does not address the interests and concerns of a handful of
individuals, who continue to make a case for more robust and rich
functionality regarding complex / structured attributes.



--
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, 26 Dec 2008 19:10:52 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue 278
Date: Fri, 26 Dec 2008 14:10:38 -0500
Message-ID: <F3C52E61C42C457FACD8E29AB95BCF35@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBLabOA

> Issue 278 -- The remaining portion of this issue relates to whether
> IANA can allocate Extended Attributes 0-255, and if by doing so, 
> confusion would be created with respect to existing RADIUS attributes.

> In general, we have not seen confusion relating to use of VSAs with
> Type Code values which overlap the standards range (which most do).

I think that Extended Attributes (for implementations which _know_ that they
_are_ Extended Attributes) are clearly not the same thing as Vendor Specific
Attributes.  Assuming that VSA rules and practices apply to Extended
Attributes is probably not the best way to go.   Carving out a reservation
for the legacy codes of 0-255 seems reasonable, especially in light of the
extended type code field.



--
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, 26 Dec 2008 19:02:10 +0000
From: "D. B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Fri, 26 Dec 2008 14:02:04 -0500
Message-ID: <F5222BC028514A1B81037AEF5AADEFBE@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AclmXtE6NAoJWcbNQhOP/W2Sv7xP+QBLTfSw

Bernard Aboba writes...

> Here is my take on where each of the current open issues stands
> and what could be done to move things along.=A0

I'm going to break my comments into separate replies for each issue, and
revise the subject headers accordingly.  These will follow in subsequent
messages.



--
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, 26 Dec 2008 18:07:38 +0000
From: "D. B. Nelson" <[e-mail]>
To: "'Romascanu, Dan \(Dan\)'" <[e-mail]>, "'Glen Zorn'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Fri, 26 Dec 2008 13:06:49 -0500
Message-ID: <85A665CCE146442DA33455A452F70EC9@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrAA2PDuIA==

Dan Romascanu writes...

> I would like to ask the WG chairs and the WG at large what are
> the plans with this document following the response received from
> IEEE 802.16.

We should first ask Glen his intent / preferences.  Glen, what is your
preferred path to publish this draft?

As this draft has been deemed useful to IEEE 802.16 (at least to address
fielded deployments), the first question to ask is whether this work should
be taken on in the IETF, or whether it should be taken on in the IEEE (or as
a individual submission).  We have created a framework in which RADIUS
attributes that are of interest to particular SDOs, but not of general
interest to the Internet community, could be documented as SDO Specific
Attributes, using the RADIUS Extended Attribute format and the RADIUS Design
Guidelines.  This process may still require / desire expert review by the
RADEXT WG and/or the AAA Doctors.

OTOH, if the RADEXT WG is requested to invest substantial time in reviewing
this draft, it may make sense to publish this draft via the IETF process,
and thus as a RADEXT WG work item.  I don't have a strong opinion either
way.  If the WG chooses to take on this work, then it would need to be
appropriately prioritized w.r.t. the current deliverables, some of which
would be a prerequisite for either path (e.g. Design Guidelines and Extended
Attributes).

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, 26 Dec 2008 09:38:57 +0000
Message-ID: <[e-mail]>
Date: Fri, 26 Dec 2008 10:37:35 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: Glen Zorn <[e-mail]>,  "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Issues with draft-ietf-radext-extended-attributes-05.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Issue 225 -- It would appear that the major point of contention here
> relates to the length field and
> fragmentation.  I believe that  this comment could be resolved by
> addition of some advice (a SHOULD
> might suffice) on fragmentation usage for senders and support on
> receivers.   The ability to include
> multiple attributes inside a VSA was allowed in RFC 2865, and so should
> not be a subject of dispute
> for this document.  Given that this issue is nearly resolved, I would
> suggest that you and Alan
> work out appropriate text.

  I'll see if I can suggest something.

> Issue 278 -- The remaining portion of this issue relates to whether IANA
> can allocate Extended
> Attributes 0-255, and if by doing so, confusion would be created with
> respect to existing
> RADIUS attributes.  What is interesting about this discussion is that it
> only arose once the
> size of the type field was expanded to 16 bits.  In general, we have not
> seen confusion
> relating to use of VSAs with Type Code values which overlap the
> standards range (which
> most do).  For example, do people confuse Example.com VSA #32 with the
> RADIUS
> NAS-Identifier attribute (32)?   Maybe this issue could be resolved by
> suggestion of appropriate
> nomenclature.  For example, the term "<Attribute name> Extended
> Attribute (#)"
> instead of today's usage "NAS-Identifier Attribute (32)". 

  I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 25 Dec 2008 13:24:29 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, <[e-mail]>
Subject: RE: FW: [Fwd: Question regarding draft-ietf-radext-design-05.txt.]
Date: Thu, 25 Dec 2008 15:24:22 +0200
Message-ID: <006901c96694$1aa9fa30$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckaJaiCPnvRt3zUQ32sj+P4R+qilRMZ/msg

Hi Alan, 

also sorry that I did not reply to this mail earlier.  

>>>      * it is easier for the user to enter the data as well-known
>>>        types, rather than complex structures;
>>>
>>> I believe this text shouldn't really say "user". Even on the AAA 
>>> server (to which this text is most likely pointing to) I 
>think it is 
>>> worth pointing out that this depends a lot on where the data comes 
>>> from; often it does not come from a human.
>
>  Sure.  That could say:
>
>  * it is easier for the data to be managed as well-known types...

I guess we all agree that it would be nice to have only well-known data
types. 
The problem unfortunately is that the extended attributes draft does not
allow this to happen because of it's restricted treatement of complex
attributes. Even we some of the DIME documents we have today we run into a
lot of problems. 

>
>>>      * it enables additional error checking by leveraging the
>>>        parsing and validation routines for well-known types;
>>>
>>> If you are truely serious about this issue then one should 
>replicate 
>>> the Diameter mechanisms where you can group AVPs arbitrarily and 
>>> where you have far more data types available.
>
>  Nice idea, but this is RADIUS.  We can't change it at this point.

Well. RADIUS is a protocol and protocols seem to change over time. We see
this also with RADIUS. 
Recent example: TCP and TLS extensions for RADIUS

>
>>> I would like to discuss this statement a bit. It makes an 
>assumption 
>>> about the way how a RADIUS server works that might not be how it is 
>>> always being used today. It indicates that a RADIUS server works 
>>> roughly in the following way:
>>>
>>> a) Receive attributes (e.g., attribute foobar)
>>> b) Formulate a query based on the received attributes (e.g., select 
>>> foobar from tables where user-id=X)
>>> c) Return result from previous query
>
>  No.  It assumes that policies inside of the RADIUS server 
>are managed by attribute *name*, rather than on-the-wire number.

I am not sure how this relates to my statement. 

>
>>> This ignores that there might be more complex processing 
>going on in 
>>> the RADIUS server, for example that other protocols need to get 
>>> invoked to get the result (e.g., attributes Y require LDAP to fetch 
>>> results from server X while other mechanisms may be consulted to 
>>> obtain the necessary information related to attributes Z), 
>that there 
>>> is some business logic that needs to be executed).
>
>  That happens, but it's independent of RADIUS dictionaries.
>
>>> I would at least like to relax this statement a bit and acknowledge 
>>> the fact that RADIUS servers are a bit more complex today than just 
>>> boxes where one could have used SQL instead of the RADIUS protocol 
>>> right away.
>
>  The original servers didn't even use SQL...
>
>>> I think that policy languages in AAA servers are getting 
>more common 
>>> today.
>>> During the Diameter interop I have seen a lot of vendors 
>using quite 
>>> sophisticated policy languages and their boxes supported (in almost 
>>> all
>>> cases) not only Diameter but also RADIUS (and other protocols).
>
>  Yes.  Some RADIUS servers also support complex attribute 
>decoding through simple scripting languages.  But this has not 
>been historically wide-spread.

These assumptions have been built-into the draft and it would be good to be
explicit what type of RADIUS server you are talking about when you argue
that complex attributes lead to implementation, deployment and security
problems. This may very well be true be true for some of these servers but
certainly not true for many others. Maybe these older servers don't even
care about the functionality we are specifying today. 


>
>>> Finally, I would like to mention that RADIUS documents sometimes 
>>> specify RADIUS/Diameter compatibility in a wrong fashion.
>
>  Are there any changes required to the design guidelines 
>document?  Can you offer suggested text?

My immediate suggestion: Don't put a RADIUS / Diameter compatibility
considerations section into the document as it is almost always wrong. 

>
>>> The following paragraph (and a lot of related text) is 
>related to the 
>>> aspect of policy languages:
>>>
>>>   However, some standard attributes do not follow this format.
>>>   Attributes that use sub-fields instead of using a basic 
>data type are
>>>   known as "complex attributes".  As described below, the 
>definition of
>>>   complex attributes can lead to interoperability and deployment
>>>   issues, so they need to be introduced with care.
>>>
>>> It somewhat depends on how the policy language works and what you 
>>> expect the policy language todo.
>
> "Can lead ...".  The text is describing common practices and 
>deployments.  The only reason to change the text is if those 
>practices are not, in fact, in common use.

But these type of statements are used against draft authors who decided to
pick a different format and then we have all these discussions. 

I think it would be useful to provide a bit more context, as argued a few
paragraphs above. 

>
>>> If you also assume that the policy language is not only 
>used to deal 
>>> with the business logic but also with decoding and encoding of 
>>> attribute content then one could deal with a number of 
>>> interoperability and security issues with the choice of language.
>
>  This is really splitting hairs over what "code" is.  
>Assembler is code.  Policy languages are (not?) code.  Java is 
>intermediate...

The type of language really matters a lot when it comes to security issues.
There are certainly languages where buffer overflows and other issues are
more common than in other languages. It is also a difference whether a
developer has to write code in the scripting language of the AAA server or
whether the core part of the server has to be changed. 


>
>  In any case, *some* logic has to be updated for complex attributes.

As I mentioned in the mail to David I argue that for some of the "customer
groups" there is code at the level of the scripting language necessary
anyway (for almost all of the documents that get produced). Hence, I
provided the comparison to SQL in my previous mail by saying that RADIUS is
different to the initial versions of SQL databases in the sense that new
functionality requires often a bit of new code at the AAA server. Even SQL
has evolved over time and some of these database systems also allow some
form of scripting (e.g., via PL/SQL) 

>
>>> Btw, has the draft been sent to other SDOs for review?
>
>  Suggestions?
Almost all the major SDOs have to deal with RADIUS in some form:
Wimax Forum, Broadband Forum, 3GPP, 3GPP2, CableLabs

Ciao
Hannes

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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 25 Dec 2008 12:51:51 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Question regarding draft-ietf-radext-design-05.txt
Date: Thu, 25 Dec 2008 14:51:10 +0200
Message-ID: <006801c9668f$77a7ec60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AckZvO0ljvj3FUeSSK+9OykoRbmO5AAAg/yAEzOeFWA=

Hi David, 

I noticed that I did not reply to these messages. 

>> If you are truely serious about this issue then one should replicate 
>> the Diameter mechanisms where you can group AVPs arbitrarily 
>and where 
>> you have far more data types available.
>
>That proposal was made in one of the early extended attributes 
>drafts, and was rejected by the RADEXT WG.  WG consensus says 
>that approach is not acceptable or interesting to the WG.  So, 
>while technically you have a very valid suggestion, it does 
>not seem to gain traction in the RADEXT WG.
> 
>> I would like to discuss this statement a bit. It makes an assumption 
>> about the way how a RADIUS server works that might not be how it is 
>> always being used today. It indicates that a RADIUS server works 
>> roughly in the following way:
>> 
>> a) Receive attributes (e.g., attribute foobar)
>> b) Formulate a query based on the received attributes (e.g., select 
>> foobar from tables where user-id=X)
>> c) Return result from previous query
>> 
>> This ignores that there might be more complex processing going on in 
>> the RADIUS server, for example that other protocols need to get 
>> invoked to get the result (e.g., attributes Y require LDAP to fetch 
>> results from server X while other mechanisms may be consulted to 
>> obtain the necessary information related to attributes Z), 
>that there 
>> is some business logic that needs to be executed).
>
>The policy determination / enforcement mechanism of RADIUS 
>servers is solely a matter of implementation.  It might be 
>implemented by means of delegation / consultation with some 
>other service, via some other protocol.  Or it might not.

While this is indeed an aspect of implementation there seem to be aspects
that impact the larger topic of how extensibility is perceived to work. 

>
>> I would at least like to relax this statement a bit and acknowledge 
>> the fact that RADIUS servers are a bit more complex today than just 
>> boxes where one could have used SQL instead of the RADIUS protocol 
>> right away.
>
>I think readers likely know that.  The issue is whether 
>extensions to the RADIUS on-the-wire protocol should be 
>designed to accommodate the traditional, 
>data-dictionary-driven RADIUS server, or not.  I think what we 
>are saying is that, while complex RADIUS server 
>implementations exist, RADIUS protocol enhancements should not 
>be at the expense of the simple implementations.

I think it is not a question of simple or complex implementation. 
The main issue is what the specific customers want. AAA servers are used by
different clusters of customers (different types of enterprises, WLAN
hotspots, universities, ISPs, cellular operators, etc). These customers have
different needs but the guidelines do not acknowledge that there are
different classes of customers and hence the design guidelines are often
applied without considering these aspects. I believe I can say that because
I was a victim of "strictly applying" the guidelines as they are, despite
the examples provided in the document on EAP etc. 


> 
>> I think that policy languages in AAA servers are getting more common 
>> today.
>
>Perhaps.

Would be worth investigating what folks develop today. 

> 
>> Finally, I would like to mention that RADIUS documents sometimes 
>> specify RADIUS/Diameter compatibility in a wrong fashion.
>
>That's an issue we need to address, and get right.
>
>> For example, there are a number of RADIUS documents that 
>indicate that 
>> the corresponding Diameter AVPs have the M-bit set.
>> This cannot be possible since this would require a new Diameter 
>> application to be specified.
>
>Ah, the long-standing Diameter Application quagmire.  :-(
>
>> I am not even sure that it is always the right way to put such a 
>> section in a RADIUS document when they authors do not envision 
>> Diameter to be used in their specific environment.
>
>What do you suggest?


Based on the discussion we had at the AAA doctors meeting I will think about
some way forward. 

>
>> The following paragraph (and a lot of related text) is 
>related to the 
>> aspect of policy languages:
>> 
>>   However, some standard attributes do not follow this format.
>>   Attributes that use sub-fields instead of using a basic data 
>>   type are known as "complex attributes".  As described below, 
>>   the definition of complex attributes can lead to interoperability
>>   and deployment issues, so they need to be introduced with care.
>> 
>> It somewhat depends on how the policy language works and what you 
>> expect the policy language todo.
>
>Please elaborate...

The above statement makes the assumption that the parsing happens in some
C-alike language that was used to implement the entire RADIUS server. 
There are indeed issues when you touch this code. 

However, most AAA servers have an abstract language they use for handling of
msg processing. This language is typically not C and written in a way that
it does not lead to security issues. As such, even additional parsing that
has to be implemented it does not lead to any interoperability or security
problems. Furthermore, as I argued above, since RADIUS usage today requires
more interaction the same language is used for the other processing and when
new functionality is added new code is being added. 

 
>
>> If you also assume that the policy language is not only used to deal 
>> with the business logic but also with decoding and encoding of 
>> attribute content then one could deal with a number of 
>> interoperability and security issues with the choice of language.
>
>So, what you are suggesting is that the syntax and semantics 
>of RADIUS attributes are contextually dependent on some policy 
>decision that is opaque to the RADIUS client, proxies, etc?  I 
>think that's a Very Bad Idea (tm) and falls under the 
>recommendation against polymorphic attribute design. 

No, my argument is different. I believe that the argument that complex
attributes lead to interoperability, deployment and security issues as
stated in the draft is incorrect and can of course happen from certain
implementation choices. Most AAA server do not have these issues as they are
providing an abstract language for the developer for business logic,
parsing, msg handling, etc. 

>
>> Btw, has the draft been sent to other SDOs for review?
>
>No.  I don't think that individual drafts are noticed the IETF 
>New Work list (maybe I'm wrong) so it would only come to the 
>attention of other SDOs via the efforts of overlapping participants.


Maybe it would have been good to get some feedback from organizations that
typically mess around with RADIUS protocols. 

Ciao
Hannes

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


--
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, 25 Dec 2008 07:03:40 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_38be55ae-d34f-4a23-bacd-d9459b16d1c1_"
From: Bernard Aboba <[e-mail]>
To: Glen Zorn <[e-mail]>, "David B. Nelson" <[e-mail]>, Alan DeKok <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Wed, 24 Dec 2008 23:02:57 -0800
MIME-Version: 1.0

--_38be55ae-d34f-4a23-bacd-d9459b16d1c1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


In general=2C it is the job of the editor to work with the Issue filters to
resolve review comments. =20

While it is possible to issue a formal WG consensus call to resolve=20
contentious issues=2C it is neither practical or necessary to go through=20
this process for each of the open issues.  We have already had to=20
engage that formal consensus process twice -- and that proved=20
to be  extremely time consuming.=20

In looking at the open issues=2C in most cases the remaining
areas of dispute are relatively minor=2C so that they are readily
resolvable between the editor and the Issue proposers.  =20

In one or two cases the issues are more substantial=2C but=20
discussion has not yet clarified the problem.  In these=20
situations more discussion is probably required.=20

Here is my take on where each of the current open issues stands
and what could be done to move things along.   Given the current
status=2C it is hard to see why the majority of these issues could
not be closed by the IETF 74 submission deadline.=20

Extended=20
      Attributes=20
      Issue Number
    Status
    Type
    Description
    Owner
 =20
    Issue 225
    Pending
    Technical
   =20
	Review
    Alan=20
    DeKok
 =20
    Issue 251
    Pending
    Technical
   =20
	Review
    Bernard=20
      Aboba
 =20
    Issue 278
    Pending
    Technical
   =20
=09
	Comments
    Alan=20
    DeKok
=09
=09
    Issue 279
    Pending
    Technical
   =20
=09
	Comments
    Stefan=20
	Winter
=09
 =20
    Issue 287
    No Discussion
    Technical
   =20
=09
	Comments
    Greg=20
    Weber
=09
=09
    Issue 290
    No Discussion
    Technical
   =20
	RFC=20
	4005bis Dependency
    Bernard=20
	Aboba
=09
 =20
    Issue 298
    No Discussion
    Technical
   =20
=09
	Extended Attributes Restriction
    Bernard=20
	Aboba

Issue 225 -- It would appear that the major point of contention here relate=
s to the length field and=20
fragmentation.  I believe that  this comment could be resolved by addition =
of some advice (a SHOULD
might suffice) on fragmentation usage for senders and support on receivers.=
   The ability to include
multiple attributes inside a VSA was allowed in RFC 2865=2C and so should n=
ot be a subject of dispute
for this document.  Given that this issue is nearly resolved=2C I would sug=
gest that you and Alan
work out appropriate text.=20

Issue 251 -- This relates to the need for IANA considerations text.  I can =
post a suggestion.=20

Issue 278 -- The remaining portion of this issue relates to whether IANA ca=
n allocate Extended
Attributes 0-255=2C and if by doing so=2C confusion would be created with r=
espect to existing
RADIUS attributes.  What is interesting about this discussion is that it on=
ly arose once the
size of the type field was expanded to 16 bits.  In general=2C we have not =
seen confusion
relating to use of VSAs with Type Code values which overlap the standards r=
ange (which
most do).  For example=2C do people confuse Example.com VSA #32 with the RA=
DIUS=20
NAS-Identifier attribute (32)?   Maybe this issue could be resolved by sugg=
estion of appropriate
nomenclature.  For example=2C the term "<Attribute name> Extended Attribute=
 (#)"
instead of today's usage "NAS-Identifier Attribute (32)". =20

Issue 279 -- Stefan has made concrete suggestions for resolving the remaini=
ng aspects of this
issue.  My suggestion would be to either incorporate them or make a counter=
-proposal.=20

Issue 290 -- This relates to the issue of Diameter support for non-standard=
 VSA formats (which this
document now uses).   During IETF 73=2C we discussed one potential avenue f=
or addressing this=2C which
would be to update RFC 4005 to enable use of Diameter AVP 26 for translatio=
n of RADIUS VSAs of
non-standard type.   This document would then normatively reference RFC 400=
5bis for a discussion
on translation of Extended Attributes.   Dave Mitton has expressed interest=
 in working on the
RFC 4005 revision=2C so my suggestion would be to work with him on that.=20

Issue 298 -- This issue relates to whether Extended Attributes are treated =
like VSAs or not.  For
implementations of this document=2C the answer is probably "no" -- they are=
 treated like any other standard
attribute.  However=2C for implementations that don't support Extended Attr=
ibutes=2C the answer is=20
probably "yes" -- which has implications for Accounting-Responses (where VS=
As are permitted=2C=20
but few standard attributes) and  Disconnect-Responses (where VSAs may only=
 be used for=20
session identification).   So one question is whether this implies that a N=
AS should signal its
support for Extended Attributes in the Access-Request in some way -- so as =
to make it clear
to the RADIUS server how those attributes would be interpretted.   Given th=
at the implications
of this issue (and therefore consensus) are still somewhat unclear=2C my re=
commendation would to=20
continue discussion in hope of achieving clarity.=20


Glen Zorn said:

> Hi=2C guys.  I would _really_ like to get this draft done=2C but none of =
the
> outstanding issues are owned by myself & the issue owners haven't been ve=
ry
> forthcoming w/text.  So=2C in the interest alacrity=2C could I talk you i=
nto
> doing a little more Chair-stuff?  Specifically=2C if you have comprehende=
d WG
> consensus on any/all of the issues=2C can you provide editing instruction=
s to
> me so that the issues may be closed & the document progressed?  TIA!




--_38be55ae-d34f-4a23-bacd-d9459b16d1c1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In general=2C it is the job of the editor to work with the Issue filters to=
<br>resolve review comments.&nbsp=3B <br><br>While it is possible to issue =
a formal WG consensus call to resolve <br>contentious issues=2C it is neith=
er practical or necessary to go through <br>this process for each of the op=
en issues.&nbsp=3B We have already had to <br>engage that formal consensus =
process twice -- and that proved <br>to be&nbsp=3B extremely time consuming=
. <br><br>In looking at the open issues=2C in most cases the remaining<br>a=
reas of dispute are relatively minor=2C so that they are readily<br>resolva=
ble between the editor and the Issue proposers.&nbsp=3B&nbsp=3B <br><br>In =
one or two cases the issues are more substantial=2C but <br>discussion has =
not yet clarified the problem.&nbsp=3B In these <br>situations more discuss=
ion is probably required. <br><br>Here is my take on where each of the curr=
ent open issues stands<br>and what could be done to move things along.&nbsp=
=3B&nbsp=3B Given the current<br>status=2C it is hard to see why the majori=
ty of these issues could<br>not be closed by the IETF 74 submission deadlin=
e. <br><br><table id=3D"table62" width=3D"761" border=3D"1" height=3D"1"><t=
body><tr><td width=3D"117" height=3D"34"><font size=3D"4"><strong>Extended=
=20
      Attributes</strong></font>=20
      <b><font size=3D"4">Issue Number</font></b><BR></td>
    <td width=3D"146" height=3D"34"><b><font size=3D"4">Status</font></b></=
td>
    <td width=3D"84" height=3D"34"><font size=3D"4"><b>Type</b></font></td>
    <td width=3D"272" height=3D"34"><b><font size=3D"4">Description</font><=
/b></td>
    <td width=3D"112" height=3D"34"><b><font size=3D"4">Owner</font></b></t=
d></tr>
  <tr>
    <td width=3D"117" height=3D"62">Issue 225</td>
    <td width=3D"146" height=3D"34">Pending</td>
    <td width=3D"73" height=3D"62">Technical</td>
    <td width=3D"277" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
225">Review</a></td>
    <td width=3D"117" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
    DeKok</a></td></tr>
  <tr>
    <td style=3D"height: 62px=3B" width=3D"117">Issue 251</td>
    <td style=3D"height: 62px=3B" width=3D"146">Pending</td>
    <td style=3D"height: 62px=3B" width=3D"84">Technical</td>
    <td style=3D"height: 62px=3B" width=3D"272">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
251">Review</a></td>
    <td style=3D"height: 62px=3B" width=3D"112"><a href=3D"mailto:Bernard_A=
[e-mail]">Bernard=20
      Aboba</a></td></tr>
  <tr>
    <td width=3D"117" height=3D"62">Issue 278</td>
    <td width=3D"146" height=3D"34">Pending</td>
    <td width=3D"73" height=3D"62">Technical</td>
    <td width=3D"277" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
278">
	Comments</a></td>
    <td width=3D"117" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
    DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"117" height=3D"62">Issue 279</td>
    <td width=3D"146" height=3D"34">Pending</td>
    <td width=3D"73" height=3D"62">Technical</td>
    <td width=3D"277" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
279">
	Comments</a></td>
    <td width=3D"117" height=3D"51"><a href=3D"mailto:stefan.winter@restena=
.lu">Stefan=20
	Winter</a></td>
	</tr>
  <tr>
    <td width=3D"116" height=3D"62">Issue 287</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
287">
	Comments</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:[e-mail]">Gr=
eg=20
    Weber</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 290</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
290">RFC=20
	4005bis Dependency</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td>
	</tr>
  <tr>
    <td width=3D"116" height=3D"62">Issue 298</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
298">
	Extended Attributes Restriction</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td></tr></tbody></table><br><br>Issue 225 -- It would appear th=
at the major point of contention here relates to the length field and <br>f=
ragmentation.&nbsp=3B I believe that&nbsp=3B this comment could be resolved=
 by addition of some advice (a SHOULD<br>might suffice) on fragmentation us=
age for senders and support on receivers.&nbsp=3B&nbsp=3B The ability to in=
clude<br>multiple attributes inside a VSA was allowed in RFC 2865=2C and so=
 should not be a subject of dispute<br>for this document.&nbsp=3B Given tha=
t this issue is nearly resolved=2C I would suggest that you and Alan<br>wor=
k out appropriate text. <br><br>Issue 251 -- This relates to the need for I=
ANA considerations text.&nbsp=3B I can post a suggestion. <br><br>Issue 278=
 -- The remaining portion of this issue relates to whether IANA can allocat=
e Extended<br>Attributes 0-255=2C and if by doing so=2C confusion would be =
created with respect to existing<br>RADIUS attributes.&nbsp=3B What is inte=
resting about this discussion is that it only arose once the<br>size of the=
 type field was expanded to 16 bits.&nbsp=3B In general=2C we have not seen=
 confusion<br>relating to use of VSAs with Type Code values which overlap t=
he standards range (which<br>most do).&nbsp=3B For example=2C do people con=
fuse Example.com VSA #32 with the RADIUS <br>NAS-Identifier attribute (32)?=
&nbsp=3B&nbsp=3B Maybe this issue could be resolved by suggestion of approp=
riate<br>nomenclature.&nbsp=3B For example=2C the term "&lt=3BAttribute nam=
e&gt=3B Extended Attribute (#)"<br>instead of today's usage "NAS-Identifier=
 Attribute (32)".&nbsp=3B <br><br>Issue 279 -- Stefan has made concrete sug=
gestions for resolving the remaining aspects of this<br>issue.&nbsp=3B My s=
uggestion would be to either incorporate them or make a counter-proposal. <=
br><br>Issue 290 -- This relates to the issue of Diameter support for non-s=
tandard VSA formats (which this<br>document now uses).&nbsp=3B&nbsp=3B Duri=
ng IETF 73=2C we discussed one potential avenue for addressing this=2C whic=
h<br>would be to update RFC 4005 to enable use of Diameter AVP 26 for trans=
lation of RADIUS VSAs of<br>non-standard type.&nbsp=3B&nbsp=3B This documen=
t would then normatively reference RFC 4005bis for a discussion<br>on trans=
lation of Extended Attributes.&nbsp=3B&nbsp=3B Dave Mitton has expressed in=
terest in working on the<br>RFC 4005 revision=2C so my suggestion would be =
to work with him on that. <br><br>Issue 298 -- This issue relates to whethe=
r Extended Attributes are treated like VSAs or not.&nbsp=3B For<br>implemen=
tations of this document=2C the answer is probably "no" -- they are treated=
 like any other standard<br>attribute.&nbsp=3B However=2C for implementatio=
ns that don't support Extended Attributes=2C the answer is <br>probably "ye=
s" -- which has implications for Accounting-Responses (where VSAs are permi=
tted=2C <br>but few standard attributes) and&nbsp=3B Disconnect-Responses (=
where VSAs may only be used for <br>session identification).&nbsp=3B&nbsp=
=3B So one question is whether this implies that a NAS should signal its<br=
>support for Extended Attributes in the Access-Request in some way -- so as=
 to make it clear<br>to the RADIUS server how those attributes would be int=
erpretted.&nbsp=3B&nbsp=3B Given that the implications<br>of this issue (an=
d therefore consensus) are still somewhat unclear=2C my recommendation woul=
d to <br>continue discussion in hope of achieving clarity. <br><br><br>Glen=
 Zorn said:<br><br>&gt=3B Hi=2C guys.  I would _really_ like to get this dr=
aft done=2C but none of the<br>&gt=3B outstanding issues are owned by mysel=
f &amp=3B the issue owners haven't been very<br>&gt=3B forthcoming w/text. =
 So=2C in the interest alacrity=2C could I talk you into<br>&gt=3B doing a =
little more Chair-stuff?  Specifically=2C if you have comprehended WG<br>&g=
t=3B consensus on any/all of the issues=2C can you provide editing instruct=
ions to<br>&gt=3B me so that the issues may be closed &amp=3B the document =
progressed?  TIA!<br><br><br><br></body>
</html>=

--_38be55ae-d34f-4a23-bacd-d9459b16d1c1_--

--
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, 25 Dec 2008 05:16:59 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, "'David B. Nelson'" <[e-mail]>, "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: Issues with draft-ietf-radext-extended-attributes-05.txt
Date: Thu, 25 Dec 2008 12:15:21 +0700
Message-ID: <004901c9664f$d36c4ef0$7a44ecd0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclmT8hQxaQgaRJtRSO/nI9Rfag3SQ==
Content-Language: en-us

Hi, guys.  I would _really_ like to get this draft done, but none of the
outstanding issues are owned by myself & the issue owners haven't been very
forthcoming w/text.  So, in the interest alacrity, could I talk you into
doing a little more Chair-stuff?  Specifically, if you have comprehended WG
consensus on any/all of the issues, can you provide editing instructions to
me so that the issues may be closed & the document progressed?  TIA!


--
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, 22 Dec 2008 10:24:37 +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: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Mon, 22 Dec 2008 11:22:48 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1wACxgKrA=
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Glen Zorn" <[e-mail]>, <[e-mail]>

I would like to ask the WG chairs and the WG at large what are the plans
with this document following the response received from IEEE 802.16.=20

Thanks and Regards,

Dan
=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Glen Zorn
> Sent: Sunday, December 21, 2008 3:12 PM
> To: [e-mail]
> Subject: FW: I-D Action:draft-zorn-radius-pkmv1-03.txt=20
>=20
> FYI, in case you didn't see it.
>=20
> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]]
> On Behalf Of [e-mail]
> Sent: Wednesday, December 17, 2008 5:30 PM
> To: [e-mail]
> Subject: I-D Action:draft-zorn-radius-pkmv1-03.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
> 	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
> Management Version 1 (PKMv1) Protocol Support
> 	Author(s)       : G. Zorn
> 	Filename        : draft-zorn-radius-pkmv1-03.txt
> 	Pages           : 15
> 	Date            : 2008-12-17
>=20
> This document defines a set of RADIUS Attributes which are=20
> designed to provide RADIUS support for IEEE 802.16 Privacy=20
> Key Management Version 1.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-03.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
>=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, 21 Dec 2008 13:13:18 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>
Subject: FW: I-D Action:draft-zorn-radius-pkmv1-03.txt 
Date: Sun, 21 Dec 2008 20:11:31 +0700
Message-ID: <000701c9636d$ac2c76b0$04856410$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C963A8.588B4EB0"
Thread-Index: AclgMmoDv9wWoOeKQUax0EMGg1Bi9wDOyg1w
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0008_01C963A8.588B4EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI, in case you didn't see it.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Wednesday, December 17, 2008 5:30 PM
To: [e-mail]
Subject: I-D Action:draft-zorn-radius-pkmv1-03.txt 

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

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-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_000_0008_01C963A8.588B4EB0
Content-Type: Message/External-body;
	name="draft-zorn-radius-pkmv1-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-zorn-radius-pkmv1-03.txt"

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


------=_NextPart_000_0008_01C963A8.588B4EB0
Content-Type: text/plain;
	name="ATT00065.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00065.txt"

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

------=_NextPart_000_0008_01C963A8.588B4EB0--


--
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, 19 Dec 2008 10:51:12 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Dec 2008 11:50:39 +0100
From: Klaas Wierenga <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>
CC: Bernard Aboba <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Inner identities, privacy, and roaming termination
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alan DeKok wrote:
> Bernard Aboba wrote:
>> In EDUROAM, an attack has been identified that involves use of two
>> distinct realms within an EAP method
>> supporting privacy (such as EAP-TTLSv0):
>> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/
> 
>   I will note that version 2.0 of FreeRADIUS doesn't have this issue.
> The functionality was originally added to support separation of the TLS
> side of EAP from traditional RADIUS.  i.e. Placing a modern server
> upstream from a legacy server, to enable support for EAP, when the
> legacy server doesn't support EAP.

also, it is in general not a good idea to use the same credentials both 
inside and outside tunnels anyway (compound authentication binding 
problem), so the end IdP should refuse credentials that arrive 'in the 
clear'.

What remains is that this is an end IdP problem. The IdP of the user can 
after terminating the EAP tunnel do whatever it pleases with the 
credentials, but that is not a protocol problem as Stefan mentioned.

Klaas


> 
>> It would appear that this attack can be addressed by adding a check on
>> the part of a home
>> RADIUS server in order to require that the inner and outer identities
>> share a realm.   If the
>> realms are allowed to differ, then it would appear to be necessary for
>> at least the inner realm
>> to be provided to the NAS somehow.  This could be within a CUI attribute
>> or a User-Name
>> attribute.  The question is whether an EAP-Peer-Id attribute might also
>> be useful. 
> 
>   Some deployments *require* that the realms differ, IIRC.  e.g. outer
> "anonymous" and inner "[e-mail]".
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>


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


Envelope-to: [e-mail]
Delivery-date: Fri, 19 Dec 2008 10:08:33 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Dec 2008 11:08:03 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Inner identities, privacy, and roaming termination
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> In EDUROAM, an attack has been identified that involves use of two
> distinct realms within an EAP method
> supporting privacy (such as EAP-TTLSv0):
> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/

  I will note that version 2.0 of FreeRADIUS doesn't have this issue.
The functionality was originally added to support separation of the TLS
side of EAP from traditional RADIUS.  i.e. Placing a modern server
upstream from a legacy server, to enable support for EAP, when the
legacy server doesn't support EAP.

> It would appear that this attack can be addressed by adding a check on
> the part of a home
> RADIUS server in order to require that the inner and outer identities
> share a realm.   If the
> realms are allowed to differ, then it would appear to be necessary for
> at least the inner realm
> to be provided to the NAS somehow.  This could be within a CUI attribute
> or a User-Name
> attribute.  The question is whether an EAP-Peer-Id attribute might also
> be useful. 

  Some deployments *require* that the realms differ, IIRC.  e.g. outer
"anonymous" and inner "[e-mail]".

  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, 19 Dec 2008 09:46:32 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Dec 2008 10:46:05 +0100
From: Stig Venaas <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081127)
MIME-Version: 1.0
To: Stefan Winter <[e-mail]>
Cc: Bernard Aboba <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Watchdog logic
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stefan Winter wrote:
[...]
> I am not in favour of splitting the two connections. Fate-sharing is a
> desirable property, IMHO.

+1. I think fate sharing is essential here. A separate TCP connection
also adds overhead and complexity.

> 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: Fri, 19 Dec 2008 09:09:44 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Dec 2008 10:09:15 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Watchdog logic
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello,

> I'm wondering what the implications would be of using two separate connections, 
> one for Status-Server/Access-Accept and the other 
> one for Access-Request/Access-Accept transactions. 
>
> The failover logic would change, to be sure.  For example, 
> a connection failure on the Request/Accept connection would probably trigger
> failover, regardless of the state of the Status-Server/Accept connection. 
>   

Separating into two connections is a very dangerous path, IMHO. The
scenario you depicted above may *wrongly* trigger failover in a roaming
scenario. The Request/Accept connection could be unresponsive due to the
server having proxied all its requests to a downstram server. I.e. it
could be up and running, waiting itself for answers. If that connection
is closed and fail-overed, actual traffic will be discarded without
reason. If, OTOH, Status-Server is sent within this connection, a
Status-Server/Accept pair can immediately enlighten the requesting
server that the other peer is indeed running.

> Also, the state of the two connections could get out of 
> sync; for example, if the Request/Accept connection was quite busy,
> then the Status/Accept connection might send little or no traffic,
> which might cause middleboxes (e.g. a NAT) to lose connection state
> on the Status/Accept connection.  In such a situation, you might just
> be able to bring up another Status/Accept connection rather than 
> triggering failover. 

I am not in favour of splitting the two connections. Fate-sharing is a
desirable property, IMHO.

Greetings,

Stefan Winter

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

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Fri, 19 Dec 2008 08:59:27 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Dec 2008 09:58:37 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Inner identities, privacy, and roaming termination
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello,

> Today, a mechanism for providing the user identity to the NAS is to
> send the EAP Peer-Id
> within a User-Name attribute in an Access-Accept.  This will provide
> the NAS with the inner identity,
> and will also cause Accounting-Requests to include the inner-identity
> within the User-Name attribute.

Some eduroam participants do this. NAS behaviour in Accounting-Requests
is apparently not homogenous. Some apparently continue to use the
User-Name from the authentication phase. In a roaming context, where the
home AAA server has no information on the NAS equipment being used, this
indeterminism makes the "feature" of using User-Name for EAP Peer-Id
mostly useless.
>    However,
> this does have the side effect of potentially causing authentication
> and accounting messages to take different paths
> in the situation where NAI re-writing occurs within proxies.   For
> example, if the NAI 
> example.com![e-mail] were used in the
> Access-Request, and the NAI [e-mail]
> were sent back in the Access-Accept, this would result in
> Accounting-Requests that were sent with a User-Name
> attribute of [e-mail], bypassing roamingpartner.com.  This
> concern was articulated in RFC 4372 as well.
> Providing an EAP-Peer-Id attribute would address concerns about
> overloading of the User-Name attribute.

That's true. Getting rid of this overloading would in itself be a
justification for keeping EAP-Peer-Id in the 80211 attributes draft.

> One concern that has been raised about the EAP-Peer-Id attribute is
> privacy. 
> As noted in the CUI RFC (RFC 4372), there are situations where it is
> undesirable for the NAS to obtain
> knowledge of the user identity.  Where a CUI attribute containing a
> NUL is sent in an Access-Request,
> the home server should assume that privacy is desired, and neither a
> User-Name nor an EAP-Peer-Id
> attribute should be sent in an Access-Accept, only a CUI attribute. 

IMHO, there is little a NAS can do if a home AAA wants to send this
information. The home AAA could also send it in an arbitrary VSA. So,
while it may be undesirable, it is also not deterministically possible
for the NAS to disable getting this information. Providing or not
providing a defined semantics/attribute for the piece of information
doesn't magically make the possibility for transmission go away. So, I
wouldn't use this argument against the definition of an EAP-Peer-Id.

> However, there are situations in which privacy might be desired, but
> the NAS does not support the
> CUI attribute.  Therefore the document currently states that the
> EAP-Peer-Id is only sent in an
> Access-Accept if the EAP-Peer-Id attribute is included in an
> Access-Request.   To address the concerns
> expressed by Alfred Hoenes (see
> http://ops.ietf.org/lists/radiusext/2008/msg00822.html),
> it would be possible to include a single NUL character in EAP-Peer-Id
> and EAP-Server-Id attributes sent within
> an Access-Request, rather than sending empty attributes. 

Since empty attributes are forbidden, a 0x00 seems like a good workaround.

> In EDUROAM, an attack has been identified that involves use of two
> distinct realms within an EAP method
> supporting privacy (such as EAP-TTLSv0):
> http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduroam/
>
> It would appear that this attack can be addressed by adding a check on
> the part of a home
> RADIUS server in order to require that the inner and outer identities
> share a realm.   If the
> realms are allowed to differ, then it would appear to be necessary for
> at least the inner realm
> to be provided to the NAS somehow.  This could be within a CUI
> attribute or a User-Name
> attribute.  The question is whether an EAP-Peer-Id attribute might
> also be useful.

While we were concerned over this redirection possibility, I wouldn't
call it an "attack", but much rather an "unexpected feature". It can be
mitigated by the AAA server which terminates the EAP session. It is in
possession of both the outer identity and the EAP Peer-Id, and can do
the sanity checks. This reduces the problem to one of a correct local
configuration at the side of the EAP peer. I wonder if it really makes
sense to do additional checks on the visited AAA or NAS side. If so, an
EAP-Peer-Id attribute might make sense here.
Also, I could imagine some configurations where a home AAA server serves
multiple realms, a user uses a combination with differing realms but
which are both handled by the same AAA server, in which case it might be
unexpected that a NAS somewhere decides that this is an unjust action.

Greetings,

Stefan Winter

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

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Thu, 18 Dec 2008 18:04:50 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_121e0a5e-1e16-4a63-96b5-ffd54f78387a_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Inner identities, privacy, and roaming termination
Date: Thu, 18 Dec 2008 10:03:55 -0800
MIME-Version: 1.0

--_121e0a5e-1e16-4a63-96b5-ffd54f78387a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The current version of the IEEE 802 attributes draft includes support for E=
AP-Server-Id and EAP-Peer-Id attributes:
http://tools.ietf.org/html/draft-aboba-radext-wlan

I am considering removing these attributes in the next revision of the docu=
ment=2C and would like to get the WG's
opinion on this.  The question is whether these attributes are needed=2C an=
d whether they would be used if provided.=20

The primary use of the EAP-Peer-Id attribute would be to enable a NAS to de=
termine the identity of the user where
the EAP method-specific identity differed from the identity provided in the=
 EAP-Response/Identity.   For example=2C
in EAP-TTLSv0=2C the outer identity could be anonymous=2C while the inner i=
dentity could provide the authenticated
identity of the user.=20

Today=2C a mechanism for providing the user identity to the NAS is to send =
the EAP Peer-Id
within a User-Name attribute in an Access-Accept.  This will provide the NA=
S with the inner identity=2C=20
and will also cause Accounting-Requests to include the inner-identity withi=
n the User-Name attribute.   However=2C=20
this does have the side effect of potentially causing authentication and ac=
counting messages to take different paths=20
in the situation where NAI re-writing occurs within proxies.   For example=
=2C if the NAI =20
example.com![e-mail] were used in the Access-Request=2C=
 and the NAI [e-mail]=20
were sent back in the Access-Accept=2C this would result in Accounting-Requ=
ests that were sent with a User-Name
attribute of [e-mail]=2C bypassing roamingpartner.com.  This concer=
n was articulated in RFC 4372 as well.=20
Providing an EAP-Peer-Id attribute would address concerns about overloading=
 of the User-Name attribute.=20

One concern that has been raised about the EAP-Peer-Id attribute is privacy=
. =20
As noted in the CUI RFC (RFC 4372)=2C there are situations where it is unde=
sirable for the NAS to obtain
knowledge of the user identity.  Where a CUI attribute containing a NUL is =
sent in an Access-Request=2C
the home server should assume that privacy is desired=2C and neither a User=
-Name nor an EAP-Peer-Id
attribute should be sent in an Access-Accept=2C only a CUI attribute. =20

However=2C there are situations in which privacy might be desired=2C but th=
e NAS does not support the
CUI attribute.  Therefore the document currently states that the EAP-Peer-I=
d is only sent in an
Access-Accept if the EAP-Peer-Id attribute is included in an Access-Request=
.   To address the concerns=20
expressed by Alfred Hoenes (see http://ops.ietf.org/lists/radiusext/2008/ms=
g00822.html)=2C


it would be possible to include a single NUL character in EAP-Peer-Id and E=
AP-Server-Id attributes sent within


an Access-Request=2C rather than sending empty attributes. =20

In EDUROAM=2C an attack has been identified that involves use of two distin=
ct realms within an EAP method=20
supporting privacy (such as EAP-TTLSv0):
http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-eduro=
am/

It would appear that this attack can be addressed by adding a check on the =
part of a home
RADIUS server in order to require that the inner and outer identities share=
 a realm.   If the
realms are allowed to differ=2C then it would appear to be necessary for at=
 least the inner realm
to be provided to the NAS somehow.  This could be within a CUI attribute or=
 a User-Name
attribute.  The question is whether an EAP-Peer-Id attribute might also be =
useful. =20









 EMAILING FOR THE GREATER GOOD
Join me=

--_121e0a5e-1e16-4a63-96b5-ffd54f78387a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
The current version of the IEEE 802 attributes draft includes support for E=
AP-Server-Id and EAP-Peer-Id attributes:<br>http://tools.ietf.org/html/draf=
t-aboba-radext-wlan<br><br>I am considering removing these attributes in th=
e next revision of the document=2C and would like to get the WG's<br>opinio=
n on this.&nbsp=3B The question is whether these attributes are needed=2C a=
nd whether they would be used if provided. <br><br>The primary use of the E=
AP-Peer-Id attribute would be to enable a NAS to determine the identity of =
the user where<br>the EAP method-specific identity differed from the identi=
ty provided in the EAP-Response/Identity.&nbsp=3B&nbsp=3B For example=2C<br=
>in EAP-TTLSv0=2C the outer identity could be anonymous=2C while the inner =
identity could provide the authenticated<br>identity of the user. <br><br>T=
oday=2C a mechanism for providing the user identity to the NAS is to send t=
he EAP Peer-Id<br>within a User-Name attribute in an Access-Accept.&nbsp=3B=
 This will provide the NAS with the inner identity=2C <br>and will also cau=
se Accounting-Requests to include the inner-identity within the User-Name a=
ttribute.&nbsp=3B&nbsp=3B However=2C <br>this does have the side effect of =
potentially causing authentication and accounting messages to take differen=
t paths <br>in the situation where NAI re-writing occurs within proxies.&nb=
sp=3B&nbsp=3B For example=2C if the NAI&nbsp=3B <br>example.com!anonymous@r=
oamingpartner.com were used in the Access-Request=2C and the NAI fred@examp=
le.com <br>were sent back in the Access-Accept=2C this would result in Acco=
unting-Requests that were sent with a User-Name<br>attribute of fred@exampl=
e.com=2C bypassing roamingpartner.com.&nbsp=3B This concern was articulated=
 in RFC 4372 as well. <br>Providing an EAP-Peer-Id attribute would address =
concerns about overloading of the User-Name attribute. <br><br>One concern =
that has been raised about the EAP-Peer-Id attribute is privacy.&nbsp=3B <b=
r>As noted in the CUI RFC (RFC 4372)=2C there are situations where it is un=
desirable for the NAS to obtain<br>knowledge of the user identity.&nbsp=3B =
Where a CUI attribute containing a NUL is sent in an Access-Request=2C<br>t=
he home server should assume that privacy is desired=2C and neither a User-=
Name nor an EAP-Peer-Id<br>attribute should be sent in an Access-Accept=2C =
only a CUI attribute.&nbsp=3B <br><br>However=2C there are situations in wh=
ich privacy might be desired=2C but the NAS does not support the<br>CUI att=
ribute.&nbsp=3B Therefore the document currently states that the EAP-Peer-I=
d is only sent in an<br>Access-Accept if the EAP-Peer-Id attribute is inclu=
ded in an Access-Request.&nbsp=3B&nbsp=3B To address the concerns <br>expre=
ssed by Alfred Hoenes (see http://ops.ietf.org/lists/radiusext/2008/msg0082=
2.html)=2C<br>

it would be possible to include a single NUL character in EAP-Peer-Id and E=
AP-Server-Id attributes sent within<br>

an Access-Request=2C rather than sending empty attributes.&nbsp=3B <br><br>=
In EDUROAM=2C an attack has been identified that involves use of two distin=
ct realms within an EAP method <br>supporting privacy (such as EAP-TTLSv0):=
<br>http://www.cesnet.cz/doc/techzpravy/2008/incorrect-eap-termination-in-e=
duroam/<br><br>It would appear that this attack can be addressed by adding =
a check on the part of a home<br>RADIUS server in order to require that the=
 inner and outer identities share a realm.&nbsp=3B&nbsp=3B If the<br>realms=
 are allowed to differ=2C then it would appear to be necessary for at least=
 the inner realm<br>to be provided to the NAS somehow.&nbsp=3B This could b=
e within a CUI attribute or a User-Name<br>attribute.&nbsp=3B The question =
is whether an EAP-Peer-Id attribute might also be useful.&nbsp=3B <br><br><=
br><br><br><br><br><br><br><br><table style=3D"border-top: 1px solid black=
=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><=
tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML=
_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=
=3B text-decoration: none=3B"><img style=3D"border-style: none=3B" src=3D"h=
ttp://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILING FOR=
 THE GREATER GOOD<br><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B =
color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">Join me</span=
></a></td></tr></tbody></table></body>
</html>=

--_121e0a5e-1e16-4a63-96b5-ffd54f78387a_--

--
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, 18 Dec 2008 15:34:22 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_8c203aac-c42b-44e1-bbc4-9605944bd286_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Watchdog logic
Date: Thu, 18 Dec 2008 07:33:25 -0800
MIME-Version: 1.0

--_8c203aac-c42b-44e1-bbc4-9605944bd286_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   Ok.  There are situations where a connection may be up=2C but the
> application is unresponsive.  It would be good to use the RFC 3539
> method to validate the connection.

The watchdog is based on application-layer timescales (e.g. 6 seconds)=2C r=
ather than connection timescales.  So it's possible for the watchdog to cau=
se application layer failover prior to connection failure/reset.=20

>   I'm not sure having a separate connection for Status-Server is a good
> idea.

I'm not sure either.   Separating the Status-Server traffic from the RADSEC
traffic breaks "fate sharing" which could introduce a number of bugs.

>   In addition=2C the algorithm in 3539 appears to be focussed on keeping
> the connections up... even if that means re-opening them.  I'm not sure
> this is a good idea.  It means that spikes in traffic cause a large
> number of connections to be opened... which then never close=2C or are
> continuously re-opened.  Even if there's no traffic on them.

The idea is to always have a connection "ready" for traffic=2C so yes=2C th=
e
algorithm does keep connections up even if there is no regular traffic
(e.g. the algorithm generates watchdog traffic). =20

>   It may be worth adding suggestions:
>=20
> - TCP connections SHOULD be kept "full".  i.e. used in a "most recently
> used" fashion for normal RADIUS traffic.
>=20
> - The RFC 3539 watchdog algorithm should be used to determine the status =
of a *connection*.

Not sure that the watchdog really determines connection status so much as s=
tatus at the application layer. =20

> - so long as one connection is alive=2C the server should be marked "aliv=
e".

Agreed.  But doesn't this somewhat conflict with the previous goal?

> - connections that haven't been used for T seconds (4 * RTT?) may be
> pro-actively closed.

How do you know what RTT is?  Or do you assume RTTMAX?  Since routing trans=
ients can take as long as 30 seconds to resolve=2C T probably would need to=
 be significant (e.g. minutes).=20

> - at least one connection should remain open to determine application
> responsiveness.

Sure.=20

--_8c203aac-c42b-44e1-bbc4-9605944bd286_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Ok.  There are situations where a connection may be up=2C but the<=
br>&gt=3B application is unresponsive.  It would be good to use the RFC 353=
9<br>&gt=3B method to validate the connection.<br><br>The watchdog is based=
 on application-layer timescales (e.g. 6 seconds)=2C rather than connection=
 timescales.&nbsp=3B So it's possible for the watchdog to cause application=
 layer failover prior to connection failure/reset. <br><br>&gt=3B   I'm not=
 sure having a separate connection for Status-Server is a good<br>&gt=3B id=
ea.<br><br>I'm not sure either.&nbsp=3B&nbsp=3B Separating the Status-Serve=
r traffic from the RADSEC<br>traffic breaks "fate sharing" which could intr=
oduce a number of bugs.<br><br>&gt=3B   In addition=2C the algorithm in 353=
9 appears to be focussed on keeping<br>&gt=3B the connections up... even if=
 that means re-opening them.  I'm not sure<br>&gt=3B this is a good idea.  =
It means that spikes in traffic cause a large<br>&gt=3B number of connectio=
ns to be opened... which then never close=2C or are<br>&gt=3B continuously =
re-opened.  Even if there's no traffic on them.<br><br>The idea is to alway=
s have a connection "ready" for traffic=2C so yes=2C the<br>algorithm does =
keep connections up even if there is no regular traffic<br>(e.g. the algori=
thm generates watchdog traffic).&nbsp=3B <br><br>&gt=3B   It may be worth a=
dding suggestions:<br>&gt=3B <br>&gt=3B - TCP connections SHOULD be kept "f=
ull".  i.e. used in a "most recently<br>&gt=3B used" fashion for normal RAD=
IUS traffic.<br>&gt=3B <br>&gt=3B - The RFC 3539 watchdog algorithm should =
be used to determine the status of a *connection*.<br><br>Not sure that the=
 watchdog really determines connection status so much as status at the appl=
ication layer.&nbsp=3B <br><br>&gt=3B - so long as one connection is alive=
=2C the server should be marked "alive".<br><br>Agreed.&nbsp=3B But doesn't=
 this somewhat conflict with the previous goal?<br><br>&gt=3B - connections=
 that haven't been used for T seconds (4 * RTT?) may be<br>&gt=3B pro-activ=
ely closed.<br><br>How do you know what RTT is?&nbsp=3B Or do you assume RT=
TMAX?&nbsp=3B Since routing transients can take as long as 30 seconds to re=
solve=2C T probably would need to be significant (e.g. minutes). <br><br>&g=
t=3B - at least one connection should remain open to determine application<=
br>&gt=3B responsiveness.<br><br>Sure. <br></body>
</html>=

--_8c203aac-c42b-44e1-bbc4-9605944bd286_--

--
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, 18 Dec 2008 10:39:09 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Dec 2008 11:38:21 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Watchdog logic
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> "With TCP, there is a connection between client and server.  The
> watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
> ID has to be reserved, because the client can't open a new connection to
> test if an existing connection is still alive."
> 
> While it's true that the watchdog timer algorithm is defined per connection,
> it seems like Status-Server is about determining whether a server is up
> or not.  The only way to determine whether a connection is down
> is to wait for it to close (either via a RESET or timeout).  RFC 3539
> attempts to detect a failure at the application layer prior to connection failure. 

  Ok.  There are situations where a connection may be up, but the
application is unresponsive.  It would be good to use the RFC 3539
method to validate the connection.

> I'm wondering what the implications would be of using two separate connections, 
> one for Status-Server/Access-Accept and the other 
> one for Access-Request/Access-Accept transactions. 
> 
> The failover logic would change, to be sure.  For example, 
> a connection failure on the Request/Accept connection would probably trigger
> failover, regardless of the state of the Status-Server/Accept connection. 
> Also, the state of the two connections could get out of 
> sync; for example, if the Request/Accept connection was quite busy,
> then the Status/Accept connection might send little or no traffic,
> which might cause middleboxes (e.g. a NAT) to lose connection state
> on the Status/Accept connection.  In such a situation, you might just
> be able to bring up another Status/Accept connection rather than 
> triggering failover. 

  I'm not sure having a separate connection for Status-Server is a good
idea.

  In addition, the algorithm in 3539 appears to be focussed on keeping
the connections up... even if that means re-opening them.  I'm not sure
this is a good idea.  It means that spikes in traffic cause a large
number of connections to be opened... which then never close, or are
continuously re-opened.  Even if there's no traffic on them.


  It may be worth adding suggestions:

- TCP connections SHOULD be kept "full".  i.e. used in a "most recently
used" fashion for normal RADIUS traffic.

- The RFC 3539 watchdog algorithm should be used to determine the status
of a *connection*.

- so long as one connection is alive, the server should be marked "alive".

- connections that haven't been used for T seconds (4 * RTT?) may be
pro-actively closed.

- at least one connection should remain open to determine application
responsiveness.

  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, 17 Dec 2008 17:40:09 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_26d31129-88e8-46c5-9100-33d20413d498_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Watchdog logic
Date: Wed, 17 Dec 2008 09:39:38 -0800
MIME-Version: 1.0

--_26d31129-88e8-46c5-9100-33d20413d498_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


In a previous message (http://ops.ietf.org/lists/radiusext/2008/msg00857.ht=
ml) Alan DeKok
pointed out:

"With TCP=2C there is a connection between client and server.  The
watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
ID has to be reserved=2C because the client can't open a new connection to
test if an existing connection is still alive."

While it's true that the watchdog timer algorithm is defined per connection=
=2C
it seems like Status-Server is about determining whether a server is up
or not.  The only way to determine whether a connection is down
is to wait for it to close (either via a RESET or timeout).  RFC 3539
attempts to detect a failure at the application layer prior to connection f=
ailure.=20

I'm wondering what the implications would be of using two separate connecti=
ons=2C=20
one for Status-Server/Access-Accept and the other=20
one for Access-Request/Access-Accept transactions.=20

The failover logic would change=2C to be sure.  For example=2C=20
a connection failure on the Request/Accept connection would probably trigge=
r
failover=2C regardless of the state of the Status-Server/Accept connection.=
=20
Also=2C the state of the two connections could get out of=20
sync=3B for example=2C if the Request/Accept connection was quite busy=2C
then the Status/Accept connection might send little or no traffic=2C
which might cause middleboxes (e.g. a NAT) to lose connection state
on the Status/Accept connection.  In such a situation=2C you might just
be able to bring up another Status/Accept connection rather than=20
triggering failover.=20



=20

--_26d31129-88e8-46c5-9100-33d20413d498_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In a previous message (http://ops.ietf.org/lists/radiusext/2008/msg00857.ht=
ml) Alan DeKok<br>pointed out:<br><br><pre>"With TCP=2C there is a connecti=
on between client and server.  The<br>watchdog timer algorithm in RFC 3539 =
is defined per *connection*.  So an<br>ID has to be reserved=2C because the=
 client can't open a new connection to<br>test if an existing connection is=
 still alive."<br><br>While it's true that the watchdog timer algorithm is =
defined per connection=2C<br>it seems like Status-Server is about determini=
ng whether a server is up<br>or not.  The only way to determine whether a c=
onnection is down<br>is to wait for it to close (either via a RESET or time=
out).  RFC 3539<br>attempts to detect a failure at the application layer pr=
ior to connection failure. <br><br>I'm wondering what the implications woul=
d be of using two separate connections=2C <br>one for Status-Server/Access-=
Accept and the other <br>one for Access-Request/Access-Accept transactions.=
 <br><br>The failover logic would change=2C to be sure.  For example=2C <br=
>a connection failure on the Request/Accept connection would probably trigg=
er<br>failover=2C regardless of the state of the Status-Server/Accept conne=
ction. <br>Also=2C the state of the two connections could get out of <br>sy=
nc=3B for example=2C if the Request/Accept connection was quite busy=2C<br>=
then the Status/Accept connection might send little or no traffic=2C<br>whi=
ch might cause middleboxes (e.g. a NAT) to lose connection state<br>on the =
Status/Accept connection.  In such a situation=2C you might just<br>be able=
 to bring up another Status/Accept connection rather than <br>triggering fa=
ilover. <br><br><br><br></pre>&nbsp=3B<table style=3D"border-top: 1px solid=
 black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=
=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=
=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C =
203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 24px=3B font-=
size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">=
</span></a><br></td></tr></tbody></table></body>
</html>=

--_26d31129-88e8-46c5-9100-33d20413d498_--

--
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, 17 Dec 2008 17:23:39 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_42a820e1-386f-45cd-a21f-926389685def_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Wed, 17 Dec 2008 09:22:31 -0800
MIME-Version: 1.0

--_42a820e1-386f-45cd-a21f-926389685def_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> > Why should the ID be unique regardless of packet code when run
> > over reliable transport=2C but not UDP?  This suggests that the ID is
> > being processed differently for unreliable vs. reliable transport=2C wh=
ich
> > seems odd.
>=20
>   With UDP=2C there is no "connection" from client to server.  So any
> Status-Server checks are sent from any client port.  This removes much
> of the problem of reserving one ID: the client just opens another source
> port.
>=20
>   If it uses the same source port for Status-Server as for
> Access-Request=2C then it would need to ensure that the ID allocated to
> Status-Server is unused by any Access-Request.

The problem is not so much with the Status-Server/Access-Request ID
conflict=2C as with the potential conflict of Access-Accept IDs=2C correct?=
=20

>   With TCP=2C there is a connection between client and server.  The
> watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
> ID has to be reserved=2C because the client can't open a new connection t=
o
> test if an existing connection is still alive.

Ah.  I understand now.  Let's talk about the implications of this on a sepa=
rate
thread.  Some of the above logic might be worth putting into the document.=
=20



--_42a820e1-386f-45cd-a21f-926389685def_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B &gt=3B Why should the ID be unique regardless of packet code when ru=
n<br>&gt=3B &gt=3B over reliable transport=2C but not UDP?  This suggests t=
hat the ID is<br>&gt=3B &gt=3B being processed differently for unreliable v=
s. reliable transport=2C which<br>&gt=3B &gt=3B seems odd.<br>&gt=3B <br>&g=
t=3B   With UDP=2C there is no "connection" from client to server.  So any<=
br>&gt=3B Status-Server checks are sent from any client port.  This removes=
 much<br>&gt=3B of the problem of reserving one ID: the client just opens a=
nother source<br>&gt=3B port.<br>&gt=3B <br>&gt=3B   If it uses the same so=
urce port for Status-Server as for<br>&gt=3B Access-Request=2C then it woul=
d need to ensure that the ID allocated to<br>&gt=3B Status-Server is unused=
 by any Access-Request.<br><br>The problem is not so much with the Status-S=
erver/Access-Request ID<br>conflict=2C as with the potential conflict of Ac=
cess-Accept IDs=2C correct? <br><br>&gt=3B   With TCP=2C there is a connect=
ion between client and server.  The<br>&gt=3B watchdog timer algorithm in R=
FC 3539 is defined per *connection*.  So an<br>&gt=3B ID has to be reserved=
=2C because the client can't open a new connection to<br>&gt=3B test if an =
existing connection is still alive.<br><br>Ah.&nbsp=3B I understand now.&nb=
sp=3B Let's talk about the implications of this on a separate<br>thread.&nb=
sp=3B Some of the above logic might be worth putting into the document. <br=
><br><br></body>
</html>=

--_42a820e1-386f-45cd-a21f-926389685def_--

--
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, 17 Dec 2008 14:26:27 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 15:26:09 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> Yes. I suggest that the Extended attributes draft (and maybe even the
>> guidelines document) contain text that says "Extended attributes with
>> Vendor-Id of zero (0) are not to be interpreted as VSA's within the
>> meaning of the other drafts".
> 
> You might be able to make that recommendation with respect to
> implementations
> that understand Extended Attributes (e.g. implementations of the Extended
> Attribute specification). But how can we say that with respect to existing
> implementations?  This implies that legacy implementations will treat
> Extended Attributes like VSAs (e.g. ignore them if they don't understand
> them).  

  I think that's what will happen.

  We can't change the behavior of legacy implementations.  We just have
to be careful about how we use the extended attributes.

  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, 17 Dec 2008 14:25:14 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 15:25:00 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: draft-ietf-radext-status-server-02 editorials (fwd)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> Ok... so should it be Experimental, or Informational?
> 
> FWIW, I'd say Informational.  That is what we did for RFC 5176, since
> its original implementation had so many warts.  Where there were
> potential fixes, we pointed them out, but since the goal was to
> describe what was implemented, we could not break backward
> compatibility by inserting MUST/MUST NOT language to outlaw
> poor practices (e.g. the original specification enabled replay
> attacks). 

  OK.  The next version will be marked "Informational".

  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, 17 Dec 2008 14:23:41 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 15:23:14 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Summary of WG review of "RADIUS over TCP" document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> I would prefer to leave the discussion of Status-Server && RADIUS ID
>> use in this document. The traditional use of Status-Server is over UDP,
>> and therefore does not have the issues presented here. (i.e. suggestion
>> to reserve one RADIUS ID per TCP connection for Status-Server.)
> 
> Why should the ID be unique regardless of packet code when run
> over reliable transport, but not UDP?  This suggests that the ID is
> being processed differently for unreliable vs. reliable transport, which
> seems odd.

  With UDP, there is no "connection" from client to server.  So any
Status-Server checks are sent from any client port.  This removes much
of the problem of reserving one ID: the client just opens another source
port.

  If it uses the same source port for Status-Server as for
Access-Request, then it would need to ensure that the ID allocated to
Status-Server is unused by any Access-Request.

  With TCP, there is a connection between client and server.  The
watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
ID has to be reserved, because the client can't open a new connection to
test if an existing connection is still alive.

  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, 17 Dec 2008 13:55:50 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Dec 2008 14:54:53 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-radext-radsec-02 for WGLC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi, Joe,

thanks for the review!
> Here are some working group last call comments on RADSEC:
>
> 1.  How is backward compatibility/forward migration of RADSEC handled?
> Operational recommendations in this area should be discussed.   The
> potential for rollback attacks should also be covered in the security
> considerations section.
>   

True. I had hoped to offload backward compatibility to the TCP transport
document, since this is the one with the new transport. But since TCP
w/o TLS and TCP with TLS have different port numbers, a distinct issue
is raised between the two. Effectively, both tcp-transport and radsec
need to have their own backwards compatibility section. I will add text
to the next revision, also for the security considerations.

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

The hesitance against mandating specific options is historic from when I
thought this would only become an informational description. I'll
merrily promote the check options mentioned in the document to
mandatory-to-implement. A revised draft will follow.

> 3.  I'm not sure I understand the choice of ciphersuites.
>
> Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that it would be
> much preferable to use AES or 3DES? 
>   

Hm... This was a first shot :-) I can't brag about being a cipher suite
expert. Can you create a list of suggested cipher suites?

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

I fully agree that using a fixed, well-known shared secret is suicidal
when not using TLS. I'm not sure though if it needs to be in this
document though... the document specifies how to behave when *doing*
TLS. People who implement TCP only (without RadSec) wouldn't necessarily
read the RadSec document anyway. So I'm not sure if it makes sense to
write it down here. It makes much sense though to add this word of
warning to tcp-transport though. So... any particular opinion in the
group about adding this or not?

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

The whole dynamic discovery will be moved to a separate document, as
discussed in MSP. That other document should clearly define this though,
agreed.

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

I'm almost certain it would! There are certainly deployment scenarios
where a PKI rollout could be seen as "overkill". I tried to formulate
the draft PKI-agnostic, saying "*When using X.509 certificates* in the
"Connection Setup" section, hoping to imply that any other way of
establishing a TLS connection, like with a PSK, is not excluded. I can
make this more explicit though.

Greetings,

Stefan Winter

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

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Dec 2008 17:11:53 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_380781a3-26dd-4d14-a4b9-4124844d8442_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, "David B. Nelson" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Tue, 16 Dec 2008 09:11:30 -0800
MIME-Version: 1.0

--_380781a3-26dd-4d14-a4b9-4124844d8442_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   Yes.  I suggest that the Extended attributes draft (and maybe even the
> guidelines document) contain text that says "Extended attributes with
> Vendor-Id of zero (0) are not to be interpreted as VSA's within the
> meaning of the other drafts".

You might be able to make that recommendation with respect to implementatio=
ns
that understand Extended Attributes (e.g. implementations of the Extended
Attribute specification). But how can we say that with respect to existing=
=20
implementations?  This implies that legacy implementations will treat
Extended Attributes like VSAs (e.g. ignore them if they don't understand
them).  =20

--_380781a3-26dd-4d14-a4b9-4124844d8442_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Yes.  I suggest that the Extended attributes draft (and maybe even=
 the<br>&gt=3B guidelines document) contain text that says "Extended attrib=
utes with<br>&gt=3B Vendor-Id of zero (0) are not to be interpreted as VSA'=
s within the<br>&gt=3B meaning of the other drafts".<br><br>You might be ab=
le to make that recommendation with respect to implementations<br>that unde=
rstand Extended Attributes (e.g. implementations of the Extended<br>Attribu=
te specification). But how can we say that with respect to existing <br>imp=
lementations?&nbsp=3B This implies that legacy implementations will treat<b=
r>Extended Attributes like VSAs (e.g. ignore them if they don't understand<=
br>them).&nbsp=3B&nbsp=3B <br></body>
</html>=

--_380781a3-26dd-4d14-a4b9-4124844d8442_--

--
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, 16 Dec 2008 17:07:05 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_2653eca6-4b77-430c-8f36-e519a7087396_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, "David B. Nelson" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: draft-ietf-radext-status-server-02 editorials (fwd)
Date: Tue, 16 Dec 2008 09:06:48 -0800
MIME-Version: 1.0

--_2653eca6-4b77-430c-8f36-e519a7087396_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   Ok... so should it be Experimental=2C or Informational?

FWIW=2C I'd say Informational.  That is what we did for RFC 5176=2C since
its original implementation had so many warts.  Where there were
potential fixes=2C we pointed them out=2C but since the goal was to
describe what was implemented=2C we could not break backward
compatibility by inserting MUST/MUST NOT language to outlaw
poor practices (e.g. the original specification enabled replay
attacks). =20

--_2653eca6-4b77-430c-8f36-e519a7087396_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Ok... so should it be Experimental=2C or Informational?<br><br>FWI=
W=2C I'd say Informational.&nbsp=3B That is what we did for RFC 5176=2C sin=
ce<br>its original implementation had so many warts.&nbsp=3B Where there we=
re<br>potential fixes=2C we pointed them out=2C but since the goal was to<b=
r>describe what was implemented=2C we could not break backward<br>compatibi=
lity by inserting MUST/MUST NOT language to outlaw<br>poor practices (e.g. =
the original specification enabled replay<br>attacks).&nbsp=3B <br></body>
</html>=

--_2653eca6-4b77-430c-8f36-e519a7087396_--

--
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, 16 Dec 2008 17:02:31 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_7b9c7ebd-af26-4d21-ba64-6269f183df06_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: [ISSUE] Status-Server
Date: Tue, 16 Dec 2008 09:02:08 -0800
MIME-Version: 1.0

--_7b9c7ebd-af26-4d21-ba64-6269f183df06_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> > * I would suggest removing all of section 5.  These topics seem related=
=2C
> > but not germane to the purpose and scope of this doc.

I can see removing all of Section 5=2C though I would want the material in
Section 5.2 to end up somewhere (maybe the RADIUS over TCP doc).=20

Section 5.1 does seem tangential to the goal of describing how Status-Serve=
r
is used. =20

Section 5.2 does seem relevant=2C since it clarifies the use/limitations of
Status-Server over reliable transport.  This section could just as easily
go in the RADIUS over TCP document=2C though.=20

At IETF 73=2C we talked about removing references to CoA (Section 5.3).=20


--_7b9c7ebd-af26-4d21-ba64-6269f183df06_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B &gt=3B * I would suggest removing all of section 5.  These topics se=
em related=2C<br>&gt=3B &gt=3B but not germane to the purpose and scope of =
this doc.<br><br>I can see removing all of Section 5=2C though I would want=
 the material in<br>Section 5.2 to end up somewhere (maybe the RADIUS over =
TCP doc). <br><br>Section 5.1 does seem tangential to the goal of describin=
g how Status-Server<br>is used.&nbsp=3B <br><br>Section 5.2 does seem relev=
ant=2C since it clarifies the use/limitations of<br>Status-Server over reli=
able transport.&nbsp=3B This section could just as easily<br>go in the RADI=
US over TCP document=2C though. <br><br>At IETF 73=2C we talked about remov=
ing references to CoA (Section 5.3). <br><br></body>
</html>=

--_7b9c7ebd-af26-4d21-ba64-6269f183df06_--

--
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, 16 Dec 2008 16:56:35 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c82e55c1-bc1b-492e-ad36-0403f6224cf4_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Tue, 16 Dec 2008 08:55:32 -0800
MIME-Version: 1.0

--_c82e55c1-bc1b-492e-ad36-0403f6224cf4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   I would prefer to leave the discussion of Status-Server && RADIUS ID
> use in this document.  The traditional use of Status-Server is over UDP=
=2C
> and therefore does not have the issues presented here.  (i.e. suggestion
> to reserve one RADIUS ID per TCP connection for Status-Server.)

Why should the ID be unique regardless of packet code when run
over reliable transport=2C but not UDP?  This suggests that the ID is
being processed differently for unreliable vs. reliable transport=2C which
seems odd.=20


--_c82e55c1-bc1b-492e-ad36-0403f6224cf4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   I would prefer to leave the discussion of Status-Server &amp=3B&am=
p=3B RADIUS ID<br>&gt=3B use in this document.  The traditional use of Stat=
us-Server is over UDP=2C<br>&gt=3B and therefore does not have the issues p=
resented here.  (i.e. suggestion<br>&gt=3B to reserve one RADIUS ID per TCP=
 connection for Status-Server.)<br><br>Why should the ID be unique regardle=
ss of packet code when run<br>over reliable transport=2C but not UDP?&nbsp=
=3B This suggests that the ID is<br>being processed differently for unrelia=
ble vs. reliable transport=2C which<br>seems odd. <br><br></body>
</html>=

--_c82e55c1-bc1b-492e-ad36-0403f6224cf4_--

--
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, 16 Dec 2008 14:45:16 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-tcp-transport-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 16 Dec 2008 06:45:02 -0800 (PST)

--NextPart

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


	Title           : RADIUS Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-02.txt
	Pages           : 16
	Date            : 2008-12-16

The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer.  This document defines RADIUS over the
Transmission Control Protocol (TCP).

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

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

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

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

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Dec 2008 14:35:13 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 15:34:30 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Summary of WG review of "RADIUS over TCP" document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Based on the discussion at IETF 73, the following issues have been filed
> against the document:
> 
> Issue 291 	Pending 	Technical 	UDP/TCP Translation
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20291>
> Alan DeKok

  I've updated the document with text as suggested by Bernard.

> Issue 292 	Pending 	Technical 	Applicability
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20292>
> Alan DeKok 

  I have updated the document as per review, and consolidated the
multiple applicability sections into one.  The document now also says
that using bare TCP is NOT RECOMMENDED.

> Issue 293 	Pending 	Technical 	Watchdog Timer
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20293>
> Alan DeKok

  I would prefer to leave the discussion of Status-Server && RADIUS ID
use in this document.  The traditional use of Status-Server is over UDP,
and therefore does not have the issues presented here.  (i.e. suggestion
to reserve one RADIUS ID per TCP connection for Status-Server.)

  Since this document is discussing non-traditional TCP transport issues
related to Status-Server, this document appears to be the best place for
this discussion.

> Issue 294 	No Discussion 	Technical 	Document Status
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20294>
> Bernard Aboba

  I have updated the document status to be "Experimental", to be in line
with the RadSec document, which is also experimental.

> Issue 295 	Pending 	Technical 	Head of Line Blocking
> <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20295>
> Alan DeKok <mailto:[e-mail]>

  This issue appears to be substantially similar, if not ientical, to
Issue 291.

  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, 16 Dec 2008 10:41:45 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 11:41:04 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Summary of RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Issue 283 	No Discussion 	Technical 	Status-Server Comments
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 283> 	Greg
> Weber

  I have responded to that issue.  The only remaining question for the
WG is whether or not Section 5 is appropriate for the document.  If not,
it can be deleted in its entirety.

> Issue 285 	Pending 	Technical 	Question
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 285> 	Alan
> DeKok <mailto:[e-mail]>

  The text on CoA has been removed as per WG consensus.  This issue
should be now closed.

> Issue 288 	Pending 	Technical 	Review
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 288> 	Stig
> Venaas <mailto:[e-mail]>

  I have updated the document as per comments form the review, with
additional text as per David Nelson.

> Issue 289 	No Discussion 	Editorial 	Editorial Comments
> <http://www.drizzle.com/~aboba/RADEXT/radissues2.html#Issue 289> 	Stig
> Venaas <mailto:[e-mail]>

  I responded in a message on December 8.  The comments are mostly
editorial, and the document has been updated as per the review.  The one
change suggested that was not made was changing "packet" to "message".
RFC 2865, etc. use "packet", so that term is used here for consistency.

> Overall, as was discussed during IETF 73, it should be understood that
> the goal of this document is to document the
> existing Status-Server protocol (which was first developed by Ascend
> Communications in the mid-1990s).  Therefore
> inclusion of non-implemented functionality in this document is out of
> scope.

  The CoA text has been deleted.

  I've also updated the document as per editorial reviews from Alfred.

  I will submit an updated document shortly.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Dec 2008 10:04:17 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 11:03:48 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Greg Weber <[e-mail]>
CC: radext mailing list <[e-mail]>
Subject: Re: [ISSUE] Status-Server
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Weber wrote:
> * idnits says the boilerplate needs to be updated.

  Done.

> *  In section 3, I see: "Status-Server packets MAY include NAS-Identifier,
> one of NAS-IP-Address or NAS-IPv6-Address, and Reply-Message."
> This conflicts with the Table of Attributes in section 6 which indicates
> that Reply-Message cannot be included in Status-Server packets.

  The Status-Server packet shouldn't include a Reply-Message.  I've
updated the document.

> * Reply-Message can be included in Access-Accept, but not Acct-Response?
> That means the Verbose Query and Response example in section 7.3 works
> only for authentication servers and not accounting servers.  That seems like
> a discontinuity.

  Yes.  It's in line with existing implementations, and with practices
for Accounting-Response.  I wouldn't want this document to make it look
like Accounting-Response can now contain standard RADIUS attributes.

> * The Table of Attributes in section 6 indicates that Calling-Station-Id
> may be included Status-Server and Access-Accept packets.  This
> conflicts with RFC 2865 which disallows that attribute in Access-Accept.
> And, how would this attribute be populated in Status-Server packets
> where there is no associated calling station?

  The reference to Calling-Station-Id has been removed from the Table of
Attributes.

> * I would suggest removing all of section 5.  These topics seem related,
> but not germane to the purpose and scope of this doc.

  Possibly.  Are there other people who agree?

> * In section 4.1, I see "Robust implementations SHOULD accept any Response
> packet as a valid response to a Status-Server packet..."  That seems to be a
> pretty fundamental change to the RADIUS request/response model.  I would
> suggest removing that paragraph or changing it to a MAY.

  As per other reviews, I've updated that to say SHOULD accept
Access-Accept/Accounting-Response.  Other response types are NOT
RECOMMENDED.

> Small changes by section:
> ToC: Fix indent & missing title on 2.3.2
> Section 3: "MUST NOTE" -> "MUST NOT"
> Section 3.1: "is an CoA-ACK packet" -> "is a CoA-ACK packet."

  I've deleted that text.

> Section 4.3: "to start packets to start" -> "to start"
> Section 4.4: "may sent" -> "may be sent"
> Section 4.6: "along along" -> "along"

  Fixed.

> Section 4.6: "impement" -> "implement"
> Section 5.1: "has internal RADIUS server that proxy" ->
>   "has an internal RADIUS server that proxies"

  Fixed as per Alfred's review.

> Section 6: "table provide a guide" -> "table provides a guide"
> 
> Small global changes:
> "it's" -> "its" (6 times)
> "wide-spread" -> "widespread" (2 times)

  Fixed.

> "inter-operable" -> "interoperable" (1 time)

  Fixed.

> "use-case" -> "use case" (3 times)

  Fixed.

> "pro-actively" -> "proactively" (1 time)

  Deleted.

> "re-use" -> "reuse" (3 times)

  Fixed.

> "coa" -> "CoA" (2 times)

  Deleted.

> "16-octet" -> "16 octet" (3 times)

  Fixed.

  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, 16 Dec 2008 09:35:38 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 10:35:18 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Is it possible to make a meaningful and logical distinction between Extended
> Attribute and Vendor Specific Attribute? 

  Yes.  I suggest that the Extended attributes draft (and maybe even the
guidelines document) contain text that says "Extended attributes with
Vendor-Id of zero (0) are not to be interpreted as VSA's within the
meaning of the other drafts".

  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, 16 Dec 2008 09:23:27 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 10:22:44 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Given that the intended scope of this draft is to document an implemented
> but heretofore undocumented practice, it seems inappropriate that this draft
> would Update any other RFCs, be they Standards Track or Informational.
> 
> In publishing this draft, the WG does not intend revise any aspects of the
> RADIUS operational model.  We wish acknowledge what's been deployed, without
> raising the status of that deployment so as to create defacto changes to the
> de jure RADIUS protocol.  Perhaps it's a fine line to tread...

  Ok... so should it be Experimental, or Informational?

  There was also some discussion at one point of making it Proposed
Standard, but I don't think the consensus is going that way.

  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, 16 Dec 2008 07:46:53 +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=ua+81TN/8A3RXMGOlKhmTKHQCl1cMSPiqrMBnX+bArQ=; b=EH4ARzN10CPZ5WJUCn5yFnFb1EpczdSXUurl7aRUNKEwPEbxwSyuPDaetRC/nd2nQM ZVOSV627PR0C8xR7DOXjZZ7ICv0zFzex0rFWUTUyyxfeJ/1jTSML/h5ing2qVCpDnkAH 1+wOrxMmcNylqKQpxyWnkND+FGYZPzZOZGo/M=
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=DnzV/Q0GxrymHamXTk+7G/6PwbCU8fCaNAQQJpeD7t9lyvsGc4EhsnRJONa5lbBlVQ FqDn7c3Fhj/7LS95E00LoiQt/UPtzkWbIYoHaOgJP+Wh8RCVTcCPCiZHUoh8ZxeI37KK XPwNAiRiHUAUhi/h3py1SzkZAvZrHthMQI6ao=
Message-ID: <[e-mail]>
Date: Tue, 16 Dec 2008 02:46:04 -0500
From: "Greg Weber" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Subject: Re: Issue with Guidelines document
Cc: "Bernard Aboba" <[e-mail]>,  "[e-mail]" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Dec 15, 2008 at 2:39 AM, Alan DeKok <[e-mail]> wrote:
> Greg Weber wrote:
>>>  I would like to know what it *means* to have VSA's in an
>>> Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
>>> them?  Change it's behavior?
>>
>> This can be used to communicate server load or pending planned downtime
>> information back to the NAS which then can be used in server selection
>> algorithms.
>
>  That sounds like a bit of a hack to me.  "Yes I've stored the
> accounting data for bob, and by the way, I'm rebooting in 5 minutes".

I think this was used with the client's own accounting session id,
not a user's (bob's) session id.  In other words, when the client booted
or was configured for accounting, it sent an Accounting-Request with
Acct-Status-Type = Accounting-On and Acct-Session-Id = "I am foo client".
Then it sent periodic Accounting-Requests (Acct-Status-Type=Interim-Update)
using the same Acct-Session-Id.  The server could send responses to
these interims with the load or potentially planned downtime schedule info.

--
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, 15 Dec 2008 22:47:45 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 17:47:19 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <475EED652C414846BB6CACE3FA7BD7D2@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcleNzfZGXpVGkqcROipF5ra4XbrrQAq2RiQAAh+X8AAAF9EkA==

Bernard Aboba writes...

> It would be good for the Extended Attributes draft to clear this up
> (I've filed on issue on this).  However, a number of existing
> Documents (including RFC 2866 and RFC 5176) make statements about
> the allowable uses of Attribute 26.  Since Extended Attribute
> use Attribute 26, those statements will by default apply.

Well... yes.  That's a logical inference.  I wonder, however, if it's the
inference that we desire.  I think if we fail to separate the restrictions
of the "classic" VSA from the intended use model of the Extended Attributes,
we will have failed in some significant way.  Yes, the Extended Attributes
"overload" the use of the VSA type code, but IMHO they are not VSAs, as we
know them.  Another way of saying this is that all the current references to
type code 26 and/or VSA in the RFCs are in the context of "classic" VSAs,
i.e. "proprietary secret sauce" attributes.

Is it possible to make a meaningful and logical distinction between Extended
Attribute and Vendor Specific Attribute?  If not, I think that the utility
of Extended Attributes will be substantially lessened.



--
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, 15 Dec 2008 22:34:13 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 14:33:26 -0800
Message-ID: <001001c95f05$259affc0$70d0ff40$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcleNzfZGXpVGkqcROipF5ra4XbrrQAq2RiQAAh+X8A=
Content-Language: en-us

David Nelson said:

"If this is a common misunderstanding -- i.e. the traditional usage rules
for
VSAs apply to Extended Attributes -- we should indeed clear up that
confusion immediately.  Perhaps in the Extended Attributes draft itself."

It would be good for the Extended Attributes draft to clear this up
(I've filed on issue on this).  However, a number of existing
Documents (including RFC 2866 and RFC 5176) make statements about
the allowable uses of Attribute 26.  Since Extended Attribute
use Attribute 26, those statements will by default apply.    


--
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, 15 Dec 2008 21:07:08 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Alfred ?'" <[e-mail]>, <[e-mail]>, "'Alan DeKok'" <[e-mail]>
Subject: RE: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)
Date: Mon, 15 Dec 2008 16:06:42 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <C3F7AD99528C426ABF076658CB53A245@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acle9DH1DqSj2E50TZO9oflljP52iAAA8mgQ

Given that the intended scope of this draft is to document an implemented
but heretofore undocumented practice, it seems inappropriate that this draft
would Update any other RFCs, be they Standards Track or Informational.

In publishing this draft, the WG does not intend revise any aspects of the
RADIUS operational model.  We wish acknowledge what's been deployed, without
raising the status of that deployment so as to create defacto changes to the
de jure RADIUS protocol.  Perhaps it's a fine line to tread...



--
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, 15 Dec 2008 20:29:04 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 21:28:13 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], =?UTF-8?B?QWxmcmVkIO+/vQ==?= <[e-mail]>
Subject: Re: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

> From [e-mail] Thu Dec 11 16:15:59 MEZ 2008
...
> (1)  Section 1, last para -- typo/grammar
> 
>       The remaining text contains ...  and discussed security ...
> ---                                                ^
>       The remaining text contains ...  and discusses security ...

  Fixed.
                                                    ^
> 
> (2)  Section 2.1, last para -- typo
> 
> s/qeuries/queries/
>    ^^      ^^

  Fixed.

> (3)  Section 2.3.2
> 
> (3a)  headline missing  (already noted)
> 
> (3b)  requirements language
> 
> Section 2.3.1 starts:
> 
>    Status-Server SHOULD be used instead ...
>                  !!!!!!
> 
> But 2.3.2, which apparently is intended to catch the alternative
> case left open by that 'SHOULD', starts with:
> 
> |  Status-Server may be used instead of ...
>                  ^^^
> For logical consistency, this counterpoint also should use uppercase:
> 
> |  Status-Server MAY be used instead of ...

  OK, thanks.

                 ^^^
> 
> (4)  Section 2.3.3
> 
> Following up from above, 2.3.3 should also be changed:
> 
>    Status-Server may be pro-actively sent ...
> ---
>    Status-Server MAY be pro-actively sent ...
>                  ^^^

  That section has been deleted, at the suggestion of the RADEXT chairs
&& Area Director.

> (5)  Section 3 -- clarifications
> 
> (5a)  1st para below indented part 'Request Authenticator'
> 
> The draft says:
> 
>    Similarly, the Response Authenticator field of an Access-Accept
>    packet sent in response to Status-Server queries MUST be generated
>    using the same method as used for for calculating the Response
> |  Authenticator of the Access-Accept, with the Status-Server Request
>    Authenticator taking the place of the Access-Request Request
>    Authenticator.
> 
> For clarity, I suggest to insert a phrase better qualifying the
> Access-Accept taken as a reference:
> 
>    Similarly, the Response Authenticator field of an Access-Accept
>    packet sent in response to Status-Server queries MUST be generated
>    using the same method as used for for calculating the Response
> |  Authenticator of the Access-Accept sent in response to an Access-
>    vvvvvvvv                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  Request, with the Status-Server Request Authenticator taking the
>    place of the Access-Request Request Authenticator.

  Good suggestion, thanks.

> (5b)  2nd para below indented part 'Request Authenticator'
> 
> Similarly, I suggest to improve the wording in the next paragraph:
> 
>    The Response Authenticator field of an Accounting-Response packet
>    sent in response to Status-Server queries MUST be generated using the
>    same method as used for for calculating the Response Authenticator of
> |  the Accounting-Response, with the Status-Server Request Authenticator
>    taking the place of the Accounting-Request Request Authenticator.
> ---
>    The Response Authenticator field of an Accounting-Response packet
>    sent in response to Status-Server queries MUST be generated using the
>    same method as used for for calculating the Response Authenticator of
> |  the Accounting-Response sent in response to and Accounting-Request,
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    with the Status-Server Request Authenticator taking the place of the
>    Accounting-Request Request Authenticator.

  Agreed.

> 
> (6)  Section 3.1
> 
> (6a)  headline
> 
> To better indicate the simplification for implementations, which seems
> to be the spirit of this detail, I suggest to change the headline
> (this will be even more become clear by the subsequent modification
> I'll propose below):
> 
> |3.1.  Consistent definition for Status-Server
> ---
> |3.1.  Single Definition for Status-Server
>        ^^^^^^^^
> 
> (6b)  2nd paragraph -- clarification / textual improvement
> 
> I suggest to replace "one" by "a single":
> 
>           vvv
> |  Having one definition for Status-Server packets is simpler than
>    having different definitions for different destination ports.  [...]
> ---       vvvvvvvvv
> |  Having a single definition for Status-Server packets is simpler than
>    having different definitions for different destination ports.  [...]

  That is reasonable.

> 
> (7)  Section 4 -- consistent spelling of abbreviation
> 
> For uniformity and consistency, I suggest to    s/coa/CoA/
> (2 instances in Section 4).

  That text has been deleted at the suggestion of the RADEXT chairs &&
the Area Director.

> 
> (8)  Section 4.2
> 
> (8a)  need to update the metadata (front matter)
> 
> The third para says:
> 
>    We note that [RFC2865] Section 3 defines a number of RADIUS Codes,
>    but does not make statements about which Codes are valid for port
> |  1812.  In contrast, [RFC2866] Section 3 specifies that only RADIUS
> |  Accounting packets are to be sent to port 1813.  This specification
>    is compatible with [RFC2865], as it uses a known Code for packets to
>    port 1812.  This specification is not compatible with [RFC2866], as
>    it adds a new code (Status-Server) that is valid for port 1812.
> |  However, as the category of [RFC2866] is Informational, this conflict
> |  is acceptable.
> 
> This statement clearly indicates that this specification
> *** Updates RFC 2866 ***.

  I'll have to ask the RADEXT chairs for help on this one.  Can we do this?

> This relationship really should be noted in the front matter of the
> draft.
> 
> (8b)  7th para -- word omission
> 
> Please correct:
>                                          v
> |  The server MAY prioritize the handling Status-Server queries over the
>    handling of other requests, subject to the rate limiting described
>    above.
> ---                                      vvvv
> |  The server MAY prioritize the handling of Status-Server queries over
>    the handling of other requests, subject to the rate limiting
>    described above.

  Fixed as per earlier comments.

> 
> (9)  Section 4.3
> 
> (9a)  1st para -- improvement #1
...
> (9b)  1st para -- improvement #2 (missing word)
...
> (9c)  4th para -- inconsistency with 1st para
...
> (9d)  last para -- punctuation

  All of this text has been deleted as per comments from the chairs &&
the AD.

> (10)  Section 4.4, 2nd para -- improvement
> 
> I suggest to slightly change the wording:
> 
>         [...].  If the server is still unresponsive, however, the result
>    may be user login failures.  The Status-Server solution is an ideal
> |  one to solve this problem.
> ---^^^
>         [...].  If the server is still unresponsive, however, the result
>    may be user login failures.  The Status-Server solution is an ideal
> |  way to solve this problem.
>    ^^^

  Fixed, thanks.

> 
> (11)  Section 4.6
> 
> (11a)  4th para below first figure -- improvement/grammar
> 
> I suggest to change:
> 
>            [...].  If the implementation fails to respond, then the NAS
>    cannot distinguish between the Proxy Server being down, or the next
> |  server along along the proxy chain is unreachable.
> --                                    ^^
>            [...].  If the implementation fails to respond, then the NAS
>    cannot distinguish between the Proxy Server being down, or the next
> |  server along along the proxy chain being unreachable.
>                                       ^^^^^

  Agreed.

> (11b)  5th para below first figure -- missing word
> 
> I suggest to insert "in" as follows:
> 
>    In the worst case, failures in routing for Realm A may affect users
> |  Realm B.  [...]
> ---^
>    In the worst case, failures in routing for Realm A may affect users
> |  in Realm B.  [...]
>    ^^^^

  Changed to "of" Realm B, as per earlier comments.

> (11c)  denomination of entities
> 
>>From the second figure ...
> 
>                 /-> Proxy Server P -----> Home Server P
>                /                    \ /
>             NAS                      X
>                \                    / \
>                 \-> Proxy Server S -----> Home Server S
> 
> ... it becomes apparent that the denominations of the entities are
> not chosen carefully; in this case, 'P' and 'S' are both overloaded.
> 
> To disambiguate the whole stuff, here's my proposal:
> 
> Use 'P1' and 'P2' (in place of 'P' and 'S') for the two Proxy Servers
> in both scenarios (figures and text); use 'H1' and 'H2'  for the Home
> Servers in the second scenario.

  The terms "Primary" and "Secondary" are commonly used in RADIUS.  I'll
see if there's some compromise that uses historical terminology, but
also clarifies the diagram.

> (12)  Section 4.7 -- terminology
> 
> The draft uses the colloquial, but incorrect short term "MIB" whenever
> in wants to indicate a "MIB Module".  Please see the BCP 111, RFC 4181
> for the detailed rationale of the precise terminology.
> 
> Therefore,  please change     MIB[s]   -->   MIB module[s]
> throughout the text.

  Fixed.

> (13)  Section 4.7.1
> 
> (13a)  need to update the metadata (front matter)
> 
> The 1st para clearly indicates that this draft
> ***  Updates RFC 4669 and RFC 4671  ***
> 
> To make it easier for developers and users to find this update,
> please amend the draft front matter accordingly.

  I'm not sure it *updates* those documents.  Comments from the Area
Director would help here.


> (13b)  last para
> 
> The draft text is confusingly complicated, yet inprecise.
> The draft text could be misunderstood as recommending to
> define alternate MIB modules where it better should recommend
>  using extensions for standard MIB tables.
> 
> I suggest to modify this paragraph as follows:
> 
>    If a server supports Status-Server and the [RFC4669] or [RFC4671]
> |  MIBs, then it SHOULD also support vendor-specific MIBs containing
> |  similar information as the standard MIBs, but which are instead
>    dedicated solely to tracking Status-Server requests and responses.
> |  Any definition of the server MIBs for Status-Server is outside of the
>    scope of this document.
> ---
> |  If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB
> |  modules, then it SHOULD also support vendor-specific MIB extensions
>    ^^^^^^^                                              ^^^^^^^^^^^^^^^^
>    dedicated solely to tracking Status-Server requests and responses.
> |  Any definition of the server MIB module extensions for Status-Server
>                                 ^^^^^^^^^^^^^^^^^^^^^
>    is outside of the scope of this document.

  OK.

> (Please note the deletion of the full 3rd line!)

  Noted.

> (14)   Section 4.7.2
> 
> (14a)
> Similar as noted in (13a) above, the first para of 4.7.2 clearly
> indicates that this specification  *** updates RFCs 4668 and 4670 ***.

  Maybe clarifies?  I'm unsure here.

> (14b)
> Similarly as in (13b) above, the last para of 4.7.2 should be modified
> as follows:
> 
>    If an implementation supports Status-Server and the [RFC4668] or
> |  [RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs
> |  containing similar information as those MIBs, but which are instead
>    dedicated solely to tracking Status-Server requests and responses.
> |  Any definition of the client MIBs for Status-Server is outside of the
>    scope of this document.
> ---
>    If an implementation supports Status-Server and the [RFC4668] or
> |  [RFC4670] MIB modules, then it SHOULD also support vendor-specific
>              ^^^^^^^^^^^
> |  MIB extensions dedicated solely to tracking Status-Server requests
>    ^^^^^^^^^^^^^^^
> |  and responses.  Any definition of the client MIB module extensions
>                                                 ^^^^^^^^^^^^^^^^^^^^^
>    for Status-Server is outside of the scope of this document.

  OK.

> (15)  Section 5.1
> 
> (15a)  2nd para, last sentence -- typo/grammar
> 
> Please   s/server/servers/  in ...
> 
>                      [...].  These queries are most useful in
> |  deployments where an administrator has internal RADIUS servers that

  Fixed, thanks.

> (15b)  3rd para -- improvement
> 
> To improve the readability, I suggest varying the multiple uses of
> "use", e.g.:
>       vvvv            vvvv                vvvvv
>    If used, the names used for these test users SHOULD be difficult to
>    guess by an attacker.  [...]
> ---                   vvvvvvvv
>    If used, the names utilized for these test users SHOULD be difficult
>    to guess by an attacker.  [...]

  Ok.


> (16)  Section 5.2  -- outdated text
> 
> The first paragraph seems to be outdated now by the RADIUS-over-TCP
> draft!

  Yes.  I'll see if I can coordinate the text.  The "RADIUS over TCP"
will be published after this one.  I don't know that we want to have the
two drafts depend on each other...

> (17)  Section 5.3, 1st para
> 
> The draft says:
>                                                   [...].  It may be
>    tempting to increase the utility of Status-Server by having the
> |  responses carry additional information, implementors are warned that
>    such uses have not been analyzed for potential security issues or
>    network problems.
> 
> To better reflect the relationship between the two (half-)sentences
> connected with a comma, I propose to either use a semicolon instead
> of the comma, or insert  " but" after the comma:
> 
>                                                   [...].  It may be
>    tempting to increase the utility of Status-Server by having the
> |  responses carry additional information, but implementors are warned
>    that such uses have not been analyzed for potential security issues
>    or network problems.

  I would suggest using "but".

  Thanks for the feedback.

  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, 15 Dec 2008 18:49:14 +0000
Date: Mon, 15 Dec 2008 18:48:52 +0000 (UTC)
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Subject: Fwd: draft-ietf-radext-status-server-02 editorials (fwd)
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_166748_896156211.1229366932742"

------=_Part_166748_896156211.1229366932742
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



Forwarding for a non-list member:=20


>From [e-mail] Thu Dec 11 16:15:59 MEZ 2008=20
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16=
.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id AA022718557; Thu, 11 Dec 2008 16:15:57 +0100=
=20
Return-Path: <[e-mail]>=20
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id QAA22212; Thu, 11 Dec 2008 16:15:57 +0100 (MEZ=
)=20
From: Alfred H=EF=BF=BDnes <[e-mail]>=20
To: [e-mail]=20
Cc: [e-mail]=20
Message-Id: <[e-mail]>=20
Date: Thu, 11 Dec 2008 16:15:56 +0100 (MEZ)=20
Subject: draft-ietf-radext-status-server-02 editorials=20

Hello,=20
after studying the Internet-Draft authored/edited by you,=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-radext-status-server-02,=
=20
I'd like to submit a few comments, mostly addressing textual=20
flaws I found in that memo.=20

Note on proofreading:=20
=C2=A0=C2=A0Quickly browsing the radext list, I saw that there's some overl=
ap=20
=C2=A0=C2=A0of another review with the items below. =C2=A0My apologies -- I=
 didn't=20
=C2=A0=C2=A0clean up that all now to avoid having to renumber the items.=20


The items below are presented in textual order.=20
To give more context, sometimes I quote larger blocks of text=20
literally and show the replacement proposed using the shorthand=20
notation:=20

=C2=A0=C2=A0 <original draft text>=20
---=20
=C2=A0=C2=A0 <modified text>=20

I use change bars ('|' in column 1) and up/down pointing marker=20
lines ('^^^'/'vvv') to emphasize the location of textual issues=20
and/or proposed corrections. =C2=A0Modified text has been re-adjusted=20
to match RFC formatting rules, where appropriate.=20


(1) =C2=A0Section 1, last para -- typo/grammar=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The remaining text contains ... =C2=A0and discuss=
ed security ...=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0The remaining text contains ... =C2=A0and discuss=
es security ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^=20

(2) =C2=A0Section 2.1, last para -- typo=20

s/qeuries/queries/=20
=C2=A0=C2=A0 ^^ =C2=A0 =C2=A0 =C2=A0^^=20

(3) =C2=A0Section 2.3.2=20

(3a) =C2=A0headline missing =C2=A0(already noted)=20

(3b) =C2=A0requirements language=20

Section 2.3.1 starts:=20

=C2=A0=C2=A0 Status-Server SHOULD be used instead ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 !!!!!!=20

But 2.3.2, which apparently is intended to catch the alternative=20
case left open by that 'SHOULD', starts with:=20

| =C2=A0Status-Server may be used instead of ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20
For logical consistency, this counterpoint also should use uppercase:=20

| =C2=A0Status-Server MAY be used instead of ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20

(4) =C2=A0Section 2.3.3=20

Following up from above, 2.3.3 should also be changed:=20

=C2=A0=C2=A0 Status-Server may be pro-actively sent ...=20
---=20
=C2=A0=C2=A0 Status-Server MAY be pro-actively sent ...=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20

(5) =C2=A0Section 3 -- clarifications=20

(5a) =C2=A01st para below indented part 'Request Authenticator'=20

The draft says:=20

=C2=A0=C2=A0 Similarly, the Response Authenticator field of an Access-Accep=
t=20
=C2=A0=C2=A0 packet sent in response to Status-Server queries MUST be gener=
ated=20
=C2=A0=C2=A0 using the same method as used for for calculating the Response=
=20
| =C2=A0Authenticator of the Access-Accept, with the Status-Server Request=
=20
=C2=A0=C2=A0 Authenticator taking the place of the Access-Request Request=
=20
=C2=A0=C2=A0 Authenticator.=20

For clarity, I suggest to insert a phrase better qualifying the=20
Access-Accept taken as a reference:=20

=C2=A0=C2=A0 Similarly, the Response Authenticator field of an Access-Accep=
t=20
=C2=A0=C2=A0 packet sent in response to Status-Server queries MUST be gener=
ated=20
=C2=A0=C2=A0 using the same method as used for for calculating the Response=
=20
| =C2=A0Authenticator of the Access-Accept sent in response to an Access-=
=20
=C2=A0=C2=A0 vvvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20
| =C2=A0Request, with the Status-Server Request Authenticator taking the=20
=C2=A0=C2=A0 place of the Access-Request Request Authenticator.=20

(5b) =C2=A02nd para below indented part 'Request Authenticator'=20

Similarly, I suggest to improve the wording in the next paragraph:=20

=C2=A0=C2=A0 The Response Authenticator field of an Accounting-Response pac=
ket=20
=C2=A0=C2=A0 sent in response to Status-Server queries MUST be generated us=
ing the=20
=C2=A0=C2=A0 same method as used for for calculating the Response Authentic=
ator of=20
| =C2=A0the Accounting-Response, with the Status-Server Request Authenticat=
or=20
=C2=A0=C2=A0 taking the place of the Accounting-Request Request Authenticat=
or.=20
---=20
=C2=A0=C2=A0 The Response Authenticator field of an Accounting-Response pac=
ket=20
=C2=A0=C2=A0 sent in response to Status-Server queries MUST be generated us=
ing the=20
=C2=A0=C2=A0 same method as used for for calculating the Response Authentic=
ator of=20
| =C2=A0the Accounting-Response sent in response to and Accounting-Request,=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 with the Status-Server Request Authenticator taking the place =
of the=20
=C2=A0=C2=A0 Accounting-Request Request Authenticator.=20


(6) =C2=A0Section 3.1=20

(6a) =C2=A0headline=20

To better indicate the simplification for implementations, which seems=20
to be the spirit of this detail, I suggest to change the headline=20
(this will be even more become clear by the subsequent modification=20
I'll propose below):=20

|3.1. =C2=A0Consistent definition for Status-Server=20
---=20
|3.1. =C2=A0Single Definition for Status-Server=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 ^^^^^^^^=20

(6b) =C2=A02nd paragraph -- clarification / textual improvement=20

I suggest to replace "one" by "a single":=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvv=20
| =C2=A0Having one definition for Status-Server packets is simpler than=20
=C2=A0=C2=A0 having different definitions for different destination ports. =
=C2=A0[...]=20
--- =C2=A0 =C2=A0 =C2=A0 vvvvvvvvv=20
| =C2=A0Having a single definition for Status-Server packets is simpler tha=
n=20
=C2=A0=C2=A0 having different definitions for different destination ports. =
=C2=A0[...]=20


(7) =C2=A0Section 4 -- consistent spelling of abbreviation=20

For uniformity and consistency, I suggest to =C2=A0 =C2=A0s/coa/CoA/=20
(2 instances in Section 4).=20


(8) =C2=A0Section 4.2=20

(8a) =C2=A0need to update the metadata (front matter)=20

The third para says:=20

=C2=A0=C2=A0 We note that [RFC2865] Section 3 defines a number of RADIUS Co=
des,=20
=C2=A0=C2=A0 but does not make statements about which Codes are valid for p=
ort=20
| =C2=A01812. =C2=A0In contrast, [RFC2866] Section 3 specifies that only RA=
DIUS=20
| =C2=A0Accounting packets are to be sent to port 1813. =C2=A0This specific=
ation=20
=C2=A0=C2=A0 is compatible with [RFC2865], as it uses a known Code for pack=
ets to=20
=C2=A0=C2=A0 port 1812. =C2=A0This specification is not compatible with [RF=
C2866], as=20
=C2=A0=C2=A0 it adds a new code (Status-Server) that is valid for port 1812=
.=20
| =C2=A0However, as the category of [RFC2866] is Informational, this confli=
ct=20
| =C2=A0is acceptable.=20

This statement clearly indicates that this specification=20
*** Updates RFC 2866 ***.=20

This relationship really should be noted in the front matter of the=20
draft.=20

(8b) =C2=A07th para -- word omission=20

Please correct:=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=20
| =C2=A0The server MAY prioritize the handling Status-Server queries over t=
he=20
=C2=A0=C2=A0 handling of other requests, subject to the rate limiting descr=
ibed=20
=C2=A0=C2=A0 above.=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvvv=20
| =C2=A0The server MAY prioritize the handling of Status-Server queries ove=
r=20
=C2=A0=C2=A0 the handling of other requests, subject to the rate limiting=
=20
=C2=A0=C2=A0 described above.=20


(9) =C2=A0Section 4.3=20

(9a) =C2=A01st para -- improvement #1=20

I suggest to improver the wording:=20

=C2=A0=C2=A0 When a Dynamic Authorization Client ([RFC5176] Section 1.3) re=
boots,=20
| =C2=A0it SHOULD send a Status-Server packet to a CoA port to IP addresses=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 !! =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0!!=20
=C2=A0=C2=A0 that are configured as both Dynamic Authorization Servers and =
RADIUS=20
=C2=A0=C2=A0 clients. =C2=A0[...]=20
---=20
=C2=A0=C2=A0 When a Dynamic Authorization Client ([RFC5176] Section 1.3) re=
boots,=20
| =C2=A0it SHOULD send a Status-Server packet to a CoA port at IP addresses=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^=20
=C2=A0=C2=A0 that are configured as both Dynamic Authorization Servers and =
RADIUS=20
=C2=A0=C2=A0 clients. =C2=A0[...]=20

(9b) =C2=A01st para -- improvement #2 (missing word)=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] =C2=A0Wh=
en a response is received, the Dynamic=20
=C2=A0=C2=A0 Authorization Client MUST NOT send further Status-Server packe=
ts to=20
| =C2=A0the CoA port of any Dynamic Authorization until it next reboots.=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] =C2=A0Wh=
en a response is received, the Dynamic=20
=C2=A0=C2=A0 Authorization Client MUST NOT send further Status-Server packe=
ts to=20
| =C2=A0the CoA port of any Dynamic Authorization Server until it next=20
=C2=A0=C2=A0 reboots.=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0^^^^^^^^=20
(9c) =C2=A04th para -- inconsistency with 1st para=20

The final part of the 4th para apparently contradicts the last=20
sentence of the first para (quoted in (9b) above):=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0[...]. =C2=A0The NAS MAY=20
| =C2=A0otherwise decide to receive multiple packets to it's CoA port befor=
e=20
| =C2=A0marking the RADIUS server as responsive. =C2=A0This behavior is=20
| =C2=A0implementation-defined, and SHOULD be configurable.=20

(9d) =C2=A0last para -- punctuation=20

The last comma (after "port 3799") IMO distorts the sentence=20
and should better be deleted.=20


(10) =C2=A0Section 4.4, 2nd para -- improvement=20

I suggest to slightly change the wording:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0If the server is still unresp=
onsive, however, the result=20
=C2=A0=C2=A0 may be user login failures. =C2=A0The Status-Server solution i=
s an ideal=20
| =C2=A0one to solve this problem.=20
---^^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0If the server is still unresp=
onsive, however, the result=20
=C2=A0=C2=A0 may be user login failures. =C2=A0The Status-Server solution i=
s an ideal=20
| =C2=A0way to solve this problem.=20
=C2=A0=C2=A0 ^^^=20


(11) =C2=A0Section 4.6=20

(11a) =C2=A04th para below first figure -- improvement/grammar=20

I suggest to change:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]. =C2=A0If the implementation=
 fails to respond, then the NAS=20
=C2=A0=C2=A0 cannot distinguish between the Proxy Server being down, or the=
 next=20
| =C2=A0server along along the proxy chain is unreachable.=20
-- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]. =C2=A0If the implementation=
 fails to respond, then the NAS=20
=C2=A0=C2=A0 cannot distinguish between the Proxy Server being down, or the=
 next=20
| =C2=A0server along along the proxy chain being unreachable.=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^=20

(11b) =C2=A05th para below first figure -- missing word=20

I suggest to insert "in" as follows:=20

=C2=A0=C2=A0 In the worst case, failures in routing for Realm A may affect =
users=20
| =C2=A0Realm B. =C2=A0[...]=20
---^=20
=C2=A0=C2=A0 In the worst case, failures in routing for Realm A may affect =
users=20
| =C2=A0in Realm B. =C2=A0[...]=20
=C2=A0=C2=A0 ^^^^=20

(11c) =C2=A0denomination of entities=20

>From the second figure ...=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/-> Proxy Serv=
er P -----> Home Server P=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ /=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NAS =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ \=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\-> Proxy Serv=
er S -----> Home Server S=20

... it becomes apparent that the denominations of the entities are=20
not chosen carefully; in this case, 'P' and 'S' are both overloaded.=20

To disambiguate the whole stuff, here's my proposal:=20

Use 'P1' and 'P2' (in place of 'P' and 'S') for the two Proxy Servers=20
in both scenarios (figures and text); use 'H1' and 'H2' =C2=A0for the Home=
=20
Servers in the second scenario.=20


(12) =C2=A0Section 4.7 -- terminology=20

The draft uses the colloquial, but incorrect short term "MIB" whenever=20
in wants to indicate a "MIB Module". =C2=A0Please see the BCP 111, RFC 4181=
=20
for the detailed rationale of the precise terminology.=20

Therefore, =C2=A0please change =C2=A0 =C2=A0 MIB[s] =C2=A0 --> =C2=A0 MIB m=
odule[s]=20
throughout the text.=20

(13) =C2=A0Section 4.7.1=20

(13a) =C2=A0need to update the metadata (front matter)=20

The 1st para clearly indicates that this draft=20
*** =C2=A0Updates RFC 4669 and RFC 4671 =C2=A0***=20

To make it easier for developers and users to find this update,=20
please amend the draft front matter accordingly.=20

(13b) =C2=A0last para=20

The draft text is confusingly complicated, yet inprecise.=20
The draft text could be misunderstood as recommending to=20
define alternate MIB modules where it better should recommend=20
=C2=A0using extensions for standard MIB tables.=20

I suggest to modify this paragraph as follows:=20

=C2=A0=C2=A0 If a server supports Status-Server and the [RFC4669] or [RFC46=
71]=20
| =C2=A0MIBs, then it SHOULD also support vendor-specific MIBs containing=
=20
| =C2=A0similar information as the standard MIBs, but which are instead=20
=C2=A0=C2=A0 dedicated solely to tracking Status-Server requests and respon=
ses.=20
| =C2=A0Any definition of the server MIBs for Status-Server is outside of t=
he=20
=C2=A0=C2=A0 scope of this document.=20
---=20
| =C2=A0If a server supports Status-Server and the [RFC4669] or [RFC4671] M=
IB=20
| =C2=A0modules, then it SHOULD also support vendor-specific MIB extensions=
=20
=C2=A0=C2=A0 ^^^^^^^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 dedicated solely to tracking Status-Server requests and respon=
ses.=20
| =C2=A0Any definition of the server MIB module extensions for Status-Serve=
r=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 is outside of the scope of this document.=20

(Please note the deletion of the full 3rd line!)=20


(14) =C2=A0 Section 4.7.2=20

(14a)=20
Similar as noted in (13a) above, the first para of 4.7.2 clearly=20
indicates that this specification =C2=A0*** updates RFCs 4668 and 4670 ***.=
=20

(14b)=20
Similarly as in (13b) above, the last para of 4.7.2 should be modified=20
as follows:=20

=C2=A0=C2=A0 If an implementation supports Status-Server and the [RFC4668] =
or=20
| =C2=A0[RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs=20
| =C2=A0containing similar information as those MIBs, but which are instead=
=20
=C2=A0=C2=A0 dedicated solely to tracking Status-Server requests and respon=
ses.=20
| =C2=A0Any definition of the client MIBs for Status-Server is outside of t=
he=20
=C2=A0=C2=A0 scope of this document.=20
---=20
=C2=A0=C2=A0 If an implementation supports Status-Server and the [RFC4668] =
or=20
| =C2=A0[RFC4670] MIB modules, then it SHOULD also support vendor-specific=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^=20
| =C2=A0MIB extensions dedicated solely to tracking Status-Server requests=
=20
=C2=A0=C2=A0 ^^^^^^^^^^^^^^^=20
| =C2=A0and responses. =C2=A0Any definition of the client MIB module extens=
ions=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^=20
=C2=A0=C2=A0 for Status-Server is outside of the scope of this document.=20


(15) =C2=A0Section 5.1=20

(15a) =C2=A02nd para, last sentence -- typo/grammar=20

Please =C2=A0 s/server/servers/ =C2=A0in ...=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 [...]. =C2=A0These queries are most useful in=20
| =C2=A0deployments where an administrator has internal RADIUS servers that=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0^=20
=C2=A0=C2=A0 proxy to other internal RADIUS servers, such as for load balan=
cing or=20
=C2=A0=C2=A0 fail over.=20

(15b) =C2=A03rd para -- improvement=20

To improve the readability, I suggest varying the multiple uses of=20
"use", e.g.:=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvv=
v =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvvvv=20
=C2=A0=C2=A0 If used, the names used for these test users SHOULD be difficu=
lt to=20
=C2=A0=C2=A0 guess by an attacker. =C2=A0[...]=20
--- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vvvvvvvv=
=20
=C2=A0=C2=A0 If used, the names utilized for these test users SHOULD be dif=
ficult=20
=C2=A0=C2=A0 to guess by an attacker. =C2=A0[...]=20


(16) =C2=A0Section 5.2 =C2=A0-- outdated text=20

The first paragraph seems to be outdated now by the RADIUS-over-TCP=20
draft!=20


(17) =C2=A0Section 5.3, 1st para=20

The draft says:=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0It may be=20
=C2=A0=C2=A0 tempting to increase the utility of Status-Server by having th=
e=20
| =C2=A0responses carry additional information, implementors are warned tha=
t=20
=C2=A0=C2=A0 such uses have not been analyzed for potential security issues=
 or=20
=C2=A0=C2=A0 network problems.=20

To better reflect the relationship between the two (half-)sentences=20
connected with a comma, I propose to either use a semicolon instead=20
of the comma, or insert =C2=A0" but" after the comma:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]. =C2=A0It may be=20
=C2=A0=C2=A0 tempting to increase the utility of Status-Server by having th=
e=20
| =C2=A0responses carry additional information, but implementors are warned=
=20
=C2=A0=C2=A0 that such uses have not been analyzed for potential security i=
ssues=20
=C2=A0=C2=A0 or network problems.=20


Best regards,=20
=C2=A0=C2=A0Alfred H=EF=BF=BDnes.=20

--=20

+------------------------+--------------------------------------------+=20
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|=20
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: [phone], Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=20
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=[e-mail] =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=20
+------------------------+--------------------------------------------+=20

------=_Part_166748_896156211.1229366932742
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'><P>Forwar=
ding for a non-list member:</P>
<P><BR>From [e-mail] Thu Dec 11 16:15:59 MEZ 2008<BR>Received: fr=
om ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)<BR>&nbsp=
;&nbsp; &nbsp; &nbsp;id AA022718557; Thu, 11 Dec 2008 16:15:57 +0100<BR>Ret=
urn-Path: &lt;[e-mail]&gt;<BR>Received: (from ah@localhost) by z.=
TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)<BR>&nbsp;&nbsp; &nbsp; &nbsp;id QAA222=
12; Thu, 11 Dec 2008 16:15:57 +0100 (MEZ)<BR>From: Alfred H=EF=BF=BDnes &lt=
;[e-mail]&gt;<BR>To: [e-mail]<BR>Cc: [e-mail]=
<BR>Message-Id: &lt;[e-mail]&gt;<BR>Date: Thu, 11 De=
c 2008 16:15:56 +0100 (MEZ)<BR>Subject: draft-ietf-radext-status-server-02 =
editorials<BR><BR>Hello,<BR>after studying the Internet-Draft authored/edit=
ed by you,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;draft-ietf-radext-sta=
tus-server-02,<BR>I'd like to submit a few comments, mostly addressing text=
ual<BR>flaws I found in that memo.<BR><BR>Note on proofreading:<BR>&nbsp;&n=
bsp;Quickly browsing the radext list, I saw that there's some overlap<BR>&n=
bsp;&nbsp;of another review with the items below. &nbsp;My apologies -- I d=
idn't<BR>&nbsp;&nbsp;clean up that all now to avoid having to renumber the =
items.<BR><BR><BR>The items below are presented in textual order.<BR>To giv=
e more context, sometimes I quote larger blocks of text<BR>literally and sh=
ow the replacement proposed using the shorthand<BR>notation:<BR><BR>&nbsp;&=
nbsp; &lt;original draft text&gt;<BR>---<BR>&nbsp;&nbsp; &lt;modified text&=
gt;<BR><BR>I use change bars ('|' in column 1) and up/down pointing marker<=
BR>lines ('^^^'/'vvv') to emphasize the location of textual issues<BR>and/o=
r proposed corrections. &nbsp;Modified text has been re-adjusted<BR>to matc=
h RFC formatting rules, where appropriate.<BR><BR><BR>(1) &nbsp;Section 1, =
last para -- typo/grammar<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The remaining te=
xt contains ... &nbsp;and discussed security ...<BR>--- &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;^<=
BR>&nbsp;&nbsp; &nbsp; &nbsp;The remaining text contains ... &nbsp;and disc=
usses security ...<BR>&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; ^<BR><BR>(2) &nbsp;Sec=
tion 2.1, last para -- typo<BR><BR>s/qeuries/queries/<BR>&nbsp;&nbsp; ^^ &n=
bsp; &nbsp; &nbsp;^^<BR><BR>(3) &nbsp;Section 2.3.2<BR><BR>(3a) &nbsp;headl=
ine missing &nbsp;(already noted)<BR><BR>(3b) &nbsp;requirements language<B=
R><BR>Section 2.3.1 starts:<BR><BR>&nbsp;&nbsp; Status-Server SHOULD be use=
d instead ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; !!!!!!<BR><BR>But 2.3.2, which apparently is intended to catch the alte=
rnative<BR>case left open by that 'SHOULD', starts with:<BR><BR>| &nbsp;Sta=
tus-Server may be used instead of ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; ^^^<BR>For logical consistency, this counterpoi=
nt also should use uppercase:<BR><BR>| &nbsp;Status-Server MAY be used inst=
ead of ...<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 ^^^<BR><BR>(4) &nbsp;Section 2.3.3<BR><BR>Following up from above, 2.3.3 s=
hould also be changed:<BR><BR>&nbsp;&nbsp; Status-Server may be pro-activel=
y sent ...<BR>---<BR>&nbsp;&nbsp; Status-Server MAY be pro-actively sent ..=
.<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^^<BR><=
BR>(5) &nbsp;Section 3 -- clarifications<BR><BR>(5a) &nbsp;1st para below i=
ndented part 'Request Authenticator'<BR><BR>The draft says:<BR><BR>&nbsp;&n=
bsp; Similarly, the Response Authenticator field of an Access-Accept<BR>&nb=
sp;&nbsp; packet sent in response to Status-Server queries MUST be generate=
d<BR>&nbsp;&nbsp; using the same method as used for for calculating the Res=
ponse<BR>| &nbsp;Authenticator of the Access-Accept, with the Status-Server=
 Request<BR>&nbsp;&nbsp; Authenticator taking the place of the Access-Reque=
st Request<BR>&nbsp;&nbsp; Authenticator.<BR><BR>For clarity, I suggest to =
insert a phrase better qualifying the<BR>Access-Accept taken as a reference=
:<BR><BR>&nbsp;&nbsp; Similarly, the Response Authenticator field of an Acc=
ess-Accept<BR>&nbsp;&nbsp; packet sent in response to Status-Server queries=
 MUST be generated<BR>&nbsp;&nbsp; using the same method as used for for ca=
lculating the Response<BR>| &nbsp;Authenticator of the Access-Accept sent i=
n response to an Access-<BR>&nbsp;&nbsp; vvvvvvvv &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^<BR>| &nbsp;Request, with the Status-Server Request Au=
thenticator taking the<BR>&nbsp;&nbsp; place of the Access-Request Request =
Authenticator.<BR><BR>(5b) &nbsp;2nd para below indented part 'Request Auth=
enticator'<BR><BR>Similarly, I suggest to improve the wording in the next p=
aragraph:<BR><BR>&nbsp;&nbsp; The Response Authenticator field of an Accoun=
ting-Response packet<BR>&nbsp;&nbsp; sent in response to Status-Server quer=
ies MUST be generated using the<BR>&nbsp;&nbsp; same method as used for for=
 calculating the Response Authenticator of<BR>| &nbsp;the Accounting-Respon=
se, with the Status-Server Request Authenticator<BR>&nbsp;&nbsp; taking the=
 place of the Accounting-Request Request Authenticator.<BR>---<BR>&nbsp;&nb=
sp; The Response Authenticator field of an Accounting-Response packet<BR>&n=
bsp;&nbsp; sent in response to Status-Server queries MUST be generated usin=
g the<BR>&nbsp;&nbsp; same method as used for for calculating the Response =
Authenticator of<BR>| &nbsp;the Accounting-Response sent in response to and=
 Accounting-Request,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^^^<BR>&nbsp;&nbsp; with the Status-Server Request Authenticator =
taking the place of the<BR>&nbsp;&nbsp; Accounting-Request Request Authenti=
cator.<BR><BR><BR>(6) &nbsp;Section 3.1<BR><BR>(6a) &nbsp;headline<BR><BR>T=
o better indicate the simplification for implementations, which seems<BR>to=
 be the spirit of this detail, I suggest to change the headline<BR>(this wi=
ll be even more become clear by the subsequent modification<BR>I'll propose=
 below):<BR><BR>|3.1. &nbsp;Consistent definition for Status-Server<BR>---<=
BR>|3.1. &nbsp;Single Definition for Status-Server<BR>&nbsp;&nbsp; &nbsp; &=
nbsp; ^^^^^^^^<BR><BR>(6b) &nbsp;2nd paragraph -- clarification / textual i=
mprovement<BR><BR>I suggest to replace "one" by "a single":<BR><BR>&nbsp;&n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;vvv<BR>| &nbsp;Having one definition for St=
atus-Server packets is simpler than<BR>&nbsp;&nbsp; having different defini=
tions for different destination ports. &nbsp;[...]<BR>--- &nbsp; &nbsp; &nb=
sp; vvvvvvvvv<BR>| &nbsp;Having a single definition for Status-Server packe=
ts is simpler than<BR>&nbsp;&nbsp; having different definitions for differe=
nt destination ports. &nbsp;[...]<BR><BR><BR>(7) &nbsp;Section 4 -- consist=
ent spelling of abbreviation<BR><BR>For uniformity and consistency, I sugge=
st to &nbsp; &nbsp;s/coa/CoA/<BR>(2 instances in Section 4).<BR><BR><BR>(8)=
 &nbsp;Section 4.2<BR><BR>(8a) &nbsp;need to update the metadata (front mat=
ter)<BR><BR>The third para says:<BR><BR>&nbsp;&nbsp; We note that [RFC2865]=
 Section 3 defines a number of RADIUS Codes,<BR>&nbsp;&nbsp; but does not m=
ake statements about which Codes are valid for port<BR>| &nbsp;1812. &nbsp;=
In contrast, [RFC2866] Section 3 specifies that only RADIUS<BR>| &nbsp;Acco=
unting packets are to be sent to port 1813. &nbsp;This specification<BR>&nb=
sp;&nbsp; is compatible with [RFC2865], as it uses a known Code for packets=
 to<BR>&nbsp;&nbsp; port 1812. &nbsp;This specification is not compatible w=
ith [RFC2866], as<BR>&nbsp;&nbsp; it adds a new code (Status-Server) that i=
s valid for port 1812.<BR>| &nbsp;However, as the category of [RFC2866] is =
Informational, this conflict<BR>| &nbsp;is acceptable.<BR><BR>This statemen=
t clearly indicates that this specification<BR>*** Updates RFC 2866 ***.<BR=
><BR>This relationship really should be noted in the front matter of the<BR=
>draft.<BR><BR>(8b) &nbsp;7th para -- word omission<BR><BR>Please correct:<=
BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v=
<BR>| &nbsp;The server MAY prioritize the handling Status-Server queries ov=
er the<BR>&nbsp;&nbsp; handling of other requests, subject to the rate limi=
ting described<BR>&nbsp;&nbsp; above.<BR>--- &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;vvvv<BR>| &nbsp;The server MAY prioritize the ha=
ndling of Status-Server queries over<BR>&nbsp;&nbsp; the handling of other =
requests, subject to the rate limiting<BR>&nbsp;&nbsp; described above.<BR>=
<BR><BR>(9) &nbsp;Section 4.3<BR><BR>(9a) &nbsp;1st para -- improvement #1<=
BR><BR>I suggest to improver the wording:<BR><BR>&nbsp;&nbsp; When a Dynami=
c Authorization Client ([RFC5176] Section 1.3) reboots,<BR>| &nbsp;it SHOUL=
D send a Status-Server packet to a CoA port to IP addresses<BR>&nbsp;&nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !! &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;!!<BR>&nbsp;&nbsp; that are configured as both =
Dynamic Authorization Servers and RADIUS<BR>&nbsp;&nbsp; clients. &nbsp;[..=
.]<BR>---<BR>&nbsp;&nbsp; When a Dynamic Authorization Client ([RFC5176] Se=
ction 1.3) reboots,<BR>| &nbsp;it SHOULD send a Status-Server packet to a C=
oA port at IP addresses<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^<=
BR>&nbsp;&nbsp; that are configured as both Dynamic Authorization Servers a=
nd RADIUS<BR>&nbsp;&nbsp; clients. &nbsp;[...]<BR><BR>(9b) &nbsp;1st para -=
- improvement #2 (missing word)<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp;[...] &nbsp;When a response is received, the Dynam=
ic<BR>&nbsp;&nbsp; Authorization Client MUST NOT send further Status-Server=
 packets to<BR>| &nbsp;the CoA port of any Dynamic Authorization until it n=
ext reboots.<BR>--- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; ^<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;[...] &nbsp;When a response is received, the Dynamic<BR>&nbsp;&nbsp; Autho=
rization Client MUST NOT send further Status-Server packets to<BR>| &nbsp;t=
he CoA port of any Dynamic Authorization Server until it next<BR>&nbsp;&nbs=
p; reboots.<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp;^^^^^^^^<BR>(9c) &nbsp;4th para -- inconsistency wi=
th 1st para<BR><BR>The final part of the 4th para apparently contradicts th=
e last<BR>sentence of the first para (quoted in (9b) above):<BR><BR>| &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;The NAS MAY<BR>| &nbsp;otherwise decide to receive multip=
le packets to it's CoA port before<BR>| &nbsp;marking the RADIUS server as =
responsive. &nbsp;This behavior is<BR>| &nbsp;implementation-defined, and S=
HOULD be configurable.<BR><BR>(9d) &nbsp;last para -- punctuation<BR><BR>Th=
e last comma (after "port 3799") IMO distorts the sentence<BR>and should be=
tter be deleted.<BR><BR><BR>(10) &nbsp;Section 4.4, 2nd para -- improvement=
<BR><BR>I suggest to slightly change the wording:<BR><BR>&nbsp;&nbsp; &nbsp=
; &nbsp; &nbsp;[...]. &nbsp;If the server is still unresponsive, however, t=
he result<BR>&nbsp;&nbsp; may be user login failures. &nbsp;The Status-Serv=
er solution is an ideal<BR>| &nbsp;one to solve this problem.<BR>---^^^<BR>=
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;[...]. &nbsp;If the server is still unresp=
onsive, however, the result<BR>&nbsp;&nbsp; may be user login failures. &nb=
sp;The Status-Server solution is an ideal<BR>| &nbsp;way to solve this prob=
lem.<BR>&nbsp;&nbsp; ^^^<BR><BR><BR>(11) &nbsp;Section 4.6<BR><BR>(11a) &nb=
sp;4th para below first figure -- improvement/grammar<BR><BR>I suggest to c=
hange:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [...]. &nbsp;If the =
implementation fails to respond, then the NAS<BR>&nbsp;&nbsp; cannot distin=
guish between the Proxy Server being down, or the next<BR>| &nbsp;server al=
ong along the proxy chain is unreachable.<BR>-- &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp;^^<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [...]=
. &nbsp;If the implementation fails to respond, then the NAS<BR>&nbsp;&nbsp=
; cannot distinguish between the Proxy Server being down, or the next<BR>| =
&nbsp;server along along the proxy chain being unreachable.<BR>&nbsp;&nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^<BR><BR>(11b) &nbsp=
;5th para below first figure -- missing word<BR><BR>I suggest to insert "in=
" as follows:<BR><BR>&nbsp;&nbsp; In the worst case, failures in routing fo=
r Realm A may affect users<BR>| &nbsp;Realm B. &nbsp;[...]<BR>---^<BR>&nbsp=
;&nbsp; In the worst case, failures in routing for Realm A may affect users=
<BR>| &nbsp;in Realm B. &nbsp;[...]<BR>&nbsp;&nbsp; ^^^^<BR><BR>(11c) &nbsp=
;denomination of entities<BR><BR>&gt;From the second figure ...<BR><BR>&nbs=
p;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/-&gt; Proxy Serve=
r P -----&gt; Home Server P<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; / &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp;\ /<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NAS &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;X<BR>&nbs=
p;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \ &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ \<BR>&nbsp;&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\-&gt; Proxy Server S -----&gt; Hom=
e Server S<BR><BR>... it becomes apparent that the denominations of the ent=
ities are<BR>not chosen carefully; in this case, 'P' and 'S' are both overl=
oaded.<BR><BR>To disambiguate the whole stuff, here's my proposal:<BR><BR>U=
se 'P1' and 'P2' (in place of 'P' and 'S') for the two Proxy Servers<BR>in =
both scenarios (figures and text); use 'H1' and 'H2' &nbsp;for the Home<BR>=
Servers in the second scenario.<BR><BR><BR>(12) &nbsp;Section 4.7 -- termin=
ology<BR><BR>The draft uses the colloquial, but incorrect short term "MIB" =
whenever<BR>in wants to indicate a "MIB Module". &nbsp;Please see the BCP 1=
11, RFC 4181<BR>for the detailed rationale of the precise terminology.<BR><=
BR>Therefore, &nbsp;please change &nbsp; &nbsp; MIB[s] &nbsp; --&gt; &nbsp;=
 MIB module[s]<BR>throughout the text.<BR><BR>(13) &nbsp;Section 4.7.1<BR><=
BR>(13a) &nbsp;need to update the metadata (front matter)<BR><BR>The 1st pa=
ra clearly indicates that this draft<BR>*** &nbsp;Updates RFC 4669 and RFC =
4671 &nbsp;***<BR><BR>To make it easier for developers and users to find th=
is update,<BR>please amend the draft front matter accordingly.<BR><BR>(13b)=
 &nbsp;last para<BR><BR>The draft text is confusingly complicated, yet inpr=
ecise.<BR>The draft text could be misunderstood as recommending to<BR>defin=
e alternate MIB modules where it better should recommend<BR>&nbsp;using ext=
ensions for standard MIB tables.<BR><BR>I suggest to modify this paragraph =
as follows:<BR><BR>&nbsp;&nbsp; If a server supports Status-Server and the =
[RFC4669] or [RFC4671]<BR>| &nbsp;MIBs, then it SHOULD also support vendor-=
specific MIBs containing<BR>| &nbsp;similar information as the standard MIB=
s, but which are instead<BR>&nbsp;&nbsp; dedicated solely to tracking Statu=
s-Server requests and responses.<BR>| &nbsp;Any definition of the server MI=
Bs for Status-Server is outside of the<BR>&nbsp;&nbsp; scope of this docume=
nt.<BR>---<BR>| &nbsp;If a server supports Status-Server and the [RFC4669] =
or [RFC4671] MIB<BR>| &nbsp;modules, then it SHOULD also support vendor-spe=
cific MIB extensions<BR>&nbsp;&nbsp; ^^^^^^^ &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^<BR>=
&nbsp;&nbsp; dedicated solely to tracking Status-Server requests and respon=
ses.<BR>| &nbsp;Any definition of the server MIB module extensions for Stat=
us-Server<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^^^^^=
^<BR>&nbsp;&nbsp; is outside of the scope of this document.<BR><BR>(Please =
note the deletion of the full 3rd line!)<BR><BR><BR>(14) &nbsp; Section 4.7=
.2<BR><BR>(14a)<BR>Similar as noted in (13a) above, the first para of 4.7.2=
 clearly<BR>indicates that this specification &nbsp;*** updates RFCs 4668 a=
nd 4670 ***.<BR><BR>(14b)<BR>Similarly as in (13b) above, the last para of =
4.7.2 should be modified<BR>as follows:<BR><BR>&nbsp;&nbsp; If an implement=
ation supports Status-Server and the [RFC4668] or<BR>| &nbsp;[RFC4670] MIBs=
, then it SHOULD also support vendor-specific MIBs<BR>| &nbsp;containing si=
milar information as those MIBs, but which are instead<BR>&nbsp;&nbsp; dedi=
cated solely to tracking Status-Server requests and responses.<BR>| &nbsp;A=
ny definition of the client MIBs for Status-Server is outside of the<BR>&nb=
sp;&nbsp; scope of this document.<BR>---<BR>&nbsp;&nbsp; If an implementati=
on supports Status-Server and the [RFC4668] or<BR>| &nbsp;[RFC4670] MIB mod=
ules, then it SHOULD also support vendor-specific<BR>&nbsp;&nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; ^^^^^^^^^^^<BR>| &nbsp;MIB extensions dedicated s=
olely to tracking Status-Server requests<BR>&nbsp;&nbsp; ^^^^^^^^^^^^^^^<BR=
>| &nbsp;and responses. &nbsp;Any definition of the client MIB module exten=
sions<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^^^^^^^^^^^^^^<BR>&nbsp;&nbsp; for S=
tatus-Server is outside of the scope of this document.<BR><BR><BR>(15) &nbs=
p;Section 5.1<BR><BR>(15a) &nbsp;2nd para, last sentence -- typo/grammar<BR=
><BR>Please &nbsp; s/server/servers/ &nbsp;in ...<BR><BR>&nbsp;&nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [...]. &nbsp;Thes=
e queries are most useful in<BR>| &nbsp;deployments where an administrator =
has internal RADIUS servers that<BR>&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;^<BR>&nbsp;&nbsp; proxy to other in=
ternal RADIUS servers, such as for load balancing or<BR>&nbsp;&nbsp; fail o=
ver.<BR><BR>(15b) &nbsp;3rd para -- improvement<BR><BR>To improve the reada=
bility, I suggest varying the multiple uses of<BR>"use", e.g.:<BR>&nbsp;&nb=
sp; &nbsp; &nbsp;vvvv &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vvvv &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vvvvv<BR>&nbsp;&nbsp; If us=
ed, the names used for these test users SHOULD be difficult to<BR>&nbsp;&nb=
sp; guess by an attacker. &nbsp;[...]<BR>--- &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; vvvvvvvv<BR>&nbsp;&nbsp; If used, the name=
s utilized for these test users SHOULD be difficult<BR>&nbsp;&nbsp; to gues=
s by an attacker. &nbsp;[...]<BR><BR><BR>(16) &nbsp;Section 5.2 &nbsp;-- ou=
tdated text<BR><BR>The first paragraph seems to be outdated now by the RADI=
US-over-TCP<BR>draft!<BR><BR><BR>(17) &nbsp;Section 5.3, 1st para<BR><BR>Th=
e draft says:<BR>&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;It may be<BR>&n=
bsp;&nbsp; tempting to increase the utility of Status-Server by having the<=
BR>| &nbsp;responses carry additional information, implementors are warned =
that<BR>&nbsp;&nbsp; such uses have not been analyzed for potential securit=
y issues or<BR>&nbsp;&nbsp; network problems.<BR><BR>To better reflect the =
relationship between the two (half-)sentences<BR>connected with a comma, I =
propose to either use a semicolon instead<BR>of the comma, or insert &nbsp;=
" but" after the comma:<BR><BR>&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;I=
t may be<BR>&nbsp;&nbsp; tempting to increase the utility of Status-Server =
by having the<BR>| &nbsp;responses carry additional information, but implem=
entors are warned<BR>&nbsp;&nbsp; that such uses have not been analyzed for=
 potential security issues<BR>&nbsp;&nbsp; or network problems.<BR><BR><BR>=
Best regards,<BR>&nbsp;&nbsp;Alfred H=EF=BF=BDnes.<BR><BR>--<BR><BR>+------=
------------------+--------------------------------------------+<BR>| TR-Sy=
s Alfred Hoenes &nbsp; | &nbsp;Alfred Hoenes &nbsp; Dipl.-Math., Dipl.-Phys=
. &nbsp;|<BR>| Gerlinger Strasse 12 &nbsp; | &nbsp;Phone: [phone],=
 Fax: -18 &nbsp; &nbsp; &nbsp; &nbsp; |<BR>| D-71254 &nbsp;Ditzingen &nbsp;=
 &nbsp; | &nbsp;E-Mail: &nbsp;[e-mail] &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<BR>+------------------------+------=
--------------------------------------+<BR></P></div></body></html>
------=_Part_166748_896156211.1229366932742--

--
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, 15 Dec 2008 18:47:37 +0000
Date: Mon, 15 Dec 2008 18:47:19 +0000 (UTC)
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Subject: Fwd: draft-zorn-radius-err-msg-10 (fwd)
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_166733_366877312.1229366839550"

------=_Part_166733_366877312.1229366839550
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



Forwarding for a non-list member:=20


>From [e-mail] Thu Dec 11 19:01:22 MEZ 2008=20
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16=
.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id AA023378481; Thu, 11 Dec 2008 19:01:21 +0100=
=20
Return-Path: <[e-mail]>=20
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id TAA22555; Thu, 11 Dec 2008 19:01:20 +0100 (MEZ=
)=20
From: Alfred H=EF=BF=BDnes <[e-mail]>=20
To: [e-mail]=20
Message-Id: <[e-mail]>=20
Date: Thu, 11 Dec 2008 19:01:20 +0100 (MEZ)=20
Subject: draft-zorn-radius-err-msg-10=20

Hello again,=20
I also have reviewed your Internet-Draft draft-zorn-radius-err-msg-10=20
and would like to submit a few comments.=20

I have a couple of concerns regarding the structure of the document.=20

First of all, it looks like Section 3 was intended as a summary=20
of related pre-existing specifications for RADIUS.=20
Thus, it comes to surprise that this section contains two inserts=20
giving details for the new protocol elements that will be introduced=20
later in the memo, in Sections 4 ff.=20
To avoid confusion, I suggest to move these parts to the proper=20
places later in the document; this will save text and improve=20
the clarity of the document.=20
Very few generally applicable text should be moved in the opposite=20
direction, as well.=20
I'll give the details in the document walk-through below.=20

Subsequently, Sections 4..6 are structured for extensibility,=20
which obviously is not needed in this document.=20
The headlines always let the reader expect to come more, where=20
there's always only a single new protocol object ro define.=20
I strongly suggest to update the headlines and amalgamate these=20
sections with their single subsection each.=20


(1) =C2=A0Section 3=20

The draft text starts with:=20

=C2=A03. =C2=A0RADIUS Packet Format=20

=C2=A0=C2=A0 Exactly one RADIUS packet is encapsulated in the UDP Data fiel=
d=20
=C2=A0=C2=A0 [RFC0768] where the UDP Destination Port field indicates 1812=
=20
=C2=A0=C2=A0 (decimal).=20

=C2=A0=C2=A0 When a reply is generated, the source and destination ports ar=
e=20
=C2=A0=C2=A0 reversed.=20

The topic of these two paragraphs, transport of radius messages,=20
is not directly related to the "Packet Format" announced by the=20
section headline.=20
I suggest to move these two paragraphs to the end of the section,=20
at best in a new subsection,=20

=C2=A03.1. =C2=A0RADIUS Transport=20

There, it should at least be mentioned that TCP (and TLS-secured)=20
transport of RADIUS packets is currently pursued in the RADEXT WG=20
as well (for instance, see draft-ietf-radext-tcp-transport).=20

I propose to move the short text currently in Section 4 next here=20
in Section 3, in front of the diagram, and add a more fundamental=20
explanation. In the 'Administrative Note' at the end of the section,=20
the term "RADIUS proxy" is used as well, without priop explanation.=20
Therefore, I recommend to also introduce this concept here.=20

For instance:=20

| =C2=A0RADIUS is a request-reply protocol, where each request packet sent=
=20
| =C2=A0from a "RADIUS Client" to a "RADIUS Server" is responded to with a=
=20
| =C2=A0reply packet. =C2=A0A "RADIUS proxy" relays, as an intermediate age=
nt,=20
| =C2=A0requests and reponses between an original RADIUS client and the fin=
al=20
| =C2=A0RADIUS server, behaving as a server for the forme and as a client f=
or=20
| =C2=A0the latter. =C2=A0The RADIUS Packet type is determined by the Code =
field=20
| =C2=A0in the first octet of the Packet.=20
|=20
| =C2=A0A summary of the RADIUS packet format is shown below. =C2=A0The fie=
lds are=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 ^^^^^^=20
=C2=A0=C2=A0 transmitted from left to right.=20

Having that statement in front of the diagram, the sentence immediately=20
below the diagram,=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Code field is one octet, and identifi=
es the type of RADIUS=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 packet.=20

... could be simplified to only say:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The Code field is one octet, and identifies th=
e packet type.=20

... or even:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The Code field is one octet.=20


The second part of the explanation for 'Code' is not of general nature.=20
IMHO, it should be removed from this section, and elaborated upon in=20
Section 4:=20

DELETE:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The RADIUS Codes (decimal) defined in this doc=
ument are as=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0follows:=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <MSG1> Error-Notification=20

Again, in the explanation of 'Authenticator', the second part with=20
the headline 'Notification Authenticator' comes to surprise here.=20
I suggest to move it entirely into Section 4:=20

DELETE:=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0Notification Authenticator=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The value of the Authenticator field i=
n the Error-=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification packet is called the Noti=
fication=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticator, and contains a one-way =
MD5 hash calculated=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 over a stream of octets consisting of:=
 the RADIUS packet,=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 beginning with the Code field, includi=
ng the Identifier, the=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Length, the Authenticator field from t=
he packet to which=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this packet is a response, and the res=
ponse Attributes,=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 followed by the shared secret. =C2=A0T=
hat is,=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification Auth =3D=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MD5=
(Code+ID+Length+RequestAuth+Attributes+Secret)=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where '+' denotes concatenation.=20

In the 3rd paragraph of the 'Administrative Note', I suggest to add a=20
few clarifying words in order to disambiguate the scenario described:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 When using a forwarding proxy, the proxy =
must be able to alter=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 the packet as it passes through in each d=
irection - when the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy forwards the request, the proxy MAY=
 add a Proxy-State=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Attribute, and when the proxy forwards a =
response, it MUST=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0remove its Proxy-State Attribute if it added o=
ne. =C2=A0[...]=20
---=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 When using a forwarding proxy, the proxy =
must be able to alter=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 the packet as it passes through in each d=
irection - when the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy forwards the request, the proxy MAY=
 add a Proxy-State=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Attribute, and when the proxy forwards a =
response, it MUST=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0remove its Proxy-State Attribute if it added o=
ne to the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 vvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0request. =C2=A0[...]=20


(2) =C2=A0Section 4=20

As noted above, I propose to simplify and clarify the structure=20
of this section:=20

|4. =C2=A0Packet Types=20
|=20
| =C2=A0The RADIUS Packet type is determined by the Code field in the first=
=20
| =C2=A0octet of the Packet.=20
|=20
|4.1. =C2=A0Error-Notification=20

The prose already has been moved inTo section 3, so the replacement=20
is simply:=20

|4. =C2=A0New Packet Type: Error-Notification=20

The explanation for 'Notification Authenticator' currently says:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0Notification Authenticator=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The Notification Authenticator value is calcul=
ated from the=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0Error-Notification packet, as described above.=
=20

This sentence IMO does not match reasonably what was currently=20
described in Section 3.=20
As mentioned above, I strongly recommend to move that text (DELETED=20
above) to this location; doing so allows to drop the above two-liner=20
entirely:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0Notification Authenticator=20

| =C2=A0 =C2=A0 =C2=A0 =C2=A0The value of the Authenticator field in the Er=
ror-Notification=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0packet is called the Notification Authenticato=
r, and contains a=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0one-way MD5 hash calculated over a stream of o=
ctets consisting=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0of: the RADIUS packet, beginning with the Code=
 field, including=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0the Identifier, the Length, the Authenticator =
field from the=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0packet to which this packet is a response, and=
 the response=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0Attributes, followed by the shared secret. =C2=
=A0That is,=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification Auth =3D=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MD5(Code+I=
D+Length+RequestAuth+Attributes+Secret)=20
|=20
| =C2=A0 =C2=A0 =C2=A0 =C2=A0where '+' denotes concatenation.=20

As I understand that (unchanged) text, with the single exception of the=20
original Authenticator field from the errored packet, all these fields=20
are the fields of the Error-Notification packet; that was not clear=20
from the two-liner above!=20

Another concern: =C2=A0This new 'signature' again is stuck with the old-=20
fashioned Keyed-MD5 construction; obviously, doing so violates the=20
directive from the IESG and the IAB to equip all IETF protocols with=20
capabilities for crypto-algorithm agility.=20


(3) =C2=A0Section 5=20

Again, as indicated above, I strongly recommend to simplify the=20
section structure:=20

|5. =C2=A0Attributes=20
|=20
|5.1. =C2=A0Error-Code=20
---=20
|5. =C2=A0New Attribute: Error-Code=20


(4) =C2=A0Section 6=20

Currently the text in Section 4 says:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 vv =C2=A0 =C2=A0 =C2=A0vv=20
| =C2=A0The following sub-sections defines a new value for the Acct-Status-=
=20
=C2=A0=C2=A0 Type Attribute [RFC2866].=20

That's bogus grammar anyway. =C2=A0However, following the spirit of the=20
above proposals for simplification, I suggest to change that entirely:=20

|6. =C2=A0Attribute Values=20
|=20
| =C2=A0The following sub-sections defines a new value for the Acct-Status-=
=20
| =C2=A0Type Attribute [RFC2866].=20
|=20
|6.1. =C2=A0Acct-Error-Notification=20
---=20
|6. =C2=A0New Attribute Value: Acct-Error-Notification=20

=C2=A0=C2=A0 This section defines a new value for the Acct-Status-Type Attr=
ibute=20
=C2=A0=C2=A0 [RFC2866], 'Acct-Error-Notification' (<VAL>).=20


(5) =C2=A0Section 7=20

Since this document does not define any new (sub-)namespaces to be=20
managed by IANA, the present text seems to be misleading.=20
Instead, the three specific assignments should be detailed there;=20
for instance, following this pattern (cf BCP 26, RFC 5226):=20

| =C2=A0The criteria to be used by the Internet Assigned Numbers Authority=
=20
| =C2=A0(IANA) for assignment of numbers within namespaces defined within=
=20
| =C2=A0this document are identical to those given in [RFC3575].=20
---=20
| =C2=A0IANA is requested to assign three code points within the RADIUS=20
| =C2=A0Parameters registry defined in [RFC3575], currently located at=20
| =C2=A0<http://www.iana.org/assignments/...> :=20
|=20
| =C2=A0o =C2=A0One RADIUS Packet Type=20
|=20
| =C2=A0 =C2=A0 Type =C2=A0 =C2=A0 Name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reference=20
| =C2=A0 =C2=A0 ------------------------------------------=20
| =C2=A0 =C2=A0 <MSG1> =C2=A0 Error-Notification =C2=A0 =C2=A0 =C2=A0[RFCth=
is]=20
|=20
| =C2=A0o =C2=A0...=20
|=20
|=20
| =C2=A0o =C2=A0...=20


(6) =C2=A0Section 8=20

|8. =C2=A0Security Considerations=20
|=20
| =C2=A0None.=20

I bet the IESG will not be a friend of such brevity ...=20


Kind regards,=20
=C2=A0=C2=A0Alfred H=EF=BF=BDnes.=20

--=20

+------------------------+--------------------------------------------+=20
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|=20
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: [phone], Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=20
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=[e-mail] =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=20
+------------------------+--------------------------------------------+=20

------=_Part_166733_366877312.1229366839550
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'><P>Forwar=
ding for a non-list member:</P>
<P><BR>From [e-mail] Thu Dec 11 19:01:22 MEZ 2008<BR>Received: fr=
om ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)<BR>&nbsp=
;&nbsp; &nbsp; &nbsp;id AA023378481; Thu, 11 Dec 2008 19:01:21 +0100<BR>Ret=
urn-Path: &lt;[e-mail]&gt;<BR>Received: (from ah@localhost) by z.=
TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)<BR>&nbsp;&nbsp; &nbsp; &nbsp;id TAA225=
55; Thu, 11 Dec 2008 19:01:20 +0100 (MEZ)<BR>From: Alfred H=EF=BF=BDnes &lt=
;[e-mail]&gt;<BR>To: [e-mail]<BR>Message-Id: &lt;200812111801.TA=
[e-mail]&gt;<BR>Date: Thu, 11 Dec 2008 19:01:20 +0100 (MEZ)<BR>Subj=
ect: draft-zorn-radius-err-msg-10<BR><BR>Hello again,<BR>I also have review=
ed your Internet-Draft draft-zorn-radius-err-msg-10<BR>and would like to su=
bmit a few comments.<BR><BR>I have a couple of concerns regarding the struc=
ture of the document.<BR><BR>First of all, it looks like Section 3 was inte=
nded as a summary<BR>of related pre-existing specifications for RADIUS.<BR>=
Thus, it comes to surprise that this section contains two inserts<BR>giving=
 details for the new protocol elements that will be introduced<BR>later in =
the memo, in Sections 4 ff.<BR>To avoid confusion, I suggest to move these =
parts to the proper<BR>places later in the document; this will save text an=
d improve<BR>the clarity of the document.<BR>Very few generally applicable =
text should be moved in the opposite<BR>direction, as well.<BR>I'll give th=
e details in the document walk-through below.<BR><BR>Subsequently, Sections=
 4..6 are structured for extensibility,<BR>which obviously is not needed in=
 this document.<BR>The headlines always let the reader expect to come more,=
 where<BR>there's always only a single new protocol object ro define.<BR>I =
strongly suggest to update the headlines and amalgamate these<BR>sections w=
ith their single subsection each.<BR><BR><BR>(1) &nbsp;Section 3<BR><BR>The=
 draft text starts with:<BR><BR>&nbsp;3. &nbsp;RADIUS Packet Format<BR><BR>=
&nbsp;&nbsp; Exactly one RADIUS packet is encapsulated in the UDP Data fiel=
d<BR>&nbsp;&nbsp; [RFC0768] where the UDP Destination Port field indicates =
1812<BR>&nbsp;&nbsp; (decimal).<BR><BR>&nbsp;&nbsp; When a reply is generat=
ed, the source and destination ports are<BR>&nbsp;&nbsp; reversed.<BR><BR>T=
he topic of these two paragraphs, transport of radius messages,<BR>is not d=
irectly related to the "Packet Format" announced by the<BR>section headline=
.<BR>I suggest to move these two paragraphs to the end of the section,<BR>a=
t best in a new subsection,<BR><BR>&nbsp;3.1. &nbsp;RADIUS Transport<BR><BR=
>There, it should at least be mentioned that TCP (and TLS-secured)<BR>trans=
port of RADIUS packets is currently pursued in the RADEXT WG<BR>as well (fo=
r instance, see draft-ietf-radext-tcp-transport).<BR><BR>I propose to move =
the short text currently in Section 4 next here<BR>in Section 3, in front o=
f the diagram, and add a more fundamental<BR>explanation. In the 'Administr=
ative Note' at the end of the section,<BR>the term "RADIUS proxy" is used a=
s well, without priop explanation.<BR>Therefore, I recommend to also introd=
uce this concept here.<BR><BR>For instance:<BR><BR>| &nbsp;RADIUS is a requ=
est-reply protocol, where each request packet sent<BR>| &nbsp;from a "RADIU=
S Client" to a "RADIUS Server" is responded to with a<BR>| &nbsp;reply pack=
et. &nbsp;A "RADIUS proxy" relays, as an intermediate agent,<BR>| &nbsp;req=
uests and reponses between an original RADIUS client and the final<BR>| &nb=
sp;RADIUS server, behaving as a server for the forme and as a client for<BR=
>| &nbsp;the latter. &nbsp;The RADIUS Packet type is determined by the Code=
 field<BR>| &nbsp;in the first octet of the Packet.<BR>|<BR>| &nbsp;A summa=
ry of the RADIUS packet format is shown below. &nbsp;The fields are<BR>&nbs=
p;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; ^^^^^^<BR>&nbsp;&nbsp; transmitted from left to right.<BR=
><BR>Having that statement in front of the diagram, the sentence immediatel=
y<BR>below the diagram,<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; The Code f=
ield is one octet, and identifies the type of RADIUS<BR>&nbsp;&nbsp; &nbsp;=
 &nbsp; &nbsp; packet.<BR><BR>... could be simplified to only say:<BR><BR>|=
 &nbsp; &nbsp; &nbsp; &nbsp;The Code field is one octet, and identifies the=
 packet type.<BR><BR>... or even:<BR><BR>| &nbsp; &nbsp; &nbsp; &nbsp;The C=
ode field is one octet.<BR><BR><BR>The second part of the explanation for '=
Code' is not of general nature.<BR>IMHO, it should be removed from this sec=
tion, and elaborated upon in<BR>Section 4:<BR><BR>DELETE:<BR><BR>| &nbsp; &=
nbsp; &nbsp; &nbsp;The RADIUS Codes (decimal) defined in this document are =
as<BR>| &nbsp; &nbsp; &nbsp; &nbsp;follows:<BR>|<BR>| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &lt;MSG1&gt; Error-Notification<BR><BR>Again, in the explanat=
ion of 'Authenticator', the second part with<BR>the headline 'Notification =
Authenticator' comes to surprise here.<BR>I suggest to move it entirely int=
o Section 4:<BR><BR>DELETE:<BR><BR>| &nbsp; &nbsp; &nbsp; &nbsp;Notificatio=
n Authenticator<BR>|<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The value of t=
he Authenticator field in the Error-<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; Notification packet is called the Notification<BR>| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; Authenticator, and contains a one-way MD5 hash calculated<BR>=
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; over a stream of octets consisting of:=
 the RADIUS packet,<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; beginning with =
the Code field, including the Identifier, the<BR>| &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; Length, the Authenticator field from the packet to which<BR>| &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; this packet is a response, and the respons=
e Attributes,<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; followed by the share=
d secret. &nbsp;That is,<BR>|<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Notif=
ication Auth =3D<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; MD5(Code+ID+Length+RequestAuth+Attributes+Secret)<BR>| &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; where '+' denotes concatenation.<BR><BR>In =
the 3rd paragraph of the 'Administrative Note', I suggest to add a<BR>few c=
larifying words in order to disambiguate the scenario described:<BR><BR>&nb=
sp;&nbsp; &nbsp; &nbsp; &nbsp; When using a forwarding proxy, the proxy mus=
t be able to alter<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; the packet as it pa=
sses through in each direction - when the<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nb=
sp; proxy forwards the request, the proxy MAY add a Proxy-State<BR>&nbsp;&n=
bsp; &nbsp; &nbsp; &nbsp; Attribute, and when the proxy forwards a response=
, it MUST<BR>| &nbsp; &nbsp; &nbsp; &nbsp;remove its Proxy-State Attribute =
if it added one. &nbsp;[...]<BR>---<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; Wh=
en using a forwarding proxy, the proxy must be able to alter<BR>&nbsp;&nbsp=
; &nbsp; &nbsp; &nbsp; the packet as it passes through in each direction - =
when the<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; proxy forwards the request, t=
he proxy MAY add a Proxy-State<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; Attribu=
te, and when the proxy forwards a response, it MUST<BR>| &nbsp; &nbsp; &nbs=
p; &nbsp;remove its Proxy-State Attribute if it added one to the<BR>&nbsp;&=
nbsp; &nbsp; &nbsp; &nbsp; vvvvvvv &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; ^^^^^^^<BR>| &nbsp; &nbsp; &nbsp; &nbsp;request. &=
nbsp;[...]<BR><BR><BR>(2) &nbsp;Section 4<BR><BR>As noted above, I propose =
to simplify and clarify the structure<BR>of this section:<BR><BR>|4. &nbsp;=
Packet Types<BR>|<BR>| &nbsp;The RADIUS Packet type is determined by the Co=
de field in the first<BR>| &nbsp;octet of the Packet.<BR>|<BR>|4.1. &nbsp;E=
rror-Notification<BR><BR>The prose already has been moved inTo section 3, s=
o the replacement<BR>is simply:<BR><BR>|4. &nbsp;New Packet Type: Error-Not=
ification<BR><BR>The explanation for 'Notification Authenticator' currently=
 says:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;Notification Authenticator<BR><BR>|=
 &nbsp; &nbsp; &nbsp; &nbsp;The Notification Authenticator value is calcula=
ted from the<BR>| &nbsp; &nbsp; &nbsp; &nbsp;Error-Notification packet, as =
described above.<BR><BR>This sentence IMO does not match reasonably what wa=
s currently<BR>described in Section 3.<BR>As mentioned above, I strongly re=
commend to move that text (DELETED<BR>above) to this location; doing so all=
ows to drop the above two-liner<BR>entirely:<BR><BR>&nbsp;&nbsp; &nbsp; &nb=
sp;Notification Authenticator<BR><BR>| &nbsp; &nbsp; &nbsp; &nbsp;The value=
 of the Authenticator field in the Error-Notification<BR>| &nbsp; &nbsp; &n=
bsp; &nbsp;packet is called the Notification Authenticator, and contains a<=
BR>| &nbsp; &nbsp; &nbsp; &nbsp;one-way MD5 hash calculated over a stream o=
f octets consisting<BR>| &nbsp; &nbsp; &nbsp; &nbsp;of: the RADIUS packet, =
beginning with the Code field, including<BR>| &nbsp; &nbsp; &nbsp; &nbsp;th=
e Identifier, the Length, the Authenticator field from the<BR>| &nbsp; &nbs=
p; &nbsp; &nbsp;packet to which this packet is a response, and the response=
<BR>| &nbsp; &nbsp; &nbsp; &nbsp;Attributes, followed by the shared secret.=
 &nbsp;That is,<BR>|<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Notification A=
uth =3D<BR>| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 MD5(Code+ID+Length+RequestAuth+Attributes+Secret)<BR>|<BR>| &nbsp; &nbsp; =
&nbsp; &nbsp;where '+' denotes concatenation.<BR><BR>As I understand that (=
unchanged) text, with the single exception of the<BR>original Authenticator=
 field from the errored packet, all these fields<BR>are the fields of the E=
rror-Notification packet; that was not clear<BR>from the two-liner above!<B=
R><BR>Another concern: &nbsp;This new 'signature' again is stuck with the o=
ld-<BR>fashioned Keyed-MD5 construction; obviously, doing so violates the<B=
R>directive from the IESG and the IAB to equip all IETF protocols with<BR>c=
apabilities for crypto-algorithm agility.<BR><BR><BR>(3) &nbsp;Section 5<BR=
><BR>Again, as indicated above, I strongly recommend to simplify the<BR>sec=
tion structure:<BR><BR>|5. &nbsp;Attributes<BR>|<BR>|5.1. &nbsp;Error-Code<=
BR>---<BR>|5. &nbsp;New Attribute: Error-Code<BR><BR><BR>(4) &nbsp;Section =
6<BR><BR>Currently the text in Section 4 says:<BR><BR>&nbsp;&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 vv &nbsp; &nbsp; &nbsp;vv<BR>| &nbsp;The following sub-sections defines a =
new value for the Acct-Status-<BR>&nbsp;&nbsp; Type Attribute [RFC2866].<BR=
><BR>That's bogus grammar anyway. &nbsp;However, following the spirit of th=
e<BR>above proposals for simplification, I suggest to change that entirely:=
<BR><BR>|6. &nbsp;Attribute Values<BR>|<BR>| &nbsp;The following sub-sectio=
ns defines a new value for the Acct-Status-<BR>| &nbsp;Type Attribute [RFC2=
866].<BR>|<BR>|6.1. &nbsp;Acct-Error-Notification<BR>---<BR>|6. &nbsp;New A=
ttribute Value: Acct-Error-Notification<BR><BR>&nbsp;&nbsp; This section de=
fines a new value for the Acct-Status-Type Attribute<BR>&nbsp;&nbsp; [RFC28=
66], 'Acct-Error-Notification' (&lt;VAL&gt;).<BR><BR><BR>(5) &nbsp;Section =
7<BR><BR>Since this document does not define any new (sub-)namespaces to be=
<BR>managed by IANA, the present text seems to be misleading.<BR>Instead, t=
he three specific assignments should be detailed there;<BR>for instance, fo=
llowing this pattern (cf BCP 26, RFC 5226):<BR><BR>| &nbsp;The criteria to =
be used by the Internet Assigned Numbers Authority<BR>| &nbsp;(IANA) for as=
signment of numbers within namespaces defined within<BR>| &nbsp;this docume=
nt are identical to those given in [RFC3575].<BR>---<BR>| &nbsp;IANA is req=
uested to assign three code points within the RADIUS<BR>| &nbsp;Parameters =
registry defined in [RFC3575], currently located at<BR>| &nbsp;&lt;http://w=
ww.iana.org/assignments/...&gt; :<BR>|<BR>| &nbsp;o &nbsp;One RADIUS Packet=
 Type<BR>|<BR>| &nbsp; &nbsp; Type &nbsp; &nbsp; Name &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Reference<BR>| &nbsp; &nbsp=
; ------------------------------------------<BR>| &nbsp; &nbsp; &lt;MSG1&gt=
; &nbsp; Error-Notification &nbsp; &nbsp; &nbsp;[RFCthis]<BR>|<BR>| &nbsp;o=
 &nbsp;...<BR>|<BR>|<BR>| &nbsp;o &nbsp;...<BR><BR><BR>(6) &nbsp;Section 8<=
BR><BR>|8. &nbsp;Security Considerations<BR>|<BR>| &nbsp;None.<BR><BR>I bet=
 the IESG will not be a friend of such brevity ...<BR><BR><BR>Kind regards,=
<BR>&nbsp;&nbsp;Alfred H=EF=BF=BDnes.<BR><BR>--<BR><BR>+-------------------=
-----+--------------------------------------------+<BR>| TR-Sys Alfred Hoen=
es &nbsp; | &nbsp;Alfred Hoenes &nbsp; Dipl.-Math., Dipl.-Phys. &nbsp;|<BR>=
| Gerlinger Strasse 12 &nbsp; | &nbsp;Phone: [phone], Fax: -18 &nb=
sp; &nbsp; &nbsp; &nbsp; |<BR>| D-71254 &nbsp;Ditzingen &nbsp; &nbsp; | &nb=
sp;E-Mail: &nbsp;[e-mail] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; |<BR>+------------------------+-------------------=
-------------------------+<BR></P></div></body></html>
------=_Part_166733_366877312.1229366839550--

--
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, 15 Dec 2008 18:46:36 +0000
Date: Mon, 15 Dec 2008 18:46:03 +0000 (UTC)
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Subject: Fwd: review of draft-zorn-radius-pkmv1-02 (fwd)
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_166722_200715823.1229366763285"

------=_Part_166722_200715823.1229366763285
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



Forwarding for a non-list memeber:=20


>From [e-mail] Thu Dec 11 19:56:57 MEZ 2008=20
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16=
.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id AA023651816; Thu, 11 Dec 2008 19:56:56 +0100=
=20
Return-Path: <[e-mail]>=20
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)=20
=C2=A0=C2=A0 =C2=A0 =C2=A0id TAA22615; Thu, 11 Dec 2008 19:56:55 +0100 (MEZ=
)=20
From: Alfred H=EF=BF=BDnes <[e-mail]>=20
To: [e-mail]=20
Cc: [e-mail]=20
Message-Id: <[e-mail]>=20
Date: Thu, 11 Dec 2008 19:56:55 +0100 (MEZ)=20
Subject: review of draft-zorn-radius-pkmv1-02=20

Hello,=20
on my cycle over RADIUS-related Internet-Drafts, I also have=20
followed up to your I-D, draft-zorn-radius-pkmv1-02,=20
and would like to submit a few comments.=20

First of all, I fear that this draft violates the emerging=20
guidelines for RADIUS extensions (draft-ietf-radext-design-05,=20
IETF LC passed) in so many details that it will most probably=20
not be socially acceptable.=20
Perhaps it would be prudent to redesign the intended attributes=20
as "Extended RADIUS Attributes", following the principles laid=20
down in draft-ietf-radext-extended-attributes-05 (you should be=20
aware of, as a co-author :-) )=20

Furthermore, I am astonished by seeing the draft making use of=20
very outdated references (which perhaps should be Normative!):=20

o =C2=A0 [PKCS.1.1998] =C2=A0had been documented for the IETF in RFC 2437,=
=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which =
has been obsoleted by RFC 3447 long ago;=20

o =C2=A0 [RFC2459] =C2=A0 =C2=A0 =C2=A0had first been obsoleted by RFC 3280=
,=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which =
now has been obsoleted by RFC 5280.=20

More details:=20


(1) =C2=A0Section 2.2=20

The draft uses, but does not introduce, more Acronyms than presently=20
listed there, e.g.,=20

=C2=A0=C2=A0 SS=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Subscriber Station.=20

=C2=A0=C2=A0 BS=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Base Station.=20

=C2=A0=C2=A0 CA=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Certificate Authority; trusted party issuing and =
signing X.509=20
=C2=A0=C2=A0 =C2=A0 =C2=A0certificates.=20


(2) =C2=A0Section 3.1=20

The draft says:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-SS-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] identifying the Subscriber Stat=
ion; it=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0MAY be transmitted in the Access-Request message.=
=20

That's misleading.=20
How about saying more precisely:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-SS-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] binding a public key to the ide=
ntifier=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^=20
| =C2=A0 =C2=A0 of the Subscriber Station; it MAY be transmitted in the Acc=
ess-=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Request message.=20

'Value' :=20

Since you explicitely refer to RSA, how do you imagine to squeeze=20
an RSA public key certificate into the Value field (I guess you mean,=20
in RADIUS String format, do you?), which is limited to 253 octets ???=20

Did you mean -- contrary to the explanation quoted above -- a plain=20
certificate hash?=20


(3) =C2=A0Section 3.2=20

The draft says:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-CA-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] identifying the CA certificate =
for the=20
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^=20
=C2=A0=C2=A0 =C2=A0 =C2=A0SS; it MAY be transmitted in the Access-Request m=
essage.=20

I'm getting confused even more. =C2=A0Did you mean:=20

=C2=A0=C2=A0 Description=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The PKM-CA-Cert Attribute is variable length and =
contains the=20
| =C2=A0 =C2=A0 X.509 certificate [RFC2459] used by the CA to sign the SS=
=20
| =C2=A0 =C2=A0 certificate carried in the PKM-SS-Cert attribute of the sam=
e=20
| =C2=A0 =C2=A0 message; it MAY be transmitted in the Access-Request messag=
e.=20

'Value' :=20

Same issue as in (2) above!=20


(4) =C2=A0Section 3.3=20

'Description' :=20

I fear the text confuses the terms "timer" and "timeout".=20
A 'timer' is a running counter; it only makes sense to transport=20
its limit/starting value, a 'timeout value' in a packet over the=20
network.=20

The intended restriction,=20

=C2=A0=C2=A0 =C2=A0 An instance ... MAY be included ...=20

should perhaps better, and more precisely say,=20

=C2=A0=C2=A0 =C2=A0 One instance ... MAY be included ...=20
=C2=A0=C2=A0 =C2=A0 ^^^=20

'Value' :=20

The definition given is in direct violation of the principles laid down=20
in the RADIUS Extension Guidelines. =C2=A0Following the spirit of that memo=
,=20
doing so requires much more detailed, and much more convincing=20
rationale!=20


(5) =C2=A0Sections 3.4 and 3.5=20

Using 24- or 16-bit integers seems to be inacceptable, according to=20
the Guidelines. =C2=A0Putting multiple such values into one option also is=
=20
not conformant; the Guidelines recommend using multiple instances=20
of an elementary option instead.=20


(6) =C2=A0Section 3.6=20

The draft says:=20

=C2=A0=C2=A0 Description=20

| =C2=A0 =C2=A0 The PKM-SA-Descriptor Attribute is 8 octets in length. =C2=
=A0It=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvvvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^=20
| =C2=A0 =C2=A0 consists of 3 fields, described below, which together speci=
fy the=20
| =C2=A0 =C2=A0 characteristics of a PKM security association. =C2=A0One or=
 more=20
=C2=A0=C2=A0 =C2=A0 =C2=A0vvvvvvvvv =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^=20
| =C2=A0 =C2=A0 instances of the PKM-SA-Descriptor Attribute MAY occur in a=
n=20
=C2=A0=C2=A0 =C2=A0 =C2=A0Access-Accept message.=20

Semantically, the "It consists" is ambiguous and misleading;=20
obviously the text only talks about the sub-fields of the value=20
field; thus, it should be explicit about that and say:=20

=C2=A0=C2=A0"Its value consists ..." =C2=A0 =C2=A0or =C2=A0 =C2=A0"It conta=
ins ..." =C2=A0.=20
=C2=A0=C2=A0 ^^^^^^^^^^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^=20

I do not understand the semantics of "One or more instances".=20
Other parts of the text indicate that this attributes carries=20
the selection from the choice of cryptosuite identifiers offered=20
in the PKM-Cryptosuite-List attribute, plus more SA data.=20
Also, the table in Section 4 contains '0-1' in the 'Accept' column=20
and '0' in all other columns for this attribute.=20
Hence, the expected multiplicity needs to be clarified.=20

Subsequently, the draft says:=20

=C2=A0=C2=A0 SAID=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The SAID field is two octets in length and contai=
ns a PKM SAID=20
| =C2=A0 =C2=A0 Section 3.5.=20

Apparently something is missing here. =C2=A0I guess:=20

=C2=A0=C2=A0 =C2=A0 =C2=A0The SAID field is two octets in length and contai=
ns a PKM SAID=20
| =C2=A0 =C2=A0 (see Section 3.5).=20

The structured 'Value' field again violated the Guidelines.=20
It needs explicit, convincing justification.=20


(7) =C2=A0Section 3.7=20

Similar issues as in (6) apply here.=20
For brevity, I omit the details.=20


Kind regards,=20
=C2=A0=C2=A0Alfred H=EF=BF=BDnes.=20

--=20

+------------------------+--------------------------------------------+=20
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|=20
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: [phone], Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=20
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=[e-mail] =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=20
+------------------------+--------------------------------------------+=20

------=_Part_166722_200715823.1229366763285
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'><P>Forwar=
ding for a non-list memeber:</P>
<P><BR>From [e-mail] Thu Dec 11 19:56:57 MEZ 2008<BR>Received: fr=
om ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)<BR>&nbsp=
;&nbsp; &nbsp; &nbsp;id AA023651816; Thu, 11 Dec 2008 19:56:56 +0100<BR>Ret=
urn-Path: &lt;[e-mail]&gt;<BR>Received: (from ah@localhost) by z.=
TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)<BR>&nbsp;&nbsp; &nbsp; &nbsp;id TAA226=
15; Thu, 11 Dec 2008 19:56:55 +0100 (MEZ)<BR>From: Alfred H=EF=BF=BDnes &lt=
;[e-mail]&gt;<BR>To: [e-mail]<BR>Cc: [e-mail]<BR>M=
essage-Id: &lt;[e-mail]&gt;<BR>Date: Thu, 11 Dec 200=
8 19:56:55 +0100 (MEZ)<BR>Subject: review of draft-zorn-radius-pkmv1-02<BR>=
<BR>Hello,<BR>on my cycle over RADIUS-related Internet-Drafts, I also have<=
BR>followed up to your I-D, draft-zorn-radius-pkmv1-02,<BR>and would like t=
o submit a few comments.<BR><BR>First of all, I fear that this draft violat=
es the emerging<BR>guidelines for RADIUS extensions (draft-ietf-radext-desi=
gn-05,<BR>IETF LC passed) in so many details that it will most probably<BR>=
not be socially acceptable.<BR>Perhaps it would be prudent to redesign the =
intended attributes<BR>as "Extended RADIUS Attributes", following the princ=
iples laid<BR>down in draft-ietf-radext-extended-attributes-05 (you should =
be<BR>aware of, as a co-author :-) )<BR><BR>Furthermore, I am astonished by=
 seeing the draft making use of<BR>very outdated references (which perhaps =
should be Normative!):<BR><BR>o &nbsp; [PKCS.1.1998] &nbsp;had been documen=
ted for the IETF in RFC 2437,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; which has been obsoleted by RFC 3447 long ago;<B=
R><BR>o &nbsp; [RFC2459] &nbsp; &nbsp; &nbsp;had first been obsoleted by RF=
C 3280,<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; which now has been obsoleted by RFC 5280.<BR><BR>More details:<BR><BR>=
<BR>(1) &nbsp;Section 2.2<BR><BR>The draft uses, but does not introduce, mo=
re Acronyms than presently<BR>listed there, e.g.,<BR><BR>&nbsp;&nbsp; SS<BR=
>&nbsp;&nbsp; &nbsp; &nbsp;Subscriber Station.<BR><BR>&nbsp;&nbsp; BS<BR>&n=
bsp;&nbsp; &nbsp; &nbsp;Base Station.<BR><BR>&nbsp;&nbsp; CA<BR>&nbsp;&nbsp=
; &nbsp; &nbsp;Certificate Authority; trusted party issuing and signing X.5=
09<BR>&nbsp;&nbsp; &nbsp; &nbsp;certificates.<BR><BR><BR>(2) &nbsp;Section =
3.1<BR><BR>The draft says:<BR><BR>&nbsp;&nbsp; Description<BR><BR>&nbsp;&nb=
sp; &nbsp; &nbsp;The PKM-SS-Cert Attribute is variable length and contains =
the<BR>| &nbsp; &nbsp; X.509 certificate [RFC2459] identifying the Subscrib=
er Station; it<BR>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^^^^^^^^=
^^^<BR>&nbsp;&nbsp; &nbsp; &nbsp;MAY be transmitted in the Access-Request m=
essage.<BR><BR>That's misleading.<BR>How about saying more precisely:<BR><B=
R>&nbsp;&nbsp; Description<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The PKM-SS-Cert=
 Attribute is variable length and contains the<BR>| &nbsp; &nbsp; X.509 cer=
tificate [RFC2459] binding a public key to the identifier<BR>&nbsp;&nbsp; &=
nbsp; &nbsp;vvv &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>| &nbsp;=
 &nbsp; of the Subscriber Station; it MAY be transmitted in the Access-<BR>=
&nbsp;&nbsp; &nbsp; &nbsp;Request message.<BR><BR>'Value' :<BR><BR>Since yo=
u explicitely refer to RSA, how do you imagine to squeeze<BR>an RSA public =
key certificate into the Value field (I guess you mean,<BR>in RADIUS String=
 format, do you?), which is limited to 253 octets ???<BR><BR>Did you mean -=
- contrary to the explanation quoted above -- a plain<BR>certificate hash?<=
BR><BR><BR>(3) &nbsp;Section 3.2<BR><BR>The draft says:<BR><BR>&nbsp;&nbsp;=
 Description<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The PKM-CA-Cert Attribute is =
variable length and contains the<BR>| &nbsp; &nbsp; X.509 certificate [RFC2=
459] identifying the CA certificate for the<BR>&nbsp;&nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp;^^^^^^^^^^^<BR>&nbsp;&nbsp; &nbsp; &nbsp;SS; it MAY be=
 transmitted in the Access-Request message.<BR><BR>I'm getting confused eve=
n more. &nbsp;Did you mean:<BR><BR>&nbsp;&nbsp; Description<BR><BR>&nbsp;&n=
bsp; &nbsp; &nbsp;The PKM-CA-Cert Attribute is variable length and contains=
 the<BR>| &nbsp; &nbsp; X.509 certificate [RFC2459] used by the CA to sign =
the SS<BR>| &nbsp; &nbsp; certificate carried in the PKM-SS-Cert attribute =
of the same<BR>| &nbsp; &nbsp; message; it MAY be transmitted in the Access=
-Request message.<BR><BR>'Value' :<BR><BR>Same issue as in (2) above!<BR><B=
R><BR>(4) &nbsp;Section 3.3<BR><BR>'Description' :<BR><BR>I fear the text c=
onfuses the terms "timer" and "timeout".<BR>A 'timer' is a running counter;=
 it only makes sense to transport<BR>its limit/starting value, a 'timeout v=
alue' in a packet over the<BR>network.<BR><BR>The intended restriction,<BR>=
<BR>&nbsp;&nbsp; &nbsp; An instance ... MAY be included ...<BR><BR>should p=
erhaps better, and more precisely say,<BR><BR>&nbsp;&nbsp; &nbsp; One insta=
nce ... MAY be included ...<BR>&nbsp;&nbsp; &nbsp; ^^^<BR><BR>'Value' :<BR>=
<BR>The definition given is in direct violation of the principles laid down=
<BR>in the RADIUS Extension Guidelines. &nbsp;Following the spirit of that =
memo,<BR>doing so requires much more detailed, and much more convincing<BR>=
rationale!<BR><BR><BR>(5) &nbsp;Sections 3.4 and 3.5<BR><BR>Using 24- or 16=
-bit integers seems to be inacceptable, according to<BR>the Guidelines. &nb=
sp;Putting multiple such values into one option also is<BR>not conformant; =
the Guidelines recommend using multiple instances<BR>of an elementary optio=
n instead.<BR><BR><BR>(6) &nbsp;Section 3.6<BR><BR>The draft says:<BR><BR>&=
nbsp;&nbsp; Description<BR><BR>| &nbsp; &nbsp; The PKM-SA-Descriptor Attrib=
ute is 8 octets in length. &nbsp;It<BR>&nbsp;&nbsp; &nbsp; &nbsp;vvvvvvvvv =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; ^^^<BR>| &nbsp; &nbsp; consists of 3 fields, described below, wh=
ich together specify the<BR>| &nbsp; &nbsp; characteristics of a PKM securi=
ty association. &nbsp;One or more<BR>&nbsp;&nbsp; &nbsp; &nbsp;vvvvvvvvv &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^^^^^^^^^^^<BR>| &=
nbsp; &nbsp; instances of the PKM-SA-Descriptor Attribute MAY occur in an<B=
R>&nbsp;&nbsp; &nbsp; &nbsp;Access-Accept message.<BR><BR>Semantically, the=
 "It consists" is ambiguous and misleading;<BR>obviously the text only talk=
s about the sub-fields of the value<BR>field; thus, it should be explicit a=
bout that and say:<BR><BR>&nbsp;&nbsp;"Its value consists ..." &nbsp; &nbsp=
;or &nbsp; &nbsp;"It contains ..." &nbsp;.<BR>&nbsp;&nbsp; ^^^^^^^^^^ &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; ^^^^^^^^<BR><BR>I do not understand the semantics of "One or mor=
e instances".<BR>Other parts of the text indicate that this attributes carr=
ies<BR>the selection from the choice of cryptosuite identifiers offered<BR>=
in the PKM-Cryptosuite-List attribute, plus more SA data.<BR>Also, the tabl=
e in Section 4 contains '0-1' in the 'Accept' column<BR>and '0' in all othe=
r columns for this attribute.<BR>Hence, the expected multiplicity needs to =
be clarified.<BR><BR>Subsequently, the draft says:<BR><BR>&nbsp;&nbsp; SAID=
<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The SAID field is two octets in length an=
d contains a PKM SAID<BR>| &nbsp; &nbsp; Section 3.5.<BR><BR>Apparently som=
ething is missing here. &nbsp;I guess:<BR><BR>&nbsp;&nbsp; &nbsp; &nbsp;The=
 SAID field is two octets in length and contains a PKM SAID<BR>| &nbsp; &nb=
sp; (see Section 3.5).<BR><BR>The structured 'Value' field again violated t=
he Guidelines.<BR>It needs explicit, convincing justification.<BR><BR><BR>(=
7) &nbsp;Section 3.7<BR><BR>Similar issues as in (6) apply here.<BR>For bre=
vity, I omit the details.<BR><BR><BR>Kind regards,<BR>&nbsp;&nbsp;Alfred H=
=EF=BF=BDnes.<BR><BR>--<BR><BR>+------------------------+------------------=
--------------------------+<BR>| TR-Sys Alfred Hoenes &nbsp; | &nbsp;Alfred=
 Hoenes &nbsp; Dipl.-Math., Dipl.-Phys. &nbsp;|<BR>| Gerlinger Strasse 12 &=
nbsp; | &nbsp;Phone: [phone], Fax: -18 &nbsp; &nbsp; &nbsp; &nbsp;=
 |<BR>| D-71254 &nbsp;Ditzingen &nbsp; &nbsp; | &nbsp;E-Mail: &nbsp;ah@TR-S=
ys.de &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 |<BR>+------------------------+-------------------------------------------=
-+<BR></P></div></body></html>
------=_Part_166722_200715823.1229366763285--

--
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, 15 Dec 2008 18:34:20 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 13:33:18 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <88B2F5DFA78B474299C17EAAAB533533@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcleNzfZGXpVGkqcROipF5ra4XbrrQAq2RiQ

Bernard Aboba writes...

> > 5.13. Table of Attributes
> >=20
> > The following table provides a guide to which attributes may be=20
> > found in Accounting-Request packets. No attributes should be found
> > in Accounting-Response packets except Proxy-State and possibly
> > Vendor-Specific.
> >
> > That seems pretty clear. Nothing but Proxy-State && VSA's.
>
> Yes.=A0=A0 VSAs are allowed.=A0 Presumably this would also include
> Extended Attributes?=20

Uh...  No.  Extended Attributes leverage the VSA _format_ for =
extensibility
reasons but they are not [inherently] vendor specific.  VSA =
traditionally
implied "proprietary secret sauce" that other vendors could safely =
ignore.
That is certainly not the case with Extended Attributes, which could be
Standards Track.

If this is a common misunderstanding -- i.e. the traditional usage rules =
for
VSAs apply to Extended Attributes -- we should indeed clear up that
confusion immediately.  Perhaps in the Extended Attributes draft itself. =




--
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, 15 Dec 2008 16:01:30 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_b5ca6ad8-e603-4619-81af-a72db548d792_"
From: Bernard Aboba <[e-mail]>
To: Glen Zorn <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 08:00:27 -0800
MIME-Version: 1.0

--_b5ca6ad8-e603-4619-81af-a72db548d792_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Perhaps you could suggest a better way to accomplish this?  Maybe it's
> really not needed: much more efficient to just wait till the server goes
> away then retry a few times.

I don't think there is a better way to accomplish this in RADIUS at this po=
int.=20

SIP=2C Diameter and HTTP all have a "redirect" error message.  RADIUS does
not.  This means that the RADIUS accounting server either stores the=20
accounting packet and returns an Accounting-Response=2C or it drops the=20
packet=2C and then has to deal with a retry.=20

Given this=2C about the best that can be done is for the server to process =
the
Accounting-Request and then send whatever load shedding info it has in
a VSA. =20

If the NAS doesn't understand the VSA=2C then it will ignore it=2C and
things will be no worse off than had the server not sent the VSA at all.=20

> Excellent suggestion: it's not like the semantics of the CoA exchange bin=
d
> it to a specific session=2C while the Accounting-Response is a generic
> accounting-related ACK. =20

TheCoA-Request also requires the NAS (and Dynamic Authorization Client)
to implement RFC 5176.=20

--_b5ca6ad8-e603-4619-81af-a72db548d792_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B Perhaps you could suggest a better way to accomplish this?  Maybe it=
's<br>&gt=3B really not needed: much more efficient to just wait till the s=
erver goes<br>&gt=3B away then retry a few times.<br><br>I don't think ther=
e is a better way to accomplish this in RADIUS at this point. <br><br>SIP=
=2C Diameter and HTTP all have a "redirect" error message.&nbsp=3B RADIUS d=
oes<br>not.&nbsp=3B This means that the RADIUS accounting server either sto=
res the <br>accounting packet and returns an Accounting-Response=2C or it d=
rops the <br>packet=2C and then has to deal with a retry. <br><br>Given thi=
s=2C about the best that can be done is for the server to process the<br>Ac=
counting-Request and then send whatever load shedding info it has in<br>a V=
SA.&nbsp=3B <br><br>If the NAS doesn't understand the VSA=2C then it will i=
gnore it=2C and<br>things will be no worse off than had the server not sent=
 the VSA at all. <br><br>&gt=3B Excellent suggestion: it's not like the sem=
antics of the CoA exchange bind<br>&gt=3B it to a specific session=2C while=
 the Accounting-Response is a generic<br>&gt=3B accounting-related ACK.  <b=
r><br>TheCoA-Request also requires the NAS (and Dynamic Authorization Clien=
t)<br>to implement RFC 5176. <br></body>
</html>=

--_b5ca6ad8-e603-4619-81af-a72db548d792_--

--
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, 15 Dec 2008 13:20:57 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 14:20:24 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Greg Weber' <[e-mail]>,  'Bernard Aboba' <[e-mail]>, [e-mail]
Subject: Re: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
>>   That sounds like a bit of a hack to me.  "Yes I've stored the
>> accounting data for bob, and by the way, I'm rebooting in 5 minutes".
> 
> Perhaps you could suggest a better way to accomplish this?  Maybe it's
> really not needed: much more efficient to just wait till the server goes
> away then retry a few times.

  I have no good suggestions here.  Traditionally, yes, the server just
"goes away".

  I'm not even aware of *which* NASes support this behavior.  This
behavior is new to me, and I've been doing this for well over a decade.

>>   I would suggest that CoA might be a better choice for that.
> 
> Excellent suggestion: it's not like the semantics of the CoA exchange bind
> it to a specific session, while the Accounting-Response is a generic
> accounting-related ACK.  

 ... which is sent in response to an Accounting-Request for a particular
user session.

  Just like CoA.

  If the NAS vendors need this functionality, CoA seems to be a better
fit than Accounting-Response.  Few RADIUS servers have traditionally
implemented CoA, so I understand why using Accounting-Response is tempting.

  Now that we have the potential for Status-Server, it is much safer for
the RADIUS server to just "go away".

  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, 15 Dec 2008 11:41:47 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'Greg Weber'" <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>, <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Mon, 15 Dec 2008 18:40:12 +0700
Message-ID: <002801c95ea9$f092b440$d1b81cc0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcleiObyblMMmwseTBev0F47Oc2GFQAEhzwA
Content-Language: en-us

> Greg Weber wrote:
> >>  I would like to know what it *means* to have VSA's in an
> >> Accounting-Response.  What does the NAS do with them?  Log them?
> Ignore
> >> them?  Change it's behavior?
> >
> > This can be used to communicate server load or pending planned
> downtime
> > information back to the NAS which then can be used in server
> selection
> > algorithms.
> 
>   That sounds like a bit of a hack to me.  "Yes I've stored the
> accounting data for bob, and by the way, I'm rebooting in 5 minutes".

Perhaps you could suggest a better way to accomplish this?  Maybe it's
really not needed: much more efficient to just wait till the server goes
away then retry a few times.

> 
> >  I believe there's a commercial server in the PacketCable space
> > doing this (for voice gateway RADIUS clients).  Also have heard some
> > discussion about a server being able to dynamically adjust the
> interim
> > accounting
> > record interval by setting a VSA in the accounting response
> (mimicking a
> > Diameter feature), but I'm not sure if that's implemented by any
> servers.
> 
>   I would suggest that CoA might be a better choice for that.

Excellent suggestion: it's not like the semantics of the CoA exchange bind
it to a specific session, while the Accounting-Response is a generic
accounting-related ACK.  

...


--
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, 15 Dec 2008 10:22:41 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 11:21:59 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail], "[e-mail]" <[e-mail]>
Subject: Re: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Yes.   VSAs are allowed  Presumably this would also include 
> Extended Attributes?

  Likely, yes.

> Since this document is a BCP, not an update to RFC 2866, it can quote from
> existing RFCs, but shouldn't modify them.
> 
> So it's ok to add an item to Section 3.3 about not including standard RADIUS
> attributes beyond Proxy-State in Accounting-Responses, using a quote
> from RFC 2866 Section 5.13 for justification.  Since RFC 2866 allows VSAs,
> I don't think they can or should be prohibited in this document.

  Maybe make them NOT RECOMMENDED?

  Ongoing discussion indicates that people are using them to implement
CoA behavior.  i.e. changes to billing, bandwidth, etc.  Because "doing
CoA is too hard".

  Also, making changes to user sessions as a result of VSA's in an
Accounting-Response should be NOT RECOMMENDED.  Implementors SHOULD use
CoA instead.

  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, 15 Dec 2008 07:40:35 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Dec 2008 08:39:45 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Greg Weber <[e-mail]>
CC: Bernard Aboba <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Weber wrote:
>>  I would like to know what it *means* to have VSA's in an
>> Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
>> them?  Change it's behavior?
> 
> This can be used to communicate server load or pending planned downtime
> information back to the NAS which then can be used in server selection
> algorithms.

  That sounds like a bit of a hack to me.  "Yes I've stored the
accounting data for bob, and by the way, I'm rebooting in 5 minutes".

>  I believe there's a commercial server in the PacketCable space
> doing this (for voice gateway RADIUS clients).  Also have heard some
> discussion about a server being able to dynamically adjust the interim
> accounting
> record interval by setting a VSA in the accounting response (mimicking a
> Diameter feature), but I'm not sure if that's implemented by any servers.

  I would suggest that CoA might be a better choice for that.

  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, 14 Dec 2008 22:04:32 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Issue 298:  Extended Attribute Usage Restrictions
Date: Sun, 14 Dec 2008 14:04:09 -0800
MIME-Version: 1.0

--_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue 298:  Extended Attributes Restrictions

Submitter name: Bernard Aboba

Submitter email address: [e-mail]=20

Date first submitted:  December 14=2C 2008

Reference:  =20

Document: EXTENDED

Comment type:  Technical

Priority: S=20

Section: Various =20

Rationale/Explanation of issue:

RFC 2866 Section 5.13 states:
   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

Given that RADIUS Extended Attributes are VSAs=2C the question arises as to=
 whether
they are allowed in Accounting-Responses or not.  My take would be "no" -- =
they
should be treated like RADIUS standard attributes.=20

In RFC 5176=2C VSAs are listed as not permitted within CoA-ACK=2C CoA-NAK=
=2C Disconnect-ACK
or Disconnect-NAK packets.  They are listed as "0+" within CoA-Request and=
=20
Disconnect-Request packets=2C however:

   (Note 7) Within Disconnect-Request packets=2C Vendor-Specific
   Attributes (VSAs) MAY be used for session identification.  Within
   CoA-Request packets=2C VSAs MAY be used for either session
   identification or authorization change.  However=2C the same Attribute
   MUST NOT be used for both purposes simultaneously.

So=2C do the restrictions on VSA usage apply to Extended Attributes as well=
?=20




--_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<b>Issue 298:&nbsp=3B Extended Attributes Restrictions</b><br>
Submitter name: Bernard Aboba<br>
Submitter email address: [e-mail] <br>
Date first submitted:&nbsp=3B December 14=2C 2008<br>
Reference:&nbsp=3B&nbsp=3B <br>
Document: EXTENDED<br>
Comment type:&nbsp=3B Technical<br>
Priority: S <br>
Section: Various&nbsp=3B <br>
Rationale/Explanation of issue:<br><br>RFC 2866 Section 5.13 states:<br><pr=
e>   The following table provides a guide to which attributes may be found<=
br>   in Accounting-Request packets.  No attributes should be found in<br> =
  Accounting-Response packets except Proxy-State and possibly Vendor-<br>  =
 Specific.<br><br>Given that RADIUS Extended Attributes are VSAs=2C the que=
stion arises as to whether<br>they are allowed in Accounting-Responses or n=
ot.  My take would be "no" -- they<br>should be treated like RADIUS standar=
d attributes. <br><br>In RFC 5176=2C VSAs are listed as not permitted withi=
n CoA-ACK=2C CoA-NAK=2C Disconnect-ACK<br>or Disconnect-NAK packets.  They =
are listed as "0+" within CoA-Request and <br>Disconnect-Request packets=2C=
 however:<br><br>   (Note 7) Within Disconnect-Request packets=2C Vendor-Sp=
ecific<br>   Attributes (VSAs) MAY be used for session identification.  Wit=
hin<br>   CoA-Request packets=2C VSAs MAY be used for either session<br>   =
identification or authorization change.  However=2C the same Attribute<br> =
  MUST NOT be used for both purposes simultaneously.<br><br>So=2C do the re=
strictions on VSA usage apply to Extended Attributes as well? <br></pre><br=
><br><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B fo=
nt-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"ht=
tp://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D=
"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"=
><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=
=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tbody>=
</table></body>
</html>=

--_d8ae8bd6-d3d6-4ab0-bb26-8a646e4cb5c5_--

--
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, 14 Dec 2008 21:56:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_e467b4d2-4cab-41cb-bcc5-0096977c6733_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>, Alan DeKok <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Sun, 14 Dec 2008 13:55:42 -0800
MIME-Version: 1.0

--_e467b4d2-4cab-41cb-bcc5-0096977c6733_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>In this particular case=2C while RFC 2866 indicates that there are no
>required attributes in an Accounting-Response=2C it doesn't prohibit
>them.
>
> 5.13.  Table of Attributes
>
> The following table provides a guide to which attributes may be found
> in Accounting-Request packets.  No attributes should be found in
> Accounting-Response packets except Proxy-State and possibly Vendor-
> Specific.
>
> That seems pretty clear.  Nothing but Proxy-State && VSA's.

Yes.   VSAs are allowed  Presumably this would also include

Extended Attributes?=20

> >  I would like to know what it *means* to have VSA's in an
> > Accounting-Response.  What does the NAS do with them?  Log them?  Ignor=
e
> > them?  Change it's behavior?
>=20
> This can be used to communicate server load or pending planned downtime
> information back to the NAS which then can be used in server selection
> algorithms.  I believe there's a commercial server in the PacketCable spa=
ce
> doing this (for voice gateway RADIUS clients).  Also have heard some
> discussion about a server being able to dynamically adjust the interim
> accounting record interval by setting a VSA in the accounting response (m=
imicking a
> Diameter feature)=2C but I'm not sure if that's implemented by any server=
s.
>=20
> But it sounds like you're talking about static attribute values below.
> Anyway=2C I don't think we should try to prohibit VSAs in accounting resp=
onses.

Since this document is a BCP=2C not an update to RFC 2866=2C it can quote f=
rom
existing RFCs=2C but shouldn't modify them.=20

So it's ok to add an item to Section 3.3 about not including standard RADIU=
S
attributes beyond Proxy-State in Accounting-Responses=2C using a quote
from RFC 2866 Section 5.13 for justification.  Since RFC 2866 allows VSAs=
=2C
I don't think they can or should be prohibited in this document.=20

It also probably makes sense to log an issue against the Extended Attribute=
s
document for clarification on whether they can be included in Accounting-Re=
sponses.=20

--_e467b4d2-4cab-41cb-bcc5-0096977c6733_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3BIn this particular case=2C while RFC 2866 indicates that there are no=
<br>&gt=3Brequired attributes in an Accounting-Response=2C it doesn't prohi=
bit<br>&gt=3Bthem.<br>&gt=3B<br>&gt=3B 5.13.  Table of Attributes<br>&gt=3B=
<br>&gt=3B The following table provides a guide to which attributes may be =
found<br>&gt=3B in Accounting-Request packets.  No attributes should be fou=
nd in<br>&gt=3B Accounting-Response packets except Proxy-State and possibly=
 Vendor-<br>&gt=3B Specific.<br>&gt=3B<br>&gt=3B That seems pretty clear.  =
Nothing but Proxy-State &amp=3B&amp=3B VSA's.<br><br>Yes.&nbsp=3B&nbsp=3B V=
SAs are allowed&nbsp=3B Presumably this would also include<br><br>Extended =
Attributes? <br><br>&gt=3B &gt=3B  I would like to know what it *means* to =
have VSA's in an<br>&gt=3B &gt=3B Accounting-Response.  What does the NAS d=
o with them?  Log them?  Ignore<br>&gt=3B &gt=3B them?  Change it's behavio=
r?<br>&gt=3B <br>&gt=3B This can be used to communicate server load or pend=
ing planned downtime<br>&gt=3B information back to the NAS which then can b=
e used in server selection<br>&gt=3B algorithms.  I believe there's a comme=
rcial server in the PacketCable space<br>&gt=3B doing this (for voice gatew=
ay RADIUS clients).  Also have heard some<br>&gt=3B discussion about a serv=
er being able to dynamically adjust the interim<br>&gt=3B accounting record=
 interval by setting a VSA in the accounting response (mimicking a<br>&gt=
=3B Diameter feature)=2C but I'm not sure if that's implemented by any serv=
ers.<br>&gt=3B <br>&gt=3B But it sounds like you're talking about static at=
tribute values below.<br>&gt=3B Anyway=2C I don't think we should try to pr=
ohibit VSAs in accounting responses.<br><br>Since this document is a BCP=2C=
 not an update to RFC 2866=2C it can quote from<br>existing RFCs=2C but sho=
uldn't modify them. <br><br>So it's ok to add an item to Section 3.3 about =
not including standard RADIUS<br>attributes beyond Proxy-State in Accountin=
g-Responses=2C using a quote<br>from RFC 2866 Section 5.13 for justificatio=
n.&nbsp=3B Since RFC 2866 allows VSAs=2C<br>I don't think they can or shoul=
d be prohibited in this document. <br><br>It also probably makes sense to l=
og an issue against the Extended Attributes<br>document for clarification o=
n whether they can be included in Accounting-Responses. <br></body>
</html>=

--_e467b4d2-4cab-41cb-bcc5-0096977c6733_--

--
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, 14 Dec 2008 19:09:52 +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=SFFKKiLTUJaWGh8yI/fygfC/ewkCnwx6fhq9oA0lmRw=; b=OQRVDHumPxMKq6/PaJYUDQJ+l2DAZ0zfizVxhHZCXDGCr8WIZQFx9n4I98Kn8r6q8A nrfoW88r+E2lrsM7TU3oq6Pog24QRLlTCYLzTOHmR5s3rSYEYjaII1AmF2HzVdkzQLnG oBsPNwX3TfwrCQer4fppMM1FEBN5n3bEScT4s=
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=bxPzTHrqEPN9Kur9g3VmzUBZFzrO55lu5cqXv6lH3nNWZSun4VD7GTcuVqH34g43xP U4JJBIvkOK9KmO/WMq8jkaDJUuF7D5ApfvLM62SkGX7vPXAzav+YLtBzAgdS1NdIpIqd GSIVIV1I18r+QsrY/SNqYBgR/YmXirJgMSKVg=
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 14:09:03 -0500
From: "Greg Weber" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Subject: Re: Issue with Guidelines document
Cc: "Bernard Aboba" <[e-mail]>,  "[e-mail]" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 14, 2008 at 12:53 PM, Alan DeKok <[e-mail]> wrote:
> Bernard Aboba wrote:
>> In this particular case, while RFC 2866 indicates that there are no
>> required attributes in an Accounting-Response, it doesn't prohibit
>> them.
>
>  Hmm...
>
> 5.13.  Table of Attributes
>
>   The following table provides a guide to which attributes may be found
>   in Accounting-Request packets.  No attributes should be found in
>   Accounting-Response packets except Proxy-State and possibly Vendor-
>   Specific.
>
>  That seems pretty clear.  Nothing but Proxy-State && VSA's.
>
>>  So is the issue the inclusion of attributes, or is it the use
>> of those attributes?
>
>  I would like to know what it *means* to have VSA's in an
> Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
> them?  Change it's behavior?

This can be used to communicate server load or pending planned downtime
information back to the NAS which then can be used in server selection
algorithms.  I believe there's a commercial server in the PacketCable space
doing this (for voice gateway RADIUS clients).  Also have heard some
discussion about a server being able to dynamically adjust the interim
accounting
record interval by setting a VSA in the accounting response (mimicking a
Diameter feature), but I'm not sure if that's implemented by any servers.

But it sounds like you're talking about static attribute values below.
Anyway, I don't think we should try to prohibit VSAs in accounting responses.

Greg

>
>  I'm seeing people who insist that they have to put attributes in an
> Accounting-Response.  Sometimes they claim their NAS requires it.  But I
> can't get an explanation as to *why*.
>
>  Alan DeKok.
>
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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


Envelope-to: [e-mail]
Delivery-date: Sun, 14 Dec 2008 17:54:12 +0000
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 18:53:30 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> In this particular case, while RFC 2866 indicates that there are no
> required attributes in an Accounting-Response, it doesn't prohibit
> them.

  Hmm...

5.13.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

  That seems pretty clear.  Nothing but Proxy-State && VSA's.

>  So is the issue the inclusion of attributes, or is it the use
> of those attributes?

  I would like to know what it *means* to have VSA's in an
Accounting-Response.  What does the NAS do with them?  Log them?  Ignore
them?  Change it's behavior?

  I'm seeing people who insist that they have to put attributes in an
Accounting-Response.  Sometimes they claim their NAS requires it.  But I
can't get an explanation as to *why*.

  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, 14 Dec 2008 16:20:11 +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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=t42MCO3vaH9o3jHk3TLX1KoSoSKpOum9YVDILbXKBC8=; b=SwgtUiA1kcy8OC0nzS5FQvCjWx5FxJGkbBh0eVnvE5h3e7R25KDjJRZ8hliWhwiXOB KeEruKS0IJHZCreMnZxAjI7f0IiPw8mDqXMKZ9vliLpLCSFmNTQ0w9FE2DSYpqd8//EF N9EJXQzLF3mGFLRXYTdJsqu9C8OHgf6h7KImU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Kig5cq2EHBOaLAFfflbzPU4HueOK71VffNdtkwNt2gDnpj+9l7cNHjJtoXS8UC0Mym Egh8kMxlIF7XMxPf1ekieGhasO3wNqn7Fp1cLDkbcaa3ZOPCvtzMqASk/8GBvE/5xHRM Oj/xukdM/zVFpXyQHdVv65gz4ShIyOk1NbkDE=
Message-ID: <[e-mail]>
Date: Sun, 14 Dec 2008 11:19:47 -0500
From: "Greg Weber" <[e-mail]>
To: [e-mail]
Subject: Re: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I liked the proposed title change too (below).

Also, the current text has one error and one warning in idnits.


On Tue, Nov 25, 2008 at 4:54 PM, David B. Nelson
<[e-mail]> wrote:
> Glen Zorn writes...
>
>> The title is so vague as to be meaningless: suggest changing to the
>> extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating Security
>> Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see
>> below), w/an appropriate abbreviation for the second & following pages.
>
> Agreed.
>
<snip>

--
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, 14 Dec 2008 15:34:01 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c84f5585-0f36-4c90-94e3-39e0d1535ddc_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Issue with Guidelines document
Date: Sun, 14 Dec 2008 07:32:45 -0800
MIME-Version: 1.0

--_c84f5585-0f36-4c90-94e3-39e0d1535ddc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


In gerneral=2C the purpose of the Design Guidelines document is to provide
guidelines compatible with existing RADIUS RFCs.  As a result=2C RADIUS
operational model issues discussed in Section 3.3 contain citations
to existing RFCs.=20
=20
In this particular case=2C while RFC 2866 indicates that there are no
required attributes in an Accounting-Response=2C it doesn't prohibit
them.  So is the issue the inclusion of attributes=2C or is it the use
of those attributes?
=20
>From Section 4.2:
=20
4.2.  Accounting-Response   Description      Accounting-Response packets ar=
e sent by the RADIUS accounting      server to the client to acknowledge th=
at the Accounting-Request      has been received and recorded successfully.=
  If the Accounting-      Request was recorded successfully then the RADIUS=
 accounting      server MUST transmit a packet with the Code field set to 5=
      (Accounting-Response).  On reception of an Accounting-Response by    =
  the client=2C the Identifier field is matched with a pending      Account=
ing-Request.  The Response Authenticator field MUST contain      the correc=
t response for the pending Accounting-Request.  Invalid      packets are si=
lently discarded.      A RADIUS Accounting-Response is not required to have=
 any      attributes in it.   A summary of the Accounting-Response packet f=
ormat is shown below.   The fields are transmitted from left to right.    0=
                   1                   2                   3    0 1 2 3 4 5=
 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifi=
er   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                        =
                       |   |                     Response Authenticator    =
                |   |                                                      =
         |   |                                                             =
  |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |=
  Attributes ...   +-+-+-+-+-+-+-+-+-+-+-+-+-   Code      5 for Accounting-=
Response.   Identifier      The Identifier field is a copy of the Identifie=
r field of the      Accounting-Request which caused this Accounting-Respons=
e.   Response Authenticator      The Response Authenticator of an Accountin=
g-Response contains a      16-octet MD5 hash value calculated according to =
the method      described in "Response Authenticator" above.   Attributes  =
    The Attributes field is variable in length=2C and contains a list of   =
   zero or more Attributes.
=20



 EMAILING FOR THE GREATER GOODJoin me> Date: Sat=2C 13 Dec 2008 10:16:53 +0=
100> From: [e-mail]> To: [e-mail]> Subject: =
Issue with Guidelines document> > This might be a little late=2C but it may=
 be worth adding one more note:> > ---> Accounting-Response packets SHOULD =
contain only Proxy-State.> > State changes in the RADIUS client based on Ac=
counting-Response> packets are NOT RECOMMENDED. They do not fit within the =
traditional> RADIUS operational model. Despite the text in [RFC2866] Sectio=
n 5.13> saying that "possibly" Vendor-Specific is permitted=2C such use is =
NOT> RECOMMENDED.> ---> > > Is it too late for this? Do we have Area Direct=
or agreement that this> is a good idea?> > The background is a growing numb=
er of NAS equipment that I'm seeing> which *does* look for attributes in an=
 Accounting-Response. It's not> clear what the NAS does with those attribut=
es=2C but internal state> changes are a logical conclusion.> > Alan DeKok.>=
 > --> to unsubscribe send a message to [e-mail] with=
> the word 'unsubscribe' in a single line as the message text body.> archiv=
e: <http://psg.com/lists/radiusext/>=

--_c84f5585-0f36-4c90-94e3-39e0d1535ddc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In gerneral=2C the purpose of the Design Guidelines document is to provide<=
BR>
guidelines compatible with existing RADIUS RFCs.&nbsp=3B As a result=2C RAD=
IUS<BR>
operational model issues discussed in Section 3.3 contain citations<BR>
to existing RFCs. <BR>
&nbsp=3B<BR>
In this particular case=2C while RFC 2866 indicates that there are no<BR>
required attributes in an Accounting-Response=2C&nbsp=3Bit doesn't prohibit=
<BR>
them. &nbsp=3BSo is the issue the inclusion of attributes=2C or is it the u=
se<BR>
of those attributes?<BR>
&nbsp=3B<BR>
>From Section 4.2:<BR>
&nbsp=3B<BR>
4.2.&nbsp=3B Accounting-Response<BR><BR>&nbsp=3B&nbsp=3B Description<BR><BR=
>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Accounting-Response packets are s=
ent by the RADIUS accounting<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B se=
rver to the client to acknowledge that the Accounting-Request<BR>&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B has been received and recorded successfully.=
&nbsp=3B If the Accounting-<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Req=
uest was recorded successfully then the RADIUS accounting<BR>&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B server MUST transmit a packet with the Code fie=
ld set to 5<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B (Accounting-Respons=
e).&nbsp=3B On reception of an Accounting-Response by<BR>&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B the client=2C the Identifier field is matched with a=
 pending<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Accounting-Request.&nb=
sp=3B The Response Authenticator field MUST contain<BR>&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B the correct response for the pending Accounting-Reques=
t.&nbsp=3B Invalid<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B packets are =
silently discarded.<BR><BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B A RADIU=
S Accounting-Response is not required to have any<BR>&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B attributes in it.<BR><BR>&nbsp=3B&nbsp=3B A summary of =
the Accounting-Response packet format is shown below.<BR>&nbsp=3B&nbsp=3B T=
he fields are transmitted from left to right.<BR><BR>&nbsp=3B&nbsp=3B&nbsp=
=3B 0&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
 1&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B 2&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B 3<BR>&n=
bsp=3B&nbsp=3B&nbsp=3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 =
6 7 8 9 0 1<BR>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B Code&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |&nbsp=3B Identifier&nbsp=
=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B Length&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=
=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&n=
bsp=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=
=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B Response Authenticator&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=3B |=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=3B |&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |<BR>&nbsp=3B&nbsp=3B +-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbsp=3B&nbsp=
=3B |&nbsp=3B Attributes ...<BR>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-=
<BR><BR>&nbsp=3B&nbsp=3B Code<BR><BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B 5 for Accounting-Response.<BR><BR>&nbsp=3B&nbsp=3B Identifier<BR><BR>&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Identifier field is a copy of th=
e Identifier field of the<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Accou=
nting-Request which caused this Accounting-Response.<BR><BR>&nbsp=3B&nbsp=
=3B Response Authenticator<BR><BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B =
The Response Authenticator of an Accounting-Response contains a<BR>&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B 16-octet MD5 hash value calculated accordi=
ng to the method<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B described in "=
Response Authenticator" above.<BR><BR>&nbsp=3B&nbsp=3B Attributes<BR><BR>&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Attributes field is variable in =
length=2C and contains a list of<BR>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B zero or more Attributes.<BR><BR><BR>
<BR>&nbsp=3B<BR>
<TABLE style=3D"BORDER-TOP: black 1px solid=3B FONT-WEIGHT: bold=3B FONT-FA=
MILY: 'Segoe UI'=2CTahoma=2Csan-serif">
<TBODY>
<TR>
<TD><A style=3D"FONT-SIZE: 9pt=3B COLOR: #0184cb=3B TEXT-DECORATION: none" =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood=
"><IMG style=3D"BORDER-TOP-STYLE: none=3B BORDER-RIGHT-STYLE: none=3B BORDE=
R-LEFT-STYLE: none=3B BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<=
BR><SPAN style=3D"PADDING-RIGHT: 24px=3B PADDING-LEFT: 24px=3B FONT-SIZE: 8=
pt=3B PADDING-BOTTOM: 0px=3B COLOR: #3fb555=3B PADDING-TOP: 0px=3B TEXT-DEC=
ORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE><BR><BR>&gt=
=3B Date: Sat=2C 13 Dec 2008 10:16:53 +0100<BR>&gt=3B From: aland@deploying=
radius.com<BR>&gt=3B To: [e-mail]<BR>&gt=3B Subject: Issue wi=
th Guidelines document<BR>&gt=3B <BR>&gt=3B This might be a little late=2C =
but it may be worth adding one more note:<BR>&gt=3B <BR>&gt=3B ---<BR>&gt=
=3B Accounting-Response packets SHOULD contain only Proxy-State.<BR>&gt=3B =
<BR>&gt=3B State changes in the RADIUS client based on Accounting-Response<=
BR>&gt=3B packets are NOT RECOMMENDED. They do not fit within the tradition=
al<BR>&gt=3B RADIUS operational model. Despite the text in [RFC2866] Sectio=
n 5.13<BR>&gt=3B saying that "possibly" Vendor-Specific is permitted=2C suc=
h use is NOT<BR>&gt=3B RECOMMENDED.<BR>&gt=3B ---<BR>&gt=3B <BR>&gt=3B <BR>=
&gt=3B Is it too late for this? Do we have Area Director agreement that thi=
s<BR>&gt=3B is a good idea?<BR>&gt=3B <BR>&gt=3B The background is a growin=
g number of NAS equipment that I'm seeing<BR>&gt=3B which *does* look for a=
ttributes in an Accounting-Response. It's not<BR>&gt=3B clear what the NAS =
does with those attributes=2C but internal state<BR>&gt=3B changes are a lo=
gical conclusion.<BR>&gt=3B <BR>&gt=3B Alan DeKok.<BR>&gt=3B <BR>&gt=3B --<=
BR>&gt=3B to unsubscribe send a message to [e-mail] w=
ith<BR>&gt=3B the word 'unsubscribe' in a single line as the message text b=
ody.<BR>&gt=3B archive: &lt=3Bhttp://psg.com/lists/radiusext/&gt=3B<BR></bo=
dy>
</html>=

--_c84f5585-0f36-4c90-94e3-39e0d1535ddc_--

--
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, 13 Dec 2008 09:17:51 +0000
Message-ID: <[e-mail]>
Date: Sat, 13 Dec 2008 10:16:53 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Issue with Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  This might be a little late, but it may be worth adding one more note:

---
    Accounting-Response packets SHOULD contain only Proxy-State.

  State changes in the RADIUS client based on Accounting-Response
packets are NOT RECOMMENDED.  They do not fit within the traditional
RADIUS operational model.  Despite the text in [RFC2866] Section 5.13
saying that "possibly" Vendor-Specific is permitted, such use is NOT
RECOMMENDED.
---


  Is it too late for this?  Do we have Area Director agreement that this
is a good idea?

  The background is a growing number of NAS equipment that I'm seeing
which *does* look for attributes in an Accounting-Response.  It's not
clear what the NAS does with those attributes, but internal state
changes are a logical conclusion.

  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, 12 Dec 2008 20:34:44 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/mixed; boundary="_d70a75a7-397d-4744-bff9-a64b9a19ac7c_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Preliminary Meeting Minutes from IETF 73
Date: Fri, 12 Dec 2008 12:33:35 -0800
MIME-Version: 1.0

--_d70a75a7-397d-4744-bff9-a64b9a19ac7c_
Content-Type: multipart/alternative;
	boundary="_833c9354-ddfe-4bff-827b-8c55e5288d63_"

--_833c9354-ddfe-4bff-827b-8c55e5288d63_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Are enclosed.=20



 EMAILING FOR THE GREATER GOODJoin me=

--_833c9354-ddfe-4bff-827b-8c55e5288d63_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Are enclosed. <BR><BR><BR><BR><BR>
<TABLE style=3D"BORDER-TOP: black 1px solid=3B FONT-WEIGHT: bold=3B FONT-FA=
MILY: 'Segoe UI'=2CTahoma=2Csan-serif">
<TBODY>
<TR>
<TD><A style=3D"FONT-SIZE: 9pt=3B COLOR: #0184cb=3B TEXT-DECORATION: none" =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood=
"><IMG style=3D"BORDER-TOP-STYLE: none=3B BORDER-RIGHT-STYLE: none=3B BORDE=
R-LEFT-STYLE: none=3B BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<=
BR><SPAN style=3D"PADDING-RIGHT: 24px=3B PADDING-LEFT: 24px=3B FONT-SIZE: 8=
pt=3B PADDING-BOTTOM: 0px=3B COLOR: #3fb555=3B PADDING-TOP: 0px=3B TEXT-DEC=
ORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>=

--_833c9354-ddfe-4bff-827b-8c55e5288d63_--

--_d70a75a7-397d-4744-bff9-a64b9a19ac7c_
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ietf73-minutes.txt"

SUVURiA3MyAtIFJBREVYVCBXRyBNZWV0aW5nIE1pbnV0ZXMgDQpUdWVzZGF5LCBOb3ZlbWJlciAx
OCwgMzAwOCANCg0KQWdlbmRhIEJhc2hpbmcgDQotLS0tLS0tLS0tLS0tLSANCk5vIGNoYW5nZXMg
dG8gYWdlbmRhLiANCg0KRG9jdW1lbnQgU3RhdHVzIA0KLS0tLS0tLS0tLS0tLS0tDQpGb3IgdXBk
YXRlLCBzZWUgaHR0cDovL3d3dy5kcml6emxlLmNvbS9+YWJvYmEvUkFERVhULw0KDQpDb21wbGV0
ZWQgSUVURiBsYXN0IGNhbGwNCglOQVMgTWFuYWdlbWVudCBBdXRob3JpemF0aW9uIChjb21wbGV0
ZWQgTm92ZW1iZXIgMTEsIDIwMDgpDQoJRGVzaWduIEd1aWRlbGluZXMgKGNvbXBsZXRlZCBOb3Zl
bWJlciAxMSwgMjAwOCkNCkNvbXBsZXRlZCBXRyBsYXN0IGNhbGwNCglDcnlwdG8tYWdpbGl0eSBy
ZXF1aXJlbWVudHMgKDIgaXNzdWVzIHN0aWxsIG9wZW4pDQoJRXh0ZW5kZWQgQXR0cmlidXRlcyAo
NiBpc3N1ZXMgc3RpbGwgb3BlbikNCkluIFdHIExhc3QgQ2FsbA0KCVJBRFNFQyAoY29tcGxldGVz
IE5vdmVtYmVyIDI1LCAyMDA4KQ0KCVN0YXR1cyBTZXJ2ZXIgKGNvbXBsZXRlcyBOb3ZlbWJlciAy
NSwgMjAwOCkNCldHIFdvcmsgaXRlbXMNCglkcmFmdC10aXdhcmktcmFkZXh0LXR1bm5lbC10eXBl
cy0wMg0KSW5kaXZpZHVhbCBzdWJtaXNzaW9ucw0KCWRyYWZ0LWRla29rLXJhZGV4dC10Y3AtdHJh
bnNwb3J0LTAwIChyZXZpZXcgY29tcGxldGVzIE5vdmVtYmVyIDE5LCAyMDA4KQ0KCWRyYWZ0LWxv
dXJkZWxldC1yYWRleHQtcmZjMzE2MmJpcy0wMiAoZGlzY3Vzc2lvbiBpbiBwcm9ncmVzcykgDQoJ
ZHJhZnQtYWJvYmEtcmFkZXh0LXdsYW4tMDkudHh0IChJRUVFIDgwMi4xIHJldmlldyBjb21wbGV0
ZWQpDQoJZHJhZnQtem9ybi1yYWRpdXMtZW5jYXRyci0xNS50eHQNCglkcmFmdC1kZWtvay1yYWRp
dXNleHQtZGx0cy0wMi50eHQNCglkcmFmdC16b3JuLXJhZGl1cy1wa212MS0wMS50eHQgKElFRUUg
ODAyLjE2IHJldmlldyBpbiBwcm9ncmVzcykNCg0KSUVFRSA4MDIgUmV2aWV3cw0KLS0tLS0tLS0t
LS0tLS0tLQ0KSW5pdGlhbCBJRUVFIDgwMi4xIHJldmlldyBvZiBkcmFmdC1hYm9iYS1yYWRleHQt
d2xhbiBjb21wbGV0ZWQsIGNvbW1lbnRzIGluY29ycG9yYXRlZCANCmludG8gLTA5LiAgTW9yZSBj
b21tZW50cyBtYXkgc3RpbGwgYmUgY29taW5nOyBhc3BlY3RzIHN1Y2ggYXMgU3RhdHVzIGluZGlj
YXRpb25zIGFyZQ0Kc3RpbGwgaW4gZmx1eC4gDQoNCkpvZSBTYWxvd2V5OiBTdHVmZiBzdGlsbCBo
YXBwZW5pbmcgaW4gODAyLjEsIGJ1dCBpdCdzIHNldHRsaW5nIGRvd24uICBXZSdsbCBnZXQNCm1v
cmUgY29tbWVudHMgd2hlbiB0aGUgbmV3IDgwMi4xWC1SRVYgZHJhZnQgY29tZXMgb3V0LiANCg0K
V2lNYXggRm9ydW0gYW5kIElFRUUgODAyLjE2IChjb21tZW50cyByZWNlaXZlZCB0b2RheSkgaGF2
ZSByZXZpZXdlZCBkcmFmdC16b3JuLXJhZGl1cy1wa212MS4gIA0KDQpDb21wbGV0ZWQgSUVURiBM
YXN0IENhbGwNCg0KOToxMCAtIDk6MjAgQU2gIFJBRElVUyBBdXRob3JpemF0aW9uIGZvciBOQVMg
TWFuYWdlbWVudCwgRGF2aWQgTmVsc29uICgxMCBtaW51dGVzKQ0KaHR0cDovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1yYWRleHQtbWFuYWdlbWVudC1hdXRob3JpemF0aW9uLTA2DQoN
CkRhdmlkIE5lbHNvbjogIElFVEYgbGFzdCBjYWxsIGNvbW1lbnRzIHJlY2VpdmVkLiANCjEgaXNz
dWUgd2FzIHRhbGtpbmcgYWJvdXQgdW5kZXJzdGFuZGluZyBvZiB0ZXh0LCBkaXNjdXNzaW9uIG9m
IFNOTVAgdnMuIFJBRElVUw0KdGVybWlub2xvZ3kuICBBbm90aGVyIGNvbW1lbnQgaW52b2x2ZWQg
ZWRpdG9yaWFsIG5pdHMgKG5vdGhpbmcgZWFydGggc2hha2luZyksDQphIHJlcXVlc3QgZm9yIGNo
YW5nZXMgdG8gdGhlIEFTQ0lJIGFydC4gIFR5cGljYWxseSBESU1FIFdHIHVzZXMgZG90cy9jb2xv
biwNClJBRElVUyBkb2NzIGRvbid0IHVzZSBhbnl0aGluZy4gIFRoZXJlIHdhcyBhIG1pc3Npbmcg
cmVmZXJlbmNlIGZvciBIVFRQUzsNCmEgcmVxdWVzdCB0aGF0IElBTkEgYWN0aW9ucyBhYm91dCBj
b2RlIHBvaW50cyB0byBiZSBhc3NpZ25lZCByZW1haW4gaW4NCnRoZSBwdWJsaXNoZWQgUkZDLiAg
TWlnaHQgbm90IGJlIG5lY2Vzc2FyeSB0byBrZWVwIHRob3NlIGluLiANClRoYXQncyBpdCAtLSBu
byB0ZWNobmljYWwgb3Igc3Vic3RhbnRpdmUgY29tbWVudHMgcmVjZWl2ZWQuIA0KDQpXRyBDaGFp
ciBpbnN0cnVjdGlvbiBpcyB0byBhZGRyZXNzIHRoZSBjb21tZW50cywgaXNzdWUgYW4gLTA3IHJl
dmlzaW9uLiANCg0KOToyMCAtIDk6MzAgQU0gUkFESVVTIERlc2lnbiBHdWlkZWxpbmVzLCBBbGFu
IERlS29rICgxMCBtaW51dGVzKQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1yYWRleHQtZGVzaWduLTA1DQoNCkFsYW4gRGVLb2s6ICBBIGZldyBjb21tZW50cyB3ZXJlIHJl
Y2VpdmVkIGluIElFVEYgbGFzdCBjYWxsLiAgVGhlc2UgV2lsbCBiZSANCmFkZHJlc3NlZCBpbiBu
ZXh0IHJldmlzaW9uLg0KDQpBcHBlbmRpeCBCIGxpc3RzIHRoZSBjb21wbGV4IGF0dHJpYnV0ZXMg
YW5kIHdoeSB0aGV5IGFyZSBnb29kL2JhZC4NCk1pZ2h0IGJlIGdvb2QgdG8gcHV0IGluIENhbGxl
ZC1TdGF0aW9uLUlkIHdoaWNoIGhhcyBTU0lEL01hYyBBZGRyZXNzLg0KDQpEYXZpZCBOZWxzb246
ICBSZW1lbWJlciB0aGF0IGRvY3VtZW50cyBpbiBJRVRGIGxhc3QgY2FsbCBhcmUgdW5kZXIgSUVT
Rw0KY2hhbmdlIGNvbnRyb2wuICBTbyB5b3UgbmVlZCBJRVNHIHBlcm1pc3Npb24gdG8gbWFrZSB0
aGlzIGNoYW5nZS4gIFBlcmhhcHMNCnlvdSBjb3VsZCBjb25zaWRlciBpdCBhbiBJRVRGIGxhc3Qg
Y2FsbCBjb21tZW50OyBob3dldmVyLCB5b3UgbmVlZCB0byB0YWxrDQp0byB0aGUgQUQgdG8gZ2V0
IHBlcm1pc3Npb24gdG8gbWFrZSB0aGUgY2hhbmdlLiANCg0KSW4gV0cgTGFzdCBDYWxsDQoNCjk6
MzAgQU0gLSA5OjQwIEFNIFN0YXR1cy1TZXJ2ZXIsIEFsYW4gRGVLb2sgKDEwIG1pbnV0ZXMpDQpo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1zdGF0dXMtc2VydmVy
LTAyDQoNCkFsYW4gRGVLb2s6IEEgZmV3IGNvbW1lbnRzIHJlY2VpdmVkIGluIFdHIGxhc3QgY2Fs
bCwgd2lsbCBiZSBmaXhlZCBpbiBuZXh0IA0KcmV2aXNpb24uICBPbmUgaXNzdWUgaXMgd2hldGhl
ciB0byBwZXJtaXQgYW4gQWNjZXNzLUFjY2VwdCBzZW50IGZyb20gYW4gDQphY2NvdW50aW5nIHBv
cnQuICANCg0KRGF2aWQgTmVsc29uOiAgVGhlIGNoYXJ0ZXIgb2YgdGhpcyB3b3JrIGl0ZW0gaXMg
dG8gZG9jdW1lbnQgZXhpc3RpbmcNCnByYWN0aWNlLCBub3QgdG8gZXh0ZW5kIHRoZSBwcm90b2Nv
bC4gIEkgZmxpbmNoIGF0IEFjY2Vzcy1BY2NlcHRzIGNvbWluZyANCmZyb20gQWNjb3VudGluZyBw
b3J0cy4gUkFESVVTIG1lZXRzIGl0c2VsZiBhdCB0aGUgZW5kIGFuZCBzbmFwcy4uLi4NCg0KQWxh
biBEZUtvazogUkZDIDI4NjUvNjYgZG9lc24ndCB0aWUgZG93biBvcmlnaW5hdGluZyBwb3J0cywg
b25seQ0KZGVzdGluYXRpb24gcG9ydHMuIA0KDQpCZXJuYXJkIEFib2JhOiAgU3RhdHVzLVNlcnZl
ciBoYXMgYmVlbiBhcm91bmQgc2luY2UgdGhlIG1pZC0xOTkwcywgd2hlbg0KaXQgd2FzIG9yaWdp
bmF0ZWQgYnkgQXNjZW5kIENvbW11bmljYXRpb25zLiAgU28gd2UgYXJlIGRvY3VtZW50aW5nDQpl
eGlzdGluZyBwcmFjdGljZS4gIEFncmVlIHRoYXQgUkZDIDI4NjUvNjYgZG9lc24ndCB0YWxrIGFi
b3V0DQpvcmlnaW5hdGluZyBwb3J0cywgc28gaXQncyBsZWdhbC4gIEJ1dCBkbyBleGlzdGluZyBp
bXBsZW1lbnRhdGlvbnMgZG8NCnRoaXM/ICBUaGVyZSBhcmUgbWFueSB0aGluZ3MgaW4gdGhpcyBk
b2N1bWVudCB0aGF0IHdlcmUganVkZ2VkDQpub25jb25mb3JtYW50L2luYXBwcm9wcmlhdGUgYXQg
dGhlIHRpbWUgKHdoaWNoIGlzIHdoeSBpdCB3YXMNCm5vdCBwdWJsaXNoZWQgYXMgYW4gUkZDKS4g
V2UgYXJlIGRvY3VtZW50aW5nIGl0IGJlY2F1c2UgaXQncw0Kd2lkZWx5IGltcGxlbWVudGVkLiAN
Cg0KRGF2aWQgTmVsc29uOiAgSXQgaXMgaGlzdG9yaWNhbC4uLiBidXQgbm90IGNyZWF0aW5nIGEg
cHJlY2VkZW50Lg0KDQpBbGFuIERlS29rOiAgVGhlIEFjY2Vzcy1BY2NlcHQgY2Fubm90IGNvbnRh
aW4gYXV0aG9yaXphdGlvbiBhdHRyaWJ1dGVzLg0KQ2xpZW50IHNlbmRzIGEgU3RhdHVzLVNlcnZl
ciAoYXBwbGljYXRpb24gbGF5ZXIgcGluZyksIHNlcnZlciByZXNwb25kcw0Kd2l0aCBhbiBBY2Nl
c3MtQWNjZXB0ICYgbm8gYXV0aG9yaXphdGlvbnMuDQpUQ1AgZHJhZnQgdXNlcyB0aGlzIGFzIHRo
ZSBhcHBsaWNhdGlvbiBsYXllciB3YXRjaGRvZy4NClN1Z2dlc3Rpb24gZnJvbSBHbGVuOiAgRXh0
ZW5kIFN0YXR1cy1TZXJ2ZXIgdG8gYSBDb0EgcG9ydC4uLiBmb3Igc2VydmVyDQp0byB0ZWxsIHRo
ZSBOQVMgdGhhdCB0aGV5J3JlIHVwIGFnYWluLg0KDQpkYXZlIG1pdHRvbjogIHNvbWUgb2YgdXMg
YXJlIHRyeWluZyB0byBmb3JnZXQgdGhlIEFzY2VuZCBkYXlzIQ0KIA0KQmVybmFyZCBBYm9iYTog
IERvIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhY3R1YWxseSBkbyB0aGlzPw0KQWxhbiBEZUtv
azogbWF5YmUgV0cgY29uc2Vuc3VzIGlzIHRvIHJlbW92ZSB0ZXh0IG9uIENvQS4gDQoNCjk6NDAg
QU0gLSA5OjUwIEFNIFJBRFNFQywgU3RlZmFuIFdpbnRlciAoMTAgbWludXRlcykNCmh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmFkZXh0LXJhZHNlYy0wMg0KDQpTdGVmYW4g
V2ludGVyOiAgTmV3IHZlcnNpb24gcHVibGlzaGVkLiAgVHdvIG9wZW4gaXNzdWVzICgyODEsIDI4
MikuIA0KV0cgbGFzdCBjYWxsIGxhc3RzIHVudGlsIDI1IG5vdmVtYmVyLiANCg0KT25lIHF1ZXN0
aW9uIGlzIHdoZXRoZXIgdG8gdXNlIFNSViBSUnMgKGFzIGluIFNJUCkgb3IgQS9BQUFBIFJScyAo
YXMgaW4gRElBTUVURVIpLiANClRoZXJlIGlzIGFsc28gYSBxdWVzdGlvbiBvbiBob3cgdG8gcmVn
aXN0ZXIgTkFQVFIgUlJzIHdpdGggSUFOQS4gICBUaGUgZHJhZnQNCmN1cnJlbnRseSBmb2xsb3dz
IFJGQyAzNTg4LCB3aGljaCBzYXlzIHRvIGRvIE5BUFRSIGxvb2t1cCwgaWYgdW5zdWNjZXNzZnVs
LA0KbG9vayB1cCBBL0FBQUEgUlJzIHdpdGhpbiAgX3JhZHNlYy5fdGNwLmRvbWFpbi4gDQoNClRo
aXMgbWF5IG5vdCBiZSBhbiBhcHByb3ByaWF0ZSB0aGluZyB0byBkby4gV2h5IG5vdCBqdXN0IHVz
ZSBTUlYgUlJzPyANCg0KQmVybmFyZCBBYm9iYTogIFRoZXJlIGFyZSBzb21lIGF2YW50YWdlcyB0
byB1c2luZyBTUlYgKGNhbiBzcGVjaWZ5IHBvcnRzLA0Kd2VpZ2h0aW5nKS4gIFdlIHRhbGtlZCBh
Ym91dCB0aGlzIG9uIHRoZSBsaXN0LiANCg0KU3RlZmFuOiAgRGlhbWV0ZXIgaXMgdGhlIG9ubHkg
b25lIHVzaW5nIEEvQUFBQSB3aXRoIE5BUFRSLiAgRXZlcnlvbmUgZWxzZQ0KKGUuZy4gU0lQKSB1
c2VzIFNSVi4gDQoNCkJlcm5hcmQgQWJvYmE6DQpTSVAgaGFzIHNlcGFyYXRlIGRvY3VtZW50IG9u
IGhvdyB0byBmaW5kIGEgc2VydmVyIChSRkMgMzI2MykuICANCkl0IG1pZ2h0IGJlIGEgZ29vZCB0
aGluZyB0byBzcGxpdCB0aGlzIG91dCBpbnRvIGEgc2VwYXJhdGUgZG9jdW1lbnQsIA0KcmF0aGVy
IHRoYW4gaW5jbHVkaW5nIGl0IGluIFJBRFNFQywgZXNwZWNpYWxseSBmb3IgaTE4biBpc3N1ZXMu
IA0KDQpTdGVmYW46IGRvY3VtZW50IGlzIHNpbGVudCBvbiBpMThuIGlzc3Vlcy4gIENvdWxkIHB1
dCBhbGdvcml0aG0gaW50byBhbm90aGVyIA0KZG9jdW1lbnQuIFJGQyAzMjYzIGlzIGFuIGV4YW1w
bGUgb2YgaG93IHRvIGRvIHRoaXMuIA0KDQpKb2U6IERvZXMgZGlhbWV0ZXIgaGF2ZSBhbnkgcmVj
b21tZW5kYXRpb24gaGVyZT8NCg0KQmVybmFyZDogeWVzLCBSRkMgMzU4OC4gQnV0IGRvZXMgYW55
b25lIGltcGxlbWVudCBpdD8gIChzaWxlbmNlKQ0KDQpTdGVmYW46IEhvdyBkbyBJIHJlZ2lzdGVy
IE5BUFRSIGNvbnN0cnVjdD8gSSBoYXZlIG5vIGNsdWUhIEFza2luZyBmb3IgaGVscC4uLg0KDQpC
ZXJuYXJkOiBBc2sgSGFubmVzLiAgSSB0aGluayBESU1FIFdHIGlzIGNvbnNpZGVyaW5nIGEgcmV2
aXNpb24gdG8gdXNlDQpTUlYgUlJzLCBpbnN0ZWFkIG9mIEEvQUFBQSBSUnMuIA0KDQpCZXJuYXJk
OiBMYXN0IGNhbGwgb24gdGhlIFJBRFNFQyBkb2N1bWVudCBnb2VzIHRvIE5vdmVtYmVyIDI1dGgu
ICBQbGVhc2UgcmVhZCBpdC4NCg0KQ29tcGxldGVkIFdHIExhc3QgQ2FsbA0KDQo5OjUwIEFNIC2g
MTA6MDAgQU0gRXh0ZW5kZWQgUkFESVVTIEF0dHJpYnV0ZXMsIEJlcm5hcmQgQWJvYmEgKDEwIG1p
bnV0ZXMpDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1leHRl
bmRlZC1hdHRyaWJ1dGVzLTA1DQoNCkJlcm5hcmQgQWJvYmE6ICBUaGUgRXh0ZW5kZWQgQXR0cmli
dXRlcyBkb2N1bWVudCBoYXMgY29tcGxldGVkIFJBREVYVCBXRw0KbGFzdCBjYWxsLiAgV2UgYXJl
IGN1cnJlbnRseSBpbiBpc3N1ZXMgcmVzb2x1dGlvbi4gIFNvbWUgaXNzdWVzIGFyZSANCmN1cnJl
bnRseSBpbiBkaXNwdXRlOyB3ZSBjdXJyZW50bHkgaGF2ZSA1IG9wZW4gaXNzdWVzLCBzb21lIG9w
ZW4gbW9yZQ0KdGhhbiBhIHllYXIuICBPdGhlciBXR3MgaGF2ZSBkZXBlbmRlbmNpZXMgb24gdGhp
cyBkb2N1bWVudCwgYnV0IGl0DQpkb2Vzbid0IHNlZW0gdG8gYmUgbW92aW5nIGZvcndhcmQuICBX
ZSBhcmUgaG9waW5nIHRoYXQgdGhlIGRpc2N1c3Npb24gDQp3aWxsIGNvbnZlcmdlLCBidXQgaXQg
aXMgaGFyZCB0byBkZXRlcm1pbmUgY29uc2Vuc3VzIGZyb20gYSBzbWFsbCBncm91cA0Kb2YgcGVv
cGxlIHNheWluZyAieWVzIiBhbmQgIm5vIi4gIFdlIGFyZSByZXF1ZXN0aW5nIHRoYXQgdGhlIFdH
IHJlYWQgaXQNCmFuZCBzZW5kIGNvbW1lbnRzL29waW5pb25zIG9uIHRoZSBvcGVuIGlzc3Vlcy4g
DQoNCk9wZW4gaXNzdWVzIGluY2x1ZGUgMjI1LCAyNTEsIDI3OCwgMjc5IGFuZCAyODcuICANCg0K
SXNzdWUgMjUwIHdhcyBjbG9zZWQgYnkgR3JlZyBXZWJlci4gDQpJc3N1ZSAyNzIgd2FzIHdpdGhk
cmF3biBieSBHbGVuLiANCg0KVGhlIGlzc3VlcyBzdGF0dXMgaGFzIGJlZW4gdXBkYXRlZCBvbiB0
aGUgUkFERVhUIFdHIElzc3VlcyB3ZWINCnBhZ2UgKGh0dHA6Ly93d3cuZHJpenpsZS5jb20vfmFi
b2JhL1JBREVYVCkuIA0KDQpTdGVmYW46IFRoZXJlIGlzIGFuIGlzc3VlIGFib3V0IHdoZW4geW91
IGFyZSBhbGxvd2VkIHRvIGZyYWdtZW50IGlmIHlvdSBoYXZlIGxlc3MNCnRoYW4gMjQ2IG9jdGV0
cy4uLiBubyBjb25zZW5zdXMgc28gZmFyLiANCg0KQWxhbiBEZUtvazogZG9pbmcgd2VpcmQgbGl0
dGxlIGZyYWdtZW50cyBpcyBhIGdyZWF0IHdheSB0byBicmVhayB0aGluZ3MNCkRhdmUgTmVsc29u
OiBpZiBpdCdzIGEgbWF0dGVyIG9mIGVmZmljaWVuY3ksIHRoZW4gaXQgd291bGQgYmUgYSBSRUNP
TU1FTkRFRA0Kb3IgU0hPVUxEIGJlaGF2aW9yLCB1bmxlc3MgaXQgYnJlYWtzIGludGVyb3BlcmFi
aWxpdHkuICBJdCBkb2Vzbid0IG5lZWQgdG8gYmUgDQphIE1VU1QuIA0KDQpCZXJuYXJkIEFib2Jh
OiBJIHRoaW5rIHRoZXJlIGlzIGFuIGlzc3VlIHdpdGggdGhlIERJQU1FVEVSIGNvbnNpZGVyYXRp
b25zIHNlY3Rpb24uIA0KU2luY2UgdGhlIFR5cGUtQ29kZSB3YXMgY2hhbmdlZCB0byB0d28gYnl0
ZXMsIEV4dGVuZGVkIEF0dHJpYnV0ZXMgZG9lc24ndA0KY29uZm9ybSB0byB0aGUgUkZDIDI4NjUg
cmVjb21tZW5kZWQgVlNBIGZvcm1hdCBhbnkgbW9yZS4gIFJGQyA0MDA1IGFzc3VtZXMNCnRoYXQg
VlNBcyBhcmUgaW4gdGhpcyBmb3JtYXQsIGZvciB0cmFuc2xhdGlvbiBmcm9tIFJBRElVUyB0byBE
aWFtZXRlci4gDQpTbyBhbiB1cGRhdGUgdG8gUkZDIDQwMDUgaXMgcHJvYmFibHkgcmVxdWlyZWQu
ICBXZSB3aWxsIG5lZWQgdG8gYnJpbmcNCmluIERJTUUgV0cgZm9sa3MgdG8gZGVhbCB3aXRoIHRo
aXMuICBBcyBSRkMgNDAwNSAgc3RhbmRzLCBhdHRyaWJ1dGUgMjYgaXMgDQpub3QgYWxsb3dlZCBp
biBEaWFtZXRlci4NCg0KRGF2ZSBOZWxzb246IERhdmUgbWl0dG9uIGhhZCBwcmVzZW50ZWQgc2xp
ZGVzIGFib3V0IGF0dHJpYnV0ZSAyNiBhbmQgRGlhbWV0ZXINCg0KQmVybmFyZDogWWVzLiAgU2Vl
Og0KaHR0cDovL3d3dy53YXRlcnNwcmluZ3Mub3JnL3B1Yi9pZC9kcmFmdC1taXR0b24tZGlhbWV0
ZXItcmFkaXVzLXZzYXMtMDEudHh0DQpIb3dldmVyLCBESU1FIGN1cnJlbnRseSBkb2Vzbid0IGhh
dmUgYSB3b3JrIGl0ZW0gZm9yIHJldmlzaW9uDQpvZiBSRkMgNDAwNS4gIEluIHJlc3BvbnNlIHRv
IElzc3VlIDI1MSwgR2xlbiBab3JuIGhhcyBjbGFpbWVkIHRoYXQgdGhlDQpleHRlbmRlZCBhdHRy
aWJ1dGVzIGNhbiBiZSB0cmFuc2xhdGVkIHRvIERpYW1ldGVyIHVzaW5nIHRoZSBSQURJVVMvRGlh
bWV0ZXINCmdhdGV3YXkgZGVmaW5lZCBpbiBSRkMgNDAwNS4gIFRoYXQgdXNlZCB0byBiZSB0aGUg
Y2FzZSwgYmVmb3JlIHRoZSBUeXBlDQpDb2RlIHdhcyBleHRlbmRlZCB0byB0d28gYnl0ZXMuICBC
dXQgaXQgaXNuJ3QgdGhlIGNhc2UgYW55IG1vcmUuIA0KDQpBbHNvLCB0aGVyZSBpcyBhbiBJQU5B
IGNvbnNpZGVyYXRpb25zIGlzc3VlLiAgQ2FuIHdlIGFsbG9jYXRlIGZyb20gdGhlDQpFeHRlbmRl
ZCBBdHRyaWJ1dGUgc3BhY2UgYmVmb3JlIHRoZSBzdGFuZGFyZCBSQURJVVMgYXR0cmlidXRlIHNw
YWNlIGlzDQpleGhhdXN0ZWQ/ICBTb21lIGRvY3VtZW50cyBhcmUgc3BlY2lmeWluZyB1c2Ugb2Yg
RXh0ZW5kZWQgQXR0cmlidXRlczsNCnNob3VsZCB0aGV5IGhhdmUgdG8gd2FpdCB1bnRpbCB0aGUg
c3RhbmRhcmQgYXR0cmlidXRlIHNwYWNlIGlzIGV4aGF1c3RlZA0KYmVmb3JlIHRoZXkgY2FuIGdl
dCBhbiBhbGxvY2F0aW9uPyBPciBjYW4gdGhleSByZXF1ZXN0IGFuIGFsbG9jYXRpb24NCmZyb20g
dGhlIEV4dGVuZGVkIHNwYWNlLCBhbmQgZ2V0IG9uZSByaWdodCBhd2F5PyANCg0KV2hhdCBhYm91
dCBkb2N1bWVudHMgdGhhdCBhcmUgc3BlY2lmeWluZyBzdGFuZGFyZCBSQURJVVMgYXR0cmlidXRl
cz8gDQpEbyB0aGV5IGF1dG9tYXRpY2FsbHkgZ2V0IGFuIGFsbG9jYXRpb24gZnJvbSB0aGUgRXh0
ZW5kZWQgUkFESVVTIGF0dHJpYnV0ZQ0Kc3BhY2Ugb25jZSB0aGUgc3RhbmRhcmQgYmFzZSBpcyBl
eGhhdXN0ZWQ/ICBPciBkbyB3ZSBuZWVkIHRvIGZpbmQgYSB3YXkgdG8NCmV4dGVuZCBhbGxvY2F0
aW9ucyBpbiB0aGUgc3RhbmRhcmQgUkFESVVTIGF0dHJpYnV0ZSBmb3JtYXQgYXMgd2VsbD8gDQog
DQpBbHNvLCB3ZSBoYXZlIGRvY3VtZW50cyB0aGF0IGFyZSByZXF1ZXN0aW5nIGEgbG90IG9mIGF0
dHJpYnV0ZXMgKDUrKS4gIA0KSUVTRyBoYXMgYXNrZWQgd2hldGhlciBESUFNRVRFUiBBVlBzIHNo
b3VsZCBiZSBhbGxvY2F0ZWQgd2l0aGluIHRoZQ0KUkFESVVTIGF0dHJpYnV0ZSBzcGFjZSAoTUlQ
djYsIERpYW1ldGVyIFFvUywgZXRjLikuICBUaGlzIGNvdWxkIHJlc3VsdA0KaW4gcmFwaWQgZXho
YXVzdGlvbiBvZiB0aGUgc3RhbmRhcmQgUkFESVVTIGF0dHJpYnV0ZSBzcGFjZS4gIFNob3VsZA0K
cmVxdWVzdHMgZm9yIGEgbG90IG9mIGF0dHJpYnV0ZSByZWNlaXZlIGF1dG9tYXRpYyBhbGxvY2F0
aW9ucyB3aXRoaW4NCnRoZSBleHRlbmRlZCBBdHRyaWJ1dGUgc3BhY2UsIHJhdGhlciB0aGFuIHRo
ZSBzdGFuZGFyZCBzcGFjZT8gIA0KDQpEYW4gUm9tYXNjYW51OiB3aGF0IGRvIHdlIGRvIGlmIHdl
IGhhdmUgYSByZXF1ZXN0IGZvciBhbGxvY2F0aW9uIG9mDQpFeHRlbmRlZCBBdHRyaWJ1dGVzPyAN
CkJlcm5hcmQ6IFNpbmNlIHRoZSBkcmFmdCBpc24ndCBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24g
YXMgYW4gUkZDLA0KSUFOQSBjYW5ub3QgbWFrZSB0aGUgYWxsb2NhdGlvbi4gDQpEYW4gUm9tYXNj
YW51OiAgVGhpcyBkcmFmdCBuZWVkcyB0byBiZSBwcm9ncmVzc2VkIGluIHN5bmMgd2l0aCBjaGFu
Z2VzDQp0byBEaWFtZXRlci4gDQpCZXJuYXJkOiBZZXMsIERJTUUgV0cgaGFzIHRvIGZpZ3VyZSBv
dXQgaG93IHRvIHRyYW5zbGF0ZSBSQURJVVMNCkV4dGVuZGVkIEF0dHJpYnV0ZXMuICBEYXZlIE1p
dHRvbidzIHByb3Bvc2FsIG1pZ2h0IGJlIG9uZSB3YXkgZm9yd2FyZC4gDQoNCkRhbiBSb21hc2Nh
bnU6ICBUaGlzIGlzIGFuIGFjdGlvbiBpdGVtIGZvciB0aGUgRElNRSBXRywgYW5kIHRleHQgbmVl
ZHMNCnRvIGJlIHB1dCBpbnRvIHRoZSBJQU5BIGFuZCBESUFNRVRFUiBjb25zaWRlcmF0aW9ucyBz
ZWN0aW9ucy4gIFRoaXMNCnRleHQgaXNuJ3QgaW4gdGhlIGRvY3VtZW50IG5vdywgIFBlb3BsZSBz
aG91ZGwgYmUgYWJsZSB0byBzaXQgZG93bg0KYXQgYSB0YWJsZSBmb3IgMS0yIGhvdXJzIGFuZCBn
ZXQgY29uc2Vuc3VzIG9uIHRoZXNlIGlzc3Vlcy4gDQoNCkJlcm5hcmQ7IG1pZ2h0IGJlIGdvb2Qg
dG8gc2hvdyB1cCBpbiBESU1FIFdHIGFuZCBkaXNjdXNzIHRoaXMuIA0KRGF2aWQgTmVsc29uOiAg
V2UgY2FuIGFsc28gdGFsayBhYm91dCB0aGlzIGF0IHRoZSBBQUEgRG9jdG9ycyBsdW5jaC4gDQpU
aGVyZSBhcmUgZnVuY3Rpb25hbCBlbmhhbmNlbWVudHMgYXMgd2VsbCBhcyBleGhhdXN0aW9uIGlz
c3Vlcy4gIEluIHRoZQ0KYWJzZW5jZSBvZiB0ZXh0LCBJQU5BIHNob3VsZCBhbGxvdyBhbGxvY2F0
aW9ucyBpbiB0aGUgZXh0ZW5kZWQgc3BhY2UNCnByaW9yIHRvIGV4aGF1c3Rpb24gb2YgdGhlIFJB
RElVUyBzdGFuZGFyZCBhdHRyaWJ1dGUgc3BhY2UsIG9uIHJlcXVlc3QuDQpQZW9wbGUgc2hvdWxk
bid0IG5lZWQgdG8gd2FpdCB1bnRpbCBzdGFuZGFyZCBzcGFjZSBpcyBleGhhdXN0ZWQuDQoNCmRh
dmVtOiAgQ2FuIEkgcmVzdXJlY3QgdGhlIGRyYWZ0IGlmIHRoZXJlIGlzIGludGVyZXN0Pw0KQmVy
bmFyZDogIEFzayB0aGUgRElNRSBXRy4gDQoNCjEwOjAwoEFNIC0gMTA6MTAgQU0gUkFESVVTIENy
eXB0b2FnaWxpdHkgUmVxdWlyZW1lbnRzLCBEYXZpZCBOZWxzb24gKDEwIG1pbnV0ZXMpDQpodHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1jcnlwdG8tYWdpbGl0eS1y
ZXF1aXJlbWVudHMtMDILDQoNCkRhdmlkIE5lbHNvbjogMiBvcGVuIGlzc3VlcyAoMjc0LCAyNzUp
LCBzb21lIGVkaXRvcmlhbCBpc3N1ZXMuICAtMDEgc3VibWl0dGVkIHRoaXMgd2Vlay4NCldlIGhh
dmUgaGFkIHNvbWUgZGlzY3Vzc2lvbiByZWxhdGluZyB0byBhdXRvbWF0ZWQga2V5IG1hbmFnZW1l
bnQ7IHRoZXJlIHdhcyBjb25zZW5zdXMNCnRoYXQgdGhpcyB3YXMgbm90IGEgcmVxdWlyZW1lbnQu
ICBUaGVyZSBpcyBhbHNvIGFuIGlzc3VlIHJlbGF0aW5nIHRvIGNpcGhlcnN1aXRlDQpuZWdvdGlh
dGlvbi4gIFJBRElVUyBkb2Vzbid0IHN1cHBvcnQgbmVnb3RpYXRpb24gaW4gZ2VuZXJhbC4gIFRo
ZSBiZXN0IHdlIGNhbiBkbw0KaXMgZm9yIHRoZSBOQVMgdG8gcHJvdmlkZSBhIGhpbnQsIGFuZCBm
b3IgdGhlIFJBRElVUyBzZXJ2ZXIgdG8gYWNjZXB0IG9yIHJlamVjdCB0aGUNCmhpbnQuICAgVGhl
IHF1ZXN0aW9uIGlzIGhvdyB0byBhdm9pZCBiaWRkaW5nIGRvd24gYXR0YWNrcy4gIA0KDQpCZXJu
YXJkIEFib2JhOiBXaGF0IGhhcHBlbnMgaWYgdGhlIE5BUyBvZmZlcnMgYW4gdXBncmFkZWQgY2lw
aGVyc3VpdGUsIGJ1dCB0aGUgcGFja2V0IA0KaXMgaW50ZWdyaXR5IHByb3RlY3RlZCBhbmQgYXV0
aGVudGljYXRlZCB1c2luZyBNRDU/ICBJZiB0aGUgTUQ1IHNlY3JldCBpcyByZWNvdmVyZWQgDQpi
eSBhbiBhdHRhY2tlciwgdGhlbiB0aGUgYXR0YWNrZXIgY2FuIGNyZWF0ZSBhIG5ldyBwYWNrZXQg
dGhhdCByZW1vdmVzIHRoZSB1cGdyYWRlZCANCmNpcGhlcnN1aXRlIG9mZmVyIGFuZCBhbnkgdXBn
cmFkZWQgc2VjdXJpdHkgc2VydmljZXMgKGludGVncml0eS9jb25maWRlbnRpYWxpdHkpLiAgDQpJ
ZiB0aGUgUkFESVVTIHNlcnZlciBpcyBjb25maWd1cmVkIHRvIHJlcXVpcmUgdXBncmFkZWQgc2Vj
dXJpdHksIHRoZW4gaXQgY2FuIA0KcmVqZWN0IHRoaXMgKHRhbXBlcmVkKSBBY2Nlc3MtUmVxdWVz
dC4gIEJ1dCBpZiBpdCBpcyBjb25maWd1cmVkIHRvIHN0aWxsIGFjY2VwdCANCk1ENSBzZWN1cml0
eSBhcyB3ZWxsIGFzIHVwZ3JhZGVkIGNpcGhlcnN1aXRlcywgdGhlbiBpdCB3aWxsIGJlIGZvb2xl
ZCBieSB0aGUgDQpiaWRkaW5nLWRvd24gYXR0YWNrLiAgDQoNCkpvZSBTYWxvd2V5OiAgSG93IGRv
ZXMgdGhlIFJBRElVUyBjbGllbnQga25vdyB3aHkgaXRzIGJlZW4gcmVqZWN0ZWQ/ICANCg0KQmVy
bmFyZCBBYm9iYTogSWYgaXQgaXMgcmVqZWN0ZWQgYmVjYXVzZSBvZiBhbiBpbmFwcHJvcHJpYXRl
IGNpcGhlcnN1aXRlIG9mZmVyLCB0aGVuIA0KbWF5YmUgaXQgY2FuIGZpZ3VyZSBvdXQgdGhhdCBz
b21ldGhpbmcgd2VudCB3cm9uZyAodW5sZXNzIHRoZSBhdHRhY2tlciBhbHNvIG1vZGlmaWVzIA0K
dGhlIGVycm9yIG1lc3NhZ2UgY29taW5nIGJhY2spLiAgTm90IGNsZWFyIHRoYXQgdGhlIFJBRElV
UyBFcnJvci1DYXVzZSBhdHRyaWJ1dGUgaXMgDQpzdWZmaWNpZW50IGZvciB0aGlzLi4uLiANCg0K
Sm9lIFNhbG93ZXk6IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIFJBRElVUyBBY2Nlc3MtUmVxdWVz
dCBpcyBub3QgcmVhbGx5IGEgaGludC4gIElmIA0KYSBwYXNzd29yZCBvciBrZXkgaXMgZW5jcnlw
dGVkIHdpdGggYSBuZXcgY2lwaGVyc3VpdGUsIHRoZW4gdGhlIHR3byBzaWRlcyBuZWVkIHRvIGFn
cmVlLiANCg0KRGF2aWQgTmVsc29uOiBXZSBjb3VsZCB1c2UgYW5vdGhlciByb3VuZCB0cmlwIGFz
IGNhbGwtY2hlY2suLg0KDQpCZXJuYXJkOiBXZSBkb24ndCBuZWVkIHRvIGRlc2lnbiBhIHNvbHV0
aW9uIGhlcmUuLi4gYnV0IHdlIGRvIG5lZWQgdG8gZmlndXJlIG91dCB0aGUNCnJlcXVpcmVtZW50
cy4NCg0KT25lIHJlcXVpcmVtZW50IGlzIHRvIGF2b2lkIGNhc2NhZGVkIGNvbXByb21pc2UuICBJ
ZiB0aGUgTUQ1IHNlY3JldCBpcyBjb21wcm9taXNlZCwNCmRvbid0IGFsc28gd2FudCB0byBjb21w
cm9taXNlIGtleXMgdXNlZCBmb3IgdGhlIHVwZ3JhZGVkIGNpcGhlcnN1aXRlcy4gIEZvcg0KZXhh
bXBsZSwgd2UgY2FuIHJlcXVpcmUgdGhhdCBrZXlzIHVzZWQgaW4gZW5oYW5jZWQgY2lwaGVyc3Vp
dGVzIGJlIGNyeXB0b2dyYXBoaWNhbGx5DQppbmRlcGVuZGVudCBvZiB0aGUgTUQ1IHNlY3JldC4g
IFNvIGlmIHRoZSBNRDUgc2VjcmV0IGlzIGNvbXByb21pc2VkLCB0aGVuIHRoaXMgZG9lc24ndA0K
YWxzbyBjb21wcm9taXNlIGVuaGFuY2VkIGNpcGhlcnN1aXRlcy4NCg0KSm9lIFNhbG93ZXk6ICBU
aGVyZSBoYXMgYmVlbiBsb3RzIG9mIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYWJvdXQgcmVxdWly
ZW1lbnRzLiAgV2UNCmRvbid0IHdhbnQgdG8gd3JpdGUgc3R1cGlkIHJlcXVpcmVtZW50cy4gDQoN
CkJlcm5hcmQgQWJvYmE6ICBUaGUgYmlnIHF1ZXN0aW9uIGlzIHdoYXQgdGhlIHRyYW5zaXRpb24g
bW9kZWwgaXMuICBEdXJpbmcgc29tZQ0KcGVyaW9kIHdlIHdpbGwgaGF2ZSBhIG1peHR1cmUgb2Yg
TUQ1IGFuZCB1Z3ByYWRlZCBjaXBoZXJzdWl0ZXMsIGF0IGxlYXN0IGJlZm9yZQ0KTUQ1IGNvbXBy
b21pc2Ugb2YgYSBzdHJvbmcgc2hhcmVkIHNlY3JldCBiZWNvbWVzIHByYWN0aWNhbC4gIE9uY2Ug
dGhhdCBoYXBwZW5zLA0Kd2UgY2FuIHRyeSB0byBsaW1pdCB0aGUgZGFtYWdlIChlLmcuIHZpYSBj
cnlwdG9ncmFwaGljIGluZGVwZW5kZW5jZSBvZiBrZXlzKSwNCmJ1dCB3aXRob3V0IHBvbGljeSAo
cmVxdWlyaW5nIHVwZ3JhZGVkIGNpcGhlcnN1aXRlcykgd2UgcHJvYmFibHkgY2Fubm90IHByZXZl
bnQNCmJpZGRpbmcgZG93biBhdHRhY2tzLiANCg0KTWF5YmUgd2Ugc2hvdWxkIGV4cGxpY2l0bHkg
ZGVzY3JpYmUgdGhlIHRyYW5zaXRpb24gc3RyYXRlZ3k6ICBkbyB5b3UgdXBncmFkZQ0KdGhlIFJB
RElVUyBzZXJ2ZXIgZmlyc3QsIHNvIGFzIHRvIHN1cHBvcnQgdGhlIG5ldyBmdW5jdGlvbmFsaXR5
IGFuZCB1cGdyYWRlZA0KY2lwaGVyc3VpdGVzPyAgVGhpcyBpcyB1c3VhbGx5IGVhc2llciB0aGFu
IHVwZ3JhZGluZyBsZWdhY3kgTkFTZXMuIA0KDQpBbHNvLCB3aGF0IHBvbGljeSBjb25maWd1cmF0
aW9ucyBkbyB3ZSBhc3N1bWUvcmVxdWlyZT8gIE1heWJlIGFuIHVwZ3JhZGVkDQpSQURJVVMgc2Vy
dmVyIGluaXRpYWxseSBhY2NlcHRzIE1ENSBhcyB3ZWxsIGFzIHVwZ3JhZGVkIGNpcGhlcnN1aXRl
cywgdGhlbg0KZXZlbnR1YWxseSByZXF1aXJlcyB1cGdyYWRlZCBjaXBoc2VydWl0ZXMgb25jZSBh
bGwgTkFTZXMgYXJlIHVwZ3JhZGVkLiAgDQpPciBtYXliZSB1cGdyYWRlZCBOQVNlcyBjYW4gYmUg
Y29uZmlndXJlZCB0byByZXF1aXJlIHRoYXQgdGhlIFJBRElVUyBzZXJ2ZXIgDQpzdXBwb3J0cyBj
cnlwdG8tYWdpbGl0eS4gIA0KDQpJbiB0aGF0IGNvbmZpZ3VyYXRpb24sIHRoZSBOQVMgd291bGQg
bm90IGFjY2VwdCBhIHJlc3BvbnNlIGZyb20gdGhlIFJBRElVUw0Kc2VydmVyIHByb3RlY3RlZCB3
aXRoIE1ENTsgaXQgYXNzdW1lcyB0aGF0IGl0IE1VU1Qgc3VwcG9ydCB1cGdyYWRlZA0KY2lwaGVy
c3VpdGVzLiAgUGVyaGFwcyB0aGUgTkFTIGNhbiBiZSBjb25maWd1cmVkIG5vdCB0byB1c2UgTUQ1
IGF0IGFsbCwgDQpqdXN0IGFuIHVwZ3JhZGVkIGNpcGhlcnN1aXRlLiAgSWYgdGhlIFJBRElVUyBz
ZXJ2ZXIgb25seSBzdXBwb3J0cyBNRDUsDQp0aGVuIHRoZSBSQURJVVMgc2VydmVyIHdpbGwgc2ls
ZW50bHkgZGlzY2FyZCB0aGUgcGFja2V0ICh1bmxlc3MgYW4gYXR0YWNrZXINCmFscmVhZHkga25v
d3MgdGhlIE1ENSBzZWNyZXQgYW5kIGNhbiBmb3JnZSBpbnRlZ3JpdHkvYXV0aGVudGljYXRpb24p
LiAgDQoNCkRhdmlkIE5lbHNvbjogIENyeXB0by1hZ2lsaXR5IHNvbHV0aW9ucyBjYW4ndCBkZXBl
bmQgb24gaW50cm9kdWN0aW9uIG9mDQpuZXcgbmVnb3RpYXRpb24gY2FwYWJpbGl0aWVzIGludG8g
UkFESVVTLiAgV2UgYXJlIGxvb2tpbmcgZm9yIGZlZWRiYWNrDQpvbiB0aGlzIChlaXRoZXIgaW4g
dGhlIHJvb20sIG9yIG9uIHRoZSBsaXN0KS4gDQoNCkpvZTogYmFjayB0byBpc3N1ZXMgc2xpZGUN
CkRhdmlkIE5lbHNvbjogc2xpZGVzIHdlcmUgcHJvcG9zYWw7IGxldCdzIHNlZSBpZiBpdCdzIHJl
YXNvbmFibGUNCkpvZTogc2VlbXMgcmVhc29uYWJsZSwgc2VlbXMgdG8gYmUgcmlnaHQgZGlyZWN0
aW9uDQoNCkluZGl2aWR1YWwgU3VibWlzc2lvbnMNCg0KMTA6MTAgQU0gLSAxMDoyMCBBTSBUQ1Ag
VHJhbnNwb3J0LCBBbGFuIERlS29rICgxMCBtaW51dGVzKQ0KaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtZGVrb2stcmFkZXh0LXRjcC10cmFuc3BvcnQtMDANCg0KR29hbCBpcyB0byB0
YWtlIFRDUC1zcGVjaWZpYyBpc3N1ZXMgaW4gUkFEU0VDIGRyYWZ0IHRoYXQgd2VyZQ0KaW5kZXBl
bmRlbnQgb2YgVExTIGlzc3VlcyBhbmQgaGFuZGxlIHRoZW0gc2VwYXJhdGVseS4gIFRoZQ0KZ29h
bCBpcyB0byBkZXNjcmliZSBob3cgdG8gdHJhbnNwb3J0IFJBRElVUyBvdmVyIFRDUC4gIFRoZQ0K
UkFESVVTIHByb3RvY29sIGlzbid0IGNoYW5nZWQ7IHRoaXMgc2hvdWxkIHNpbXBsaWZ5IGltcGxl
bWVudGF0aW9ucy4NCg0KVGhlcmUgYXJlIHNvbWUgVENQLXNwZWNpZmljIGlzc3Vlcy4gDQpPbmNl
IHRoZSB0aHJlZS13YXkgaGFuZHNoYWtlIGlzIHNldCB1cCwgeW91IGRvbid0IGhhdmUgdG8gdmFs
aWRhdGUNCnRoZSBJUCBhZGRyZXNzIG9uIGVhY2ggbWVzc2FnZS4gIA0KDQpUaGUgVENQIGNvbm5l
Y3Rpb24gaGFzIHRvIGJlIHJlc2V0IGFmdGVyIHJlY2VpdmluZyBhIG1hbGZvcm1lZCBwYWNrZXQu
IA0KDQpNYWdudXMgV2VzdGVybHVuZDogIEl0IGRlcGVuZHMgb24gaG93IHlvdSBzdHJ1Y3R1cmUg
dGhlIHByb3RvY29sLiAgSWYNCnlvdSB3b3VsZCBwcm92aWRlIGZyYW1pbmcgYXJvdW5kIGl0LCBu
b3QgcmF3IFJBRElVUywgdGhlbiBwZXJoYXBzDQp5b3UgY291bGQgcmVjb3ZlciBmcm9tIGEgbWFs
Zm9ybWVkIHBhY2tldC4NCg0KQWxhbiBEZUtvazogTm8gZnJhbWluZy4uLiBqdXN0IHJhdyBSQURJ
VVMuIFNvIGlmIHRoZSBwYWNrZXQgaXMgbWFsZm9ybWVkLCANCnRoZXJlIGlzIG5vIHdheSB0byBy
ZS1zeW5jLiANCg0KTWFnbnVzOiAgSSB1bmRlcnN0YW5kLi4NCg0KQWxhbjogIEFsc28sIGlmIHlv
dSBoYXZlIGF0dHJpYnV0ZXMgd2l0aCBsZW5ndGggb2YgMCBvciAxLCB5b3UgcmVzZXQgdGhlIFRD
UA0KY29ubmVjdGlvbi4NCg0KVGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggSWRlbnRpZmllcnMuICBU
aGUgSWRlbnRpZmllciBzcGFjZSBpcyBvbmx5IDggYml0cywNCnNvIHlvdSBjYW4gb25seSBoYXZl
IDI1NiBJRHMuLi4gc28gb25seSAyNTYgbWVzc2FnZXMgY2FuIGJlIGluIGZsaWdodCBmb3INCmEg
c2luZ2xlIE9wIENvZGUuICAgUkFEU0VDIHNlbmRzIGJvdGggYWNjb3VudGluZyBhbmQgYXV0aGVu
dGljYXRpb24gcGFja2V0cyANCm92ZXIgb25lIFRDUCBjb25uZWN0aW9uLg0KDQpNYWdudXM6ICBJ
cyBpdCBvdXRzdGFuZGluZyByZXF1ZXN0cyBvciBwYWNrZXRzIGluIGZsaWdodD8NCkFsYW46ICBP
dXRzdGFuZGluZyByZXF1ZXN0cy4NCk1hZ251czogIFRoaXMgd2lsbCBpbnRlcmFjdCBiYWRseSB3
aXRoIFRDUCBjb25uZWN0aW9uIHN0YXRlLi4uLiB3b24ndCBrZWVwDQplbm91Z2ggdHJhZmZpYyBp
biBmbG93LiAgT3BlbmluZyBhbm90aGVyIGNvbm5lY3Rpb24gd2lsbCBhbHNvIGJlIHByb2JsZW1h
dGljDQp3aXRoIHJlc3BlY3QgdG8gY29uZ2VzdGlvbi4gDQoNCkJlcm5hcmQgQWJvYmE6ICBZb3Ug
ZG9uJ3Qgd2FudCB0byBoYXZlIGxvdHMgb2YgY29ubmVjdGlvbnMgb3BlbiwgYWxsIGluDQpzbG93
IHN0YXJ0LCByYW1waW5nIHVwIHJhcGlkbHkuLi4uDQoNCkJlcm5hcmQgQWJvYmE6IEFyZSB3ZSB0
cnlpbmcgdG8gZW5hYmxlIFJBRElVUyBvdmVyIFRDUCB3aXRob3V0IFJBRFNFQz8NCg0KTWFnbnVz
IFdlc3Rlcmx1bmQ6ICBJdCBzZWVtcyBnZW5lcmljLiBTQ1RQIG1pZ2h0IGJlIGEgYmV0dGVyIGZp
dC4NCkFsc28sIHRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzZWVtcyB0byBiZSBhIGJpdCBv
ZmYuICAgTXkNCmltcHJlc3Npb24gaXMgdGhhdCBzZW5kaW5nIGxlc3MgdGhhbiBvbmUgcGFja2V0
IHBlciBSVFQgZG9lc24ndCBkaXNxdWFsaWZ5DQpUQ1AuIFdoYXQgaXMgdGhlIGFwcGxpY2FiaWxp
dHkgYW5kIHdoYXQgZG8geW91IHdhbnQgdG8gZ2FpbiBoZXJlPw0KDQpEYXZpZCBOZWxzb246ICBU
aGVyZSBpcyBXRyBjb25zZW5zdXMsIGFuZCB0aGVyZSBpcyB3aGF0IG1ha2VzIHNlbnNlLg0KV2Ug
aGFkIFdHIGNvbnNlbnN1cyB0byBzZXBhcmF0ZSB0aGUgZG9jdW1lbnQsIHNvIGl0IGNvdWxkIGJl
IHVzZWQNCmZvciB0aGluZ3Mgb3RoZXIgdGhhbiBSQURTRUMuICBXZSBtYXkgbmVlZCB0byByZXZp
c2l0IHRoaXMgaWYgd2UgZGV0ZXJtaW5lDQp0aGF0IHRoaXMgd2FzIGEgYmFkIGlkZWEuDQoNCkFs
YW4gRGVLb2s6ICBUaGUgZG9jdW1lbnQgaXMgcmVsYXRpdmVseSBzaWxlbnQgb24gdGhpcyByaWdo
dCBub3cuDQoNCkFsYW46ICBUaGUgaXNzdWUgb2YgMjU2IElEcyBpbnRlcmFjdHMgd2l0aCB0aGUg
d2F0Y2hkb2cgdGltZXIuICANClRoZXJlIG5lZWRzIHRvIGJlIGEgd2F5IHRvIGRpc3Rpbmd1aXNo
IEFjY2Vzcy1BY2NlcHRzIHNlbnQgaW4NCnJlc3BvbnNlIHRvIGEgU3RhdHVzLVNlcnZlciBmcm9t
IEFjY2Vzcy1SZXF1ZXN0cyBzZW50IGluIHJlc3BvbnNlIHRvDQphbiBBY2Nlc3NzLVJlcXVlc3Qu
ICBPdGhlcndpc2UsIHRoZSBSQURTRUMgY2xpZW50IGNhbiBoYXZlIDI1Ng0Kb3V0c3RhbmRpbmcg
cmVxdWVzdHMsIHVzaW5nIHVwIGFsbCB0aGUgSUQgc3BhY2UuICBOb3cgeW91IHRyeSB0bw0Kc2Vu
ZCBhIFN0YXR1cy1TZXJ2ZXIgcGFja2V0LCBidXQgeW91IGNhbid0IGJlY2F1c2UgdGhlcmUgYXJl
IG5vDQpmcmVlIElEcyB5ZXQuICBOb2JvZHkgbGlrZXMgdGhpcyBpZGVhLiAgSWYgYW55b25lIGhh
cyBhIGJldHRlcg0Kc3VnZ2VzdGlvbj8NCg0KV0c6IENvbGxlY3RpdmUgZ3JvYW4uIA0KDQpBbGFu
OiAgVGhpcyBpcyBSQURJVVMuICBJdCBpcyBkaXNndXN0aW5nLg0KQmVybmFyZDogIFRoaXMgaXMg
YmV5b25kIGRpc2d1c3RpbmcuLi4gaXQncyBiYWRseSBicm9rZW4uDQpEYXZpZCBOZWxzb246ICBX
ZSBuZWVkIHRvIGF2b2lkIHRoaXMuLi4uDQpCZXJuYXJkOiAgV2Ugc2hvdWxkIG9wZW4gYW4gaXNz
dWUgb24gdGhpcy4uLg0KDQpBbGFuIERlS29rOiAgQW5vdGhlciBpc3N1ZSB0aGF0IGhhcyBhcmlz
ZW4gaXMgd2l0aCByZXNwZWN0IHRvIFNOTVAgTUlCcy4gDQpTaG91bGQgUkFEU0VDIGltcGxlbWVu
dGF0aW9ucyB1c2UgdGhlIGV4aXN0aW5nIFJBRElVUyBjbGllbnQvc2VydmVyIE1JQnM/IA0KRGFu
IFJvbWFzY2FudTogIFdlIG1pZ2h0IHdhbnQgdG8gc2VwYXJhdGUgVURQL1RDUCBjb3VudGVycy4u
LiBjb3VsZCBkbyB0aGlzIGluIG5leHQgTUlCIHJldmlzaW9uLg0KSW4gdGhlIHN0YW5kYXJkIE1J
Qi4uLiB0aGVyZSBpcyBvbmx5IGdsb2JhbCBjb3VudGVycy4NCg0KTWFnbnVzIFdlc3Rlcmx1bmQ6
ICBUaGVyZSBpcyBhbiBpc3N1ZSBoZXJlIHdoZW4geW91IGFyZSB1c2luZyBUQ1AgZm9yIG9uZSBs
ZWcgYW5kDQphbm90aGVyIGxlZyBpcyB1c2luZyBVRFAuICBUaGlzIGNvdWxkIGNhdXNlIHRyYW5z
cG9ydCBwcm9ibGVtcy4gDQoNCkJlcm5hcmQgQWJvYmE6ICBUaGlzIGlzIGFuIGlzc3VlIGV2ZW4g
aWYgVENQIGlzIGJlaW5nIHVzZWQgZm9yIGJvdGggbGVncy4gIFRvZGF5J3MNClJBRElVUyBwcm94
aWVzIGZvcndhcmQgVURQIHBhY2tldHMgd2l0aG91dCBzZW5kaW5nIGFuIGFja25vd2xlZGdlbWVu
dCwgc28gdGhhdCB0aGUNCnRyYW5zcG9ydCBkeW5hbWljcyAoUlRULCBmcmFtZSBsb3NzKSBhcmUg
ZWZmZWN0aXZlbHkgZW5kLXRvLWVuZC4gIFRoaXMgaXNuJ3QNCnRydWUgYW55bW9yZSB3aGVuIHRo
ZXJlIGlzIGV2ZW4gb25lIFRDUCBsZWcgaW4gdGhlIHBhdGguICBSRkMgMzUzOSB0YWxrcyBhYm91
dA0KdGhpcy4gVHdvIGNvbnRyb2wgbG9vcHMgYXJlIGFsd2F5cyBsZXNzIHN0YWJsZSB0aGFuIG9u
ZS4gDQoNCkJlcm5hcmQ6IFdlIHNob3VsZCBvcGVuIGFuIGlzc3VlIG9uIHRoaXMgYXMgd2VsbC4g
DQpBbGFuIERlS29rOiAgQSBsb3Qgb2YgdHJhbnNwb3J0IGFyZWEgcmV2aWV3IG5lZWRzIHRvIGJl
IGRvbmUuIA0KQmVybmFyZDogV2Ugd2lsbCBhc2sgdGhlIFRyYW5zcG9ydCBEaXJlY3RvcmF0ZSBm
b3IgYXNzaWdubWVudCBvZiBhbiBhZHZpc29yLiANCg0KDQoxMDoyMCBBTSAtIDEwOjI1IEFNIE5l
dyBUdW5uZWwtVHlwZSBWYWx1ZXMsIEFiaGlzaGVrIFRpd2FyaSAoNSBtaW51dGVzKQ0KaHR0cDov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGl3YXJpLXJhZGV4dC10dW5uZWwtdHlwZS0wMg0K
DQpEYXZpZCBOZWxzb246IElzIHRoZXJlIGFueSBvYmplY3Rpb24gaW4gdGhlIHJvb20gdG8gc3Rh
cnRpbmcgV0cgbGFzdCBjYWxsIG9uDQp0dW5uZWwtdHlwZSB2YWx1ZSBkcmFmdD8NClJvb206IE5v
bmUuIA0KRGF2aWQgTmVsc29uOiAgSSB3aWxsIHN0YXJ0IHRoZSBXRyBsYXN0IGNhbGwuIA0KDQox
MDoyNSBBTSAtIDEwOjMwIEFNIFJBRElVUyBBdHRyaWJ1dGVzIGZvciBJRUVFIDgwMiBOZXR3b3Jr
cywgQmVybmFyZCBBYm9iYSAoNSBtaW51dGVzKQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtYWJvYmEtcmFkZXh0LXdsYW4tMDkNCg0KQmVybmFyZCBBYm9iYTogIFRoaXMgZHJhZnQg
Y29udGFpbnMgYXR0cmlidXRlcyBmb3IgSUVFRSA4MDIuMTFpLCAxMXIsIDExcyBhcyB3ZWxsIGFz
DQpJRUVFIDgwMi4xWC1SRVYuICBJRUVFIDgwMi4xWC1SRVYgaGFzIGJlZW4gZXZvbHZpbmcuICBJ
RUVFIDgwMi4xWC0yMDA0IGluY2x1ZGVkIHRleHQNCmZyb20gd2hhdCB3YXMgZXZlbnR1YWxseSBw
dWJsaXNoZWQgYXMgUkZDIDM1ODAuICBUaGF0IHRleHQgaGFzIG5vdyBiZWVuIHJlbW92ZWQgaW4g
DQpmYXZvciBvZiBhIHJlZmVyZW5jZSB0byBSRkMgMzU4MC4gIElFRUUgODAyLjFYLVJFViBEMi45
IG5vdyByZWZlcmVuY2VzIHRoaXMgZHJhZnQNCmluIEFwcGVuZGl4IEUuICANCg0KVGhlIC0wOSBk
cmFmdCBjb250YWlucyAyIGF0dHJpYnV0ZXMgdG8gc3VwcG9ydCBJRUVFIDgwMi4xWC1SRVY6ICBO
ZXR3b3JrLUlELU5hbWUgYW5kDQpBY2Nlc3MtU3RhdHVzLiAgTmV0d29yay1JRC1OYW1lIGNhbiBi
ZSB1cCB0byAyNTMgb2N0ZXRzLCBzbyBpdCBpcyBzbWFsbGVyIHRoYW4gdGhlDQpTU0lEICgzMiBv
Y3RldHMpIGFuZCB3b3VsZG4ndCBuZWNlc3NhcmlseSBmaXQgd2l0aGluIGEgQ2FsbGVkLVN0YXRp
b24tSWQgYXR0cmlidXRlLA0Kc28gaXQgaGFzIHRvIGJlIHNlcGFyYXRlLiAgDQoNClRoZSBjdXJy
ZW50IGRyYWZ0IGluY2x1ZGVzIGZ1bmN0aW9uYWxpdHkgZm9yIElFRUUgODAyLjExcyAoTWVzaCBL
ZXkgRGlzdHJpYnV0b3JzKSwgYnV0DQoxMXMgc3RhdHVzIGlzIHVuY2VydGFpbi4gIFRoZSBFVEEg
b2YgMTFzIGhhcyBzbGlwcGVkOyAgdGhlcmUgaXMgY3VycmVudGx5IG5vIGVkaXRvcg0KZm9yIHRo
ZSBkb2N1bWVudDsgIHRoZXJlIHdhcyBhIHN1Z2dlc3Rpb24gYXQgdGhlIGxhc3QgSUVFRSA4MDIg
cGxlbmFyeSB0aGF0IHRoZQ0KZ3JvdXAgYmUgZGlzc29sdmVkLiAgDQoNClNpbmNlIElFRUUgODAy
LjFYLVJFViBoYXMgYSBkZXBlbmRlbmN5IG9uIHRoaXMgZG9jdW1lbnQsIGFuZCBpdCBoYXMgYW4g
RVRBIG9mIA0KMjAwOSAod2FzIERlY2VtYmVyIDIwMDgsIGJ1dCBpdCBzbGlwcGVkKSwgZGVwZW5k
aW5nIG9uIElFRUUgODAyLjExcyBmdW5jdGlvbmFsaXR5DQp0aGF0IGlzbid0IHNvbGlkIHByb2Jh
Ymx5IGlzbid0IGEgZ29vZCBpZGVhLiAgDQoNCk5leHQgc3RlcHMgYXJlIHRvIHN5bmMgdGhlIGRy
YWZ0IHdpdGggdGhlIG5leHQgcmV2aXNpb24gb2YgSUVFRSA4MDIuMVgtUkVWLCBhbmQNCmFsc28g
dG8gcmVtb3ZlIG1hdGVyaWFsIHJlbGF0aW5nIHRvIDExcy4gIEF0IHRoYXQgcG9pbnQsIHdlIHdp
bGwgcmVxdWVzdCB3aWRlcg0KcmV2aWV3IGFuZCBhZG9wdGlvbiBhcyBhIFJBREVYVCBXRyB3b3Jr
IGl0ZW0uICANCg0KMTA6MzAgQU0gLSAxMDo0MCBBTSAsIFRyYW5zbWl0dGluZyBDb25maWRlbnRp
YWwgRGF0YSBpbiBSQURJVVMsIEpvZSBTYWxvd2V5ICgxMCBtaW51dGVzKQ0KaHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtem9ybi1yYWRpdXMtZW5jYXR0ci0xNQ0KDQpKb2U6IFF1aWNr
IHVwZGF0ZSBvbiB0aGUgZW5jcnlwdGVkIGF0dHJpYnV0ZXMgZHJhZnQuDQpJbiB0aGUgbGF0ZXN0
IGRyYWZ0LCB3ZSBtZXJnZWQgbXVsdGlwbGUgYXR0cmlidXRlcyBpbnRvIDEgZm9yIHdyYXBwZXIg
dG8gZW5jcnlwdCBkYXRhLiAgVGhpcw0KbWF5IGJlIGtleXMgb3Igb3RoZXIgZGF0YS4gDQoNCkFs
YW4gRGVLb2s6ICJDb21zaWRlcmF0aW9ucyIgPyAgVmVyeSB0ZWxjby1jZW50cmljLg0KIA0KSm9l
OiAgSXMgdGhpcyBkb2N1bWVudCByZWFkeSBmb3IgYWRvcHRpb24gYXMgV0cgaXRlbT8NCkRhdmlk
IE5lbHNvbjogIFdlIGFyZSBjdXJyZW50bHkgZGlzY3Vzc2luZyBjcnlwdG8tYWdpbGl0eSByZXF1
aXJlbWVudHMuICBBcmUgdGhlcmUNCmFkZGl0aW9uYWwgV0cgd29yayBpdGVtcyB0aGF0IHRoaXMg
ZG9jdW1lbnQgZGVwZW5kcyBvbj8gDQpKb2UgU2Fsb3dleTogd291bGQgbmVlZCB0byBiZSBzb21l
IHN1cHBvcnRpbmcgdGhpbmdzIGFyb3VuZCBuZWdvdGlhdGlvbi4NCk1heSBiZSBzb21lIGtpbmQg
b2YgZXJyb3IgaW5kaWNhdGlvbi4gDQpEYXZlIE5lbHNvbjogd291bGQgYmUgbmljZSB0byBrZWVw
IHJlcXVpcmVtZW50cyAmJiBzb2x1dGlvbiBkb2N1bWVudHMgaW4gc3luYw0KQmVybmFyZDogS2Vl
cCBpbiBtaW5kIHRoYXQgdGhpcyBkb2N1bWVudCBuZWdvdGlhdGVzIGEgYnVuY2ggb2YNCmRpZmZl
cmVudCB0aGluZ3MuICBXZSB3YW50IHRvIGJlIGFibGUgdG8gYXZvaWQgYmlkZGluZyBkb3duIGF0
dGFja3MsDQplaXRoZXIgdmlhIGNyeXB0b2dyYXBoaWMgb3IgcG9saWN5IG1lYXN1cmVzLiANCkpv
ZTogRXZlcnkgUkFESVVTIHJlc3BvbnNlIG5vdyBoYXMgY3J5cHRvIGltcGxpZWQuICAgTWFueSBy
ZXF1ZXN0cyBkbywgdG9vLg0KQmVybmFyZDogc2F5IE1ENSBnZXRzIGNyYWNrZWQgdG9tb3Jyb3cu
Li4gdGhhdCB3b3VsZG4ndCBhbGxvdyB0aGUgYXR0YWNrZXINCnRvIHJlY292ZXIgZW5jcnlwdGlv
biBrZXlzIG9yIHBhc3N3b3JkcywgcmlnaHQ/IA0KSm9lOiBXZSBtaWdodCBzYXkgdGhhdCBwYXNz
d29yZHMgc2hvdWxkIGJlIGVuY3J5cHRlZCB3aXRoIEFFUyByYXRoZXIgdGhhbiBNRDUuDQpEYXZl
OiBJdCBpcyBpbXBsaWNpdCBpbiBjcnlwdG8gYWdpbGl0eSB0aGF0IGFsbCBhbGdvcml0aG1zIHdp
bGwgc29tZWRheSBmYWlsLg0KV2UgY2FuJ3QgYXNzdW1lIHRoYXQgdGhlcmUncyBubyBiaWRkaW5n
IGRvd24gYXR0YWNrLg0KQmVybmFyZDogaWYgd2UgYXNzdW1lIHRoYXQgeW91IHdvdWxkbid0IGJl
IGRvaW5nIGVuY3J5cHRpb24gd2l0aCBhbiBlbmhhbmNlZA0KY2lwaGVyc3V0aWUgd2l0aG91dCBh
IHN0cm9uZ2VyIGhhc2ggYXMgd2VsbCwgd2UnZCBiZSBiZXR0ZXIgdGhhbiB3aGVyZSB3ZSBhcmUg
bm93Lg0KV2hlbiBNRDUgZ2V0cyBjcmFja2VkLCB5b3UgbG9zZSBib3RoIGVuY3J5cHRpb24gYW5k
IGludGVncml0eSBvZiBSQURJVVMgYXMNCml0IGN1cnJlbnRseSBleGlzdHMuIE9uY2UgdGhhdCBo
YXBwZW5zLCB0aGUgdHJhbnNpdGlvbiBiZWNvbWVzIGEgbG90IHRvdWdoZXIsDQpiZWNhdXNlIHlv
dSBuZWVkIGEgImZsYWcgZGF5Ii4gIA0KDQpPbmNlIHRoaXMgZG9jdW1lbnQgaXMgaW1wbGVtZW50
ZWQsIHdlIHdpbGwgaGF2ZSBjcnlwdG8tZ3JhcGhpYyBuZWdvdGlhdGlvbg0KaW4gcGxhY2U7ICBh
c3N1bWluZyB0aGF0IHRoZSBhbGdvcml0aG0gcHJvdGVjdGluZyB0aGUgbmVnb3RpYXRpb24gaXRz
ZWxmIGlzDQpub3QgY29tcHJvbWlzZWQsIHRoZW4gd2Ugd2lsbCBiZSBhYmxlIHRvIHNlY3VyZWx5
IG5lZ290aWF0ZSBuZXcgY2lwaGVyc3VpdGVzDQppZiBhbiBleGlzdGluZyBvbmUgaXMgY29tcHJv
bWlzZWQuIA0KDQpEYXZpZCBOZWxzb246IGlmIHdlJ3JlIHRhbGtpbmcgYWJvdXQgYSB0cmFuc2l0
aW9uIHN0cmF0ZWd5IGZyb20gUkFESVVTIHRvDQp0aGlzIG5ldyBhcHByb2FjaCwgbmVnb3RpYXRp
b25zIGNhbiBvbmx5IGJlIHByb3RlY3RlZCB3aXRoIGNsYXNzaWMgUkFESVVTLiANCg0KQmVybmFy
ZDogSW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgdGhlIFJBRElVUyBwcm94eS9zZXJ2ZXIgb25seSBz
dXBwb3J0cyBNRDUsIA0KeWVzLiBJbiB0aGF0IHNpdHVhdGlvbiwgSSBkb24ndCBiZWxpZXZlIHdl
IGNhbiBhdm9pZCBhIGJpZGRpbmcgZG93biBhdHRhY2ssDQpidXQgd2UgY2FuIGF2b2lkIGNvbXBy
b21pc2Ugb2Yga2V5cyB1c2VkIHRvIHByb3RlY3QgdGhlIGVuaGFuY2VkIGNpcGhlcnN1aXRlLA0K
Ynkga2VlcGluZyB0aGVtIGNyeXB0b2dyYXBoaWNhbGx5IHNlcGFyYXRlIGZyb20gdGhlIE1ENSBz
ZWNyZXQuIA0KDQpIb3dldmVyLCBpZiB0aGUgUkFESVVTIHByb3h5L3NlcnZlciBzdXBwb3J0cyB0
aGlzIGRvY3VtZW50LCB0aGVuIGEgTkFTDQpjYW4gYmUgY29uZmlndXJlZCB0byByZXF1aXJlIHN1
cHBvcnQgZm9yIGVuaGFuY2VkIGNpcGhlcnN1aXRlcywgYW5kIGF2b2lkIA0KdXNlIG9mIE1ENS4g
DQoNClNvIG92ZXJhbGwsIHdlIG5lZWQgdG8gZGVzY3JpYmUgdGhlIG1pZ3JhdGlvbiBzdHJhdGVn
eS4gDQoNCkpvZTogSWYgd2UgY2FuIGdldCB0aGlzIGRvY3VtZW50IGRlcGxveWVkLCB0aGVuIHRo
aXMgc29sdmVzIGEgbG90IG9mIHByb2JsZW1zLiANCkJlcm5hcmQ6IFRoZSBkb2N1bWVudCBzaG91
bGQgdGFsayBtb3JlIGFib3V0IHRoZSBtaWdyYXRpb24gc3RyYXRlZ3kgKGUuZy4gd2hhdA0KaXMg
dXBncmFkZWQgZmlyc3QsIGhvdyB0byBhdm9pZCBiaWRkaW5nIGRvd24gdmlhIHBvbGljeSwgIGhv
dyB0byBkZWFsIHdpdGgNCmNvbXByb21pc2Ugb2YgTUQ1IGFuZCBvdGhlciBhbGdvcml0aG1zLCBl
dGMuKS4gDQoNCkludGVybmF0aW9uYWxpemF0aW9uDQoNCjEwOjQwIEFNIC0gMTEgQU0gaThuIElz
c3VlcyB3aXRoIFJGQyA0MjgyLCBBbGFuIERlS29rICgxMCBtaW51dGVzKQ0KaHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjNDI4Mg0KDQpCZXJuYXJkIEFib2JhOiAgSG93IG1hbnkgcGVvcGxl
IHdlcmUgcHJlc2VudCBpbiBFTVUgV0cgYW5kIGhhdmUgaGVhcmQNCnRoaXMgdGFsayBhbHJlYWR5
PyANCg0KUm9vbTogIFF1aXRlIGEgZmV3IGhhbmRzIGdvIHVwLiANCg0KQmVybmFyZCBBYm9iYTog
IEkgZ3Vlc3Mgd2UgZG9uJ3QgbmVlZCB0byByZXBlYXQgdGhlIEVNVSBXRyBwcmVzZW50YXRpb24u
IA0KDQpBbGFuIERlS29rOiAgVGhlIG1haW4gaXNzdWUgaGVyZSBpcyB0aGF0IFJGQyA0MjgyIGlz
IG91dCBvZiBzeW5jIHdpdGgNCndoYXQgaW1wbGVtZW50YXRpb25zIGFjdHVhbGx5IGRvLiAgSW4g
cHJhY3RpY2UsIFdpbmRvd3MsIE1hY09TIGFuZA0KTGludXggaW1wbGVtZW50YXRpb25zIG9mIEVB
UCBhbmQgUkFESVVTIHVzZSBVVEYtOCwgYm90aCBmb3IgdGhlIA0KdXNlcm5hbWUgYW5kIHRoZSBy
ZWFsbS4gDQoNCkJlcm5hcmQgQWJvYmE6IE5vdCBhbGwgdmVyc2lvbnMgb2YgV2luZG93cyB1c2Ug
VVRGLTguICBJbiBWaXN0YSwNCklFRUUgODAyLjExIGlzIGJhc2VkIG9uIGFuIFJGQyAzNzQ4IGlt
cGxlbWVudGF0aW9uIChFQVBIT1NUKS4gIFRoaXMNCnVzZXMgVVRGLTguICBIb3dldmVyLCB0aGUg
RUFQIGltcGxlbWVudGF0aW9uIHVzZWQgYnkgUFBQIGFuZCBWUE4NCihMMlRQLCBQUFRQLCBTU1RQ
KSBpcyBiYXNlZCBvbiBSRkMgMjI4NCwgYW5kIHRoaXMgaW1wbGVtZW50YXRpb24NCnVzZXMgY29k
ZSBwYWdlcy4gIFdpbmRvd3MgWFAgU1AyIGFuZCBlYXJsaWVyIGFzIHdlbGwgYXMgV2luZG93cyAy
MDAwDQphbHNvIHVzZSB0aGlzIGVhcmxpZXIgaW1wbGVtZW50YXRpb24sIHNvIHRoZXkgd2lsbCBh
bHNvIG5vdCBwdXQgb3V0DQpVVEYtOCBpbiBFQVAtUmVzcG9uc2UvSWRlbnRpdHkgcGFja2V0cy4g
DQoNClN0ZWZhbiBXaW50ZXI6ICBXZSBhbHNvIHNhdyBub24gVVRGLTggY29taW5nIGZyb20gV2lu
ZG93cyB4UCBTUDMuIA0KQmVybmFyZCBBYm9iYTogIFRoYXQgaXMgdW5kZXIgaW52ZXN0aWdhdGlv
bi4gDQoNCkFsYW4gRGVLb2s6ICBUaGVyZSBhcmUgc2V2ZXJhbCBpc3N1ZXMgdGhhdCB0aGlzIGJy
aW5ncyB1cDoNCg0KICAgKiBSRkMgMzc0OCBzYXlzIHRoYXQgdGhlIEVBUC1SZXF1ZXN0L0lkZW50
aXR5IHVzZXMgVVRGLTggYnV0IG5vdA0KICAgICB0aGUgRUFQLVJlc3BvbnNlLiAgVGhpcyBsb29r
cyBsaWtlIGFuIG92ZXJzaWdodC4gDQogICAqIFJBRElVUyBSRkNzIHN0YXRlIHRoYXQgdGhlIFVz
ZXItTmFtZSBhdHRyaWJ1dGUgaXMgZW5jb2RlZCBpbg0KICAgICBVVEYtOC4gDQogICAqIEJvdGgg
RUFQIGFuZCBSQURJVVMgYXJlIDgtYml0IGNsZWFuLiAgU28gdGhlcmUgaXMgaW4gcHJhY3RpY2UN
CiAgICAgbm8gbmVlZCBmb3IgcHVueWNvZGUgaW4gb3JkZXIgdG8gc3VwcG9ydCBhIDctYml0IGNo
YW5uZWwuIA0KICAgKiBFeGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2Z0ZW4gdHJlYXQgdGhlIE5B
SSBsaWtlIGFuIG9wYXF1ZSBibG9iLiANCiAgICAgVGhlIE5BSSBtYXkgYmUgY29uZmlndXJlZCBm
b3IgdGhlIHVzZXIsIG9yIHRoZSB1c2VyIG1heSBub3QgZXZlbg0KICAgICBhYmxlIHRvIGVudGVy
IGl0IChlLmcuIFdpbmRvd3MpLiAgSW4gdGhlc2UgY2FzZXMsIHRoZXJlIGlzIG5vDQogICAgIG5v
cm1hbGl6YXRpb24gaXNzdWU7ICB0aGUgY2xpZW50IHNlbmRzIHdoYXQgdGhlIHNlcnZlciBpcyAN
CiAgICAgY29uZmlndXJlZCB0byBhY2NlcHQuIA0KDQpCZXJuYXJkIEFib2JhOiAgSSB0aGluayB0
aGUgcHJvYmxlbSBvcmlnaW5hdGVkIGZyb20gdGhlIGFzc3VtcHRpb24NCm9mIFJGQyAyNDg2IHRo
YXQgdGhlIE5BSSBoYWQgdGhlIHNhbWUgc3ludGF4IGFzIGFuIGVtYWlsIGFkZHJlc3MuIA0KU2hv
cnRseSB0aGVyZWFmdGVyLCBvcGVyYXRpbmcgc3lzdGVtcyBiZWdhbiB0byBzdXBwb3J0IFVURi04
IGJhc2VkDQpob3N0bmFtZXMgYW5kIHVzZXJuYW1lcywgc28gdGhpcyB3YXNuJ3QgdHJ1ZSBhbnkg
bW9yZS4gDQoNCkFsYW4gRGVLb2s6ICBBbm90aGVyIGlzc3VlIHdpdGggUkZDIDQyODIgaXMgdGhh
dCBpdCBpc24ndCBpbiBzeW5jDQp3aXRoIElETkFiaXMuICBUaGlzIG1lYW5zIHRoYXQgUkZDIDQy
ODIgY2FuJ3Qgc3VwcG9ydCBuZXcgdmVyc2lvbnMNCm9mIFVOSUNPREUgb3IgbmV3IHNjcmlwdHMu
ICBJdCBpc24ndCBpbiBzeW5jIHdpdGggdGhlIG5ldyBiaWRpDQpkcmFmdCwgd2l0aCB0aGUgdXBk
YXRlZCB0YWJsZXMsIGV0Yy4gIENoYXJhY3RlciBoYXZlIHNpbmNlIGJlZW4NCnByb2hpYml0ZWQv
YWRkZWQsIG5ldyBzY3JpcHRzIGhhdmUgYmVlbiBhZGRlZCwgZXRjLiAgDQoNCkJlcm5hcmQgQWJv
YmE6ICBTbyBmYXIsIHdlJ3ZlIGp1c3QgYmVlbiBkaXNjdXNzaW5nIHRoZSBOQUkuICBIb3dldmVy
LA0KdGhlcmUgYXJlIGFsc28gaXNzdWVzIHdpdGggcmVzcGVjdCB0byBwYXNzd29yZCBoYW5kbGlu
ZywgYW5kIGluIHNvbWUNCmNhc2VzLCBFQVAgbWV0aG9kcy4gIEZvciBleGFtcGxlLCBpdCBhcHBl
YXJzIHRoYXQgUkZDIDI3NTkgcmVmZXJzIHRvDQp1c2VybmFtZXMvcGFzc3dvcmRzIGVuY29kZWQg
aW4gQVNDSUkuICBUaGVyZSBhcmUgZG9jdW1lbnRlZCBjYXNlcw0Kd2hlcmUgVVRGLTggdXNlcm5h
bWVzIGhhdmUgZmFpbGVkIHRvIGF1dGhlbnRpY2F0ZS4gIEZvciBzb21lIHJlYXNvbg0KdGhlIGhh
c2hlcyBhcmUgYWN0dWFsbHkgZmFpbGluZyB0byBydW4gb3ZlciB0aGUgVVRGLTggYml0cyBpbiB0
aGUNCnVzZXJuYW1lLiAgVGhlcmUgaXMgYW4gZXJyYXRhIGZpbGVkIG9uIFJGQyAyNzU5IGN1cnJl
bnRseSB3aGljaCANCmFwcGVhcnMgdG8gcmVsYXRlIHRvIHRoaXMuICBSRkMgMzc0OCBTZWN0aW9u
IDUgdGFsa3MgYWJvdXQNCm5vbi1BU0NJSSBjaGFyYWN0ZXJzIGluIHBhc3NwaHJhc2VzOg0KDQog
ICBFQVAgbWV0aG9kcyBNQVkgc3VwcG9ydCBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiBzaGFyZWQg
c2VjcmV0cy4gIElmDQogICB0aGUgc2hhcmVkIHNlY3JldCBpcyBhIHBhc3NwaHJhc2UgZW50ZXJl
ZCBieSB0aGUgdXNlciwNCiAgIGltcGxlbWVudGF0aW9ucyBNQVkgc3VwcG9ydCBlbnRlcmluZyBw
YXNzcGhyYXNlcyB3aXRoIG5vbi1BU0NJSQ0KICAgY2hhcmFjdGVycy4gIEluIHRoaXMgY2FzZSwg
dGhlIGlucHV0IHNob3VsZCBiZSBwcm9jZXNzZWQgdXNpbmcgYW4NCiAgIGFwcHJvcHJpYXRlIHN0
cmluZ3ByZXAgW1JGQzM0NTRdIHByb2ZpbGUsIGFuZCBlbmNvZGVkIGluIG9jdGV0cyB1c2luZw0K
ICAgVVRGLTggZW5jb2RpbmcgW1JGQzIyNzldLiAgQSBwcmVsaW1pbmFyeSB2ZXJzaW9uIG9mIGEg
cG9zc2libGUNCiAgIHN0cmluZ3ByZXAgcHJvZmlsZSBpcyBkZXNjcmliZWQgaW4gW1NBU0xQUkVQ
XS4NCg0KRG9lcyBhbnlvbmUgYWN0dWFsbHkgaW1wbGVtZW50IHRoaXM/IA0KDQpBbGFuIERlS29r
OiAgSSBkb24ndCB0aGluayBzby4gIFBhc3NwaHJhc2VzIChsaWtlIE5BSXMpIGFyZSBnZW5lcmFs
bHkNCnRyZWF0ZWQgbGlrZSBvcGFxdWUgYml0cy4gDQoNCkJlcm5hcmQgQWJvYmE6ICBNYXliZSBh
IHN0ZXAgZm9yd2FyZCB3b3VsZCBiZSB0byBjcmVhdGUgYSBkcmFmdA0KZGVzY3JpYmluZyB3aGF0
IGltcGxlbWVudGF0aW9ucyBhY3R1YWxseSBkbz8gIFRoaXMgbWlnaHQgcmVxdWlyZQ0Kc29tZSB0
ZXN0aW5nLi4uIGJ1dCBhdCBsZWFzdCB3ZSdkIGtub3cgaG93IGJpZyB0aGUgaXNzdWUgcmVhbGx5
IGlzLiAgDQoNCklQdjYNCg0KMTE6MDAgQU0gLSAxMToxMCBBTaAgUHJlZml4IEF1dGhvcml6YXRp
b24sIEJlaGNldCBTYXJpa2F5YSAoMTAgbWludXRlcykNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9p
ZC9kcmFmdC1zYXJpa2F5YS1yYWRleHQtcHJlZml4LWF1dGhvcml6YXRpb24tMDENCg0KQmVybmFy
ZCBBYm9iYTogIFNvbWUgYmFja2dyb3VuZC4gIFJGQyAzMTYyIHdhcyBkZXZlbG9wZWQgbGFyZ2Vs
eSB0bw0Kc3VwcG9ydCBJUHY2IG92ZXIgUFBQLiAgUmFscGggRHJvbXMgYW5kIG90aGVycyBhdHRl
bXB0ZWQgdG8gdXNlDQp0aGlzIHRvIHN1cHBvcnQgREhDUHY2IHByZWZpeCBkZWxlZ2F0aW9uIGFu
ZCBkaXNjb3ZlcmVkIGl0IGRpZG4ndA0Kd29yaywgYmVjYXVzZSBpZiB0aGUgdXNlciBoYWQgYSBy
b3V0ZXIgb24gdGhlIHByZW1pc2VzLCB0aGVuIHRoZQ0KSVBWNiBhZGRyZXNzIG1vZGVsIHJlcXVp
cmVkIHRoYXQgdGhlIHByZWZpeGUgYmUgYXNzaWduZWQgdG8gdGhlIA0KbGluayBiZXR3ZWVuIHRo
ZSB1c2VyIGFuZCB0aGUgTkFTLCBub3QgZm9yIHVzZSBpbiB0aGUgdXNlciBuZXR3b3JrLiAgDQpT
byB3ZSBoYWQgdG8gZGV2ZWxvcCBSRkMgNDgxOCB0byBzdXBwb3J0IERIQ1B2NiBwcmVmaXggZGVs
ZWdhdGlvbi4gDQoNClRoZW4gd2UgZGlzY292ZXJlZCBzb21lIGFkZGl0aW9uYWwgY29uZnVzaW9u
IGluIFJGQyAzMTYyIHdpdGggDQpyZXNwZWN0IHRvIHRoZSBGcmFtZWQtSVB2Ni1QcmVmaXggYXR0
cmlidXRlLiAgQ291bGQgdGhpcyBhdHRyaWJ1dGUNCmJlIHVzZWQgdG8gY29uZmlndXJlIGEgLzEy
OCBwcmVmaXggZm9yIHRoZSB1c2VyIChlLmcuIGFzc2lnbiBhbg0KSVB2NiBhZGRyZXNzKT8gIElm
IHRoZSBpbnRlbnQgd2FzIHRvIGNhdXNlIHRoZSBhc3NpZ25lZCBwcmVmaXgNCnRvIGJlIGFkdmVy
dGlzZWQgYnkgdGhlIE5BUyBpbiBhbiBSQSBzZW50IHRvIHRoZSB1c2VyLCB0aGVuIHRoaXMNCmRv
ZXNuJ3QgbWFrZSBzZW5zZS4gIFN1Y2ggYSBwcmVmaXggY291bGQgb25seSBiZSBhcyBsYXJnZSBh
cw0KYSAvNjQuICBUaGUgRnJhbWVkLUludGVyZmFjZS1JZCBhdHRyaWJ1dGUgaXMgdXNlZCB0byBz
cGVjaWZ5DQp0aGUgSWRlbnRpZmllciBwb3J0aW9uIG9mIHRoZSBhZGRyZXNzLiAgVGhpcyBpc3N1
ZSB3YXMgY2xhcmlmaWVkDQppbiBSRkMgNTA4MCAod2hpY2ggdW5leHBsaWNhYmx5LCBkaWQgbm90
IHVwZGF0ZSBSRkMgMzE2MikuIA0KDQpCZWhjZXQ6ICBOb3cgd2UgbmVlZCB0aGUgQXV0aG9yaXpl
ZC1Vc2VySWQtUHJlZml4IGF0dHJpYnV0ZS4gDQpKb2UgU2Fsb3dleTogd2hhdCBpcyBhIHByZWZp
eCBhdXRob3JpemF0aW9uIHVzZXIgaWQ/DQpCZWhjZXQ6IFRoZSBSQURJVVMgc2VydmVyIG5lZWRz
IHRvIGlkZW50aWZ5IHRoZSB1c2VyLg0KSm9lIFNhbG93ZXk6IFNvIHRoZSB0aGUgUkFESVVTIGNs
aWVudCBzdG9yZXMgdGhpcyB2YWx1ZSwgYW5kIHB1dHMgDQp0aGlzIHZhbHVlIGluIGFuIEFjY2Vz
cy1SZXF1ZXN0Pw0KQmVoY2V0OiAgSXQgaXMgYWxzbyBuZWVkZWQgZm9yIHJlbnVtYmVyaW5nIHZp
YSBhIENvQS1SZXF1ZXN0IGFuZA0KQ29BLUFDSy4gDQpCZXJuYXJkIEFib2JhOiAgSWYgcmVudW1i
ZXJpbmcgb2NjdXJzLCBob3cgZG9lcyB0aGUgZW5kIHVzZXIgb2J0YWluDQp0aGVpciBuZXcgYWRk
cmVzcz8gIFJGQyAzMTYyIGFzc3VtZXMgdGhpcyBoYXBwZW5zIGJ5IGhhdmluZyB0aGUgTkFTDQpp
c3N1ZSBhbiBSQSB3aXRoIHRoZSBuZXcgcHJlZml4LiAgQnV0IHRoaXMgZHJhZnQgaXMgYXNzdW1p
bmcgYW5vdGhlcg0KYWRkcmVzcyBhc3NpZ25tZW50IG1lY2hhbmlzbSwgcmlnaHQ/IA0KSm9lIFNh
bG93ZXk6IFRoZSBSQURJVVMgQWNjZXNzLVJlcXVlc3QgYWxyZWFkeSBoYXMgY29udGV4dCBpbmZv
cm1hdGlvbiBhYm91dCB3aG8ncw0KcmVxdWVzdGluZyB0aGluZ3MsIG5hbWVseSB0aGUgVXNlci1O
YW1lIEF0dHJpYnV0ZS4gIFNvIHdoeSBkbyB3ZSBuZWVkIGEgc2VwYXJhdGUNCmF0dHJpYnV0ZSB0
byBzcGVjaWZ5IHRoaXM/IA0KQmVybmFyZDogQXJlIHRoZXJlIG90aGVyIHRoaW5ncyBhc3NvY2lh
dGVkIHdpdGggdGhlIHByZWZpeD8gDQpCZW5vaXQ6ICBIb3cgZG9lcyB0aGlzIGRyYWZ0IHJlbGF0
ZSB0byBSRkMgNDgxOD8gIElzIGl0IHVzaW5nIERIQ1B2NiBQcmVmaXggRGVsZWdhdGlvbj8NCkJl
aGNldDogIEl0IGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50IGZyb20gUkZDIDQ4MTguICBJbiBSRkMg
NDgxOCwgdGhlIEFBQSBzZXJ2ZXIgcHJvdmlkZXMgDQpwcmVmaXhlcyB0byB0aGUgTkFTLCBmb3Ig
dXNlIHdpdGggREhDUHY2IHByZWZpeCBkZWxlZ2F0aW9uLiAgSGVyZSB0aGUgQUFBIHNlcnZlciBw
cm92aWRlcw0KcHJlZml4ZXMgdG8gdGhlIEFBQSBjbGllbnQuDQpCZXJuYXJkIEFib2JhOiAgSG93
IGRvZXMgdGhlIEFBQSBjbGllbnQgY29tbXVuaWNhdGUgdGhlIHByZWZpeGVzIHRvIHRoZSB1c2Vy
PyAgRG9lcw0KdGhpcyBkb2N1bWVudCBhc3N1bWUgdGhhdCB0aGUgTkFTIGlzIGltcGxlbWVudGlu
ZyBhbiBhbHRlcm5hdGl2ZSB0byBESENQdjYgcHJlZml4DQpkZWxlZ2F0aW9uPyAgSWYgc28sIHdo
YXQgbWVjaGFuaXNtIGlzIGJlaW5nIHVzZWQ/ICBPbmUgY29uc3RyYWludCBpbiB0aGUgUkFERVhU
IFdHDQppcyB0aGF0IHdlIGNhbm5vdCBkZWZpbmUgbmV3IG5ldHdvcmsgZnVuY3Rpb25hbGl0eSBp
biB0aGlzIFdHLiAgRG9jdW1lbnRzIGhhdmUgdG8NCnJlZmVyZW5jZSBhbiBleGlzdGluZyBzZXJ2
aWNlIG1vZGVsLiAgUkZDIDQ4MTggcmVmZXJlbmNlcyB0aGUgREhDUHY2IHByZWZpeCBkZWxlZ2F0
aW9uDQpSRkNzLiAgUkZDIDMxNjIgcmVmZXJzIHRvIHRoZSBQUFAgb3ZlciBJUHY2IFJGQyAyNDcy
LCB0aGUgSVB2NiBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZQ0KYW5kIG90aGVyIElQdjYgZG9jdW1l
bnRzLiAgV2hhdCBleGlzdGluZyBwcmVmaXggYXNzaWdubWVudCBtZWNoYW5pc20gaXMgYmVpbmcg
ZGVwZW5kZWQNCm9uIGhlcmU/ICBUaGUgUkFERVhUIFdHIGNhbid0IGJlIHVzZWQgdG8gZGVmaW5l
IGFuIGFsdGVybmF0aXZlIG1lY2hhbmlzbSBmb3IgcHJlZml4DQpkZWxlZ2F0aW9uLiANCkZyYW5r
OiBUaGUgREhDUCByYWRpdXMgaW50ZXJmYWNlIGV4Y2x1ZGVzIHRoZSBwb3NzaWJpbGl0eSB0aGF0
IHRoaXMgY2FuIGJlIGRvbmUNCmJ5IEFBQSBvbmx5LiBESENQdjYgY2FuIGRlYWwgd2l0aCByZW51
bWJlcmluZy4gIEFBQSBjYW4ndCBkbyB0aGF0LiAgVGhpcyBkcmFmdA0KdmlvbGF0ZXMgdGhlIGJh
c2ljIHByaW5jaXBsZXMgb2YgSVB2NiBhZGRyZXNzIGFsbG9jYXRpb24uIA0KDQoxMToxMCBBTSAt
IDExOjIwIEFNoCBSRkMgMzE2MmJpcywgQmVub2l0IExvdXJkZWxldCAoMTAgbWludXRlcykNCmh0
dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvdXJkZWxldC1yYWRleHQtcmZjMzE2MmJp
cy0wMg0KDQpCZW5vaXQ6IFRoaXMgZG9jdW1lbnQgaXMgYmVpbmcgcHJvcG9zZWQgdG8gYWNjb21v
ZGF0ZSBJUHY2IHByb2R1Y3Rpb24gbmV0d29ya3MsDQppbiB3aGljaCB0aGVyZSBpcyBhbiBpc3N1
ZSBvZiBob3cgdG8gY29uZmlndXJlIHRoZSBETlMgc2VydmVyIGFkZHJlc3MuICBUaGlzDQpjYW4g
YmUgZGVsaXZlcmVkIHRvIHRoZSBjbGllbnQgZWl0aGVyIHZpYSBESENQdjYgb3IgdmlhIGEgUm91
dGVyIEFkdmVydGlzZW1lbnQNCm9wdGlvbi4gDQoNCkJlcm5hcmQgQWJvYmE6IGl0IHdvdWxkIGJl
IGdyZWF0IHRvIGhhdmUgdGhvc2UgcmVmZXJlbmNlcyBpbiB0aGUgZG9jdW1lbnQuIA0KSG93ZXZl
ciwgdGhpcyBhbHNvIHJhaXNlcyB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB3ZSBtaWdodCBhbHNv
IGhhdmUgcmVxdWVzdHMNCmZvciBhbGxvY2F0aW9ucyBvZiBSQURJVVMgYXR0cmlidXRlcyBjb3Jy
ZXNwb25kaW5nIHRvIG90aGVyIERIQ1Agb3B0aW9ucy4gDQpXZSBkb24ndCBoYXZlIGVub3VnaCBy
ZW1haW5pbmcgUkFESVVTIGF0dHJpYnV0ZSBzcGFjZSB0byBoYW5kbGUgYWxsIHRoZSANCnBvdGVu
dGlhbCBhbGxvY2F0aW9uIHJlcXVlc3RzIHRoYXQgdGhpcyBjb3VsZCBnZW5lcmF0ZS4gU28sIHNo
b3VsZCB3ZQ0KYmUgZGVmaW5pbmcgYSBzaW5nbGUgUkFESVVTIGF0dHJpYnV0ZSB0byBjYXJyeSBs
b3RzIG9mIERIQ1Agb3B0aW9ucywgDQpyYXRoZXIgdGhhbiBhIHNpbmdsZSBSQURJVVMgYXR0cmli
dXRlPyANCg0KQmVub2l0OiAgVGhlIG5lZWQgdG8gY29uZmlndXJlIGEgRE5TIHNlcnZlciBpcyBp
bmRlcGVuZGVudCBvZiBESENQLA0Kc2luY2UgaXQgY2FuIGFsc28gYmUgY29tbXVuaWNhdGVkIGlu
IGEgcm91dGVyIGFkdmVydGlzZW1lbnQuICBTbw0Kd2UgcHJvYmFibHkgbmVlZCBhIHNlcGFyYXRl
IEROUyBzZXJ2ZXIgYXR0cmlidXRlIGluIFJBRElVUy4gIEJ1dA0KZnV0dXJlIERIQ1B2NiBvcHRp
b25zIG1pZ2h0IHJlcXVpcmUgYSBtb3JlIGdlbmVyaWMgYXBwcm9hY2guIA0KDQpCZXJuYXJkIEFi
b2JhOiAgQW5vdGhlciBpc3N1ZSB0aGF0IHdhcyBkaXNjdXNzZWQgb24gdGhlIGxpc3Qgd2FzIHdo
ZXRoZXINCnRoaXMgZG9jdW1lbnQgbmVlZGVkIHRvIHVwZGF0ZSBSRkMgMzE2MiBvciBub3QuICBG
cm9tIHRoZSBkcmFmdCwgaXQgbG9va2VkDQpsaWtlIHRoZSBvbmx5IGlzc3VlIHRoYXQgbmVlZGVk
IGNsYXJpZmljYXRpb24gd2FzIHRoZSB1c2Ugb2YgdGhlDQpGcmFtZWQtSVB2Ni1QcmVmaXggYXR0
cmlidXRlIHRvIGNhcnJ5IElQdjYgYWRkcmVzc2VzLiAgUkZDIDUwODANCmRpc2NvdXJhZ2VzIHRo
YXQsIHNvIHlvdSBkb24ndCBuZWVkIHRvIHJldmlzZSBSRkMgMzE2MiB0byBjbGFyaWZ5DQp0aGF0
IGlzc3VlOyB5b3UgY2FuIGp1c3QgcmVmZXJlbmNlIFJGQyA1MDgwIGFuZCBwZXJoYXBzIGluY2x1
ZGUgYW4NClVwZGF0ZXM6IFJGQyAzMTYyIGluIHRoZSBkb2N1bWVudCBoZWFkZXIuIA0KDQpUaGF0
IHNhaWQsIEkgZG9uJ3Qgd2FudCB0byBkaXNjb3VyYWdlIHlvdSBpZiB5b3Ugd2FudCB0byB2b2x1
bnRlZXINCnRvIHVwZGF0ZSBSRkMgMzE2Mi4uLiBpdCdzIGp1c3QgdGhhdCB5b3UgZG9uJ3QgbmVl
ZCB0byBkbyB0aGF0IGluIG9yZGVyDQp0byBwcm9ncmVzcyB0aGlzIGRvY3VtZW50LiANCg0KQmVu
b2l0OiAgSSdkIHJhdGhlciBnbyB3aXRoIGEgc3RhbmRhbG9uZSBkb2N1bWVudCwgaWYgdGhhdCBj
YW4gYmUgZG9uZS4gDQpCZXJuYXJkIEFib2JhOiAgQSBzZXBhcmF0ZSBkb2N1bWVudCAocmF0aGVy
IHRoYW4gYW4gUkZDIDMxNjIgcmV2aXNpb24pIHNlZW1zIHRvDQpiZSB0aGUgd2F5IGZvcndhcmQu
IA0KDQpEYXZpZCBOZWxzb246IGlmIHRoaXMgaXMgdGFsa2luZyBhYm91dCBzZXJ2aWNlcyBvdGhl
ciB0aGFuIERIQ1AuLi4gZG8gd2UgZGVmaW5lDQphIG5ldyBzZXJ2aWNlIGluIGEgUkFESVVTIGRv
Y3VtZW50Pw0KDQpCZXJuYXJkOiBJdCBsb29rcyBsaWtlIHRoaXMgZG9jdW1lbnQganVzdCByZWZl
cmVuY2VzIGV4aXN0aW5nIHNlcnZpY2VzIHN1Y2gNCmFzIERIQ1B2NiBhbmQgUm91dGVyIEFkdmVy
dGlzZW1lbnQuIA0KDQpHbGVuOiBJIGFtIG9wcG9zZWQgdG8gYm90aCB0aGlzIGRyYWZ0IGFuZCB0
aGUgcHJldmlvdXMgb25lLCBiZWNhdXNlIHRoZXkgYXJlDQpub3QgQUFBLXJlbGF0ZWQuICBJdCBt
aWdodCBub3QgYmUgYSBiYWQgaWRlYSB0byBkZWZpbmUgYSBuZXcgc2VydmljZSBhcyB0aGV5IGFy
ZQ0Kbm90IHBlci11c2VyIGF0dHJpYnV0ZXMuICBUaGUgUkFESVVTIGNsaWVudCBpcyBsaWtlbHkg
dG8gYmUgYSBESENQIHNlcnZlci9yZWxheQ0KcmF0aGVyIHRoYW4gYSBOQVMuIA0KDQpCZXJuYXJk
IEFib2JhOiAgQ291bGRuJ3QgdGhlIEROUyBzZXJ2ZXIgYXR0cmlidXRlIGJlIHVzZWQgd2l0aCBh
IE5BUyBpbXBsZW1lbnRpbmcNCmVpdGhlciBhIERIQ1B2NiBzZXJ2ZXIgb3Igc3RhdGVsZXNzIGF1
dG9jb25maWcgKGUuZy4gUkEpPyAgVGhlIGF1dGhlbnRpY2F0aW9uIGNvdWxkDQpiZSBJRUVFIDgw
Mi4xWCBvciBQUFAsIGZvciBleGFtcGxlLiAgU28gdGhlcmUgYXJlIHNvbWUgdXNhZ2UgY2FzZXMg
dGhhdCBzZWVtDQpxdWl0ZSBjb252ZW50aW9uYWwuIA0KDQpEYXZpZCBOZWxzb246ICBUaGlzIGRv
Y3VtZW50IHN0aWxsIGhhcyBzb21lIGlzc3VlcyB0aGF0IG5lZWQgYXR0ZW50aW9uLiAgV2UgbmVl
ZA0KYW4gaW5kaWNhdGlvbiBvZiB3aGF0IGdvZXMgaW4gd2hhdCBkb2N1bWVudC4gIERvIHdlIGhh
dmUgdHdvIHNlcGFyYXRlIGRvY3VtZW50cywgDQpvciBkbyB3ZSBtZXJnZSB0aGVtPyAgT3IgZG8g
d2UgZGVhbCB3aXRoIHRoZSAic2VydmljZSByZWZlcmVuY2UiIGlzc3VlIGZpcnN0Pw0KDQpCZXJu
YXJkIEFib2JhOiAgQWxsIFJBREVYVCBkb2N1bWVudHMgbmVlZCB0byBiZSBhYmxlIHRvIHByb3Zp
ZGUgYSBzZXJ2aWNlIHJlZmVyZW5jZQ0KaW4gb3JkZXIgdG8gYmUgYWNjZXB0ZWQgYXMgV0cgd29y
ayBpdGVtcy4gIFdlIGNhbid0IGRlZmluZSBuZXcgc2VydmljZXMgaGVyZTsgd2UganVzdA0KZGVm
aW5lIGhvdyBSQURJVVMgY2FuIG1hbmFnZSBleGlzdGluZyBzZXJ2aWNlcy4gDQoNCkJlcm5hcmQ6
IFRoZSAyIGRvY3VtZW50cyBpbiBJRVRGIGxhc3QgY2FsbCwgcGx1cyB0aGUgNCBkb2N1bWVudHMg
aW4gV0cgbGFzdCBjYWxsIGhhdmUgDQpjb25zdW1lZCB0aGUgZ3JvdXAuICBXZSBuZWVkIHRvIG1h
a2UgbW9yZSByYXBpZCBwcm9ncmVzcyBvbiB0aG9zZSB3b3JrIGl0ZW1zLCBnZXQNCnRoZSBkb2N1
bWVudHMgaW4gSUVURiBsYXN0IGNhbGwgaW50byB0aGUgUkZDIEVkaXRvciBRdWV1ZSwgZ2V0IHRo
ZSA0IGRvY3VtZW50cyBpbiBXRw0KbGFzdCBjYWxsIHJlYWR5IGZvciBjb25zaWRlcmF0aW9uIGJ5
IHRoZSBJRVNHLiAgT25jZSB3ZSBoYXZlIGRvbmUgdGhpcyB3ZSB3aWxsIGhhdmUNCm1vcmUgY3lj
bGVzIGZvciB0aGUgb3RoZXIgd29yayB0aGF0IHBlb3BsZSB3YW50IHRvIGdldCBnb2luZyBvbi4g
DQoNCkhvd2V2ZXIsIGRvY3VtZW50IGF1dGhvcnMgb2YgaW5kaXZpZHVhbCBzdWJtaXNzaW9ucyBj
YW4gc3RpbGwgbWFrZSBwcm9ncmVzcyBvbiB0aGVpciBvd24uICANClRoZXkgY2FuIHNvbGljaXQg
ZmVlZGJhY2ssIHRoZXkgY2FuIGdldCBnZXQgdGhlaXIgb3duIHJldmlld3MgZnJvbSBvdGhlciBh
cmVhcywgdGhleQ0KY2FuIGNsYXJpZnkgdGhlIHNlcnZpY2UgcmVmZXJlbmNlcywgcHJvdmlkZSBh
cHBsaWNhYmlsaXR5IHN0YXRlbWVudHMsIGV0Yy4gIFNvIHdvcmsgDQpkb2Vzbid0IG5lZWQgdG8g
c3RvcCB3YWl0aW5nIGZvciBSQURFWFQgV0cgYXR0ZW50aW9uIGFuZCBjeWNsZXMgdG8gZnJlZSB1
cC4gDQoNCk1lZXRpbmcgRW5kZWQuIA0K

--_d70a75a7-397d-4744-bff9-a64b9a19ac7c_--

--
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, 11 Dec 2008 23:54:29 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: Summary of Review of draft-ietf-radext-extended-attributes-05.txt
Date: Thu, 11 Dec 2008 17:53:55 -0600
Message-ID: <002201c95beb$ba060a50$2e121ef0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C95BB9.6F6B9A50"
Thread-Index: AclZTs96IY5yef14SpaBp5njuxU+FwCm8Qkw
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0023_01C95BB9.6F6B9A50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

On November 3, 2008, a call was issues for the review the status of open
issues on draft-ietf-radext-extended-attributes-05.txt:

http://ops.ietf.org/lists/radiusext/2008/msg00720.html

 

This generated the following responses:

http://ops.ietf.org/lists/radiusext/2008/msg00727.html

http://ops.ietf.org/lists/radiusext/2008/msg00737.html

http://ops.ietf.org/lists/radiusext/2008/msg00757.html

http://ops.ietf.org/lists/radiusext/2008/msg00755.html

 

Looking over these responses and subsequent postings, it would appear that
the following issues remain open:

 


Extended Attributes 

Issue Number

Status

Type

Description

Owner


Issue 225

Pending

Technical

Review <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20225> 

Alan DeKok <mailto:[e-mail]> 


Issue 251

Pending

Technical

Review <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20251> 

Bernard Aboba <mailto:[e-mail]> 


Issue 278

Pending

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20278> 

Alan DeKok <mailto:[e-mail]> 


Issue 279

Pending

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20279> 

Stefan Winter <mailto:[e-mail]> 


Issue 287

No Discussion

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20287> 

Greg Weber <mailto:[e-mail]> 


Issue 290

No Discussion

Technical

RFC <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20290>
4005bis Dependency

Bernard Aboba <mailto:[e-mail]> 

 

I have updated the Issues list to take into account the current status, as
well as to reflect

the mailing list discussion of these issues.  If any of the above issues are
now closed, or

if there is are any additional comments that the original posters wish to
make relating to

current status, please reply to this message. 


------=_NextPart_000_0023_01C95BB9.6F6B9A50
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" =
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:PMingLiU;
	panose-1:2 2 5 0 0 0 0 0 0 0;}
@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:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@PMingLiU";
	panose-1:2 2 5 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
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.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
MsoChpDefault
	{mso-style-type:export-only;}
@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>

<p class=3DMsoPlainText>On November 3, 2008, a call was issues for the =
review the
status of open issues on =
draft-ietf-radext-extended-attributes-05.txt:<o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00720.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00720.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>This generated the following =
responses:<o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00727.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00727.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00737.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00737.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00757.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00757.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><a
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00755.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00755.html</a><o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Looking over these responses and subsequent =
postings, it
would appear that the following issues remain open:<o:p></o:p></p>

<p class=3DMsoPlainText><span =
style=3D'color:black'><o:p>&nbsp;</o:p></span></p>

<table class=3DMsoNormalTable border=3D1 cellpadding=3D0 width=3D761 =
style=3D'width:570.75pt'>
 <tr style=3D'height:25.5pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:25.5pt'>
  <p class=3DMsoNormal><strong><span =
style=3D'font-size:13.5pt;font-family:"Calibri","sans-serif"'>Extended
  Attributes</span></strong> <o:p></o:p></p>
  <p><b><span style=3D'font-size:13.5pt'>Issue =
Number</span></b><o:p></o:p></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Status</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D84 style=3D'width:63.0pt;padding:.75pt .75pt .75pt =
75pt;height:25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Type</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D272 style=3D'width:204.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Description</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D112 style=3D'width:84.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  25.5pt'>
  <p class=3DMsoNormal><b><span =
style=3D'font-size:13.5pt'>Owner</span></b><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Issue 225<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D73 style=3D'width:54.75pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D277 style=3D'width:207.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2022=
5">Review</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a href=3D"mailto:[e-mail]">Alan =
DeKok</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:46.5pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:46.5pt'>
  <p class=3DMsoNormal>Issue 251<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:46.5pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D84 style=3D'width:63.0pt;padding:.75pt .75pt .75pt =
75pt;height:46.5pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D272 style=3D'width:204.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:46.5pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2025=
1">Review</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D112 style=3D'width:84.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  46.5pt'>
  <p class=3DMsoNormal><a =
href=3D"mailto:[e-mail]">Bernard Aboba</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Issue 278<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D73 style=3D'width:54.75pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D277 style=3D'width:207.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2027=
8">Comments</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a href=3D"mailto:[e-mail]">Alan =
DeKok</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Issue 279<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D146 style=3D'width:109.5pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>Pending<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D73 style=3D'width:54.75pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D277 style=3D'width:207.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2027=
9">Comments</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D117 style=3D'width:87.75pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a =
href=3D"mailto:[e-mail]">Stefan Winter</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D116 style=3D'width:87.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Issue 287<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D143 style=3D'width:107.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>No Discussion<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D80 style=3D'width:60.0pt;padding:.75pt .75pt .75pt =
75pt;height:38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D276 style=3D'width:207.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2028=
7">Comments</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D111 style=3D'width:83.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a href=3D"mailto:[e-mail]">Greg =
Weber</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr style=3D'height:38.25pt'>
  <td width=3D116 style=3D'width:87.0pt;padding:.75pt .75pt .75pt =
75pt;height:
  38.25pt'>
  <p class=3DMsoNormal>Issue 290<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D143 style=3D'width:107.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal>No Discussion<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D80 style=3D'width:60.0pt;padding:.75pt .75pt .75pt =
75pt;height:38.25pt'>
  <p class=3DMsoNormal>Technical<span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D276 style=3D'width:207.0pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a
  =
href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%2029=
0">RFC
  4005bis Dependency</a><span =
style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
  <td width=3D111 style=3D'width:83.25pt;padding:.75pt .75pt .75pt =
75pt;
  height:38.25pt'>
  <p class=3DMsoNormal><a =
href=3D"mailto:[e-mail]">Bernard Aboba</a><span
  style=3D'font-size:12.0pt'><o:p></o:p></span></p>
  </td>
 </tr>
</table>

<p class=3DMsoPlainText><span =
style=3D'color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>I have updated the =
Issues list
to take into account the current status, as well as to =
reflect<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>the mailing list =
discussion of
these issues.&nbsp; If any of the above issues are now closed, =
or<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>if there is are any =
additional
comments that the original posters wish to make relating =
to<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'>current status, =
please reply to
this message. <o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0023_01C95BB9.6F6B9A50--


--
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, 11 Dec 2008 23:11:00 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_cc2446ef-abde-4a07-a551-165783cd9a81_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: draft-aboba-radext-wlan-09 (fwd)
Date: Thu, 11 Dec 2008 15:10:04 -0800
MIME-Version: 1.0

--_cc2446ef-abde-4a07-a551-165783cd9a81_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Date: Wed=2C 10 Dec 2008 19:46:02 +0100 (MEZ)
From: Alfred H=C3=B6nes <[e-mail]>
To:  <[e-mail]>=2C  <[e-mail]>=2C  <paul_congdon@hp.=
com>=2C  <[e-mail]>
Cc:  <[e-mail]>
Subject: draft-aboba-radext-wlan-09

Hello=2C
I started to review the I-D authored by you=2C
        draft-aboba-radext-wlan-09=2C
but after stumbling over a rather general issue=2C
I stopped delving into other details.

This issue is a systematical violation of the RADIUS spec
and draft-ietf-radext-option-design-05:

As pointed out in Section 2.1.1 (et al.) of the latter=2C

   [RFC2865] defines the following data types:

|  text           1-253 octets containing UTF-8 encoded 10646 [RFC3629]
|                 characters.  Text of length zero (0) MUST NOT be sent=3B
|                 omit the entire attribute instead.
|  string         1-253 octets containing binary data (values 0 through
|                 255 decimal=2C inclusive).  Strings of length zero (0)
|                 MUST NOT be sent=3B omit the entire attribute instead.
   [...]


In persistent violation of these principles=2C
draft-aboba-radext-wlan-09 calls for zero-length String values
in many attributes=2C starting with Section 2.2:


   Length

|     >=3D2

   String


      [...]                                           As a result=2C an
|     EAP-Key-Name Attribute sent in an Access-Request MUST NOT contain
|     any data.  [...]


There's many more similar and closely related text in the draft
for other attributes.

IMO=2C this draft should be reworked to follow the existing specs and
the guidelines=2C and not request sending Null-String values attributes.


Another general recommendation:

In order to reduce the probability for clerical errors to happen
during the final processing after IANA assignments=2C I strongly
recommend using distinguished placeholders for the code points to
be assigned by IANA=2C e.g.=2C  "TBA1"=2C "TBA2"=2C ... or  "TBD1"=2C ...
(This is aligned with recommendations in BCP 26=2C RFC 5226.)


Kind regards=2C
  Alfred H=C3=B6nes.

--=20

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math.=2C Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone]=2C Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+




 EMAILING FOR THE GREATER GOOD
Join me=

--_cc2446ef-abde-4a07-a551-165783cd9a81_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<font style=3D"" face=3D"Courier New">Date: Wed=2C 10 Dec 2008 19:46:02 +01=
00 (MEZ)</font><font style=3D"" face=3D"Courier New"><br></font><font style=
=3D"" face=3D"Courier New">From: Alfred H=C3=B6nes &lt=[e-mail]&gt=3B=
</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fa=
ce=3D"Courier New">To:&nbsp=3B &lt=[e-mail]&gt=3B=2C&nbsp=3B =
&lt=[e-mail]&gt=3B=2C&nbsp=3B &lt=[e-mail]&gt=3B=
=2C&nbsp=3B &lt=[e-mail]&gt=3B</font><font style=3D"" face=3D"C=
ourier New"><br></font><font style=3D"" face=3D"Courier New">Cc:&nbsp=3B &l=
t=[e-mail]&gt=3B</font><font style=3D"" face=3D"Courier New"><br></=
font><font style=3D"" face=3D"Courier New">Subject: draft-aboba-radext-wlan=
-09</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D""=
 face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">Hell=
o=2C</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"=
" face=3D"Courier New">I started to review the I-D authored by you=2C</font=
><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"=
Courier New">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B draft=
-aboba-radext-wlan-09=2C</font><font style=3D"" face=3D"Courier New"><br></=
font><font style=3D"" face=3D"Courier New">but after stumbling over a rathe=
r general issue=2C</font><font style=3D"" face=3D"Courier New"><br></font><=
font style=3D"" face=3D"Courier New">I stopped delving into other details.<=
/font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fac=
e=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">This iss=
ue is a systematical violation of the RADIUS spec</font><font style=3D"" fa=
ce=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">and dra=
ft-ietf-radext-option-design-05:</font><font style=3D"" face=3D"Courier New=
"><br></font><font style=3D"" face=3D"Courier New"><br></font><font style=
=3D"" face=3D"Courier New">As pointed out in Section 2.1.1 (et al.) of the =
latter=2C</font><font style=3D"" face=3D"Courier New"><br></font><font styl=
e=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New=
">&nbsp=3B&nbsp=3B [RFC2865] defines the following data types:</font><font =
style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier=
 New"><br></font><font style=3D"" face=3D"Courier New">|&nbsp=3B text&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
 1-253 octets containing UTF-8 encoded 10646 [RFC3629]</font><font style=3D=
"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">|&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B characters.&nbsp=3B Te=
xt of length zero (0) MUST NOT be sent=3B</font><font style=3D"" face=3D"Co=
urier New"><br></font><font style=3D"" face=3D"Courier New">|&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B omit the entire attribute instead.=
</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fa=
ce=3D"Courier New">|&nbsp=3B string&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B 1-253 octets containing binary data (values 0 thro=
ugh</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D""=
 face=3D"Courier New">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B 255 decimal=2C inclusive).&nbsp=3B Strings of length zero (0)</font><fo=
nt style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Cour=
ier New">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B MUST NOT be=
 sent=3B omit the entire attribute instead.</font><font style=3D"" face=3D"=
Courier New"><br></font><font style=3D"" face=3D"Courier New">&nbsp=3B&nbsp=
=3B [...]</font><font style=3D"" face=3D"Courier New"><br></font><font styl=
e=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New=
"><br></font><font style=3D"" face=3D"Courier New">In persistent violation =
of these principles=2C</font><font style=3D"" face=3D"Courier New"><br></fo=
nt><font style=3D"" face=3D"Courier New">draft-aboba-radext-wlan-09 calls f=
or zero-length String values</font><font style=3D"" face=3D"Courier New"><b=
r></font><font style=3D"" face=3D"Courier New">in many attributes=2C starti=
ng with Section 2.2:</font><font style=3D"" face=3D"Courier New"><br></font=
><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"=
Courier New"><br></font><font style=3D"" face=3D"Courier New">&nbsp=3B&nbsp=
=3B Length</font><font style=3D"" face=3D"Courier New"><br></font><font sty=
le=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier Ne=
w">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B &gt=3B=3D2</font><font style=3D"" face=
=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"><br></fon=
t><font style=3D"" face=3D"Courier New">&nbsp=3B&nbsp=3B String</font><font=
 style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courie=
r New"><br></font><font style=3D"" face=3D"Courier New"><br></font><font st=
yle=3D"" face=3D"Courier New">&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B [...=
]&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B As a result=2C an</font><font style=
=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"=
>|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B EAP-Key-Name Attribute sent in an Access=
-Request MUST NOT contain</font><font style=3D"" face=3D"Courier New"><br><=
/font><font style=3D"" face=3D"Courier New">|&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B any data.&nbsp=3B [...]</font><font style=3D"" face=3D"Courier New"><br=
></font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" f=
ace=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">There'=
s many more similar and closely related text in the draft</font><font style=
=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"=
>for other attributes.</font><font style=3D"" face=3D"Courier New"><br></fo=
nt><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=
=3D"Courier New">IMO=2C this draft should be reworked to follow the existin=
g specs and</font><font style=3D"" face=3D"Courier New"><br></font><font st=
yle=3D"" face=3D"Courier New">the guidelines=2C and not request sending Nul=
l-String values attributes.</font><font style=3D"" face=3D"Courier New"><br=
></font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" f=
ace=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New">Anothe=
r general recommendation:</font><font style=3D"" face=3D"Courier New"><br><=
/font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fac=
e=3D"Courier New">In order to reduce the probability for clerical errors to=
 happen</font><font style=3D"" face=3D"Courier New"><br></font><font style=
=3D"" face=3D"Courier New">during the final processing after IANA assignmen=
ts=2C I strongly</font><font style=3D"" face=3D"Courier New"><br></font><fo=
nt style=3D"" face=3D"Courier New">recommend using distinguished placeholde=
rs for the code points to</font><font style=3D"" face=3D"Courier New"><br><=
/font><font style=3D"" face=3D"Courier New">be assigned by IANA=2C e.g.=2C&=
nbsp=3B "TBA1"=2C "TBA2"=2C ... or&nbsp=3B "TBD1"=2C ...</font><font style=
=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier New"=
>(This is aligned with recommendations in BCP 26=2C RFC 5226.)</font><font =
style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier=
 New"><br></font><font style=3D"" face=3D"Courier New"><br></font><font sty=
le=3D"" face=3D"Courier New">Kind regards=2C</font><font style=3D"" face=3D=
"Courier New"><br></font><font style=3D"" face=3D"Courier New">&nbsp=3B Alf=
red H=C3=B6nes.</font><font style=3D"" face=3D"Courier New"><br></font><fon=
t style=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Couri=
er New">-- </font><font style=3D"" face=3D"Courier New"><br></font><font st=
yle=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier N=
ew">+------------------------+--------------------------------------------+=
</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D"" fa=
ce=3D"Courier New">| TR-Sys Alfred Hoenes&nbsp=3B&nbsp=3B |&nbsp=3B Alfred =
Hoenes&nbsp=3B&nbsp=3B Dipl.-Math.=2C Dipl.-Phys.&nbsp=3B |</font><font sty=
le=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier Ne=
w">| Gerlinger Strasse 12&nbsp=3B&nbsp=3B |&nbsp=3B Phone: [phone]=
=2C Fax: -18&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B |</font><font style=3D"" face=3D"Courier New"><br></font><font style=3D=
"" face=3D"Courier New">| D-71254&nbsp=3B Ditzingen&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B |&nbsp=3B E-Mail:&nbsp=3B [e-mail]&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |</font><font s=
tyle=3D"" face=3D"Courier New"><br></font><font style=3D"" face=3D"Courier =
New">+------------------------+--------------------------------------------=
+</font><br><br><br><br><br><table style=3D"border-top: 1px solid black=3B =
font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbod=
y><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLH=
M_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B te=
xt-decoration: none=3B"><img style=3D"border-style: none=3B" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILING FOR THE G=
REATER GOOD<br><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color:=
 rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">Join me</span></a><=
/td></tr></tbody></table></body>
</html>=

--_cc2446ef-abde-4a07-a551-165783cd9a81_--

--
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, 11 Dec 2008 18:45:20 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-tcp-transport-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 11 Dec 2008 10:45:02 -0800 (PST)

--NextPart

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


	Title           : RADIUS Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-01.txt
	Pages           : 15
	Date            : 2008-12-11

The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer.  This document defines RADIUS over the
Transmission Control Protocol (TCP).

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

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

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

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

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Dec 2008 18:40:13 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Dec 2008 19:39:17 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: draft-ietf-radext-tcp-transport-01.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  It has been brought to my attention that the the -00 version of the
IETF draft was taken from -00 of the individual draft.  However,
draft-dekok-radext-tcp-transport-01.txt was the last one published.

  To fix that, I have submitted draft-ietf-radext-tcp-transport-01.txt,
with contents taken verbatim from -01 of the individual draft.

  It's been a long day.  Sorry for the confusion.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Dec 2008 16:17:52 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu, 11 Dec 2008 08:16:42 -0800
MIME-Version: 1.0

--_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Based on the discussion at IETF 73=2C the following issues have been filed =
against the document:

Issue 291
    Pending
    Technical
   =20
=09
	UDP/TCP Translation
    Alan=20
	DeKok
=09
=09
    Issue 292
    Pending
    Technical
   =20
=09
	Applicability
    Alan=20
	DeKok
=09
=09
    Issue 293
    Pending
    Technical
   =20
=09
	Watchdog Timer
    Alan=20
	DeKok
=09
=09
    Issue 294
    No Discussion
    Technical
   =20
=09
	Document Status
    Bernard=20
	Aboba
=09
=09
    Issue 295
    Pending
    Technical
   =20
=09
	Head of Line Blocking
    Alan=20
	DeKok
Rather than waiting until WG last call=2C my suggestion would be to engage =
a Transport Directorate adviser to
assist with resolution of these issues.  I have sent an email to the tsv-di=
r mailing list to solicit a volunteer.=20

Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu=2C 11 Dec 2008 10:54:18 +0100
From: [e-mail]
To: [e-mail]=3B [e-mail]










I=20
suggest that by the time the document reaches WGLC a specific request be se=
nt by=20
the chairs to the Transport Directorate for an early review.=20

=20
Dan
=20


 =20
 =20
  From: [e-mail]=20
  [mailto:[e-mail]] On Behalf Of Bernard=20
  Aboba
Sent: Thursday=2C December 11=2C 2008 8:03 AM
To:=20
  [e-mail]
Subject: Summary of WG review of "RADIUS over=20
  TCP" document


  A call for review of the "RADIUS over TCP" document was issued on=20
  November 4=2C 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html)=20
  and concluded on=20
November 19=2C 2008.=20
=20
Based on the response to=20
  the call for review=2C the document is accepted as a=20
RADEXT WG work item=2C=20
  and should be resubmitted as=20
  draft-ietf-radext-tcp-transport-00.txt.
=20
Note that a number of=20
  transport issues were raised during the IETF 73 discussion
of this=20
  document=2C by Magnus Westerlund (Transport AD) and others.   It=20
  is
therefore recommended that this document receive an=20
  early review by the
Transport=20
Directorate. =20

--_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Based on the discussion at IETF 73=2C the following issues have been filed =
against the document:<br><br><table id=3D"table66" width=3D"762" border=3D"=
1" height=3D"1"><tbody><tr><td width=3D"116" height=3D"62">Issue 291</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
291">
	UDP/TCP Translation</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 292</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
292">
	Applicability</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 293</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
293">
	Watchdog Timer</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 294</td>
    <td width=3D"143" height=3D"34">No Discussion</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
294">
	Document Status</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td>
	</tr>
	<tr>
    <td width=3D"116" height=3D"62">Issue 295</td>
    <td width=3D"143" height=3D"34">Pending</td>
    <td width=3D"80" height=3D"62">Technical</td>
    <td width=3D"276" height=3D"62">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
295">
	Head of Line Blocking</a></td>
    <td width=3D"111" height=3D"51"><a href=3D"mailto:aland@deployingradius=
.com">Alan=20
	DeKok</a></td></tr></tbody></table><br>Rather than waiting until WG last c=
all=2C my suggestion would be to engage a Transport Directorate adviser to<=
br>assist with resolution of these issues.&nbsp=3B I have sent an email to =
the tsv-dir mailing list to solicit a volunteer. <br><br><hr id=3D"stopSpel=
ling">Subject: RE: Summary of WG review of "RADIUS over TCP" document<br>Da=
te: Thu=2C 11 Dec 2008 10:54:18 +0100<br>From: [e-mail]<br>To: be=
[e-mail]=3B [e-mail]<br><br>




<style>
.ExternalClass .EC_hmmessage P
{padding-right:0px=3Bpadding-left:0px=3Bpadding-bottom:0px=3Bpadding-top:0p=
x=3B}
.ExternalClass BODY.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>



<div><span class=3D"EC_356165309-11122008"><font color=3D"#0000ff" face=3D"=
Arial"><strong><em>I=20
suggest that by the time the document reaches WGLC a specific request be se=
nt by=20
the chairs to the Transport Directorate for an early review.=20
</em></strong></font></span></div>
<div><span class=3D"EC_356165309-11122008"><strong><em><font color=3D"#0000=
ff" face=3D"Arial"></font></em></strong></span>&nbsp=3B</div>
<div><span class=3D"EC_356165309-11122008"><strong><em><font color=3D"#0000=
ff" face=3D"Arial">Dan</font></em></strong></span></div>
<div><span class=3D"EC_356165309-11122008"><strong><em><font color=3D"#0000=
ff" face=3D"Arial"></font></em></strong></span>&nbsp=3B</div><br>
<blockquote style=3D"border-left: 2px solid rgb(0=2C 0=2C 255)=3B padding-l=
eft: 5px=3B margin-left: 5px=3B margin-right: 0px=3B">
  <div class=3D"EC_OutlookMessageHeader" dir=3D"ltr" align=3D"left" lang=3D=
"en-us">
  <hr>
  <font face=3D"Tahoma"><b>From:</b> [e-mail]=20
  [mailto:[e-mail]] <b>On Behalf Of </b>Bernard=20
  Aboba<br><b>Sent:</b> Thursday=2C December 11=2C 2008 8:03 AM<br><b>To:</=
b>=20
  [e-mail]<br><b>Subject:</b> Summary of WG review of "RADIUS=
 over=20
  TCP" document<br></font><br></div>
  <div></div>A call for review of the "RADIUS over TCP" document was issued=
 on=20
  November 4=2C 2008<br>(see <a href=3D"http://ops.ietf.org/lists/radiusext=
/2008/msg00731.html">http://ops.ietf.org/lists/radiusext/2008/msg00731.html=
</a>)=20
  and concluded on <br>November 19=2C 2008. <br>&nbsp=3B<br>Based on the re=
sponse to=20
  the call for review=2C the document is accepted as a <br>RADEXT WG work i=
tem=2C=20
  and should be resubmitted as=20
  draft-ietf-radext-tcp-transport-00.txt.<br>&nbsp=3B<br>Note that a number=
 of=20
  transport issues were raised during the IETF 73 discussion<br>of this=20
  document=2C by Magnus Westerlund (Transport AD) and others.&nbsp=3B&nbsp=
=3B It=20
  is<br>therefore recommended that&nbsp=3Bthis document receive an=20
  early&nbsp=3Breview by the<br>Transport=20
Directorate.&nbsp=3B&nbsp=3B<br></blockquote></body>
</html>=

--_cb9b69a7-dd5f-4897-b70c-3ca33b8058a6_--

--
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, 11 Dec 2008 13:15:49 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-tcp-transport-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 11 Dec 2008 05:15:02 -0800 (PST)

--NextPart

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


	Title           : RADIUS Over TCP
	Author(s)       : A. DeKok
	Filename        : draft-ietf-radext-tcp-transport-00.txt
	Pages           : 14
	Date            : 2008-12-11

The Remote Authentication Dial In User Server (RADIUS) Protocol has
traditionally used the User Datagram Protocol (UDP) as it's
underlying transport layer.  This document defines RADIUS over the
Transport Control Protocol (TCP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-tcp-transport-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-tcp-transport-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: Thu, 11 Dec 2008 10:47:10 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Dec 2008 11:46:38 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Summary of WG review of "RADIUS over TCP" document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> A call for review of the "RADIUS over TCP" document was issued on
> November 4, 2008
> (see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and
> concluded on
> November 19, 2008.
>  
> Based on the response to the call for review, the document is accepted as a
> RADEXT WG work item, and should be resubmitted as
> draft-ietf-radext-tcp-transport-00.txt.

  I have submitted the document with the following changes from
draft-dekok-tcp-transport-00.txt:

 - IPR statements updated
 - name in page footers corrected
 - updated reference from status-server-00 to status-server-02
 - Submission && expiry dates changed

  No changes have been made to the body of the text.  WG reviews will be
integrated into a -01 version of the document.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Dec 2008 09:55:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95B76.6F5306F3"
Subject: RE: Summary of WG review of "RADIUS over TCP" document
Date: Thu, 11 Dec 2008 10:54:18 +0100
Message-ID: <[e-mail]>
Thread-Topic: Summary of WG review of "RADIUS over TCP" document
Thread-Index: AclbVjFUJ8zfpeZHSwmsK6BQfpj4eAAIBi7w
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C95B76.6F5306F3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I suggest that by the time the document reaches WGLC a specific request
be sent by the chairs to the Transport Directorate for an early review.=20
=20
Dan
=20


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bernard Aboba
	Sent: Thursday, December 11, 2008 8:03 AM
	To: [e-mail]
	Subject: Summary of WG review of "RADIUS over TCP" document
=09
=09
	A call for review of the "RADIUS over TCP" document was issued
on November 4, 2008
	(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and
concluded on=20
	November 19, 2008.=20
	=20
	Based on the response to the call for review, the document is
accepted as a=20
	RADEXT WG work item, and should be resubmitted as
draft-ietf-radext-tcp-transport-00.txt.
	=20
	Note that a number of transport issues were raised during the
IETF 73 discussion
	of this document, by Magnus Westerlund (Transport AD) and
others.   It is
	therefore recommended that this document receive an early review
by the
	Transport Directorate. =20
=09


------_=_NextPart_001_01C95B76.6F5306F3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2900.3429" name=3DGENERATOR></HEAD>
<BODY class=3Dhmmessage>
<DIV><SPAN class=3D356165309-11122008><FONT face=3DArial =
color=3D#0000ff><STRONG><EM>I=20
suggest that by the time the document reaches WGLC a specific request be =
sent by=20
the chairs to the Transport Directorate for an early review.=20
</EM></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=3D356165309-11122008><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D356165309-11122008><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff>Dan</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=3D356165309-11122008><STRONG><EM><FONT face=3DArial=20
color=3D#0000ff></FONT></EM></STRONG></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Bernard=20
  Aboba<BR><B>Sent:</B> Thursday, December 11, 2008 8:03 =
AM<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> Summary of WG review of =
"RADIUS over=20
  TCP" document<BR></FONT><BR></DIV>
  <DIV></DIV>A call for review of the "RADIUS over TCP" document was =
issued on=20
  November 4, 2008<BR>(see <A=20
  =
href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00731.html">http://op=
s.ietf.org/lists/radiusext/2008/msg00731.html</A>)=20
  and concluded on <BR>November 19, 2008. <BR>&nbsp;<BR>Based on the =
response to=20
  the call for review, the document is accepted as a <BR>RADEXT WG work =
item,=20
  and should be resubmitted as=20
  draft-ietf-radext-tcp-transport-00.txt.<BR>&nbsp;<BR>Note that a =
number of=20
  transport issues were raised during the IETF 73 discussion<BR>of this=20
  document, by Magnus Westerlund (Transport AD) and others.&nbsp;&nbsp; =
It=20
  is<BR>therefore recommended that&nbsp;this document receive an=20
  early&nbsp;review by the<BR>Transport=20
Directorate.&nbsp;&nbsp;<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C95B76.6F5306F3--

--
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, 11 Dec 2008 07:09:09 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: TCP transport draft
Date: Wed, 10 Dec 2008 23:08:20 -0800
Message-ID: <001e01c95b5f$3fdabb90$bf9032b0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclKdb9tHt/SxVGqR3mbFLEICof2wAQ5j4UA
Content-Language: en-us

Comments below. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Alan DeKok
Sent: Wednesday, November 19, 2008 10:33 AM
To: 'radext mailing list'
Subject: TCP transport draft

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

  1) The document doesn't discuss UDP -> TCP and TCP -> UDP issues when
proxying packets.  This needs to be updated.  

[BA] There are several situations in which the law of "conservation of
packets"
could be violated on an end-to-end basis (e.g. where more packets could
enter
the system than could leave it on a short-term basis): 

a. Where TCP is used between proxies, it is possible that the bandwidth
consumed by incoming UDP packets destined to a given realm could exceed the
sending 
rate of a single TCP connection to that realm, based on the window size/RTT
estimate. 

b.  It is possible for the incoming rate of TCP packets destined to a given
realm to exceed the UDP throughput achievable using the transport guidelines
established
in RFC 5080.  This could happen, for example, where the TCP window between
proxies
has opened, but packet loss is being experienced on the UDP leg, so that the
effective congestion window on the UDP side is 1. 

Intrinsically, proxy systems operate with multiple control loops instead of
one end-to-end
loop, and so are less stable.  This is true even for TCP-TCP proxies.  As
discussed in 
RFC 3539, the only way to achieve stability equivalent to a single TCP
connection is to 
mimic the end-to-end behavior of a single TCP connection.  This typically 
is not achievable with an application-layer RADIUS implementation regardless
of transport. 


There are also head-of-line blocking issues when there are sudden spikes of
traffic.

[BA] HoL blocking can occur whenever there is packet loss on a TCP
connection.
This need not necessarily correspond to sudden RADSEC traffic spikes, but
could
be due to background traffic. 

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

[BA] I will send a message to the tsv-dir requesting assignment of a
Transport
Advisor. 

  3) TCP && RadSec.

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

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

[BA] My suggestion would be to coalesce sections 1.1 and 1.2 into
an Applicability section in which the intent of the document
(to address transport relating to RADSEC) could be described, along with the
RECOMMENDED and NOT RECOMMENDED uses. I'm not sure that a MUST NOT is
necessarily
required; perhaps a NOT RECOMMENDED might be sufficient, along with a
reference
to the caveats described in Section 2.4 of RFC 2865. 

Another way to make it clear that "raw TCP" is not recommended for prime
time
would be to classify the document as Experimental.  If the document is
largely 
focused on use with RADSEC, this would be consistent with RADSEC's
Experimental
status.

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

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

[BA] My advice would be to describe the Status-Server ID issues in
that document, and talk about some of the Transport implications in
this one.  Once we've understood the implications and alternatives,
we can explore whether a new packet code is warranted.  However, the
current charter of the Status-Server document is to describe the
existing protocol rather than attempting to fix/radically improve it. 

  Alan DeKok.

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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Dec 2008 06:20:05 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Meeting minutes?
Date: Wed, 10 Dec 2008 22:19:40 -0800
MIME-Version: 1.0

--_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


If you took minutes of the IETF 73 RADEXT WG meeting=2C please send them to=
 me and David ASAP. =

--_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
If you took minutes of the IETF 73 RADEXT WG meeting=2C please send them to=
 me and David ASAP. </body>
</html>=

--_bd1ca3bd-a40e-4006-ab40-dcc054b40bc1_--

--
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, 11 Dec 2008 06:02:59 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_0b3d4815-f3cd-4be3-afde-50906852ae16_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Summary of WG review of "RADIUS over TCP" document
Date: Wed, 10 Dec 2008 22:02:34 -0800
MIME-Version: 1.0

--_0b3d4815-f3cd-4be3-afde-50906852ae16_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


A call for review of the "RADIUS over TCP" document was issued on November =
4=2C 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00731.html) and concluded =
on=20
November 19=2C 2008.=20
=20
Based on the response to the call for review=2C the document is accepted as=
 a=20
RADEXT WG work item=2C and should be resubmitted as draft-ietf-radext-tcp-t=
ransport-00.txt.
=20
Note that a number of transport issues were raised during the IETF 73 discu=
ssion
of this document=2C by Magnus Westerlund (Transport AD) and others.   It is
therefore recommended that this document receive an early review by the
Transport Directorate.  =

--_0b3d4815-f3cd-4be3-afde-50906852ae16_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
A call for review of the "RADIUS over TCP" document was issued on November =
4=2C 2008<BR>
(see <A href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00731.html">htt=
p://ops.ietf.org/lists/radiusext/2008/msg00731.html</A>) and concluded on <=
BR>
November 19=2C 2008. <BR>
&nbsp=3B<BR>
Based on the response to the call for review=2C the document is accepted as=
 a <BR>
RADEXT WG work item=2C and should be resubmitted as draft-ietf-radext-tcp-t=
ransport-00.txt.<BR>
&nbsp=3B<BR>
Note that a number of transport issues were raised during the IETF 73 discu=
ssion<BR>
of this document=2C by Magnus Westerlund (Transport AD) and others.&nbsp=3B=
&nbsp=3B It is<BR>
therefore recommended that&nbsp=3Bthis document receive an early&nbsp=3Brev=
iew by the<BR>
Transport Directorate.&nbsp=3B&nbsp=3B<BR></body>
</html>=

--_0b3d4815-f3cd-4be3-afde-50906852ae16_--

--
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, 11 Dec 2008 05:58:40 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Summary of RADEXT WG last call on the RADSEC document
Date: Wed, 10 Dec 2008 21:58:23 -0800
MIME-Version: 1.0

--_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RADEXT WG last call on the RADSEC document was announced on October 27=2C 2=
008
(see http://ops.ietf.org/lists/radiusext/2008/msg00691.html)=2C and conclud=
ed on November 25=2C 2008.=20
=20
The following issues were raised during WG last call:
=20




Issue 281
Pending
Technical
SRV vs. A/AAAA RRs
Stefan Winter

Issue 282
No Discussion
Technical
Comments
Joe Salowey
=20
As noted by Dan Romascanu in his posting to the list (see http://ops.ietf.o=
rg/lists/radiusext/2008/msg00793.html)=2C
the document needs to address issues of backward compatibility and rollback=
 attacks. =

--_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call on the RADSEC document was announced on October 27=2C 2=
008<BR>
(see <A href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00691.html">htt=
p://ops.ietf.org/lists/radiusext/2008/msg00691.html</A>)=2C and concluded o=
n November 25=2C 2008. <BR>
&nbsp=3B<BR>
The following issues were raised during WG last call:<BR>
&nbsp=3B<BR>

<TABLE id=3Dtable57 height=3D1 width=3D762 border=3D1>
<TBODY>
<TR>
<TD width=3D116 height=3D62>Issue 281</TD>
<TD width=3D143 height=3D34>Pending</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 281"><FONT color=3D#0066cc>SRV vs. A/AAAA RRs</FONT>=
</A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[e-mail]"><FO=
NT color=3D#0066cc>Stefan Winter</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 282</TD>
<TD width=3D143 height=3D34>No Discussion</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 282"><FONT color=3D#0066cc>Comments</FONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[e-mail]"><FONT col=
or=3D#0066cc>Joe Salowey</FONT></A></TD></TR></TBODY></TABLE><BR>
&nbsp=3B<BR>
As&nbsp=3Bnoted by Dan Romascanu in his posting to the list (see <A href=3D=
"http://ops.ietf.org/lists/radiusext/2008/msg00793.html">http://ops.ietf.or=
g/lists/radiusext/2008/msg00793.html</A>)=2C<BR>
the document needs to address issues of backward compatibility and rollback=
 attacks. <BR></body>
</html>=

--_a7f0b0a4-86bf-432f-bdf7-5e84317c8e84_--

--
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, 11 Dec 2008 05:53:31 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_41427d71-001a-4415-99e7-eb1eaf320830_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Summary of RADEXT WG Last Call on Status-Server Document
Date: Wed, 10 Dec 2008 21:53:11 -0800
MIME-Version: 1.0

--_41427d71-001a-4415-99e7-eb1eaf320830_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RADEXT WG last call on the Status-Server document was announced on November=
 3=2C 2008
(see http://ops.ietf.org/lists/radiusext/2008/msg00721.html) and concluded =
on November 25=2C 2008.=20
=20
The following issues were raised during WG last call:
=20




Issue 283
No Discussion
Technical
Status-Server Comments
Greg Weber

Issue 285
Pending
Technical
Question
Alan DeKok

Issue 288
Pending
Technical
Review
Stig Venaas

Issue 289
No Discussion
Editorial
Editorial Comments
Stig Venaas
Overall=2C as was discussed during IETF 73=2C it should be understood that =
the goal of this document is to document the
existing Status-Server protocol (which was first developed by Ascend Commun=
ications in the mid-1990s).  Therefore
inclusion of non-implemented functionality in this document is out of scope=
.=20



 EMAILING FOR THE GREATER GOODJoin me=

--_41427d71-001a-4415-99e7-eb1eaf320830_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call on the Status-Server document was announced on November=
 3=2C 2008<BR>
(see <A href=3D"http://ops.ietf.org/lists/radiusext/2008/msg00721.html">htt=
p://ops.ietf.org/lists/radiusext/2008/msg00721.html</A>) and concluded on N=
ovember 25=2C 2008. <BR>
&nbsp=3B<BR>
The following issues were raised during WG last call:<BR>
&nbsp=3B<BR>

<TABLE id=3Dtable58 height=3D1 width=3D762 border=3D1>
<TBODY>
<TR>
<TD width=3D116 height=3D62>Issue 283</TD>
<TD width=3D143 height=3D34>No Discussion</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 283"><FONT color=3D#0066cc>Status-Server Comments</F=
ONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[e-mail]"><FONT colo=
r=3D#0066cc>Greg Weber</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 285</TD>
<TD width=3D143 height=3D34>Pending</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 285"><FONT color=3D#0066cc>Question</FONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[e-mail]"><F=
ONT color=3D#0066cc>Alan DeKok</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 288</TD>
<TD width=3D143 height=3D34>Pending</TD>
<TD width=3D80 height=3D62>Technical</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 288"><FONT color=3D#0066cc>Review</FONT></A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[e-mail]"><FONT=
 color=3D#0066cc>Stig Venaas</FONT></A></TD></TR>
<TR>
<TD width=3D116 height=3D62>Issue 289</TD>
<TD width=3D143 height=3D34>No Discussion</TD>
<TD width=3D80 height=3D62>Editorial</TD>
<TD width=3D276 height=3D62><A href=3D"http://www.drizzle.com/~aboba/RADEXT=
/radissues2.html#Issue 289"><FONT color=3D#0066cc>Editorial Comments</FONT>=
</A></TD>
<TD width=3D111 height=3D51><A href=3D"mailto:[e-mail]"><FONT=
 color=3D#0066cc>Stig Venaas</FONT></A></TD></TR></TBODY></TABLE><BR>
<BR>Overall=2C as&nbsp=3Bwas discussed during IETF 73=2C it should be under=
stood that the goal of this document is to document the<BR>
existing Status-Server protocol (which was first developed by Ascend Commun=
ications in the mid-1990s).&nbsp=3B Therefore<BR>
inclusion of non-implemented functionality in this document is out of scope=
. <BR><BR><BR><BR><BR>
<TABLE style=3D"BORDER-TOP: black 1px solid=3B FONT-WEIGHT: bold=3B FONT-FA=
MILY: 'Segoe UI'=2CTahoma=2Csan-serif">
<TBODY>
<TR>
<TD><A style=3D"FONT-SIZE: 9pt=3B COLOR: #0184cb=3B TEXT-DECORATION: none" =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood=
"><IMG style=3D"BORDER-TOP-STYLE: none=3B BORDER-RIGHT-STYLE: none=3B BORDE=
R-LEFT-STYLE: none=3B BORDER-BOTTOM-STYLE: none" alt=3D"i'm" src=3D"http://=
gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE GREATER GOOD<=
BR><SPAN style=3D"PADDING-RIGHT: 24px=3B PADDING-LEFT: 24px=3B FONT-SIZE: 8=
pt=3B PADDING-BOTTOM: 0px=3B COLOR: #3fb555=3B PADDING-TOP: 0px=3B TEXT-DEC=
ORATION: underline">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>=

--_41427d71-001a-4415-99e7-eb1eaf320830_--

--
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, 11 Dec 2008 05:49:39 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_01e7b896-ca72-4c09-84e8-be8fd481b1ae_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Issue 290: RFC 4005bis Dependency
Date: Wed, 10 Dec 2008 21:48:35 -0800
MIME-Version: 1.0

--_01e7b896-ca72-4c09-84e8-be8fd481b1ae_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue 290: 4005bis DependencySubmitter name: Bernard Aboba Submitter email =
address: [e-mail] Date first submitted:  December 10=2C 20=
08Reference:   http://www.watersprings.org/pub/id/draft-mitton-diameter-rad=
ius-vsas-01.txtDocument: EXTATTR Comment type: T Priority: S  Section:  7Ra=
tionale/Explanation of issue:
=20
Section 7 of this document contains the following text on Diameter Consider=
ations:   Since the Extended Attributes are encoded as Vendor-Specific RADI=
US
   Attributes (see [IANA])=2C no special handling is required by Diameter
   [RFC3588] entities=3B see [RFC4005] for details on the Diameter
   treatment of RADIUS VSAs.
Unfortunately=2C this text is wrong.  RFC 4005 does not in fact describe ho=
w to translate RADIUS Extended Attributes to Diameter.=20
RFC 4005 Section 9 defines the RADIUS/Diameter gateway.   Unfortunately=2C =
Section 9.6 assumes that RADIUS VSAs follow the format recommended in RFC 2=
865=2C Section 5.26.  As noted in Section 9.6.2:   The Diameter AVP will co=
nsist of the following fields:

      Diameter Flags: V=3D1=2C M=3D0=2C P=3D0
      Diameter Vendor code =3D RADIUS VSA Vendor code
      Diameter AVP code =3D RADIUS VSA Vendor type code
      Diameter AVP length =3D length of AVP (header + data)
      Diameter Data =3D RADIUS VSA vendor data

   Note that the VSAs are considered optional by RADIUS rules=2C and this
   specification does not set the Mandatory flag.  If an implementor
   desires a VSA be made mandatory because it represents a required
   service policy=2C the RADIUS gateway should have a process to set the
   bit on the Diameter side.

   If the RADIUS receiving code knows of vendor specific field
   interpretations for the specific vendor=2C it may employ them to parse
   an extended AVP code or data length.  Otherwise the recommended
   standard fields will be used.

   Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs.
Since the RADIUS Extended Attribute format does not conform to the recommen=
ded RADIUS VSA format in RFC 2865=2C RFC 4005 Section 9.6.2 does not apply.=
  As a result=2C an alternative mechanism for translating RADIUS Extended A=
ttributes to Diameter needs to be defined (RFC 4005bis).  The RADIUS Extend=
ed Attributes document has a normative dependency on this document (which p=
robably should be handled in the DIME WG). =

--_01e7b896-ca72-4c09-84e8-be8fd481b1ae_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<STRONG><A name=3D"Issue 290"></A>Issue 290: 4005bis Dependency</STRONG><BR=
>Submitter name: Bernard Aboba <BR>Submitter email address: bernard_aboba@h=
otmail.com <BR>Date first submitted:&nbsp=3B December 10=2C 2008<BR>Referen=
ce: &nbsp=3B http://www.watersprings.org/pub/id/draft-mitton-diameter-radiu=
s-vsas-01.txt<BR>Document: EXTATTR <BR>Comment type: T <BR>Priority: S&nbsp=
=3B <BR>Section:&nbsp=3B&nbsp=3B7<BR>Rationale/Explanation of issue:<BR>
&nbsp=3B<BR>
Section 7 of this document contains the following text on Diameter Consider=
ations:<BR><PRE class=3Dnewpage>   Since the Extended Attributes are encode=
d as Vendor-Specific RADIUS
   Attributes (see [<A title=3D'"RADIUS TYPES"' href=3D"http://tools.ietf.o=
rg/html/draft-ietf-radext-extended-attributes-05#ref-IANA"><FONT color=3D#0=
066cc>IANA</FONT></A>])=2C no special handling is required by Diameter
   [<A title=3D'"Diameter Base Protocol"' href=3D"http://tools.ietf.org/htm=
l/rfc3588"><FONT color=3D#0066cc>RFC3588</FONT></A>] entities=3B see [<A ti=
tle=3D'"Diameter Network Access Server Application"' href=3D"http://tools.i=
etf.org/html/rfc4005"><FONT color=3D#0066cc>RFC4005</FONT></A>] for details=
 on the Diameter
   treatment of RADIUS VSAs.</PRE>
Unfortunately=2C this text is wrong.&nbsp=3B RFC 4005 does not in fact desc=
ribe how to translate RADIUS Extended Attributes to Diameter. <BR>
<A href=3D"http://tools.ietf.org/html/rfc4005"><FONT color=3D#0066cc>RFC 40=
05</FONT></A> Section 9 defines the RADIUS/Diameter gateway.&nbsp=3B&nbsp=
=3B Unfortunately=2C Section 9.6 assumes that RADIUS VSAs follow the format=
 recommended in RFC 2865=2C Section 5.26.&nbsp=3B As noted in Section 9.6.2=
:<BR><PRE class=3Dnewpage>   The Diameter AVP will consist of the following=
 fields:

      Diameter Flags: V=3D1=2C M=3D0=2C P=3D0
      Diameter Vendor code =3D RADIUS VSA Vendor code
      Diameter AVP code =3D RADIUS VSA Vendor type code
      Diameter AVP length =3D length of AVP (header + data)
      Diameter Data =3D RADIUS VSA vendor data

   Note that the VSAs are considered optional by RADIUS rules=2C and this
   specification does not set the Mandatory flag.  If an implementor
   desires a VSA be made mandatory because it represents a required
   service policy=2C the RADIUS gateway should have a process to set the
   bit on the Diameter side.

   If the RADIUS receiving code knows of vendor specific field
   interpretations for the specific vendor=2C it may employ them to parse
   an extended AVP code or data length.  Otherwise the recommended
   standard fields will be used.

   Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs.</PRE>
<P class=3Dstyle7>Since the RADIUS Extended Attribute format does not confo=
rm to the recommended RADIUS VSA format in RFC 2865=2C RFC 4005 Section 9.6=
.2 does not apply.&nbsp=3B As a result=2C an alternative mechanism for tran=
slating RADIUS Extended Attributes to Diameter needs to be defined (RFC 400=
5bis).&nbsp=3B The RADIUS Extended Attributes document has a normative depe=
ndency on this document (which probably should be handled in the DIME WG). =
</P></body>
</html>=

--_01e7b896-ca72-4c09-84e8-be8fd481b1ae_--

--
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, 08 Dec 2008 16:01:45 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2008 17:01:02 +0100
From: Stig Venaas <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081127)
MIME-Version: 1.0
To: Stefan Winter <[e-mail]>
Cc: "David B. Nelson" <[e-mail]>, [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stefan Winter wrote:
> Hi,
> 
>>>   Maybe it's best to say that authentication ports respond with
>>> Access-Accept, and accounting ports respond with Accounting-Response.
>>> Anything else is NOT RECOMMENDED.
>>>     
>> That would certainly cover all bases.
>>   
> 
> That text sounds good to me.

I am also OK with that.

It would have been easier to implement this correctly if there were
something distinguishing the requests (other than they being received
at auth or acc ports).

Stig

> 
> Stefan
> 


--
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, 08 Dec 2008 15:14:22 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2008 16:14:02 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

>>   Maybe it's best to say that authentication ports respond with
>> Access-Accept, and accounting ports respond with Accounting-Response.
>> Anything else is NOT RECOMMENDED.
>>     
>
> That would certainly cover all bases.
>   

That text sounds good to me.

Stefan

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

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 08 Dec 2008 15:02:06 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: RADEXT WG Last Call on Status-Server Document
Date: Mon, 8 Dec 2008 10:01:17 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <67D346FA058B45A1BA95CCE38E1B0A4B@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AclZRD4GwUL/pGZ5RIyl29ZWMLrXhQAAFpfA

Alan DeKok writes...

> > IIRC, the consensus of the room at the RADEXT WG meeting at
> > IETF-73 was that this was a bad idea.
 
> OK, if the consensus is that it's a bad idea, that can be
> removed from the draft.

As usual, tentative consensus from an IETF meeting needs to be confirmed on
the list.  This would seem to be a good opportunity to do so.

Consensus Call:  Should we document the following as "recognized" RADIUS
behavior?

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

> > Where do we draw the line?
> 
>   We'd like to draw it at things that are crazy.  But we're
> too late for that.

Too late in terms of what folks have implemented, yes.  Not too late in
terms of what we publish in an RFC and recognize as "recommended" behavior.
Not all bugs need to be promoted to feature status.
 
>   Maybe it's best to say that authentication ports respond with
> Access-Accept, and accounting ports respond with Accounting-Response.
> Anything else is NOT RECOMMENDED.

That would certainly cover all bases.
 
>   Comments?

Yes, comments from others, please.



--
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, 08 Dec 2008 14:50:35 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2008 15:49:57 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Hmm.  IIRC, the consensus of the room at the RADEXT WG meeting at IETF-73
> was that this was a bad idea.  I realize this was probably the only
> substantive comment received during WGLC on this draft.  However, it's only
> one opinion.

  OK, if the consensus is that it's a bad idea, that can be removed from
the draft.

>>>    Some server implementations accept both Access-Request and
>>>    Accounting-Request packets on the same port, and do not
>>>    distinguish between "authentication only" ports, and "accounting 
>>>    only" ports.  Those implementations SHOULD reply to Status-Server 
>>>    packets with an Access-Accept packet.
> 
> Yeah, but isn't that extremely broken behavior?

  Umm... if you say so.  I won't comment.

>  I know we're documenting
> existing behavior, but do we have to document the most broken parts?  I
> thought the idea was to support the needs of RADSEC with respect to server
> "liveness", and in doing so, re-use an existing mechanism.  Otherwise, there
> are probably lots of other broken behaviors in RADIUS implementations that
> could be documented.  You know... "A bug, once documented, becomes a
> feature".  :-(  Where do we draw the line?

  We'd like to draw it at things that are crazy.  But we're too late for
that.

  Maybe it's best to say that authentication ports respond with
Access-Accept, and accounting ports respond with Accounting-Response.
Anything else is NOT RECOMMENDED.

  Comments?

  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, 08 Dec 2008 14:43:29 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: RADEXT WG Last Call on Status-Server Document
Date: Mon, 8 Dec 2008 09:42:16 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <6D3A8B1186E24EECA9B782BE9F2E6521@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AclZMirqOnzGXS2iRaqweOzkRWtgHQADwxIg

Alan DeKok writes...

> > I think clients should allow Access-Accept responses to 
> > status-server messages sent to the accounting port. Even
> > if it's not the expected message, it shows that the server
> > is alive.
> 
>   Ok.  I've updated the draft, and will issue a new version
> shortly.

Hmm.  IIRC, the consensus of the room at the RADEXT WG meeting at IETF-73
was that this was a bad idea.  I realize this was probably the only
substantive comment received during WGLC on this draft.  However, it's only
one opinion.

<WG Chair hat on>

I think document editors need to be careful to avoid adding technical
changes to WG drafts at the request of just one commenter.  If that one
comment happens to represent WG consensus, then fine.  If the one comment is
simply one individual's opinion, then maybe not so fine.  I also realize
that in RADEXT, these days, it's sometimes hard to distinguish.  :-(

<WG Chair hat off>

> > Also, towards the end of section 4.2 the draft says:
> >
> >    Some server implementations accept both Access-Request and
> >    Accounting-Request packets on the same port, and do not
> >    distinguish between "authentication only" ports, and "accounting 
> >    only" ports.  Those implementations SHOULD reply to Status-Server 
> >    packets with an Access-Accept packet.

Yeah, but isn't that extremely broken behavior?  I know we're documenting
existing behavior, but do we have to document the most broken parts?  I
thought the idea was to support the needs of RADSEC with respect to server
"liveness", and in doing so, re-use an existing mechanism.  Otherwise, there
are probably lots of other broken behaviors in RADIUS implementations that
could be documented.  You know... "A bug, once documented, becomes a
feature".  :-(  Where do we draw the line?



--
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, 08 Dec 2008 12:41:31 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2008 13:41:16 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Stig Venaas <[e-mail]>
CC: Bernard Aboba <[e-mail]>, [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

  Maybe.  It's still a RADIUS packet, and the term "packet" is
consistent with RFC 2865.

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

  Fixed, thanks.

> TOC formatting is slightly broken (2.3.1/2.3.2).

  I'll fix that in the next rev.

> Section 2.3.2 has no title (missing both in TOC and body).
> 
> In 2.2:
> 
>    A similar solution for the problem of querying server status may be
>    for a NAS to send specially formed Accounting-Request packets to a
>    RADIUS servers authentication port.  The NAS can then look for a
>           ^^^^^^^^^^^^^^^^^^^^^^
>  server's accounting

  Fixed, thanks.

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

  Fixed, thanks.

> In 4.2:
> 
>    The server MAY prioritize the handling Status-Server queries over the
> 
> Insert "of"                            ^^^^^
> 
>    The server MAY decide to not respond to a Status-Server, depending on
> Insert "packet" or "message"                        ^^^^^^^

  Fixed, thanks.

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

  Fixed, thanks.

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

  Fixed, thanks.

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

  Fixed, thanks.

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

  Fixed, thanks.

  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, 08 Dec 2008 12:38:02 +0000
Message-ID: <[e-mail]>
Date: Mon, 08 Dec 2008 13:37:00 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Stig Venaas <[e-mail]>
CC: Bernard Aboba <[e-mail]>, [e-mail]
Subject: Re: RADEXT WG Last Call on Status-Server Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

  Ok.  I've updated the draft, and will issue a new version shortly.

> Also, towards the end of section 4.2 the draft says:
> 
>    Some server implementations accept both Access-Request and
>    Accounting-Request packets on the same port, and do not distinguish
>    between "authentication only" ports, and "accounting only" ports.
>    Those implementations SHOULD reply to Status-Server packets with an
>    Access-Accept packet.
> 
> Due to this, I think the text in 2.3.2 is too strict:
> 
>    The Status-Server packet MUST contain a Message-Authenticator
>    attribute for security.  The response (if any) to a Status-Server
>    packet sent to an accounting port MUST be an Accounting-Response
>    packet.  The list of attributes that are permitted in the Accounting-
>    Response packet is given in the Table of Attributes in Section 6,
>    below.
> 
> I think the second MUST should be a SHOULD. Or at the very least, in
> section 4.1 where it talks about clients being liberal at what they
> accept. Add a note that they SHOULD accept this.

  OK.  I've done that:

      The response (if any) to a Status-Server
      packet sent to an accounting port SHOULD be an Accounting-Response
      packet, and MAY be an Access-Accept packet.  Other response packet
      codes MUST NOT be used.

  With similar text for authentication packets.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 04 Dec 2008 16:30:35 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-ietf-radext-crypto-agility-requirements-01
Date: Thu, 4 Dec 2008 11:29:25 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <51074C31BB48473B8A243AE7EF9DABEE@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AclVT3db/JuB0dQ7T4enW25YwRxzxwA3dc9Q

Here are some editorial nits that I received in a private e-mail message:

> (1)  Section 3
> 
> In the first line of the first paragraph, please correct the
> typo:     s/MD5-baed/MD5-based/  .
>                            ^
> 
> (2)  Section 4.6
> 
> The bullets from a grammar point of view are made up of a complete
> sentence each, and start with a capital letter.
> Consequently, a trailing period should be added to all (4) bullets.


--
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, 02 Dec 2008 01:51:07 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: FW: [Technical Errata Reported] RFC4282 (1623)
Date: Mon, 1 Dec 2008 17:50:00 -0800
Message-ID: <000201c95420$49866180$dc932480$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AclUF0cQDt6tTw+9Qm2ZtP4TK9Cq1AABio9A
Content-Language: en-us

FYI. 

-----Original Message-----
From: RFC Errata System [mailto:[e-mail]] 
Sent: Monday, December 01, 2008 4:45 PM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [Technical Errata Reported] RFC4282 (1623)


The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1623

--------------------------------------
Type: Technical
Reported by: Martin Thomson <[e-mail]>

Section: 2.1

Original Text
-------------
   realm       =  1*( label "." ) label

Corrected Text
--------------
   realm       =  *( label "." ) label

Notes
-----
The ABNF for realm forces the inclusion of two labels, which is not
consistent with RFC 1034, which allows just one:
  <subdomain> ::= <label> | <subdomain> "." <label>

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


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