Subject: Re: Discussion of Issue 146 (fwd)
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Date: Wed, 30 Nov 2005 16:40:20 -0500

"Nelson, David" <[email-masked]> wrote:
> So then we're looking at clarifying existing behavior as described in
> the current RFCs, rather than correcting any potential errata in those
> RFCs?

  One additional issue I noticed was that RFC 2618 has a counter for
pending requests, but RFC 2619 does not.  However, the equations at
the top of page 9 in RFC 2619 do mention "pending" requests.

  Do we want to add "pending" requests to rfc2619bis and rfc2621bis?

  Alan DeKok.

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

Delivery-date: Wed, 30 Nov 2005 15:54:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Discussion of Issue 146 (fwd)
Date: Wed, 30 Nov 2005 10:53:08 -0500
From: "Nelson, David" <[email-masked]>
To: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>, <[email-masked]>

Nagi Reddy Jonnala writes...

> I'm not in favor of deprecating and adding the new objects either.

So then we're looking at clarifying existing behavior as described in
the current RFCs, rather than correcting any potential errata in those
RFCs?

> The comments I quoted hold good for the then implementation I worked
> on. I don't know what other implementation's interpretations are.

Alan DeKok was kind enough to share his implementation report.  Perhaps
others would be so kind as to follow suit?  (Hint, hint.)

> One way could be to do the math once again and ensure that the
> equations hold good for at least the intended interpretations.=20
> If there is a problem, then there is something wrong and a=20
> clarification should be added.

My opinion is that if the equations are wrong, and we wish to change
them, then the correct thing to do is to deprecate the objects.
Remember, the MIB must pass MIB Doctor and IESG review, so a convenient
"shortcut" for the WG may not pass MIB review.  If the equations are
wrong, and we simply wish to point that out, we could retain the current
objects.

-- Dave

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

Delivery-date: Wed, 30 Nov 2005 09:23:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Discussion of Issue 146 (fwd)
Date: Wed, 30 Nov 2005 14:52:18 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>, <[email-masked]>

Dave,

I'm not in favor of deprecating and adding the new objects either. The
comments I quoted hold good for the then implementation I worked on. I
don't know what  other implementation's interpretations are.=20

One way could be to do the math once again and ensure that the equations
hold good for at least the intended interpretations. If there is a
problem, then there is something wrong and a clarification should be
added.

Thanks
Nagi.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, November 28, 2005 10:28 PM
> To: [email-masked]
> Subject: Discussion of Issue 146 (fwd)
>=20
> The text of RADEXT Issue 146 is quoted below.
>=20
> It is not clear to me what action should be taken on the=20
> three sub- issues of Issue 146.  This leads to the "can be=20
> discussed now" part.
>=20
> >From a procedural perspective, if we are to redefine the=20
> equations used
> to derive counter objects, we have changed the definition of=20
> the objects.  The correct way to change the definition of=20
> existing objects is to deprecate the olds ones and add new=20
> ones.  Perhaps this formality can be waived with objects that=20
> are "advisory" in nature, such as statistics.  Advice would=20
> be appreciated.
>=20
> >From a practical perspective, it would be helpful to know=20
> what has been
> implemented.  I'd like to request that anyone on the list who=20
> has implemented RFC 2618-21 report as to how these objects=20
> were implemented.
> If the implementation matches the disputed text, then perhaps=20
> the better thing to do is to add clarification as to the=20
> existing behavior.
>=20
> That does not, of course, preclude deprecating the objects=20
> and adding new ones with more desirable behavior.
>=20
> Guidance is solicited.
>=20
> -- Dave
>=20
> <quote>
>=20
> Issue-1:
>=20
> Stefaan asked:
>=20
> >Some questions we have regarding the existing RFCs (since you are=20
> >updating these) we found while writing our draft:
> >
> >1) Is the definition of TotalIncomingPackets in RFC2618 on page 6=20
> >correct? I believe there is something wrong with it.
>=20
> Glen replied:
>=20
> I think that you are right. With the curent definition, it=20
> appears that "Successfully Received" could be negative, since=20
> we're subtracting counters from TotalIncomingPackets that=20
> were not include in the sum.
> Also, I guess that "AccessRequests + PendingRequests +=20
> ClientTimeouts =3D Successfully Received" just below should=20
> read "AccessRequests + PendingRequests + ClientTimeouts =3D=20
> Successfully Transmitted".
>=20
> Nagi commented:
>=20
> My understanding is that RFC-2618 considers that an Access=20
> Response (Accept or Reject or Challenge) counter MUST be=20
> incremented before it is validated. i.e., either one of=20
> Malformed responses or bad authenticators
>=20
> or packets dropped counters will be incremented if the packet=20
> is invalid.
>=20
> Do you interpret the same from the RFC-2618. If yes, I would=20
> like to know what are the reasons for this. Isn't that an=20
> Access Response counter MUST be incremented only after the=20
> packet is found *valid*.
> If you are convinced that the approach in RFC-2618 is OK,=20
> then I would say that the first two equations hold good.=20
> i.e., Your statement above (saying Successfully_Received=20
> could be negative) is incorrect. Am I right? or missing something?
>=20
> Issue-2:
>=20
> Stefaan asked:
>=20
> >3) radiusAuthClientPendingRequests: upon retransmission this=20
> counter is=20
> >decremented. So a retransmitted packet is not considered as being=20
> >pending, although such restransmissions can still be considered as=20
> >being pending requests.
>=20
> Glen replied:
>=20
> Yup, it probably shouldn't be decremented on retransmissions,=20
> especially since it's already decremented on timeouts.
>=20
> Nagi commented:
>=20
> My understanding is that Pending requests should be=20
> decremented on receiving an Access response and on an expiry=20
> of timeout. It looks obvious to me that Pending requests=20
> should be incremented on a retransmission (to the same server).
>=20
> Please see the text
>=20
> "This variable is incremented when an Access-Request is sent=20
> and decremented due to receipt of an Acess-Accept,=20
> Access-Reject or Access-Challenge, a timeout or retransmission."
>=20
> I suspect that the text is misleading. The text should be:
>=20
> "This variable is incremented when an Access-Request and=20
> retransmission is sent and decremented due to receipt of an=20
> Acess-Accept, Access-Reject or Access-Challenge, a timeout "
>=20
> Do you guys agree?
>=20
> Issue-3:
>=20
> See the equation:
>=20
> AccessRequests + PendingRequests + ClientTimeouts =3D=20
> Successfully Received
>=20
> I agree with you that left hand side value should be equal to=20
> "Successfully Transmitted". Also "AccessRequests +=20
> AccessRetransmissions =3D Successfully Transmitted" equation=20
> holds good. =3D
>=20
> Right?
>=20
> Requested changes:
>=20
> Nagi and Stefaan raised the issue and suggested some text to=20
> resolve the issue in the above thread. Please note that a=20
> conclusion was not reached and can be discussed now.
>=20
> </quote>
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Mon, 28 Nov 2005 19:38:27 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Discussion of Issue 146 (fwd) 
Date: Mon, 28 Nov 2005 14:42:15 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> From a practical perspective, it would be helpful to know what has been
> implemented.  I'd like to request that anyone on the list who has
> implemented RFC 2618-21 report as to how these objects were implemented.

  We've implemented pieces of RFC 2619, and RFC 2621 in FreeRADIUS.

  Due to implementation issues, it doesn't count MalformedRequests,
BadAuthenticators, or PacketsDropped.  It does count Requests,
InvalidRequests, UnknownTypes, and DupRequests.

  Requests is incremented for every well-formed packet that is
received on a port.

  InvalidRequests is incremented for every packet received from an
unknown address.

  UnknownTypes is incremented for every packet other than
Access-Request/Accounting-Request that is sent to the
authentication/accounting port.

  DupRequests is incremented for every duplicate Access-Request.

  As a result of the implementation issues, the suggested relations
between the counters don't add up.  There have been no complaints, or
discussion of this issue from administrators.

  Alan DeKok.

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

Delivery-date: Mon, 28 Nov 2005 16:57:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Discussion of Issue 146 (fwd)
Date: Mon, 28 Nov 2005 08:57:35 -0800

The text of RADEXT Issue 146 is quoted below.

It is not clear to me what action should be taken on the three sub-
issues of Issue 146.  This leads to the "can be discussed now" part.

>From a procedural perspective, if we are to redefine the equations used
to derive counter objects, we have changed the definition of the
objects.  The correct way to change the definition of existing objects
is to deprecate the olds ones and add new ones.  Perhaps this formality
can be waived with objects that are "advisory" in nature, such as
statistics.  Advice would be appreciated.

>From a practical perspective, it would be helpful to know what has been
implemented.  I'd like to request that anyone on the list who has
implemented RFC 2618-21 report as to how these objects were implemented.
If the implementation matches the disputed text, then perhaps the better
thing to do is to add clarification as to the existing behavior.

That does not, of course, preclude deprecating the objects and adding
new ones with more desirable behavior.

Guidance is solicited.

-- Dave

<quote>

Issue-1:

Stefaan asked:

>Some questions we have regarding the existing RFCs (since you are
>updating these) we found while writing our draft:
>
>1) Is the definition of TotalIncomingPackets in RFC2618 on page 6
>correct? I believe there is something wrong with it.

Glen replied:

I think that you are right. With the curent definition, it appears that
"Successfully Received" could be negative, since we're subtracting
counters from TotalIncomingPackets that were not include in the sum.
Also, I guess that "AccessRequests + PendingRequests + ClientTimeouts =
Successfully Received" just below should read "AccessRequests +
PendingRequests + ClientTimeouts = Successfully Transmitted".

Nagi commented:

My understanding is that RFC-2618 considers that an Access Response
(Accept or Reject or Challenge) counter MUST be incremented before it is
validated. i.e., either one of Malformed responses or bad authenticators

or packets dropped counters will be incremented if the packet is
invalid.

Do you interpret the same from the RFC-2618. If yes, I would like to
know what are the reasons for this. Isn't that an Access Response
counter MUST be incremented only after the packet is found *valid*.
If you are convinced that the approach in RFC-2618 is OK, then I would
say that the first two equations hold good. i.e., Your statement above
(saying Successfully_Received could be negative) is incorrect. Am I
right? or missing something?

Issue-2:

Stefaan asked:

>3) radiusAuthClientPendingRequests: upon retransmission this counter
>is decremented. So a retransmitted packet is not considered as being
>pending, although such restransmissions can still be considered as
>being pending requests.

Glen replied:

Yup, it probably shouldn't be decremented on retransmissions, especially
since it's already decremented on timeouts.

Nagi commented:

My understanding is that Pending requests should be decremented on
receiving an Access response and on an expiry of timeout. It looks
obvious to me that Pending requests should be incremented on a
retransmission (to the same server).

Please see the text

"This variable is incremented when an Access-Request is sent and
decremented due to receipt of an Acess-Accept, Access-Reject or
Access-Challenge, a timeout or retransmission."

I suspect that the text is misleading. The text should be:

"This variable is incremented when an Access-Request and retransmission
is sent and decremented due to receipt of an Acess-Accept, Access-Reject
or Access-Challenge, a timeout "

Do you guys agree?

Issue-3:

See the equation:

AccessRequests + PendingRequests + ClientTimeouts = Successfully
Received

I agree with you that left hand side value should be equal to
"Successfully Transmitted". Also "AccessRequests +
AccessRetransmissions = Successfully Transmitted" equation holds good. =

Right?

Requested changes:

Nagi and Stefaan raised the issue and suggested some text to resolve
the issue in the above thread. Please note that a conclusion
was not reached and can be discussed now.

</quote>

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

Delivery-date: Mon, 28 Nov 2005 15:26:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Conclusion of RADEXT WG last call on the RADIUS IPv6 MIBs
Date: Mon, 28 Nov 2005 07:26:27 -0800

RADEXT WG last call has concluded on the following documents:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt

The following issues were raised, and have been included on the RADEXT 
Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Issue 140  	Technical  	Review of RADIUS MIBs  	Alan DeKoK
Issue 144 	Editorial 	Minor Editorial NITs 	Greg Weber
Issue 146 	Technical 	Statistics Errors 	Nagi R Jonnala
Issue 147 	Technical 	Add RFC 3411 Reference for SnmpAdminString 	Nagi R 
Jonnala
Issue 148 	Technical 	MIB Review 	Dan Romascanu

The editors are requested to address the open issues ASAP and resubmit, so 
that the documents can be forwarded to the IESG.

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

Delivery-date: Mon, 28 Nov 2005 15:24:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Conclusion of WG last call on RFC 3576 MIBs
Date: Mon, 28 Nov 2005 07:24:28 -0800

RADEXT WG last call has concluded on the following documents:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt

The following issues were raised, and have been included on the RADEXT 
Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Issue 137  	Technical  	Session Counters  	Glen Zorn
Issue 143 	Editorial 	RFC 3576 MIB Review 	Alan DeKoK
Issue 145 	Editorial 	Minor Editorial NITs 	Greg Weber
Issue 149  Technical	MIB Review 	Dan Romascanu

Since the ETA of this document is in December, the editors are requested to 
address the open issues ASAP and resubmit, so that the documents can be 
forwarded to the IESG for consideration as Proposed Standards.

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

Delivery-date: Tue, 22 Nov 2005 08:24:18 +0000
Content-class: urn:content-classes:message
Subject: RE:  Issue 102: NAS/QoS Filter Rule
Date: Tue, 22 Nov 2005 10:23:48 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Mauricio Sanchez wrote:
>=20
> Can you describe which were the primary points you found useful in
> reading Avi's document? Moreover, how would you suggest the RFC draft
> incorporate those points you found useful?  Should we add yet another
> Appendix?  A new section?  Something else?

The most useful part of Avi's document to me was the section
titled "Directing flows to a single tunnel". Perhaps adding an
appendix containing roughly that material would be sufficient?

Best regards,
Pasi

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

Delivery-date: Sun, 20 Nov 2005 20:25:45 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap
Date: Sun, 20 Nov 2005 12:25:11 -0800

>While I do agree that we are setting a precedent that moves away from
>the legacy RADIUS behavior, this new behavior would be just applicable
>to the attributes described in this document. Perhaps a discussion item
>for the RADIUS issues and fixes document is to look at the role explicit
>acknowledgement could play for all attributes.

The "Issues and Fixes" document is designed to address clarifications to the 
existing RFCs.  It is not within scope to add major new functionality to 
RADIUS.

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

Delivery-date: Sun, 20 Nov 2005 18:26:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Liaison Request from IEEE 802.11u
Date: Sun, 20 Nov 2005 10:24:32 -0800

A liaison letter has been received from IEEE 802.11u:
http://www.drizzle.com/~aboba/IEEE/11-05-0983-00-0000-liaison-to-ietf-from-i
eee802-11u.doc

The letter references the IEEE 802.11u Requirements document, the latest 
version of which is available here:
http://www.drizzle.com/~aboba/IEEE/11-05-0822-08-000u-tgu-requirements.doc

============================================================
Title: IEEE 802.11u Interworking with External Networks Requirements 
Document
Purpose: To review and return comments on requirements which specifically 
influence WLAN interworking.

Dear Brian Carpenter,

IEEE 802.11 Task Group u, Interworking with External Networks has produced a

requirements document enclosed (11-05-822r3) with this covering letter.

The purpose of this letter is to ask you to review the attached document and

to return comments on any of the requirements which may have a direct impact

on the interworking of IEEE 802.11 technology with your technology. It would

be useful to know which requirements are important to your organisation and 
additional requirements would be considered.

Please review this document and provide comments, so that IEEE 802.11u may 
refine their requirements.  The objective of this request is then to enable 
IEEE 802.11u to correctly engineer an interworking solution which is both 
acceptable to IEEE 802.11 and your organisation.  Comments are invited 
before the end of 2005, which will enable us to complete our work.

We look forward to additional discussions, and invite you to send feedback 
and possibly attend future IEEE 802.11 face-to-face meetings to discuss this

document, if so desired.  The next two IEEE 802.11 meetings are during the 
weeks of November 13th - 18th , 2005 (Vancouver, British Colombia, Canada) 
and January 15th - 20th , 2006 (Waikoloa, Hawaii, USA).

For your reference, ANSI/IEEE Std. 802.11-1999, as amended by IEEE Std. 
802.11a, IEEE Std. 802.11b, IEEE Std. 802.11b-COR1, IEEE Std. 802.11d, IEEE 
Std. 802.11g-2003, IEEE Std. 802.11h-2003, IEEE Std. 802.11i-2004, IEEE Std.

802.11j-2004 is the current version of the IEEE 802.11 Standard.

Please contact Stuart J. Kerry, IEEE 802.11 Working Group chair, together 
with Stephen McCann, IEEE 802.11u Task Group chair and Dorothy Stanley IETF 
Liaison with any questions.

Best Regards,

Stuart J. Kerry
Contact information:
Stuart J. Kerry
[email-masked]
+1 408 474 7356

Stephen McCann
[email-masked]
+44 1794 833341

Dorothy Stanley
[email-masked]
+1 630 979 1572

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

Envelope-to: [email-masked]
Delivery-date: Sat, 19 Nov 2005 18:46:30 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap 
Date: Sat, 19 Nov 2005 13:50:23 -0500
Message-Id: <[email-masked]>

"Sanchez, Mauricio (PNB Roseville)" <[email-masked]> wrote:
> The reason that section 2.2 exists at all is because we have a strong
> desire for the capability to have an acknowledgement from the NAS, in
> particular when it was incapable or unable to apply and attribute (from
> this document).

  I will be releasing a capability problem statement draft soon.  The
draft will address this, and other issues.

  Until then, RADIUS does not have capabilities, and no amount of
tweaks to the protocol will add that functionality.

> While I do agree that we are setting a precedent that moves away from
> the legacy RADIUS behavior, this new behavior would be just applicable
> to the attributes described in this document. Perhaps a discussion item
> for the RADIUS issues and fixes document is to look at the role explicit
> acknowledgement could play for all attributes.

  Please read the capability problem statement presentation from IETF,
and the list archives discussing capabilities.  This is a known issue
which is being addresses.

> "Unless otherwise noted in the individual description of an attribute
> contained herein, a NAS that conforms to this specification and receives
> an Access-Accept message that contains an attribute from this document
> that it does not recognize or cannot apply MUST interpret this though an
> Access-Reject had been sent and MUST terminate the session.

  I believe this covered in Section 1.1 of RFC 2865, page 5:

...
   A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
   unavailable service as an access-reject instead.
...

>  If accounting is enabled on the NAS, it MUST generate an accounting
> event upon session termination."

  This is covered in the first paragraph of Section 2 of RFC 2866.

  I think what you're implying here is that an accounting stop should
be sent when an Access-Reject is received.  Please acknowledge if that
is your intent or not, as that will help clarify the discussion.

  But if so, I do not believe that sending accounting stop in response
to an access-Reject is necessary or useful.  There was NO session to
terminate, so sending a stop is improper.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Sat, 19 Nov 2005 18:39:56 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap 
Date: Sat, 19 Nov 2005 13:43:12 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> I'm not at all comfortable with the notion of introducing new normative
> RADIUS behavior in the form of an Accounting-[Start|Stop] message as an
> ACK or NAK of an Access-Accept message.  Especially a NAK.  While it
> might be made to serve that purpose, IMHO, that's a subtle but
> substantive change to the RADIUS protocol.

  I concur.

> I understand that some implementations use co-resident Accounting
> servers to implement such things as concurrent session limitations
> for a single user.  That kind of functionality is outside the scope
> of RADIUS as documented in RFC 2865/66, however.

  Agreed.  But site-local deployments of that functionality have
site-local side-effects.  This issue would involve changes to long
established implementations.

  I don't see this issue as problematic (for reasons outlined
earlier), but I don't see it as at all beneficial.  If there's no
benefit to doing it (as you pointed out), it shouldn't be done.

  Alan DeKok.

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

Delivery-date: Fri, 18 Nov 2005 22:35:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap 
Date: Fri, 18 Nov 2005 17:33:58 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Mauricio Sanchez writes...

> The reason that section 2.2 exists at all is because we have a strong
> desire for the capability to have an acknowledgement from the NAS, in
> particular when it was incapable or unable to apply and attribute
(from
> this document).   From a security perspective, not knowing explicitly
> whether a given policy (i.e. attribute) has been applied is
undesirable
> to say the least.

I understand that it would be desirable for the RADIUS server to have
some assurance (acknowledgement is one form of assurance) that if the
filter policy cannot be applied that service is denied.  However, the
proposed text seems to be promoting what should be a design conformance
issue to a run-time check.  I don't think that's a good idea.  If the
NAS is compliant with the RFC, it will deny service when if can't apply
the filter.  If it's not compliant with the RFC, it won't send the
Accounting-Stop, whether or not it provides some service.  Therefore the
server doesn't know whether the absence of an Accounting-Stop means that
NAS supports the RFC and has applied the filter, or doesn't support the
RFC and has done something else (such as ignoring the attribute).  After
all, RADIUS Accounting is a separate and optional protocol.  Tying
Accounting into Authorization in this way is a new architectural concept
for RADIUS, even though some implementations may have already some this
sort of thing.
=20
> While I do agree that we are setting a precedent that moves away from
> the legacy RADIUS behavior, this new behavior would be just applicable
> to the attributes described in this document. Perhaps a discussion
item
> for the RADIUS issues and fixes document is to look at the role
explicit
> acknowledgement could play for all attributes.

I'm not at all comfortable with the notion of introducing new normative
RADIUS behavior in the form of an Accounting-[Start|Stop] message as an
ACK or NAK of an Access-Accept message.  Especially a NAK.  While it
might be made to serve that purpose, IMHO, that's a subtle but
substantive change to the RADIUS protocol.  Accounting Servers don't
need to be co-resident with the Authentication/Authorization servers, so
making this a MUST, breaks that independence.  I understand that some
implementations use co-resident Accounting servers to implement such
things as concurrent session limitations for a single user.  That kind
of functionality is outside the scope of RADIUS as documented in RFC
2865/66, however.

I think this is starting down a slippery slope.

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

Delivery-date: Fri, 18 Nov 2005 21:26:26 +0000
Content-class: urn:content-classes:message
Subject:  Issue 102: NAS/QoS Filter Rule
Date: Fri, 18 Nov 2005 13:25:53 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5EC86.A8670278
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Pasi wrote...=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Monday, September 26, 2005 7:45 AM
> To: Congdon, Paul T (ProCurve); [email-masked]
> Subject: RE: Issue 102: NAS/QoS Filter Rule
> > 8) The document allows an IP tunnel rule with direction "out", but=20
> > does not describe what such a rule means (the description seems to=20
> > apply only to rules with direction "in")
> >=20
> > [pc] Avi has written a great description of how the tunnel facility=20
> > works and how the directions apply.  I've attached a=20
> version of this=20
> > document - perhaps Avi has something more recent?  We=20
> probably want to=20
> > consider how parts of his document are incorporated into an=20
> annex or=20
> > some part of the document to make this clear.
>=20
> Thanks, this explained things (but something along those=20
> lines needs to be included in the document).

Can you describe which were the primary points you found useful in
reading Avi's document? Moreover, how would you suggest the RFC draft
incorporate those points you found useful?  Should we add yet another
Appendix?  A new section?  Something else?

Thanks,
MS

------_=_NextPart_001_01C5EC86.A8670278
Content-Type: text/plain;
	name="Tunneling.txt"
Content-Transfer-Encoding: base64
Content-Description: Tunneling.txt
Content-Disposition: attachment;
	filename="Tunneling.txt"

------_=_NextPart_001_01C5EC86.A8670278--

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

Delivery-date: Fri, 18 Nov 2005 21:14:23 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap 
Date: Fri, 18 Nov 2005 13:13:06 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok wrote...=20

>=20
>   Multiple NAS implementations already send STOP without=20
> START.  The use appears to be that when a session is=20
> rejected, a stop may be sent with zero session time.  I've=20
> seen this for at least the last five years, so it is a fairly=20
> wide-spread and common behavior.
>=20
>=20
>   FreeRADIUS doesn't much care one way or the other.  A=20
> search on google for "stop packet with zero session length"=20
> yeilds a number of email questions about SQL queries, but SQL=20
> is just one accounting store out of many available.
>=20
>   I don't see how any RADIUS vendor could avoid seeing stop=20
> packets without a start, especially because of UDP packet=20
> loss and lack of ordering.
>=20
>   So I don't see it as much of an issue for existing=20
> implementation, but I'm not sure that codifying it in a new=20
> standard is a good idea.
>=20
>   My belief is that if a "session termination" does NOT=20
> happen when an Access-Reject is sent to the NAS.  Rather, the=20
> session was proposed, but never established.  As a result, no=20
> session existed, so no stop or start packet should be sent.
>=20
>   In general, stop should always be preceded by starts.

The reason that section 2.2 exists at all is because we have a strong
desire for the capability to have an acknowledgement from the NAS, in
particular when it was incapable or unable to apply and attribute (from
this document).   From a security perspective, not knowing explicitly
whether a given policy (i.e. attribute) has been applied is undesirable
to say the least.=20

While I do agree that we are setting a precedent that moves away from
the legacy RADIUS behavior, this new behavior would be just applicable
to the attributes described in this document. Perhaps a discussion item
for the RADIUS issues and fixes document is to look at the role explicit
acknowledgement could play for all attributes. =20

In relation to specific stop, start/stop accounting behavior that should
occur upon failure, how about the following text to replace the first
paragraph of section 2.2?=20

"Unless otherwise noted in the individual description of an attribute
contained herein, a NAS that conforms to this specification and receives
an Access-Accept message that contains an attribute from this document
that it does not recognize or cannot apply MUST interpret this though an
Access-Reject had been sent and MUST terminate the session.  If
accounting is enabled on the NAS, it MUST generate an accounting event
upon session termination."=20

MS

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

Envelope-to: [email-masked]
Delivery-date: Fri, 18 Nov 2005 17:17:43 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap 
Date: Fri, 18 Nov 2005 12:21:10 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> <quote>
> 
> [pc] I believe that this should not cause any problem, but to be honest,
> we could use some input from others.  I'm aware of some implementations
> that send a start and then immediately follow with a stop, but this
> could be more resource intensive than needed.  The stop without a start
> would either be ignored by the server or appropriately acknowledge the
> termination of the session that didn't start.  This could be useful for
> diagnostic purposes.  I'd love to hear from other Radius vendors as to
> whether this would be a problem or not.  Again, my assumption is that it
> isn't.
>
> </quote>

  Multiple NAS implementations already send STOP without START.  The
use appears to be that when a session is rejected, a stop may be sent
with zero session time.  I've seen this for at least the last five
years, so it is a fairly wide-spread and common behavior.

> I haven't seen much comment one way or the other.  My conservative
> nature tells me to be cautious about assuming that adding heretofore
> un-described behavior in a long-standing protocol based on the
> assumption that nothing will break is fairly risky.

  FreeRADIUS doesn't much care one way or the other.  A search on
google for "stop packet with zero session length" yeilds a number of
email questions about SQL queries, but SQL is just one accounting
store out of many available.

  I don't see how any RADIUS vendor could avoid seeing stop packets
without a start, especially because of UDP packet loss and lack of
ordering.

  So I don't see it as much of an issue for existing implementation,
but I'm not sure that codifying it in a new standard is a good idea.

  My belief is that if a "session termination" does NOT happen when an
Access-Reject is sent to the NAS.  Rather, the session was proposed,
but never established.  As a result, no session existed, so no stop or
start packet should be sent.

  In general, stop should always be preceded by starts.

  Alan DeKok.

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

Delivery-date: Fri, 18 Nov 2005 02:25:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap
Date: Thu, 17 Nov 2005 21:24:46 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Mauricio Sanchez writes...
=20
<quote>

Issue 101-2=20
Description: Section 2.2: "If accounting is enabled on the NAS, it MUST
generate an Accounting-Request (Stop) message upon session termination."
So the NAS must send a Stop message, even though it has not sent a Start
message for this session yet? RFC 2866 seems suggest that a session
always has a Start message before Stop, but does not seem to outright
prohibit sending a stand-alone Stop
message. Is this a common practice, or are there any problems associated
with it?=20
Discussion: 9/13/05 - Paul asserted that this behavior of not sending a
start before the stop should not be an issue. 9/14/05 - Pasi was happy
with proposal
Action: No change; leave text as is

</quote>

What Paul Congdon wrote on September 13th was:

<quote>

[pc] I believe that this should not cause any problem, but to be honest,
we could use some input from others.  I'm aware of some implementations
that send a start and then immediately follow with a stop, but this
could be more resource intensive than needed.  The stop without a start
would either be ignored by the server or appropriately acknowledge the
termination of the session that didn't start.  This could be useful for
diagnostic purposes.  I'd love to hear from other Radius vendors as to
whether this would be a problem or not.  Again, my assumption is that it
isn't.

</quote>

I haven't seen much comment one way or the other.  My conservative
nature tells me to be cautious about assuming that adding heretofore
un-described behavior in a long-standing protocol based on the
assumption that nothing will break is fairly risky.  Perhaps we don't
want to be adding new normative requirements for RADIUS Accounting in
the VLAN, Filtering and Priority Attributes draft, in any event.

Perhaps I could stimulate some additional discussion of this issue here
on the list?

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

Delivery-date: Fri, 18 Nov 2005 01:49:01 +0000
Content-class: urn:content-classes:message
Subject: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap
Date: Thu, 17 Nov 2005 17:47:44 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5EBE2.128AAFE8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is a recap of status for Issue 101 (raised by Pasi Eronen), which
consists of a number of sub-issues.  All sub-issues are considered to
have an acceptable action proposal and unless we hear otherwise, the
action will be taken.

------------------------------------------------------------
Issue 101-1
Description: Section 1.1 contains some unnecessary terminology that is
not used anywhere later in the document: "Access Point (AP)",
"Association", "Port Access Entity (PAE)", "Station (STA)"

Discussion: Paul Congdon accepted recommentation on 9/13/05.  Pasi
Eronen accepted  on 9/14/05.

Action: Remove unused terminology from section 1.1 as noted in issue
description.
-------------------------------------------------------------
Issue 101-2
Description: Section 2.2: "If accounting is enabled on the NAS, it MUST
generate an Accounting-Request (Stop) message upon session termination."

So the NAS must send a Stop message, even though it has not sent a Start
message for this session yet? RFC 2866 seems suggest that a session
always has a Start message before Stop, but does not seem to outright
prohibit sending a stand-alone Stop
message. Is this a common practice, or are there any problems associated
with it?

Discussion: 9/13/05 - Paul asserted that this behavior of not sending a
start before the stop should not be an issue. 9/14/05 - Pasi was happy
with proposal

Action: No change; leave text as is
-------------------------------------------------------------
101-3
Description: Section 3.1: 802.1Q does not use the abbreviation "VLANID"
but rather "VID". Should this document also follow that convention?
(but maybe VLANID is more understandable)

Discussion: 9/13/05 - Paul says, "Yes, 802.1Q most often uses VID for
VLAN Identifier. It sometimes uses VLAN ID (with a space).  However, RFC
3580 uses VLANID and since this document is most likely used in
conjunction with RFC 3580, I suggest we just leave VLANID as is."
9/14/05 - Pasi was happy with propsal.

Action: No change; leave text as is
-------------------------------------------------------------
101-4
Description: Section 3.1: "Padding bits SHOULD be 0 (zero)." Why
"SHOULD" instead of "MUST"? (according to RFC 2119, it would mean there
are valid reasons to send something else in some circumstances?) (This
same issue occurs also in Section 4.2.)

Discussion: 9/13/05 - Paul says, "This can be changed to MUST.  The
desired behavior, IMO, is to require the bits to be set to 0, but not
require them to be checked on receipt.  The simple MUST or SHOULD
wording doesn't really reflect this, so it is probably best that we make
this a MUST.  Agree to change this SHOULD to a MUST here and in 4.2"
9/14/05 - Pasi was happy with proposal.

Action: Change SHOULD to MUST per issue description.
-------------------------------------------------------------
101-5
Description: Section 3.3: If VLAN-Name has basically the same meaning as
Egress-VLANID, IMHO their names should reflect this. Perhaps
"Egress-VLAN-Name"?

Discussion: 9/13/05 - Paul says, "Sure, no objection.  Change the name
of the VLAN-Name attribute to Egress-VLAN-Name everywhere in the
document." 9/14/05 - Pasi was happy with proposal.

Action: Several document edits to change 'VLAN-Name' attribute to
'Egress-VLAN-Name'.
-------------------------------------------------------------
101-6
Description: Using "START OF HEADING" (0x01) and "START OF TEXT" (0x02)
control characters to indicate tagged/untagged might make it
unnecessarily difficult to enter this attribute in a management
interface... maybe something like 0x74/0x75 ("t"/"u") or 0x31/0x32
("1"/"2") would be easier?

Discussion: 9/13/05  - Paul asserts that desire exists to have
Egress-VLANID and Egress-Vlan-Name to have as similar format as
possible. Moreover, Paul feels 0x01/0x02 do not waste bits. He proposes
no change. 9/14/05 - Pasi contends that 0x31/0x32  do not waste bits and
would not prevent additional code values to be defined in the future.
9/14/05 - Paul acquieces and accepts Pasi's recommendation of using
0x31/0x32 variant.

Action: Change the one-byte field that specifies tagged/untagged for
Egress-VLANID (section 3.1) and Egress-VLAN-Name (section 3.3) from
0x01/0x02 to 0x31/0x32.
-------------------------------------------------------------
101-7
Description: Section 3.3 Probably should have reference to UTF-8?
[RFC3629]

Discussion: 9/13/05 Paul says, "yes, Add a reference to [RFC3629] here
and then a formal reference in section 8." 9/14/05 - Pasi was happy with
proposal.

Action: In section 3.3, addd reference to RFC3629 and in section 8, add
an informative reference to RFC3629.
-------------------------------------------------------------
101-8
Description: Section 3.4: "The table, expressed as an 8 octet string,
maps the incoming priority (if one exists - the default is 0) into one
of seven regenerated priorities." If the regenerated priority is an
integer in range 0-7, should that be "eight regenerated priorities"?

Discussion: 9/13 Paul says, "yes, change to "eight regenerated
priorities." 9/14 - Pasi was happy with proposal

Action: Change affected sentence to "...eight regenerated priorities."
-------------------------------------------------------------
101-9
Description: Pasi recommends an alternative bit figure format for
section 3 and 4.

Discussion: 9/13 - Paul expresses concerns that there would many changes
necessary to the document. 9/14 - Pasi outlines a series of changes
limited to sections 3.1, 3.3, and 4.1. 9/14 - Paul accepts
recommendation

Action: Make changes to document per Pasi's recommendation:
- combining the two figures in 3.1
- fixing the figure in 4.1 (explicitly show that the attribute
  contains both a 64-bit counter and a string according to
  NAS-Filter-Rule; calling the counter a part of the string
  is misleading, since it doesn't even consist of printable
  characters...)
- Add figure to section 3.3 (explicitly showing that the
  attribute contains two different items)
-------------------------------------------------------------
101-10
Description: If the semantics of Acct-EAP-Auth-Method are identical to
Diameter EAP (as Section 4.2 claims), then it can
also be included in Access-Accept messages. (Or if it can't, then the
semantics are not identical, and need to be described
in this document.)

Discussion: 9/13 - Paul points out Acct-EAP-Auth-Method is slated to be
removed from document entirely

Action: None for this issue; 'acct-EAP-auth-method' to be removed
because of issue 114.
-------------------------------------------------------------
101-11
Description: Section 7: It looks like this security considerations
section was just copied from somewhere without much thought for how well
it actually applies to this document. Most of the text looks redundant
to me; we don't need to describe how to use IPsec with RADIUS in every
document that defines a new RADIUSattribute.

On the other hand, there's exactly zero discussion about newthreats
caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a malicious or
compromised RADIUS server or proxy could do with
these attributes (compared to the situation where NAS does not support
these attributes). At least Egress-VLANID,
Ingress-Filters and NAS-Filter-Rule have some pretty obvious
possibilities for abuse... (and maybe some non-obvious as well)

Discussion: 9/13 - Paul asks Posi to suggest new wording 9/14 - Posi
puts forth a suggested wording 9/14 - Paul takes Posi recommended
wording and weaves into existing section 7 wording. 9/15 - Posi contends
his wording was supposed to be wholesale replacement of section 7, not
an addition. 9/15 - Paul recommends at least some intro wording to
Posi's original suggested wording and puts forth yet another suggested
wording 9/16 - Posi accepts Paul's latest suggestion 9/16 Paul asks for
confirmation from mailing list 9/16 - Emile van Bergen seconds the
wording

Action:  Replace existing section 7 wording suggested by Paul on 9/15.
-------------------------------------------------------------
101-12
Description: References: Both 802.1Q and .1D look normative to me, but
RFC1321 and 802.11i probably are just informative.

Discussion: 9/13 - Paul accepts Posi's recommendation and proposing
swaping reference locations.

Action: Swap refrence locations to make 802.1Q and 802.1D informative
and make RFC1321 and 802.11i informative.
-------------------------------------------------------------
101-13
Description: Document cites [DiamEAP] and [NASREQ], but they're not
included in the references section. Both are
normative.

Discussion: 9/13 - Paul accepts Posi's recommendation to add both to the
references section

Action: Add [DiamEAP] and [NASREQ] to the references section.=20

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------  =20

------_=_NextPart_001_01C5EBE2.128AAFE8
Content-Type: text/html;
	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 =
6.5.7232.46">
<TITLE>Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is a recap of status for Issue 101 =
(raised by Pasi Eronen), which consists of a number of sub-issues.&nbsp; =
All sub-issues are considered to have an acceptable action proposal and =
unless we hear otherwise, the action will be taken.</FONT></P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
--</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Issue 101-1</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 1.1 contains some =
unnecessary terminology that is not used anywhere later in the document: =
&quot;Access Point (AP)&quot;, &quot;Association&quot;, &quot;Port =
Access Entity (PAE)&quot;, &quot;Station (STA)&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: Paul Congdon accepted =
recommentation on 9/13/05.&nbsp; Pasi Eronen accepted&nbsp; on =
9/14/05.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Remove unused terminology from =
section 1.1 as noted in issue description.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Issue 101-2</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 2.2: &quot;If =
accounting is enabled on the NAS, it MUST generate an Accounting-Request =
(Stop) message upon session termination.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So the NAS must send a Stop message, =
even though it has not sent a Start message for this session yet? RFC =
2866 seems suggest that a session always has a Start message before =
Stop, but does not seem to outright prohibit sending a stand-alone =
Stop</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">message. Is this a common practice, or =
are there any problems associated with it?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13/05 - Paul asserted =
that this behavior of not sending a start before the stop should not be =
an issue. 9/14/05 - Pasi was happy with proposal</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: No change; leave text as =
is</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-3</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 3.1: 802.1Q does =
not use the abbreviation &quot;VLANID&quot; but rather &quot;VID&quot;. =
Should this document also follow that convention?&nbsp; (but maybe =
VLANID is more understandable)</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13/05 - Paul says, =
&quot;Yes, 802.1Q most often uses VID for VLAN Identifier. It sometimes =
uses VLAN ID (with a space).&nbsp; However, RFC 3580 uses VLANID and =
since this document is most likely used in conjunction with RFC 3580, I =
suggest we just leave VLANID as is.&quot; 9/14/05 - Pasi was happy with =
propsal.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: No change; leave text as =
is</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-4</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 3.1: =
&quot;Padding bits SHOULD be 0 (zero).&quot; Why &quot;SHOULD&quot; =
instead of &quot;MUST&quot;? (according to RFC 2119, it would mean there =
are valid reasons to send something else in some circumstances?) (This =
same issue occurs also in Section 4.2.)</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13/05 - Paul says, =
&quot;This can be changed to MUST.&nbsp; The desired behavior, IMO, is =
to require the bits to be set to 0, but not require them to be checked =
on receipt.&nbsp; The simple MUST or SHOULD wording doesn't really =
reflect this, so it is probably best that we make this a MUST.&nbsp; =
Agree to change this SHOULD to a MUST here and in 4.2&quot; 9/14/05 - =
Pasi was happy with proposal.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Change SHOULD to MUST per issue =
description.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-5</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 3.3: If VLAN-Name =
has basically the same meaning as Egress-VLANID, IMHO their names should =
reflect this. Perhaps &quot;Egress-VLAN-Name&quot;?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13/05 - Paul says, =
&quot;Sure, no objection.&nbsp; Change the name of the VLAN-Name =
attribute to Egress-VLAN-Name everywhere in the document.&quot; 9/14/05 =
- Pasi was happy with proposal.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Several document edits to =
change 'VLAN-Name' attribute to 'Egress-VLAN-Name'.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-6</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Using &quot;START OF =
HEADING&quot; (0x01) and &quot;START OF TEXT&quot; (0x02) control =
characters to indicate tagged/untagged might make it unnecessarily =
difficult to enter this attribute in a management interface... maybe =
something like 0x74/0x75 (&quot;t&quot;/&quot;u&quot;) or 0x31/0x32 =
(&quot;1&quot;/&quot;2&quot;) would be easier?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13/05&nbsp; - Paul =
asserts that desire exists to have Egress-VLANID and Egress-Vlan-Name to =
have as similar format as possible. Moreover, Paul feels 0x01/0x02 do =
not waste bits. He proposes no change. 9/14/05 - Pasi contends that =
0x31/0x32&nbsp; do not waste bits and would not prevent additional code =
values to be defined in the future. 9/14/05 - Paul acquieces and accepts =
Pasi's recommendation of using 0x31/0x32 variant.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Change the one-byte field that =
specifies tagged/untagged for Egress-VLANID (section 3.1) and =
Egress-VLAN-Name (section 3.3) from 0x01/0x02 to 0x31/0x32.</FONT></P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-7</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 3.3 Probably =
should have reference to UTF-8? [RFC3629]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13/05 Paul says, =
&quot;yes, Add a reference to [RFC3629] here and then a formal reference =
in section 8.&quot; 9/14/05 - Pasi was happy with proposal.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: In section 3.3, addd reference =
to RFC3629 and in section 8, add an informative reference to =
RFC3629.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-8</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 3.4: &quot;The =
table, expressed as an 8 octet string, maps the incoming priority (if =
one exists - the default is 0) into one of seven regenerated =
priorities.&quot; If the regenerated priority is an integer in range =
0-7, should that be &quot;eight regenerated priorities&quot;?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13 Paul says, &quot;yes, =
change to &quot;eight regenerated priorities.&quot; 9/14 - Pasi was =
happy with proposal</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Change affected sentence to =
&quot;&#8230;eight regenerated priorities.&quot;</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-9</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Pasi recommends an =
alternative bit figure format for section 3 and 4.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13 - Paul expresses =
concerns that there would many changes necessary to the document. 9/14 - =
Pasi outlines a series of changes limited to sections 3.1, 3.3, and 4.1. =
9/14 - Paul accepts recommendation</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Make changes to document per =
Pasi's recommendation:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">- combining the two figures in =
3.1</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">- fixing the figure in 4.1 (explicitly =
show that the attribute</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; contains both a 64-bit counter =
and a string according to</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; NAS-Filter-Rule; calling the =
counter a part of the string</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; is misleading, since it doesn't =
even consist of printable</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; characters...)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">- Add figure to section 3.3 =
(explicitly showing that the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; attribute contains two =
different items)</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-10</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: If the semantics of =
Acct-EAP-Auth-Method are identical to Diameter EAP (as Section 4.2 =
claims), then it can</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">also be included in Access-Accept =
messages. (Or if it can't, then the semantics are not identical, and =
need to be described</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">in this document.)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13 - Paul points out =
Acct-EAP-Auth-Method is slated to be removed from document =
entirely</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: None for this issue; =
'acct-EAP-auth-method' to be removed because of issue 114.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-11</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Section 7: It looks like =
this security considerations section was just copied from somewhere =
without much thought for how well it actually applies to this document. =
Most of the text looks redundant to me; we don't need to describe how to =
use IPsec with RADIUS in every document that defines a new =
RADIUSattribute.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On the other hand, there's exactly zero =
discussion about newthreats caused by the attributes defined in _this_ =
document.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">And to me it looks like there are new =
attacks that e.g. a malicious or compromised RADIUS server or proxy =
could do with</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">these attributes (compared to the =
situation where NAS does not support these attributes). At least =
Egress-VLANID,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Ingress-Filters and NAS-Filter-Rule =
have some pretty obvious possibilities for abuse... (and maybe some =
non-obvious as well)</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13 - Paul asks Posi to =
suggest new wording 9/14 - Posi puts forth a suggested wording 9/14 - =
Paul takes Posi recommended wording and weaves into existing section 7 =
wording. 9/15 - Posi contends his wording was supposed to be wholesale =
replacement of section 7, not an addition. 9/15 - Paul recommends at =
least some intro wording to Posi's original suggested wording and puts =
forth yet another suggested wording 9/16 - Posi accepts Paul's latest =
suggestion 9/16 Paul asks for confirmation from mailing list 9/16 - =
Emile van Bergen seconds the wording</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action:&nbsp; Replace existing section =
7 wording suggested by Paul on 9/15.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-12</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: References: Both 802.1Q =
and .1D look normative to me, but RFC1321 and 802.11i probably are just =
informative.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13 - Paul accepts Posi's =
recommendation and proposing swaping reference locations.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Swap refrence locations to make =
802.1Q and 802.1D informative and make RFC1321 and 802.11i =
informative.</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">----------------------------------------------------------=
---</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">101-13</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Description: Document cites [DiamEAP] =
and [NASREQ], but they're not included in the references section. Both =
are</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">normative.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Discussion: 9/13 - Paul accepts Posi's =
recommendation to add both to the references section</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Action: Add [DiamEAP] and [NASREQ] to =
the references section. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mauricio Sanchez</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">, CISSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Network Security Architect</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Procurve Networking Business</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Hewlett Packard</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">8000 Foothills Boulevard, ms =
5555</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Roseville CA, 95747-5557</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">916.785.1910 Tel</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">916.785.1815 Fax</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">[email-masked]</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">--------------------------------------------&nbsp;&nbsp; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5EBE2.128AAFE8--

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

Delivery-date: Thu, 17 Nov 2005 15:43:12 +0000
Content-class: urn:content-classes:message
Subject: RE: AW: Comments on draft-ietf-radext-digest-auth-06.txt (fwd)
Date: Thu, 17 Nov 2005 10:42:37 -0500
From: "Nelson, David" <[email-masked]>
To: "Lou Berger" <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> The WG charter states:
>=20
>=20
> >- SIP support. RADIUS is currently used for SIP authentication,
> >authorization and accounting. Standardization of these attributes
> >will enable improved interoperability.
> >
> >This document will be upwards compatible with the Diameter SIP
> >application, and conform to existing IETF RFCs on HTTP Digest,
> >including RFC 2617, 3261, and 3310.
>=20
> It seems clear that the digest-auth draft covers the objectives of
> the second paragraph.  But the first paragraph seems broader than
> this and suggesting covering the full scope of "SIP authentication,
> authorization and accounting".  (Presumably as defined in the, albeit
> informational, requirements RFC.)  Is there any intent or interest in
> covering the remaining requirements?
>=20
> I can contribute to this if there is interest, and being a newbie in
> this area, would welcome happily collaborate with anyone else who may
> be interested.

Creating RADIUS features that exceed the comparable features in Diameter
would be a problem.  That's not the intent of RADEXT.   Everything in
RADEXT WG work items needs to be upwards compatible to a corresponding
feature in Diameter, or contain that Diameter compatibility in the
RADEXT document.  If these are requirements that you see as not being
addressed in the Diameter SIP Application, then I don't see how we could
(or should) address them in RADIUS (alone). =20

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

Delivery-date: Thu, 17 Nov 2005 09:30:56 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: Comments on draft-ietf-radext-digest-auth-06.txt (fwd)
Date: Thu, 17 Nov 2005 10:06:49 +0100

Lou wrote:

> Bernard, (Wolfgang),
> 
> [..] 
> 1.  It seems to me that both the SIP and Diameter drafts 
> don't fully support 
> the requirements laid out in RFC 3702.  Also, neither draft 
> references this RFC. I found this really surprising.  What is the relationship of 
> the drafts to the RFC?  Is there any intention/desire to have 
> the drafts fully support it?  
draft-ietf-radext-digest-auth tries to be useful for other protocols than SIP, too.
It's a building block, not a complete AAA framework.

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

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

Delivery-date: Thu, 17 Nov 2005 00:23:41 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Comments on draft-ietf-radext-digest-auth-06.txt (fwd)
Date: Wed, 16 Nov 2005 16:22:45 -0800

RFC 3072 Section 1.1 talks about the requirements for RADIUS Digest 
Authentication:

   Nevertheless, a few limited RADIUS [5]
   extensions may meet some of the requirements in this document (for
   instance, some of the authentication requirements).  We expect that
   while RADIUS with these limited extensions will meet particular
   functional requirements, it will not meet other important
   requirements.  The following are some requirements that are not
   expected to be met by RADIUS:

      1. Section 2.1.3: RADIUS does not support a discovery feature.

      2. Section 2.1.7: RADIUS does not support reliable message
         delivery.

   The following list contains the requirements that can be met by
   RADIUS or RADIUS extensions.

      1. Section 2.1.2: Communication between domains does not scale
         well in RADIUS.  As a result, inter-domain communications are
         typically handled using a proxy architecture [6].

      2. Section 2.1.5: RADIUS clients would need to support Dynamic
         Authorization [7].

      3. Section 2.1.9: RADIUS clients would need to rely on a lower-
         layer security protocol, such as IPSec, to perform mutual
         authentication.

      4. Section 2.3.3: RADIUS clients would need to support Dynamic
         Authorization [7].

      5. Section 2.3.4: RADIUS clients would need to support Dynamic
         Authorization [7].

---------- Forwarded message ----------
Date: Wed, 16 Nov 2005 15:43:09 -0500
From: Lou Berger <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Comments on draft-ietf-radext-digest-auth-06.txt

Bernard, (Wolfgang),

	Per our discussion in Vancouver, I've re-read
draft-ietf-radext-digest-auth-06.txt from the perspective of SIP 
authorization
and also comparing it to  draft-ietf-aaa-diameter-sip-app-10.txt.  I think 
you
were correct (and I wasn't) in the observation that the former does the job, 
but
I still have a small number of comments:

1.  It seems to me that both the SIP and Diameter drafts don't fully support 
the
requirements laid out in RFC 3702.  Also, neither draft references this RFC. 
  I
found this really surprising.  What is the relationship of the drafts to the
RFC?  Is there any intention/desire to have the drafts fully support it?  
I'm
sure I'm missing something, so what's the "big picture here"?

2. Here are some specific mismatches between the draft and RFC3702, please 
let
me know if I missed something.  Support for RFC 3702, section:
a) 2.1.5.  Updating SIP Server Entries (and missing reference to RFC 3576)
b) 2.3.2.  Information Transfer
	[I think this implies passing via & route information on the
authorization request as well as handling the response.]
c) 2.4.5.  Support for Accounting on Different Media

3. While not covered in the AAA requirements I think that authorization 
based on
requested media is also needed.  I think this is the complement of the 
(media
related) policy extensions being discussed within the SIPPING WG.

Please let me know what you think.

Much thanks,
Lou

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

Delivery-date: Tue, 15 Nov 2005 00:45:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Misspelling (was RE:)
Date: Mon, 14 Nov 2005 16:44:50 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>

Glen Zorn (gwz) <> supposedly scribbled:

The same comments unsurprisingly apply to the dynauth client MIB, as =
well as the separate issue I raised regarding English language usage.

> Glen Zorn (gwz) <> supposedly scribbled:
>=20
> Actually, I notice that "Authorize" is misspelled "Athorize" in
> several places; perhaps a global search & replace (& a trip through a
> spelling checker) are in order. =20
>=20
>> Description of issue: Misspelling
>> Submitter name: Glen Zorn
>> Submitter email address: [email-masked] Date first submitted: 14 Nov
>> 05 Document: dynauth server MIB Comment type: E
>> Priority: 1
>> Section: 4
>> Rationale/Explanation of issue: the word "Authorize" is misspelled
>> "Autorized" in the description of the
>> radiusDynAuthServDisconAuthOnlyRequests object.
>>=20
>> Requested change:
>> Change "Service-Type attribute with value 'Autorize Only'" to
>> "Service-Type attribute with value 'Authorize Only'"

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

Delivery-date: Tue, 15 Nov 2005 00:02:30 +0000
Content-class: urn:content-classes:message
Subject: Misspelling (was RE:)
Date: Mon, 14 Nov 2005 16:02:08 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Cc: "Glen Zorn \(gwz\)" <[email-masked]>

Glen Zorn (gwz) <> supposedly scribbled:

Actually, I notice that "Authorize" is misspelled "Athorize" in several =
places; perhaps a global search & replace (& a trip through a spelling =
checker) are in order.

> Description of issue: Misspelling
> Submitter name: Glen Zorn
> Submitter email address: [email-masked]
> Date first submitted: 14 Nov 05
> Document: dynauth server MIB
> Comment type: E
> Priority: 1
> Section: 4
> Rationale/Explanation of issue: the word "Authorize" is misspelled
> "Autorized" in the description of the
> radiusDynAuthServDisconAuthOnlyRequests object. =20
>=20
> Requested change:
> Change "Service-Type attribute with value 'Autorize Only'" to
> "Service-Type attribute with value 'Authorize Only'"=20

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

Delivery-date: Tue, 15 Nov 2005 00:01:20 +0000
Content-class: urn:content-classes:message
Subject: Issue: English usage
Date: Mon, 14 Nov 2005 15:59:01 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Poor English language usage
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 14 Nov 05
Document: dynauth server MIB
Comment type: E
Priority: 1
Section: 7
Rationale/Explanation of issue: One comments upon a document, not to it.

Requested change:=20
Change "their comments to this document" to "their comments on this
document"

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

Delivery-date: Mon, 14 Nov 2005 23:48:01 +0000
Content-class: urn:content-classes:message
Subject: 
Date: Mon, 14 Nov 2005 15:47:28 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Misspelling
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 14 Nov 05
Document: dynauth server MIB
Comment type: E
Priority: 1
Section: 4
Rationale/Explanation of issue: the word "Authorize" is misspelled
"Autorized" in the description of the
radiusDynAuthServDisconAuthOnlyRequests object.

Requested change:=20
Change "Service-Type attribute with value 'Autorize Only'" to
"Service-Type attribute with value 'Authorize Only'"

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

Delivery-date: Mon, 14 Nov 2005 19:40:39 +0000
Content-class: urn:content-classes:message
Subject: Issue 100: Security Considerations (IEEE802 WG Last Call) 
Date: Mon, 14 Nov 2005 11:40:14 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>
Cc: "Alan DeKok" <[email-masked]>

Unless I hear otherwise from anyone else, the action agreed upon by this
comment will be taken.

MS
=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, September 08, 2005 3:15 PM
> To: Sanchez, Mauricio (PNB Roseville)
> Cc: [email-masked]
> Subject: Re: Issue 100: Security Considerations (IEEE802 WG=20
> Last Call)=20
>=20
> "Sanchez, Mauricio (PNB Roseville)" <[email-masked]> wrote:
> > One could say that the cat is out of the bag. Section 7 was taken=20
> > mostly from existing RFCs, in particular RFC3580.  The specific=20
> > sentence your issue relates to already exists verbatim in RFC3580=20
> > section 5.3.  My proposal is to change the last sentence in=20
> section 7 to:
> >=20
> > "For IEEE 802.X environments, best practices outlined in [RFC3580]=20
> > mandate the use of different RADIUS shared secrets for IEEE 802.1X=20
> > authentication and PAP authentication."
> >=20
> > An normative reference will also need to be added to RFC3580 in=20
> > section 8.1.
>=20
>   This change would address any concerns I have.
>=20
>   Alan DeKok.
>=20

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

Delivery-date: Mon, 14 Nov 2005 06:19:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue 148: Review of RFC2618bis-2621bis
Date: Sun, 13 Nov 2005 22:18:56 -0800

>From: "Romascanu, Dan (Dan)" <[email-masked]>
>To: <[email-masked]>
>CC: "Wijnen, Bert (Bert)" <[email-masked]>
>Subject: RE: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
>Date: Mon, 14 Nov 2005 00:47:28 +0200
>
>At the request of the Operations and Management Area Director I read
>again the documents. Here are my findings:
>
>General
>
>1. It is bad to have the following defined in multiple documents:
>
>radiusMIB  OBJECT-IDENTITY
>           STATUS  current
>           DESCRIPTION
>                 "The OID assigned to RADIUS MIB work by the IANA."
>            ::= { mib-2 67 }
>
>
>radiusAuthentication  OBJECT IDENTIFIER ::= {radiusMIB 1}
>
>These should be defined in the MIB module in one document only, say
>draft-ietf-radext-rfc2618bis-01.txt and imported in the other MIB
>modules.
>
>I remember having made this comment previously ... Or maybe I am
>confusing?
>
>2. All MIB modules include deprecated IPv4 tables and new IPv4/IPv6
>tables. In the case when both the older deprecated IPv4 tables and the
>new IPv4 / IPv6 tables are supported in agents for backwards
>compatibility reasons, is there any relationship between the indexation
>of the two tables?
>
>3. What does the following text present in all documents mean?
>
>Managed entities SHOULD NOT instantiate the deprecated table
>    containing IPv4-only address objects when the RADIUS server address
>    represented in the table row is not an IPv4 address.  Managed
>    entities SHOULD NOT return inaccurate values of IP address or SNMP
>    object access errors for IPv4-only address objects in otherwise
>    populated tables.
>
>Does this mean that if there is at least one address that is not an IPv4
>address the whole deprecated table will not be implemented, or does this
>mean that only instances that do not correspond to IPv4 addresses are
>not implemented, but the table exists and includes rows only for IPv4
>instances?
>
>
>4. It would be helpful if UNITS clauses would be added where applicable
>to objects with a SYNTAX of Counter32
>
>5. It would be helpful if REFERENCE clauses would be added to the
>definition of objects that have a direct mapping on RFC 2865. For
>example the definition of the radiusAuthClientExtAccessRequests object
>in draft-ietf-radext-rfc2618bis-01.txt should include a REFERENCE clause
>that points to RFC 2865, Section 4.1.
>
>6. All MIB modules include objects that refer to malformed requests and
>malformed responses (radiusAuthClientExtMalformedAccessResponses,
>radiusAuthServTotalMalformedAccessRequests,
>radiusAuthServExtMalformedAccessRequests,
>radiusAccClientExtMalformedResponses, etc.). I could not find a
>definition of 'malformed' in RFC 2865.Some definitions refer to length,
>but the definitions need to be clear and consistent.
>
>7. As the documents define MIB modules referring to various aspects of
>the instrumentation of RFC 2865, and RFC 2866, I believe that one
>cannot implement these documents without understanding and implementing
>relevant portions of RFC 2865 or RFC 2866. In consequence, [RFC2865]
>should be Normative Reference for RFC 2618-bis and RFC 2619-bis and
>[RFC2866] should be Normative Reference for RFC 2620-bis and RFC
>2621-bis, rather than Informative.
>
>8. RFC 3411needs to be added to the Normative References because
>SnmpAdminString is imported from SNMP-FRAMEWORK-MIB
>
>9. The Security Considerations sections in the documents are not aligned
>with the latest boilerplate described in
>http://www.ops.ietf.org/mib-security.html.
>
>Specifically the last paragraph in each Section needs to be replaced
>with the following:
>
>It is RECOMMENDED that implementers consider the security features as
>    provided by the SNMPv3 framework (see [RFC3410], section 8),
>    including full support for the SNMPv3 cryptographic mechanisms (for
>    authentication and privacy).
>
>    Further, deployment of SNMP versions prior to SNMPv3 is NOT
>    RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
>    enable cryptographic security.  It is then a customer/operator
>    responsibility to ensure that the SNMP entity giving access to an
>    instance of this MIB module is properly configured to give access to
>    the objects only to those principals (users) that have legitimate
>    rights to indeed GET or SET (change/create/delete) them.
>
>9. I believe that the DESCRIPTION clauses of the MODULE-COMPLIANCE
>modules need to be harmonized with the content of the sections
>describing the Deprecated objects. The DESCRIPTION of the deprecated
>module should mention that these modules are for IPv4 entities only,
>while the current modules support both IPv4 and IPv6.
>
>
>
>
>
>
>draft-ietf-radext-rfc2618bis-01.txt
>
>1. idnits has no problem with this I-D.
>
>2. smilint complains about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2618bis.txt
>
>rfc2618bis.txt:15: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>This is because of the root registration issue that was discussed on the
>radext mailing list, and the WG decided to keep the root of the MIB
>modules under the administration of the WG, and not of IANA.
>
>I do not like this, but I can live with it.
>
>3. The acronym NAS shows up for the first time in Section 5 of the
>document without being expanded.
>
>4. Section 5 includes the following text:
>
>    Each entry in the RADIUS Authentication Server Table includes sixteen
>    columns presenting a view of the activity of the RADIUS
>    authentication client.
>
>Actually the first column is not-accessible, representing the index of
>the table. There are only fifteen accessible columns for each entry.
>
>
>draft-ietf-radext-rfc2619bis-01.txt
>
>1. idnits has no problem with this I-D.
>
>2. smilint complies about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2619bis.txt
>
>rfc2619bis.txt:11: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>This is because of the root registration issue that was discussed on the
>radext mailing list, and the WG decided to keep the root of the MIB
>modules under the administration of the WG, and not of IANA.
>
>I do not like this, but I can live with it.
>
>3. The Abstract section should shortly define the scope of the MIB, and
>not only mentions that it updates RFC 2619.
>
>4. Section 5 includes the following text:
>
>Each entry in the RADIUS Authentication Client Table
>    includes thirteen columns presenting a view of the activity of the
>    RADIUS authentication server.
>
>One of the columns is actually an un-accessible index, so only twelve of
>the columns present a view of the activity of the clients.
>
>5. The statement made in the Security Consideration section that the MIB
>does not include any object with a read-write MAX-ACCESS is not
>accurate. The radiusAuthServConfigReset has a MAX-ACCESS of read-write,
>and the Security Consideration sections needs to include the description
>of the security hazards related to the intentional or non-intentional
>incorrect manipulation of this object, as well as the boilerplate text
>related to writeable objects.
>
>6. radiusAuthServConfigReset - is reset(2) the only writeable value for
>this object? If so, this needs to be mentioned in the DESCRIPTION
>clause, and the desired behavior of the agent if a different value is
>entered must be described.
>
>draft-ietf-radext-rfc2620bis-01.txt
>
>1. idnits has no problem with this I-D.
>
>2. smilint complies about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2620bis.txt
>
>rfc2620bis.txt:16: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>I do not like this, but I can live with it.
>
>3. The Abstract section should shortly define the scope of the MIB, and
>not only mentions that it updates RFC 2619.
>
>4. The acronym NAS shows up for the first time in Section 5 of the
>document without being expanded.
>
>5. Section 5 includes the following text:
>
>Each entry in
>    the RADIUS Accounting Server Table includes fifteen columns
>    presenting a view of the activity of the RADIUS client.
>
>One of the columns is actually an un-accessible index, so only fourteen
>of the columns present a view of the activity of the clients.
>
>
>
>draft-ietf-radext-rfc2621bis-01.txt
>
>1. idnits complains about:
>
>tmp/draft-ietf-radext-rfc2621bis-01.txt(595): Line has weird spacing:
>'...invalid  authe...'
>tmp/draft-ietf-radext-rfc2621bis-01.txt(789): Line has weird spacing:
>'...invalid  authe...'
>
>2. smilint complies about:
>
>smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2621bis.txt
>
>rfc2621bis.txt:13: [4] {module-identity-registration} warning:
>uncontrolled MODULE-IDENTITY registration
>
>I do not like this, but I can live with it.
>
>3. Section 5 includes the following text:
>
>Each entry in the RADIUS Accounting Client Table includes twelve columns
>    presenting a view of the activity of the RADIUS accounting server
>
>.One of the columns is actually an un-accessible index, so only eleven
>of the columns present a view of the activity of the clients.
>
>4. The statement made in the Security Consideration section that the MIB
>does not include any object with a read-write MAX-ACCESS is not
>accurate. The radiusAccServConfigReset has a MAX-ACCESS of read-write,
>and the Security Consideration sections needs to include the description
>of the security hazards related to the intentional or non-intentional
>incorrect manipulation of this object, as well as the boilerplate text
>related to writeable objects.
>
>
>Overall I believe that the documents are at in a reasonable shape. They
>can be forwarded to the IESG for consideration as Proposed or
>Informational, either with a list of known problems, or (better) after a
>short editing round to fix the problems detected during the WGLC.
>
>Regards,
>
>Dan
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Bernard Aboba
> > Sent: Wednesday, November 02, 2005 16:57
> > To: [email-masked]
> > Subject: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
> >
> >
> > This is a reminder that RADEXT WG last call on RFC
> > 2618bis-2621bis is in progress.  These documents are being
> > considered as Proposed Standards (2618bis, 26819bis) and
> > Informational (2620bis, 2621bis). The documents are available
> > for inspection here:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618b
> > is-01.txt
> > (Proposed Standard)
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619b
> > is-01.txt
> > (Proposed Standard)
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620b
>is-01.txt
>(Informational)
>http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt
>(Informational)
>
>RADEXT WG last call will last until Monday, November 14, 2005. Please
>send comments to the RADEXT WG mailing list ([email-masked]) in
>the format described in the RADEXT Issues list:
>http://www.drizzle.com/~aboba/RADEXT/
>
>Note:  so far no WG last call comments have been received.  If you have
>read the documents, please respond to the WG last call, even if only to
>say "I am OK with them".
>
>
>
>--
>to unsubscribe send a message to [email-masked] with the
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Mon, 14 Nov 2005 06:18:20 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue 149: Review of RFC 3576 MIBs
Date: Sun, 13 Nov 2005 22:18:16 -0800

>From: "Romascanu, Dan (Dan)" <[email-masked]>
>To: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>
>Subject: RE: REMINDER:  RADEXT WG last call on RFC 3576 MIBs
>Date: Mon, 14 Nov 2005 02:05:24 +0200
>
>
>Here are my comments:
>
>               draft-ietf-radext-dynauth-client-mib-02.txt
>
>1. It would help to expand RADIUS in the Abstract and to add an
>appropriate Informative Reference
>2. The first paragraph in Section 3 includes a repeated sentence
>3. As 2619bis and 2621bis will be supersets and will obsolete 2619 and
>2621, I do not believe that there is any need for the older documents to
>be referenced.
>4. No need to list in the Security Consideration section the MIB objects
>that are considered as non-vulnerable. These are by default all objects,
>but the ones listed as potentially vulnerable.
>
>
>               draft-ietf-radext-dynauth-server-mib-02.txt
>
>1. It would help to expand RADIUS in the Abstract and to add an
>appropriate Informative Reference
>2. As 2618bis and 2620bis will be supersets and will obsolete 2618 and
>2620, I do not believe that there is any need for the older documents to
>be mentioned in section 3 and referenced.
>3. No need to list in the Security Consideration section the MIB objects
>that are considered as non-vulnerable. These are by default all objects,
>but the ones listed as potentially vulnerable.
>
>The documents are in god shape. In my opinion, they may be forwarded to
>the IESG for consideration as Informational, with a note including the
>known editorial problems.
>
>Regards,
>
>Dan
>
>
>
>
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> > Sent: Sunday, November 06, 2005 6:33 PM
> > To: Mreview (E-mail)
> > Subject: FW: REMINDER: RADEXT WG last call on RFC 3576 MIBs
> >
> > Here are 2 other MIB documents in that WG to review.
> >
> > Bert
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Bernard Aboba
> > Sent: Wednesday, November 02, 2005 17:00
> > To: [email-masked]
> > Subject: REMINDER: RADEXT WG last call on RFC 3576 MIBs
> >
> >
> > This is a reminder of an RADEXT WG last call in progress on
> > the RFC 3576 MIBs.  These documents are being considered for
> > publication as Informational RFCs. The documents are
> > available for inspection here:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> > client-mib-02.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> > server-mib-02.txt
> >
> > RADEXT WG last call will last until Monday, November 14,
> > 2005. Please send comments to the RADEXT WG mailing list
> > ([email-masked]) in the format described in the
> > RADEXT Issues list:
> >
> > http://www.drizzle.com/~aboba/RADEXT/
> >
> > If you have read the documents, please respond to this WG
> > Last Call, if only to say "I have read the documents and I am
> > OK with them."
> >
> >
> >
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >
> >
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Mon, 14 Nov 2005 06:17:33 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Issue 111: Accounting
Date: Sun, 13 Nov 2005 22:16:49 -0800

Here is what RFC 2866 says about the notion of an Accounting Session:

   When a client is configured to use RADIUS Accounting, at the start of
   service delivery it will generate an Accounting Start packet
   describing the type of service being delivered and the user it is
   being delivered to, and will send that to the RADIUS Accounting
   server, which will send back an acknowledgement that the packet has
   been received.  At the end of service delivery the client will
   generate an Accounting Stop packet describing the type of service
   that was delivered and optionally statistics such as elapsed time,
   input and output octets, or input and output packets.  It will send
   that to the RADIUS Accounting server, which will send back an
   acknowledgement that the packet has been received.

As Greg noted, the Service-Type is not being changed here, so that the 
Service is continuing, and sending of additional Start/Stop messages is 
somewhat odd.  Also, do we really want individual RADIUS attributes to 
provide their own definitions of when a new session is started and stopped?  
RADIUS accounting is a separate protocol from RADIUS authentication, and 
runs on a separate port.  Authentication attributes that affect accounting 
(Class, Acct-Interim-Interval) have to date been general ones.  Terminating 
the Accounting Session in mid-stream could cause issues with RADIUS 
implementations that use the Accounting Records for things like simultaneous 
usage control.

For Tunnel Accounting (RFC 2867) the issue was handled by defining a new 
value for Acct-Status-Type rather than using Start/Stop.  For example:

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off
       9-14   Reserved for Tunnel Accounting
      15      Reserved for Failed

Paul Congdon said:

At IETF-64 we reviewed this issue.  There did not seem to be any
objection to having compliance statements in the Annex given that this
Annex is where the context for the statements is developed.  Also, since
a new session is created, as stated in the draft, there is no need to
use INTERM messages.

---------------------------------------------------------------------------------
Issue 111: Accounting
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: August 10, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html
Document: IEEE802-00
Comment type: T
Priority: S
Section: A.3
Rationale/Explanation of issue:

The accounting requirements do not seem to be fully treated
by the draft.  Section A.3 has a MUST requirement related to
accounting.  I would think that MUST requirements should be
treated by the text, not in an appendix.  Why does redirection
require a STOP/START pair?  Can't this information be conveyed
via an INTERIM record for the same session?  If the Service-
Type is not changing, I'd think that an INTERIM would suffice.

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

Delivery-date: Mon, 14 Nov 2005 00:06:25 +0000
content-class: urn:content-classes:message
Subject: RE: REMINDER:  RADEXT WG last call on RFC 3576 MIBs
Date: Mon, 14 Nov 2005 02:05:24 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>

Here are my comments:

              draft-ietf-radext-dynauth-client-mib-02.txt

1. It would help to expand RADIUS in the Abstract and to add an
appropriate Informative Reference
2. The first paragraph in Section 3 includes a repeated sentence
3. As 2619bis and 2621bis will be supersets and will obsolete 2619 and
2621, I do not believe that there is any need for the older documents to
be referenced.
4. No need to list in the Security Consideration section the MIB objects
that are considered as non-vulnerable. These are by default all objects,
but the ones listed as potentially vulnerable.=20

              draft-ietf-radext-dynauth-server-mib-02.txt

1. It would help to expand RADIUS in the Abstract and to add an
appropriate Informative Reference
2. As 2618bis and 2620bis will be supersets and will obsolete 2618 and
2620, I do not believe that there is any need for the older documents to
be mentioned in section 3 and referenced.
3. No need to list in the Security Consideration section the MIB objects
that are considered as non-vulnerable. These are by default all objects,
but the ones listed as potentially vulnerable.=20

The documents are in god shape. In my opinion, they may be forwarded to
the IESG for consideration as Informational, with a note including the
known editorial problems.=20

Regards,

Dan

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> Sent: Sunday, November 06, 2005 6:33 PM
> To: Mreview (E-mail)
> Subject: FW: REMINDER: RADEXT WG last call on RFC 3576 MIBs
>=20
> Here are 2 other MIB documents in that WG to review.
>=20
> Bert
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bernard Aboba
> Sent: Wednesday, November 02, 2005 17:00
> To: [email-masked]
> Subject: REMINDER: RADEXT WG last call on RFC 3576 MIBs
>=20
>=20
> This is a reminder of an RADEXT WG last call in progress on=20
> the RFC 3576 MIBs.  These documents are being considered for=20
> publication as Informational RFCs. The documents are=20
> available for inspection here:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> client-mib-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> server-mib-02.txt
>=20
> RADEXT WG last call will last until Monday, November 14,=20
> 2005. Please send comments to the RADEXT WG mailing list=20
> ([email-masked]) in the format described in the=20
> RADEXT Issues list:
>=20
> http://www.drizzle.com/~aboba/RADEXT/
>=20
> If you have read the documents, please respond to this WG=20
> Last Call, if only to say "I have read the documents and I am=20
> OK with them."
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20
>=20

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

Delivery-date: Sun, 13 Nov 2005 22:48:29 +0000
content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
Date: Mon, 14 Nov 2005 00:47:28 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>

At the request of the Operations and Management Area Director I read
again the documents. Here are my findings:

General

1. It is bad to have the following defined in multiple documents:

radiusMIB  OBJECT-IDENTITY
          STATUS  current
          DESCRIPTION
                "The OID assigned to RADIUS MIB work by the IANA."
           ::=3D { mib-2 67 }

radiusAuthentication  OBJECT IDENTIFIER ::=3D {radiusMIB 1}

These should be defined in the MIB module in one document only, say
draft-ietf-radext-rfc2618bis-01.txt and imported in the other MIB
modules.=20

I remember having made this comment previously ... Or maybe I am
confusing?=20

2. All MIB modules include deprecated IPv4 tables and new IPv4/IPv6
tables. In the case when both the older deprecated IPv4 tables and the
new IPv4 / IPv6 tables are supported in agents for backwards
compatibility reasons, is there any relationship between the indexation
of the two tables?=20

3. What does the following text present in all documents mean?=20

Managed entities SHOULD NOT instantiate the deprecated table
   containing IPv4-only address objects when the RADIUS server address
   represented in the table row is not an IPv4 address.  Managed
   entities SHOULD NOT return inaccurate values of IP address or SNMP
   object access errors for IPv4-only address objects in otherwise
   populated tables.

Does this mean that if there is at least one address that is not an IPv4
address the whole deprecated table will not be implemented, or does this
mean that only instances that do not correspond to IPv4 addresses are
not implemented, but the table exists and includes rows only for IPv4
instances?=20

4. It would be helpful if UNITS clauses would be added where applicable
to objects with a SYNTAX of Counter32=20

5. It would be helpful if REFERENCE clauses would be added to the
definition of objects that have a direct mapping on RFC 2865. For
example the definition of the radiusAuthClientExtAccessRequests object
in draft-ietf-radext-rfc2618bis-01.txt should include a REFERENCE clause
that points to RFC 2865, Section 4.1.=20

6. All MIB modules include objects that refer to malformed requests and
malformed responses (radiusAuthClientExtMalformedAccessResponses,
radiusAuthServTotalMalformedAccessRequests,
radiusAuthServExtMalformedAccessRequests,
radiusAccClientExtMalformedResponses, etc.). I could not find a
definition of 'malformed' in RFC 2865.Some definitions refer to length,
but the definitions need to be clear and consistent.=20

7. As the documents define MIB modules referring to various aspects of
the instrumentation of RFC 2865, and RFC 2866, I believe that one
cannot implement these documents without understanding and implementing
relevant portions of RFC 2865 or RFC 2866. In consequence, [RFC2865]
should be Normative Reference for RFC 2618-bis and RFC 2619-bis and
[RFC2866] should be Normative Reference for RFC 2620-bis and RFC
2621-bis, rather than Informative.

8. RFC 3411needs to be added to the Normative References because
SnmpAdminString is imported from SNMP-FRAMEWORK-MIB

9. The Security Considerations sections in the documents are not aligned
with the latest boilerplate described in
http://www.ops.ietf.org/mib-security.html.=20

Specifically the last paragraph in each Section needs to be replaced
with the following:

It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

9. I believe that the DESCRIPTION clauses of the MODULE-COMPLIANCE
modules need to be harmonized with the content of the sections
describing the Deprecated objects. The DESCRIPTION of the deprecated
module should mention that these modules are for IPv4 entities only,
while the current modules support both IPv4 and IPv6.=20

draft-ietf-radext-rfc2618bis-01.txt

1. idnits has no problem with this I-D.

2. smilint complains about:=20

smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2618bis.txt

rfc2618bis.txt:15: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration

This is because of the root registration issue that was discussed on the
radext mailing list, and the WG decided to keep the root of the MIB
modules under the administration of the WG, and not of IANA.=20

I do not like this, but I can live with it.=20

3. The acronym NAS shows up for the first time in Section 5 of the
document without being expanded.=20

4. Section 5 includes the following text:

   Each entry in the RADIUS Authentication Server Table includes sixteen
   columns presenting a view of the activity of the RADIUS
   authentication client.

Actually the first column is not-accessible, representing the index of
the table. There are only fifteen accessible columns for each entry.

draft-ietf-radext-rfc2619bis-01.txt

1. idnits has no problem with this I-D.

2. smilint complies about:

smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2619bis.txt

rfc2619bis.txt:11: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration

This is because of the root registration issue that was discussed on the
radext mailing list, and the WG decided to keep the root of the MIB
modules under the administration of the WG, and not of IANA.=20

I do not like this, but I can live with it.=20

3. The Abstract section should shortly define the scope of the MIB, and
not only mentions that it updates RFC 2619.

4. Section 5 includes the following text:

Each entry in the RADIUS Authentication Client Table
   includes thirteen columns presenting a view of the activity of the
   RADIUS authentication server.

One of the columns is actually an un-accessible index, so only twelve of
the columns present a view of the activity of the clients.=20

5. The statement made in the Security Consideration section that the MIB
does not include any object with a read-write MAX-ACCESS is not
accurate. The radiusAuthServConfigReset has a MAX-ACCESS of read-write,
and the Security Consideration sections needs to include the description
of the security hazards related to the intentional or non-intentional
incorrect manipulation of this object, as well as the boilerplate text
related to writeable objects.=20

6. radiusAuthServConfigReset - is reset(2) the only writeable value for
this object? If so, this needs to be mentioned in the DESCRIPTION
clause, and the desired behavior of the agent if a different value is
entered must be described.=20

draft-ietf-radext-rfc2620bis-01.txt

1. idnits has no problem with this I-D.

2. smilint complies about:

smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2620bis.txt

rfc2620bis.txt:16: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration

I do not like this, but I can live with it.=20

3. The Abstract section should shortly define the scope of the MIB, and
not only mentions that it updates RFC 2619.

4. The acronym NAS shows up for the first time in Section 5 of the
document without being expanded.=20

5. Section 5 includes the following text:

Each entry in
   the RADIUS Accounting Server Table includes fifteen columns
   presenting a view of the activity of the RADIUS client.

One of the columns is actually an un-accessible index, so only fourteen
of the columns present a view of the activity of the clients.=20

draft-ietf-radext-rfc2621bis-01.txt

1. idnits complains about:

tmp/draft-ietf-radext-rfc2621bis-01.txt(595): Line has weird spacing:
'...invalid  authe...'
tmp/draft-ietf-radext-rfc2621bis-01.txt(789): Line has weird spacing:
'...invalid  authe...'

2. smilint complies about:

smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2621bis.txt

rfc2621bis.txt:13: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration

I do not like this, but I can live with it.=20

3. Section 5 includes the following text:

Each entry in the RADIUS Accounting Client Table includes twelve columns
   presenting a view of the activity of the RADIUS accounting server

.One of the columns is actually an un-accessible index, so only eleven
of the columns present a view of the activity of the clients.=20

4. The statement made in the Security Consideration section that the MIB
does not include any object with a read-write MAX-ACCESS is not
accurate. The radiusAccServConfigReset has a MAX-ACCESS of read-write,
and the Security Consideration sections needs to include the description
of the security hazards related to the intentional or non-intentional
incorrect manipulation of this object, as well as the boilerplate text
related to writeable objects.=20

Overall I believe that the documents are at in a reasonable shape. They
can be forwarded to the IESG for consideration as Proposed or
Informational, either with a list of known problems, or (better) after a
short editing round to fix the problems detected during the WGLC.

Regards,

Dan

=20

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bernard Aboba
> Sent: Wednesday, November 02, 2005 16:57
> To: [email-masked]
> Subject: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
>=20
>=20
> This is a reminder that RADEXT WG last call on RFC=20
> 2618bis-2621bis is in progress.  These documents are being=20
> considered as Proposed Standards (2618bis, 26819bis) and=20
> Informational (2620bis, 2621bis). The documents are available=20
> for inspection here:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618b
> is-01.txt
> (Proposed Standard)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619b
> is-01.txt
> (Proposed Standard)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620b
is-01.txt
(Informational)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt
(Informational)

RADEXT WG last call will last until Monday, November 14, 2005. Please
send comments to the RADEXT WG mailing list ([email-masked]) in
the format described in the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Note:  so far no WG last call comments have been received.  If you have
read the documents, please respond to the WG last call, even if only to
say "I am OK with them".

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

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

Delivery-date: Sun, 13 Nov 2005 07:36:33 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG last call on RFC 2618bis-2621bis
Date: Sun, 13 Nov 2005 13:06:23 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Except the two issues I just filed (statistics issue and the RFC
reference issue), the drafts look good to me.

Regards
Nagi. =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, October 21, 2005 2:25 AM
> To: [email-masked]
> Subject: RADEXT WG last call on RFC 2618bis-2621bis
>=20
> This is an announcement of RADEXT WG last call on RFC=20
> 2618bis-2621bis, prior to sending the documents on to the=20
> IESG for consideration as Proposed Standards (2618bis,=20
> 26819bis) and Informational (2620bis, 2621bis).  The=20
> documents are available for inspection here:
>=20
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618b
> is-01.txt
> (Proposed Standard)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619b
> is-01.txt
> (Proposed Standard)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620b
> is-01.txt
> (Informational)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621b
> is-01.txt
> (Informational)
>=20
> RADEXT WG last call will last until Monday, November 14,=20
> 2005.  Please send comments to the RADEXT WG mailing list=20
> ([email-masked]) in the format described in the=20
> RADEXT Issues list:
>=20
> http://www.drizzle.com/~aboba/RADEXT/
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Sun, 13 Nov 2005 07:32:51 +0000
Content-class: urn:content-classes:message
Subject: Issue: Add RFC references 
Date: Sun, 13 Nov 2005 13:02:34 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5E824.69FC065B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Description of issue: Add RFC 3411 reference for SnmpAdminString

Submitter names: Nagi R Jonnala

Submitter email address: [email-masked]

Date first submitted: July 30th, 2004

Reference:=20

None

Document:=20

All four Radius IPv6 drafts and infact the issues were there in the
original RFCs as well.

Comment type: 'T'echnical |

Priority:  '1' Should fix

Section: See below

Rationale/Explanation of issue: See below

Length description of problem:=20

SNMP-FRAMEWORK-MIB (for SnmpAdminString) is defined in RFC 3411 and
should be added as a reference.

Requested changes:

RFC 3411 should be added in the normative reference for all four Radius
IPv6 drafts.

------_=_NextPart_001_01C5E824.69FC065B
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">
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV>
<P><FONT face=3DArial><FONT size=3D2>Description of issue:&nbsp;<SPAN=20
class=3D823201807-13112005>Add </SPAN><SPAN =
class=3D507255306-13112005><SPAN=20
class=3D823201807-13112005>RFC 3411 reference for=20
SnmpAdminString</SPAN></SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2>Submitter name<SPAN=20
class=3D507255306-13112005>s</SPAN>:&nbsp;<SPAN =
class=3D507255306-13112005>Nagi R=20
Jonnala</SPAN></FONT></FONT></P>
<P><FONT size=3D+0><SPAN class=3D507255306-13112005></SPAN><FONT =
face=3DArial><FONT=20
size=3D2>Submitter email address:&nbsp;<SPAN =
class=3D507255306-13112005><A=20
title=3Dmailto:[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</SPAN></FONT></FONT=
></FONT><FONT=20
size=3D+0><FONT face=3DArial><FONT =
size=3D2></FONT></FONT></FONT></A></P>
<P><FONT size=3D+0><FONT face=3DArial><FONT size=3D2>Date first =
submitted:&nbsp;<SPAN=20
class=3D507255306-13112005>July</SPAN>&nbsp;<SPAN=20
class=3D507255306-13112005>30</SPAN>th, 200<SPAN=20
class=3D507255306-13112005>4</SPAN></FONT></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Reference: </FONT></P>
<P><SPAN class=3D823201807-13112005><FONT face=3DArial =
size=3D2>None</FONT></SPAN></P>
<P><FONT face=3DArial size=3D2>Document: </FONT></P>
<P><SPAN class=3D507255306-13112005><FONT face=3DArial size=3D2>All four =
Radius IPv6=20
drafts and infact the issues were&nbsp;there in the original RFCs as=20
well.</FONT></SPAN></P>
<P><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Comment type:=20
'T'echnical |</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Priority:&nbsp;=20
'1' Should fix</FONT></P></FONT>
<P><FONT face=3DArial size=3D2>Section: See below</FONT></P>
<P><FONT face=3DArial><FONT size=3D2>Rationale/Explanation of =
issue:&nbsp;<SPAN=20
class=3D507255306-13112005>See below</SPAN></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Length description of problem: =
</FONT></P>
<P>SNMP-FRAMEWORK-MIB<SPAN class=3D823201807-13112005> (for <FONT =
face=3DArial=20
size=3D2>SnmpAdminString) is defined in RFC 3411 and should be added as =
a=20
reference.</FONT></SPAN></P>
<P><FONT face=3DArial size=3D2>Requested changes:</FONT></P>
<P><SPAN class=3D823201807-13112005><FONT face=3DArial size=3D2>RFC 3411 =
should be=20
added in the normative reference for all four Radius IPv6=20
drafts.</FONT></SPAN></P></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C5E824.69FC065B--

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

Delivery-date: Sun, 13 Nov 2005 07:12:51 +0000
Content-class: urn:content-classes:message
Subject: Issue: Comments to RADIUS IPv6 MIBs
Date: Sun, 13 Nov 2005 12:42:16 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Glen Zorn \(gwz\)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5E821.941EF67B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Description of issue: The description of the statistics have errors from
the original RFCs

Submitter names: Nagi R Jonnala, Stefaan De Cnodder

Submitter email address: [email-masked],
[email-masked]

Date first submitted: July 30th, 2004

Reference:=20

https://psg.com/lists/radiusext/2004/msg00650.htm

Document:=20

All four Radius IPv6 drafts and infact the issues were there in the
original RFCs as well.

Comment type: 'T'echnical |

Priority:  '1' Should fix

Section: See below

Rationale/Explanation of issue: See below

Length description of problem:=20

I realized that the issue we raised long back as mentioned in the below
thread is not resolved in the Radius IPv6 drafts and could be resolved.

https://psg.com/lists/radiusext/2004/msg00650.htm
<https://psg.com/lists/radiusext/2004/msg00650.htm>=20

Requested changes:

Nagi and Stefaan raised the issue and suggested some text to resolve the
issue in the above thread. Please note that a conclusion was not reached
and can be discussed now.

------_=_NextPart_001_01C5E821.941EF67B
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">
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT face=3DArial><FONT size=3D2>Description of issue:&nbsp;<SPAN=20
class=3D507255306-13112005>The </SPAN><SPAN =
class=3D507255306-13112005>description=20
of the statistics have errors from the original =
RFCs</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2>Submitter name<SPAN=20
class=3D507255306-13112005>s</SPAN>:&nbsp;<SPAN =
class=3D507255306-13112005>Nagi R=20
Jonnala, Stefaan De Cnodder</SPAN></FONT></FONT></P>
<P><FONT><SPAN class=3D507255306-13112005></SPAN><FONT =
face=3DArial><FONT=20
size=3D2>Submitter email address:&nbsp;<SPAN =
class=3D507255306-13112005><A=20
href=3D"mailto:[email-masked]">[email-masked]</A>, <A=20
href=3D"mailto:[email-masked]">stefaan.de_cnodder@alcatel.=
be</A></SPAN></FONT></FONT></FONT></P>
<P><FONT><FONT face=3DArial><FONT size=3D2>Date first =
submitted:&nbsp;<SPAN=20
class=3D507255306-13112005>July</SPAN>&nbsp;<SPAN=20
class=3D507255306-13112005>30</SPAN>th, 200<SPAN=20
class=3D507255306-13112005>4</SPAN></FONT></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Reference: </FONT></P>
<P><FONT face=3DArial size=3D2><A=20
href=3D"https://psg.com/lists/radiusext/2004/msg00650.htm">https://psg.co=
m/lists/radiusext/2004/msg00650.htm</A></FONT></P>
<P><FONT face=3DArial size=3D2>Document: </FONT></P>
<P><SPAN class=3D507255306-13112005><FONT face=3DArial size=3D2>All four =
Radius IPv6=20
drafts and infact the issues were&nbsp;there in the original RFCs as=20
well.</FONT></SPAN></P>
<P><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Comment type:=20
'T'echnical |</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Priority:&nbsp;=20
'1' Should fix</FONT></P></FONT>
<P><FONT face=3DArial size=3D2>Section: See below</FONT></P>
<P><FONT face=3DArial><FONT size=3D2>Rationale/Explanation of =
issue:&nbsp;<SPAN=20
class=3D507255306-13112005>See below</SPAN></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Length description of problem: =
</FONT></P>
<P><SPAN class=3D507255306-13112005><FONT face=3DArial size=3D2>I =
realized that the=20
issue we raised long back as mentioned in the below thread&nbsp;is not =
resolved=20
in the Radius IPv6 drafts and could be resolved.</FONT></SPAN></P>
<P><SPAN class=3D507255306-13112005><A=20
href=3D"https://psg.com/lists/radiusext/2004/msg00650.htm"><FONT =
face=3DArial=20
size=3D2>https://psg.com/lists/radiusext/2004/msg00650.htm</FONT></A></SP=
AN></P>
<P><FONT face=3DArial size=3D2>Requested changes:</FONT></P>
<P><FONT face=3DArial size=3D2><SPAN class=3D507255306-13112005>Nagi and =

Stefaan&nbsp;raised the issue and suggested&nbsp;some text to resolve =
the issue=20
in the above thread. Please note that a conclusion was not =
reached&nbsp;and can=20
be discussed now.</SPAN></FONT><FONT face=3DArial=20
size=3D2></FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C5E821.941EF67B--

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

Delivery-date: Sun, 13 Nov 2005 06:07:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of RFC 3576 MIBs
Date: Sun, 13 Nov 2005 11:37:09 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Thank you very much Alan for your review. Please see inline for <Nagi>.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Thursday, November 10, 2005 7:19 AM
> To: [email-masked]
> Subject: Review of RFC 3576 MIBs
>=20
> draft-ietf-radext-dynauth-client-mib-02.txt
>=20
>   Nits:
>=20
>  1) There are references to "Disconnect messages" and "CoA messages"
> (radiusDynAuthClientDisconInvalidServerAddresses,
> radiusDynAuthClientCoAInvalidServerAddresses, and maybe others).
> While this terminology is used in RFC 3576, it would be good=20
> to be consistent with Section 3 of the document, the other=20
> MIB entries, and use "Disconnect-Request packet" and=20
> CoA-Request packet".

<Nagi> The DAC may receive Disconnect-Response packets. To make it
consistent with other four MIBs, we'll update with "Disconnect-Response
packets" and "CoA-Response packets". Please note that as you mentioned
Response packets are mentioned in RFC 3576 Section 2.2.

>=20
>   See also radiusDynAuthServerDisconInvalidClientAddresses=20
> and radiusDynAuthServerCoAInvalidClientAddresses in the=20
> server MIB. The radiusDynAuthServDupDisconRequests refers to=20
> "Disconnect-Request packets", for example.

>   2) radiusDynAuthServerAddress has a description of "IP=20
> address value...", but it's missing a phrase used in the=20
> 26**bis documents:
>=20
> 	"..., , using the version neutral IP adddess format."
>=20
>   See also radiusDynAuthClientAddress in the server MIB.
>=20
>   I suggest adding that to be consistent with other RADIUS MIBs.

<Nagi> OK, we'll change.=20

>=20
>   3) Similarly, radiusDynAuthServerID talks about the=20
> NAS-Identifier, but is missing text that's in RFC 2619, and=20
> rfc2619bis:
>=20
> 	"This is not necessarily the same as sysName in MIB II."
>=20
>    See also radiusDynAuthServerIdentifier in the server MIB.
>=20
>   Question: Is this text relevant?

<Nagi> I guess this text means that it is a particular Radius
authentication/accounting/DynAuth client/server module name and could be
different from sysName. To make it consistent, we can also adopt that
text.=20

>=20
>  4) radiusDynAuthClientMalformedCoAResponses talks about=20
> "CoA-Response packets", but no such packets are defined in=20
> RFC 3576 (barring a diagram on page 6).  I would suggest=20
> using explicit "CoA-ACK" and CoA-NAK", but rfc2618bis uses=20
> "Access-Response" in the same manner.
>=20
>   And the text in radiusDynAuthClientCoAPendingRequests uses=20
> "CoA-Ack, CoA -NAK" explicitly.  (And there's an extra space=20
> in CoA-NAK)
>=20
>   I'm not sure what to suggest here.  Either leave it as-is,=20
> or change both this and rfc2618bis.

<Nagi> As I mentioned above, IMO, it is ok to have
Disconnect/CoA-Response packtes terminology and they are mentioned in
the diagram.

>=20
> ---
> draft-ietf-radext-dynauth-server-mib-02.txt
>=20
>   See comments above. Also, page 4, references to=20
> [RFC2618bis] and [DYNCLIENT] don't have RFC editor notes to=20
> replace the text with the final RFC numbers.  I don't know if=20
> such a note is necessary.
>=20

<Nagi> This makes sense otherwise how will the RFC editor know.=20

Thanks
Nagi.

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

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

Delivery-date: Sun, 13 Nov 2005 05:07:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Cmts on 3576 MIBs
Date: Sun, 13 Nov 2005 10:36:14 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Greg Weber \(gdweber\)" <[email-masked]>, <[email-masked]>

Thank you Greg for your review. Apparently new changes in this draft
have got these typos and we'll update.

Thanks
Nagi.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Greg Weber=20
> (gdweber)
> Sent: Thursday, November 10, 2005 7:54 AM
> To: [email-masked]
> Subject: Issue: Cmts on 3576 MIBs
>=20
>=20
> Description of issue: Minor editorial cmts Submitter name:=20
> Greg Weber Submitter email address: [email-masked] Date=20
> first submitted: November 9th, 2005
> Reference: N/A
> Document:=20
>   draft-ietf-radext-dynauth-server-mib-02.txt
>   draft-ietf-radext-dynauth-client-mib-02.txt
> Comment type: 'E' Editorial
> Priority: '2' May fix
> Section: See below
> Rationale/Explanation of issue: Typos
> Length description of problem:=20
>   I reread the docs.  They look fine to me with the exception of the
>   typos mentioned below.
> Requested changes:
>=20
> draft-ietf-radext-dynauth-server-mib-02.txt
>   p7, radiusDynAuthServerMIB:
>     Remote Access Dialin User Service ->=20
>     Remote Authentication Dial In User Service
>   p11, radiusDynAuthServDisconAuthOnlyRequests:=20
>     Autorize -> Authorize
>   p12, radiusDynAuthServDisconNakAuthOnlyRequests:
>     Autorize -> Authorize
>   p14, radiusDynAuthServCoAAuthOnlyRequests:
>     Autorize -> Authorize
>   p15, radiusDynAuthServCoANakAuthOnlyRequests:
>     Autorize -> Authorize
>   p19, radiusDynAuthServerAuthOnlyGroup:
>     Autorize -> Authorize
>   p21, Section 5: IPSec -> IPsec
>=20
> draft-ietf-radext-dynauth-client-mib-02.txt
>   p1, Abstract:  RFC3576 -> RFC 3576
>   p10, radiusDynAuthClientDisconAuthOnlyRequests:
>     Autorize -> Authorize
>   p11, radiusDynAuthClientDisconNakAuthOnlyRequest:
>     Autorize -> Authorize
>   p14, radiusDynAuthClientCoAAuthOnlyRequest:
>     Autorize -> Authorize
>   p15, radiusDynAuthClientCoANakAuthOnlyRequest:
>     Autorize -> Authorize
>   p19, radiusDynAuthClientAuthOnlyGroup:
>     Autorize -> Authorize
>   p21, Section 5:  IPSec -> IPsec
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Fri, 11 Nov 2005 21:47:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 116: Technical Comments by Dave Nelson
Date: Fri, 11 Nov 2005 13:47:40 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Yes, we are only using the 12-bit VID field.=20

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]]=20
> Sent: Friday, November 11, 2005 1:20 PM
> To: Congdon, Paul T (ProCurve)
> Cc: [email-masked]
> Subject: RE: Issue 116: Technical Comments by Dave Nelson
>=20
>=20
> > We discussed the use of the Integer type for VLAN-ID field=20
> at IETF-64=20
> > and agreed to not change this to a string of octects as suggested by
> the
> > issue resolution.  It was also pointed out that the MIB uses an
> Integer
> > to represent a VLAN-ID.
>=20
> As long as we are only using the 12-bit VID part and not the=20
> other bit fields, using an integer is fine with me.
>=20

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

Delivery-date: Fri, 11 Nov 2005 21:21:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 116: Technical Comments by Dave Nelson
Date: Fri, 11 Nov 2005 16:20:25 -0500
From: "Nelson, David" <[email-masked]>
To: "Congdon, Paul T \(ProCurve\)" <[email-masked]>
Cc: <[email-masked]>

> We discussed the use of the Integer type for VLAN-ID field at IETF-64
> and agreed to not change this to a string of octects as suggested by
the
> issue resolution.  It was also pointed out that the MIB uses an
Integer
> to represent a VLAN-ID.

As long as we are only using the 12-bit VID part and not the other bit
fields, using an integer is fine with me.

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

Delivery-date: Fri, 11 Nov 2005 20:06:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 130: Diameter Compatibility (IEEE 802 Last call) 
Date: Fri, 11 Nov 2005 12:06:42 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>

I'd like to test the consensus from IETF-64 on this issue.  I believe we
agreed that we would not split-up the attribute into multiple attributes
because of the ordering issues.  I also believe we agreed to define the
Radius attribute as needed and provide compatibility and
interoperability with Diameter using existing practices for supporting
Radius attributes in Diameter.  This would imply that we need to rename
the current NAS-Filter-Rule attribute to something else in order to
avoid confusion with Diameter's AVP.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Sanchez,=20
> Mauricio (PNB Roseville)
> Sent: Thursday, September 08, 2005 2:56 PM
> To: [email-masked]
> Subject: Issue 130: Diameter Compatibility (IEEE 802 Last call)=20
>=20
>=20
> Bernard writes...=20
>=20
> > Issue 130: Diameter Compatibility
> > Submitter name: Bernard Aboba
> > Submitter email address: [email-masked] Date first
> > submitted: August 29, 2005
> > Reference:=20
> > Document: IEEE802-00
> > Comment type: T
> > Priority: S
> > Section: Various
> > Rationale/Explanation of issue:
> > The document does not contain a Diameter Compatibility section, as=20
> > required by the RADEXT WG charter.
> >=20
> > In reviewing the document, there appears to a major compatibility=20
> > problem between this document and Diameter NASREQ (RFC 4005).
> >=20
> > The NAS-Filter-Rule attribute defined in the document is not=20
> > compatible with the NAS-Filter-Rule attribute defined in RFC 4005,=20
> > which is based on the IPFilterRule type defined in RFC 3588.
> > This incompatibility will break RADIUS/Diameter gateways.=20
> > [Jari Arkko]  This is a problem.=20
> >=20
> > My suggestion is to define the restrict the NAS-Filter-Rule=20
> attribute=20
> > to the RFC 3588 syntax, and define additional attributes for other=20
> > purposes, such as Layer 2 filtering and HTTP redirect. It=20
> is ok if the=20
> > same general syntax is used for these other filters, but=20
> they need to=20
> > be defined as separate attributes to enable translation of=20
> > NAS-Filter-Rule AVP from RADIUS to Diameter and back.
> > [Jari Arkko] Sounds like a good suggestion to me.=20
> > [John Loughney] I agree. Bernard's proposal seems reasonable.=20
>=20
> Say we did break out NAS-Filter-Rule into multiple=20
> attributes, each with its own type value.  How would I be=20
> able to guarantee strict ordering, given that RADIUS proxies=20
> do not have to preserve order for attributes of different=20
> types?  Maintenance of order is vital.
>=20
> Cheers,
> MS=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Fri, 11 Nov 2005 20:02:14 +0000
Content-class: urn:content-classes:message
Subject: Issue 116: Technical Comments by Dave Nelson
Date: Fri, 11 Nov 2005 12:02:06 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>, "Nelson, David" <[email-masked]>

We discussed the use of the Integer type for VLAN-ID field at IETF-64
and agreed to not change this to a string of octects as suggested by the
issue resolution.  It was also pointed out that the MIB uses an Integer
to represent a VLAN-ID.

Paul

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

Delivery-date: Fri, 11 Nov 2005 19:57:52 +0000
Content-class: urn:content-classes:message
Subject: Issue 111: Accounting (in current ieee802 draft)
Date: Fri, 11 Nov 2005 11:57:47 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>

At IETF-64 we reviewed this issue.  There did not seem to be any
objection to having compliance statements in the Annex given that this
Annex is where the context for the statements is developed.  Also, since
a new session is created, as stated in the draft, there is no need to
use INTERM messages.

Paul

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

Delivery-date: Fri, 11 Nov 2005 19:56:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 110: Compliance and Coherence
Date: Fri, 11 Nov 2005 11:54:30 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

At IETF-64 we discussed this issue and I believe the consensus regarding
this was that we will NOT split the draft into two or more drafts with
fewer attributes and that the current statement in section 2.2 was
sufficient to describe compliance.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Congdon,=20
> Paul T (ProCurve)
> Sent: Wednesday, September 21, 2005 2:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Issue 110: Compliance and Coherence
> Importance: High
>=20
>=20
> Greg has made the following comment on the 802 attributes draft:
>=20
> >1) Compliance vs. Functional Coherence
> >Most of the RADIUS RFCs tend to address a single functional=20
> area, e.g.=20
> >IPv6 attributes, EAP, tunneling, etc.  This is good because=20
> RFCs tend=20
> >to become checkmarks on RFPs or customer requirements.  This=20
> documents=20
> >seems to combine functionality that is only related to IEEE=20
> 802 (VLANs)
>=20
> >and things that are independent of access type.  For=20
> example, filtering
>=20
> >and redirection can apply equally usefully to PPP-based L2=20
> connections.
>=20
> >If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim=20
> >compliance to this potential RFC unless I support all the=20
> VLAN oriented
>=20
> >attributes because the compliance language in section 1.2=20
> requires an=20
> >all or nothing approach to compliance.  Can the authors=20
> clarify why the
>=20
> >NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802=20
> >specific attributes?
> >
> >I would think these should be addressed via separate documents.
>=20
> Throughout the history of this document we have included,=20
> excluded, added and removed various attributes to get the=20
> scope of the document
> just right.   We have been balancing the tradeoff of getting a
> reasonable focused set of attributes in a single document=20
> without creating a slew of attribute documents to run through=20
> the process.
> Also, we are addressing the needs and requests of other SDOs=20
> for completing the work on this set of attributes in a timely manner.
>=20
> I believe we can (and perhaps have) address the issue of=20
> compliance to the spec by indicating in the front matter how=20
> NAS devices that do not support media that provides the=20
> functionality controlled by the attributes in the spec are=20
> supposed to behave.  We already have statements in the spec=20
> (section 2.2) that say if you can't support the functionality=20
> requested by the attributes you MUST treat an Access-Accept=20
> as an Reject.  This should be sufficient to allow non VLAN=20
> devices to use this spec and still create an environment with=20
> predictable behavior.
>=20
> Paul
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Fri, 11 Nov 2005 18:52:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Fri, 11 Nov 2005 10:51:02 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

At IETF-64, we discussed this issue and concluded that we would remove
QoS-Filter-Rule from the draft.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Congdon,=20
> Paul T (ProCurve)
> Sent: Tuesday, October 25, 2005 10:20 AM
> To: Glen Zorn (gwz)
> Cc: [email-masked]; [email-masked]
> Subject: RE: Issue 113: Attribute Concatenation
>=20
>=20
> I'd like to revive this thread a bit.  I never finished the=20
> response to Glenn about QoS-Filter-Rule for Radius...
>=20
> As a warm-up, remember, what we are trying to do is simply=20
> import the QoS-Filter-Rule AVP from Diameter into Radius.  We=20
> felt since it was defined for Diameter (and presumable=20
> implemented), that we could easily define it for Radius by=20
> addressing the differences and missing funcationality.
>=20
> >=20
> > > Taking Glen's suggested text, I'd like to close this=20
> issue out with=20
> > > the following proposed text for the Text field in section 3.6.
> > > Please let me know if this will work. =20
> > >=20
> > >=20
> > >      Text
> > >=20
> > >         The Text field contains a QoS filter, utilizing the syntax
> > >         defined for the QoSFilterRule derived data type defined in
> > >         [RFC3588], Section 4.3.  Note that this=20
> definition contained
> > >         an error, so that the complete syntax is described in the
> > >         definition of the QoS-Filter-Rule AVP, defined in=20
> [NASREQ].
> >=20
> > Are you _sure_ that you want to use this syntax?  It's awfully=20
> > verbose.  Even if you really do want to use it, I would=20
> suggest that=20
> > you reproduce it (or rather, adapt it to use w/RADIUS) in this=20
> > document, rather than incorporating it by reference.  There are=20
> > several problems with the Diameter definitions, not least=20
> of which is=20
> > that the definition of the QoS-Filter-Rule AVP depends upon the=20
> > definition of IPFilterRule which is derived from OctetString which=20
> > doesn't exist in RADIUS.
> >=20
>=20
> Seems like we have a couple of options here:
>=20
> 1. completely define the attribute syntax, as we have done=20
> for NAS-Filter-Rule.  Perhaps leveraging much of the same=20
> definition, but providing new actions that match=20
> QoS-Filter-Rule actions.  The actions are mark and meter. =20
> The mark action could also take-on L2 functionality such as=20
> setting 802.1p bits in addition to setting DSCP.
>=20
> 2. provide text that defines the missing pieces from=20
> IPFilterRule, such as OctetString.
>=20
> 3. Drop the attribute all together.  I don't believe any=20
> other SDOs are depending upon this attributre.  I'm sure the=20
> TNC is not currently using it.  Also, there have been a=20
> number of concerns with QoS functionality in general (as seen=20
> in the simple bandwidth draft).  However, Diamater=20
> successfully has defined this AVP.
>=20
> Option 1 would be most consistent with the rest of the=20
> document.  Option
> 3 is the easy way out.  I'm not sure exactly what would be=20
> needed for option 2.
>=20
> Paul=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Thu, 10 Nov 2005 02:28:19 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Review of RFC 3576 MIBs 
Date: Wed, 09 Nov 2005 21:31:55 -0500
Message-Id: <[email-masked]>

"Alan DeKok" <[email-masked]> wrote:
> 	"..., , using the version neutral IP adddess format."

  Oops.  See previous comments on typo.

  Alan DeKok.

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

Delivery-date: Thu, 10 Nov 2005 02:24:26 +0000
Content-class: urn:content-classes:message
Subject: Issue: Cmts on 3576 MIBs
Date: Wed, 9 Nov 2005 21:24:10 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Minor editorial cmts
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: November 9th, 2005
Reference: N/A
Document:=20
  draft-ietf-radext-dynauth-server-mib-02.txt
  draft-ietf-radext-dynauth-client-mib-02.txt
Comment type: 'E' Editorial
Priority: '2' May fix
Section: See below
Rationale/Explanation of issue: Typos
Length description of problem:=20
  I reread the docs.  They look fine to me with the exception of the
  typos mentioned below.
Requested changes:

draft-ietf-radext-dynauth-server-mib-02.txt
  p7, radiusDynAuthServerMIB:
    Remote Access Dialin User Service ->=20
    Remote Authentication Dial In User Service
  p11, radiusDynAuthServDisconAuthOnlyRequests:=20
    Autorize -> Authorize
  p12, radiusDynAuthServDisconNakAuthOnlyRequests:
    Autorize -> Authorize
  p14, radiusDynAuthServCoAAuthOnlyRequests:
    Autorize -> Authorize
  p15, radiusDynAuthServCoANakAuthOnlyRequests:
    Autorize -> Authorize
  p19, radiusDynAuthServerAuthOnlyGroup:
    Autorize -> Authorize
  p21, Section 5: IPSec -> IPsec

draft-ietf-radext-dynauth-client-mib-02.txt
  p1, Abstract:  RFC3576 -> RFC 3576
  p10, radiusDynAuthClientDisconAuthOnlyRequests:
    Autorize -> Authorize
  p11, radiusDynAuthClientDisconNakAuthOnlyRequest:
    Autorize -> Authorize
  p14, radiusDynAuthClientCoAAuthOnlyRequest:
    Autorize -> Authorize
  p15, radiusDynAuthClientCoANakAuthOnlyRequest:
    Autorize -> Authorize
  p19, radiusDynAuthClientAuthOnlyGroup:
    Autorize -> Authorize
  p21, Section 5:  IPSec -> IPsec

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

Delivery-date: Thu, 10 Nov 2005 02:18:04 +0000
Content-class: urn:content-classes:message
Subject: Issue: Cmts on 2618-21bis MIBs
Date: Wed, 9 Nov 2005 21:17:45 -0500
From: "Greg Weber \(gdweber\)" <[email-masked]>
To: <[email-masked]>

Description of issue: Minor editorial cmts
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: November 9th, 2005
Reference: N/A
Document:=20
  draft-ietf-radext-rfc2618bis-01.txt
  draft-ietf-radext-rfc2619bis-01.txt
  draft-ietf-radext-rfc2620bis-01.txt
  draft-ietf-radext-rfc2621bis-01.txt
Comment type: 'E' Editorial
Priority: '2' May fix
Section: See below
Rationale/Explanation of issue: Typos
Length description of problem:=20
  I reread the docs.  They look fine to me with the exception of the
  typos mentioned below (some of which Alan has already mentioned).
Requested changes:

draft-ietf-radext-rfc2618bis-01.txt
  p10, radiusAuthClientPendingRequests: Acess -> Access
  p12, radiusAuthServerInetAddress: adddess -> address
  p14, radiusAuthClientExtPendingRequests: Acess -> Access
  p17, Section 9: MAX-\nACCESS -> MAX-ACCESS
       (See Section 2.1, #3 of http://www.ietf.org/ID-Checklist.html)
  p18, Section 9: IPSec -> IPsec

draft-ietf-radext-rfc2619bis-01.txt
  p14, radiusAuthClientInetAddress: adddess -> address
  p19, Section 9: MAX-\nACCESS -> MAX-ACCESS
  p19, Section 9: IPSec -> IPsec
 =20
draft-ietf-radext-rfc2620bis-01.txt
  p11, radiusAccServerInetAddress: adddess -> address
  p16, Section 9: MAX-\nACCESS -> MAX-ACCESS
  p17, Section 9: IPSec -> IPsec

draft-ietf-radext-rfc2621bis-01.txt
  p13, radiusAccClientInetAddress: adddess -> address
  p18, Section 9: MAX-\nACCESS -> MAX-ACCESS
  p18, Section 9: IPSec -> IPsec

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

Envelope-to: [email-masked]
Delivery-date: Thu, 10 Nov 2005 01:45:35 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: Review of RFC 3576 MIBs
Message-Id: <[email-masked]>
Date: Wed,  9 Nov 2005 20:48:48 -0500 (EST)

draft-ietf-radext-dynauth-client-mib-02.txt

  Nits:

 1) There are references to "Disconnect messages" and "CoA messages"
(radiusDynAuthClientDisconInvalidServerAddresses,
radiusDynAuthClientCoAInvalidServerAddresses, and maybe others).
While this terminology is used in RFC 3576, it would be good to be
consistent with Section 3 of the document, the other MIB entries, and
use "Disconnect-Request packet" and CoA-Request packet".

  See also radiusDynAuthServerDisconInvalidClientAddresses and
radiusDynAuthServerCoAInvalidClientAddresses in the server MIB. The
radiusDynAuthServDupDisconRequests refers to "Disconnect-Request
packets", for example.

  2) radiusDynAuthServerAddress has a description of "IP address
value...", but it's missing a phrase used in the 26**bis documents:

	"..., , using the version neutral IP adddess format."

  See also radiusDynAuthClientAddress in the server MIB.

  I suggest adding that to be consistent with other RADIUS MIBs.

  3) Similarly, radiusDynAuthServerID talks about the NAS-Identifier, but
is missing text that's in RFC 2619, and rfc2619bis:

	"This is not necessarily the same as sysName in MIB II."

   See also radiusDynAuthServerIdentifier in the server MIB.

  Question: Is this text relevant?

 4) radiusDynAuthClientMalformedCoAResponses talks about "CoA-Response
packets", but no such packets are defined in RFC 3576 (barring a
diagram on page 6).  I would suggest using explicit "CoA-ACK" and
CoA-NAK", but rfc2618bis uses "Access-Response" in the same manner.

  And the text in radiusDynAuthClientCoAPendingRequests uses "CoA-Ack,
CoA -NAK" explicitly.  (And there's an extra space in CoA-NAK)

  I'm not sure what to suggest here.  Either leave it as-is, or change
both this and rfc2618bis.

---
draft-ietf-radext-dynauth-server-mib-02.txt

  See comments above. Also, page 4, references to [RFC2618bis] and
[DYNCLIENT] don't have RFC editor notes to replace the text with the
final RFC numbers.  I don't know if such a note is necessary.

  Alan DeKok.

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

Delivery-date: Wed, 09 Nov 2005 23:33:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: RE : Issue 74: RFC 3576 behavior
Date: Wed, 09 Nov 2005 15:33:09 -0800

>I think that the COA procedure is a way to retrieve once again location 
>information received in a previous Access-Request (e.g. to check if the 
>previous location is still up-to-date).

If we are talking about the civil location of the NAS, why would it have 
changed?

Are we talking about a NAS located on a train that moves from city to city?  
In most cases, we are talking about a NAS that has a static location, so 
that sending periodic RFC 3576 CoA-Requests purely to see if it has changed 
civil location makes little sense.

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

Delivery-date: Wed, 09 Nov 2005 23:27:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: RE : Issue 74: RFC 3576 behavior
Date: Wed, 09 Nov 2005 15:27:23 -0800

>Is there any "send-location" attribute defined in the current draft?

No, there isn't yet.  But my understanding was that one will be added in the 
next version.

>For me, there is nothing in the COA "instructing" the client to sed the 
>location. I think that the >COA procedure is a way to retrieve once again 
>location information received in a previous Access->Request (e.g. to check 
>if the previous location is still up-to-date).

The problem is that RFC 3576 CoA-Requests don't have that semantic.  If no 
authorization was sent in the Access-Accept indicating that the NAS was to 
send location in all Access-Requests during a session, there is no reason 
for the NAS to send location in an Access-Request resulting from a 
CoA-Request.

In any case, if there is a desire for ongoing location information, RFC 3576 
shouldn't be used, rather the information should be sent in an Interim 
Accounting request.  So the "send-location" attribute needs to be clear 
exactly *when* location gets sent.  Is this in a single Access-Request, all 
Access-Request,  Access-Requests + Accounting Start/STOP,  also 
Accounting-Interim, etc.

>The COA here just means "send a new access-Request". If during the previous 
>exchange the NAS >has provided the location info, it is likely that the NAS 
>will provide it once again. But there is no >way to mandate it through the 
>COA request.

Actually, I would say that unless an authorization explicitly mandated 
location in an Access-Request, then the NAS should not send location, since 
its default behavior would not have changed (and the default is not to send 
location unless asked for it by the server).

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

Delivery-date: Wed, 09 Nov 2005 23:20:12 +0000
Content-class: urn:content-classes:message
Subject: RE : Issue 74: RFC 3576 behavior
Date: Thu, 10 Nov 2005 00:19:52 +0100
From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Is there any "send-location" attribute defined in the current draft?

For me, there is nothing in the COA "instructing" the client to sed the =
location. I think that the COA procedure is a way to retrieve once again =
location information received in a previous Access-Request (e.g. to =
check if the previous location is still up-to-date).=20

The COA here just means "send a new access-Request". If during the =
previous exchange the NAS has provided the location info, it is likely =
that the NAS will provide it once again. But there is no way to mandate =
it through the COA request.

Therefore, the following text:
   "The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request if=20
   it included the location information is previous Access-Requests. "

Should be modified to remove the "MUST"

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] =
De la part de Bernard Aboba
Envoy=E9 : mercredi 9 novembre 2005 23:45
=C0 : [email-masked]
Objet : Re: Issue 74: RFC 3576 behavior

I think there is still an issue here.

You need to be very clear about the meaning of the "Send-Location" =
attribute=20
when put in various messages by the server.  For example, if sent in an=20
Access-Challenge, does this mean "send location in the next =
Access-Request",=20
  or does it mean "send location in every RADIUS Access-Request in this=20
session", or does it mean "send location in Access-Request and=20
Accounting-Request messages."

I ask because this will determine the behavior of the RADIUS client when =
a=20
"Send-Location" attribute is sent in an Access-Accept.  If it means =
"send=20
location in the next Access-Request" then the client will do that, and =
only=20
that.  You should not expect location in an Access-Request sent as the=20
result of a CoA-Request, *unless* that CoA-Request contains a=20
"Send-Location" attribute.

-------------------------------------------------------------------------=
---------------------------------
hi all,

with issue #74 bernard raised a question with regard to the usage of rfc =
3576. avi proposed text is:

"
We need to change the paragraph from:

The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request.

to:
The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request if =
it included the location information is previous Access-Requests. "

i would like to ask whether this issue can be closed now?

ciao
hannes

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

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

Delivery-date: Wed, 09 Nov 2005 23:10:22 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: New AD Requirement: Four Reviews
Date: Wed, 09 Nov 2005 15:10:16 -0800

At the RADEXT WG meeting at IETF 64, the ADs requested that documents 
completing WG last call need to be reviewed by at least four individuals 
outside of the authors before they can be forwarded to the IESG for 
consideration.

We will now be enforcing this rule on WG last calls from this point forward. 
  The goal of this is to:

* Encourage members of the WG to read the documents.  If noone is reading 
the documents, then the ADs do not want to be the first ones to discover 
issues.

* Demonstrate interest.  If the document has not garnered enough interest 
for four people to read it other than the authors, then the IETF should not 
be spending time on it.

So far, we have had 1 review of the RADIUS IPv6 MIBs, and no reviews of the 
RFC 3576 MIBs.  WG last call on these documents completes on Monday, 
November 14, 2005.

Time for some weekend reading :)

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

Delivery-date: Wed, 09 Nov 2005 23:05:18 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADIUS Digest Authentication: Going to IESG Review
Date: Wed, 09 Nov 2005 15:05:07 -0800

At the RADEXT WG meeting at IETF 64, there appeared to be no new issues with 
the RADIUS Digest Authentication draft, and since all existing issues have 
been resolved, we will request that the document be put on the IESG agenda 
for review.

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

Delivery-date: Wed, 09 Nov 2005 22:45:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Issue 74: RFC 3576 behavior
Date: Wed, 09 Nov 2005 14:45:06 -0800

I think there is still an issue here.

You need to be very clear about the meaning of the "Send-Location" attribute 
when put in various messages by the server.  For example, if sent in an 
Access-Challenge, does this mean "send location in the next Access-Request", 
  or does it mean "send location in every RADIUS Access-Request in this 
session", or does it mean "send location in Access-Request and 
Accounting-Request messages."

I ask because this will determine the behavior of the RADIUS client when a 
"Send-Location" attribute is sent in an Access-Accept.  If it means "send 
location in the next Access-Request" then the client will do that, and only 
that.  You should not expect location in an Access-Request sent as the 
result of a CoA-Request, *unless* that CoA-Request contains a 
"Send-Location" attribute.

----------------------------------------------------------------------------------------------------------
hi all,

with issue #74 bernard raised a question with regard to the usage of rfc
3576. avi proposed text is:

"
We need to change the paragraph from:

The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request.

to:
The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request if
it
included the location information is previous Access-Requests.
"

i would like to ask whether this issue can be closed now?

ciao
hannes

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

Envelope-to: [email-masked]
Delivery-date: Wed, 09 Nov 2005 21:23:36 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis 
Date: Wed, 09 Nov 2005 16:26:28 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wroteL
> http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt 

  There's a typo on Page 12, radiusAuthServerInetAddress
	...
	the version neutral IP adddess format."
			          ^
  The same typo exists in rfc2619bis page 14, rfc2620bis page 11, and
rfc2621bis page 13.

  rfc2619bis, radiusAuthServConfigReset has MAX-ACCESS of read-write.
Yet the "Security Considerations" section says:

   There are no management objects defined in this MIB that have a MAX-
   ACCESS clause of read-write and/or read-create.

  This text should be updated to reflect the MAX-ACCESS clause in
radiusAuthServConfigReset.  rfc2621bis has the same issue.  I suggest
re-using the text from the first paragraph of RFC 2619, section 6.

  Other than that, the documents look OK.

  Alan DeKok.

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

Delivery-date: Wed, 09 Nov 2005 21:23:29 +0000
Date: Wed, 9 Nov 2005 22:22:46 +0100
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Slides for IETF 64
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked]

Slides regarding GEOPRIV are at
http://www.xs4all.nl/~evbergen/ietf/ietf64_radext_geopriv_challenges.pdf

I was already way too late for IETF 64, and my message didn't reach the
list either because I used the wrong sender address, but I still hope
this may help GEOPRIV/RADIUS' progress.

Kind regards,

Emile van Bergen.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

On Tue, Nov 08, 2005 at 02:05:43AM +0100, Emile van Bergen wrote:

> Hi,
> 
> Mine are here:
> 
> http://www.xs4all.nl/~evbergen/ietf/ietf64_radext_geopriv_challenges.pdf
> 
> Thanks,
> 
> 
> Emile
> 
> On Mon, Nov 07, 2005 at 08:42:29AM -0800, Bernard Aboba wrote:
> 
> > Are available here:
> > 
> > http://www.drizzle.com/~aboba/IETF64/radext/
> > 
> >  
> > 
> > If you haven't already sent slides to the chairs, please do so ASAP. 
> > 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Tue, 08 Nov 2005 22:49:22 +0000
Content-class: urn:content-classes:message
Subject: AW: Capabilities presentation
Date: Tue, 8 Nov 2005 23:48:34 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

hi david,=20
=20
i understand your concerns and i think that there is a nice migration =
path.=20

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von Nelson, David
> Gesendet: Dienstag, 8. November 2005 13:08
> An: [email-masked]
> Betreff: RE: Capabilities presentation
>=20
> Hannes Tschofenig writes...
>=20
> > regarding the future work on the capability document. you=20
> guys need to
> > decide what presentation style, requirement goals and problem
> statement
> > you might want. during the meeting i think we agreed that=20
> the current
> > radius-geopriv work is largely independent of the future, more
> generic,
> > capability work.
>=20
> I'm sensitive to your desire to make rapid progress.  If GEOPRIV is a
> special case, then maybe it should be treated as such.  If it=20
> is simply
> part of a general case, then I worry about setting a precedent for
> handling capabilities in RADIUS (with implied general scope) that may
> affect later work, without explicitly looking at that bigger picture.
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Nov 2005 22:41:53 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Subject: Re: http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt 
Cc: [email-masked]
Date: Tue, 08 Nov 2005 17:45:04 -0500
Message-Id: <[email-masked]>

"Glen Zorn (gwz)" <[email-masked]> wrote:
> That's the point: if you have an application that RADIUS can't support,
> you must transition to Diameter.

  Agreed.

  Practically, though, there are major pushes behind minor additions
to RADIUS.  It's not just the deployed base, it's the ease of making
minor tweaks to RADIUS implementations versus adding a brand new
protocol.  That appears to be the rationale behind RADEXT.

> How can you solve it w/o either changing the RADIUS packet format or
> transport?

  Additional rounds of Access-Request/Access-Challenge may work.  I
could see it being implemented in RADIUS with only minor changes to
the protocol and existing implementations.

  I'm not trying to push multiple extensions to RADIUS, I'm just
seeing if there's a more general way of satisfying the Diameter
interoperability requirements.

  Alan DeKok.

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

Delivery-date: Tue, 08 Nov 2005 22:01:14 +0000
Content-class: urn:content-classes:message
Subject: RE: http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt 
Date: Tue, 8 Nov 2005 14:00:46 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Alan DeKok <> supposedly scribbled:

> "Glen Zorn (gwz)" <[email-masked]> wrote:
>>> People try to send
>>> 100's of long string attributes via RADIUS, and it doesn't work.
>>=20
>> I think that the standard answer would be that that is perfectly
>> acceptable RADIUS behavior, and to use Diameter;
>=20
>   In existing deployments, where clients don't support Diameter?

That's the point: if you have an application that RADIUS can't support, =
you must transition to Diameter.

>=20
>   Are there *any* diameter clients built into equipment from major
> networking vendors?  I don't recall any off-hand.=20

Yes.

>=20
>>  what we were talking about was a bug that makes transitioning
>> gracefully from RADIUS to Diameter extremely painful, if not
>> impossible.
>=20
>   I agree.  My point was that RADIUS already has this issue,
> independent of Diameter. =20

I understand that.

> If we solve the issue for RADIUS, then we
> should also get better Diameter interoperability for free. =20

How can you solve it w/o either changing the RADIUS packet format or =
transport?

>=20
>   Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Nov 2005 21:48:04 +0000
From: "Alan DeKok" <[email-masked]>
To: "Tschofenig, Hannes" <[email-masked]>
Subject: Re: AW: Capabilities presentation 
Cc: [email-masked]
Date: Tue, 08 Nov 2005 16:51:35 -0500
Message-Id: <[email-masked]>

"Tschofenig, Hannes" <[email-masked]> wrote:
> for the discussions about radius-geopriv i was more interested in
> getting the document done rather than proposing a general capability
> mechanism for radius.

  I agree.

> regarding the future work on the capability document. you guys need to
> decide what presentation style, requirement goals and problem statement
> you might want.

  I presented goals and requirements in the document.  My previous
message re-iterated this point.  I'm not sure why you would again
request statements of goals and requirements when that request has
been already met.

>  during the meeting i think we agreed that the current
> radius-geopriv work is largely independent of the future, more generic,
> capability work.

  I agree.

  Can you address the goals and requirements I presented?  Should I
re-post them here?  Are they unclear?

  I don't think I misunderstood your statements.  You indicated that
you were uncomfortable with my presentation.  I would appreciate
knowing why, in a manner that addresses the content of the
presentation.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Nov 2005 21:42:06 +0000
From: "Alan DeKok" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Subject: Re: http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt 
Cc: [email-masked]
Date: Tue, 08 Nov 2005 16:44:59 -0500
Message-Id: <[email-masked]>

"Glen Zorn (gwz)" <[email-masked]> wrote:
> > People try to send
> > 100's of long string attributes via RADIUS, and it doesn't work. 
> 
> I think that the standard answer would be that that is perfectly
> acceptable RADIUS behavior, and to use Diameter;

  In existing deployments, where clients don't support Diameter?

  Are there *any* diameter clients built into equipment from major
networking vendors?  I don't recall any off-hand.

>  what we were talking about was a bug that makes transitioning
> gracefully from RADIUS to Diameter extremely painful, if not
> impossible.

  I agree.  My point was that RADIUS already has this issue,
independent of Diameter.  If we solve the issue for RADIUS, then we
should also get better Diameter interoperability for free.

  Alan DeKok.

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

Delivery-date: Tue, 08 Nov 2005 21:29:57 +0000
Content-class: urn:content-classes:message
Subject: RE: http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt
Date: Tue, 8 Nov 2005 13:29:33 -0800
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Alan DeKok <> supposedly scribbled:

>   The discussion in the meeting was about size issues with Diameter &
> RADIUS.  But RADIUS already has size issues.  People try to send
> 100's of long string attributes via RADIUS, and it doesn't work. =20

I think that the standard answer would be that that is perfectly =
acceptable RADIUS behavior, and to use Diameter; what we were talking =
about was a bug that makes transitioning gracefully from RADIUS to =
Diameter extremely painful, if not impossible.

>=20
>   Maybe a general method to extend RADIUS would help for Diameter,
> and large packets?=20
>=20
>   How does the issues raised about flags interact with the
> capabilities problem statement?  They appear to overlap.=20
>=20
>   Alan DeKok.

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

Delivery-date: Tue, 08 Nov 2005 21:08:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities presentation
Date: Tue, 8 Nov 2005 16:08:08 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...

> regarding the future work on the capability document. you guys need to
> decide what presentation style, requirement goals and problem
statement
> you might want. during the meeting i think we agreed that the current
> radius-geopriv work is largely independent of the future, more
generic,
> capability work.

I'm sensitive to your desire to make rapid progress.  If GEOPRIV is a
special case, then maybe it should be treated as such.  If it is simply
part of a general case, then I worry about setting a precedent for
handling capabilities in RADIUS (with implied general scope) that may
affect later work, without explicitly looking at that bigger picture.

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

Delivery-date: Tue, 08 Nov 2005 20:52:48 +0000
Content-class: urn:content-classes:message
Subject: AW: Capabilities presentation
Date: Tue, 8 Nov 2005 21:52:17 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

hi alan,=20

i guess you misunderstood my comments.

i just wanted to highlight that the confusion on the mailing list was
(in my opinion) not related to the presentation style but rather about a
more fundamental issue regarding the introduction of capabilities for
radius.

for the discussions about radius-geopriv i was more interested in
getting the document done rather than proposing a general capability
mechanism for radius.=20

regarding the future work on the capability document. you guys need to
decide what presentation style, requirement goals and problem statement
you might want. during the meeting i think we agreed that the current
radius-geopriv work is largely independent of the future, more generic,
capability work.=20

ciao
hannes

>   Responses to comments:
>=20
>  - any drafts written from this presentation will include text rather
>    than math symbols, as not everyone is familiar with set theory.  I
>    just used the math here as short-hands for the presentation
>=20
>  - the goal of the presentation is to minimize the communications
>    problems as seen on the list: what's mandatory, supported, who does
>    what?  That was the main miscommunication I saw on the list.
>=20
>  - The first slide ("Goals") addresses *why* this presentation was
>    written.  I'm not sure what Hannes's comments were, about this
>    presentation not addressing the underlying concerns.
>=20
>  - the whole point of the presentation is the first two slides.
>    Everything else is gravy.  If we can't agree on the goals, then
>    there isn't much point in continuing.
>=20
>   - As Glen said, there is a wider need for capability exchange and
>     advertisement.  This presentation tries to address that need.
>=20
>   - I didn't see *any* other statement of requiremets and goals for
>     capabilities.  The geopriv presentation was about solving a
>     specific problem, not about the wider issue.  Is Hannes saying
>     that the goals and requirements don't address geopriv, or any
>     wider issue?
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Nov 2005 19:46:38 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: Capabilities presentation
Message-Id: <[email-masked]>
Date: Tue,  8 Nov 2005 14:50:10 -0500 (EST)

  Responses to comments:

 - any drafts written from this presentation will include text rather
   than math symbols, as not everyone is familiar with set theory.  I
   just used the math here as short-hands for the presentation

 - the goal of the presentation is to minimize the communications
   problems as seen on the list: what's mandatory, supported, who does
   what?  That was the main miscommunication I saw on the list.

 - The first slide ("Goals") addresses *why* this presentation was
   written.  I'm not sure what Hannes's comments were, about this
   presentation not addressing the underlying concerns.

 - the whole point of the presentation is the first two slides.
   Everything else is gravy.  If we can't agree on the goals, then
   there isn't much point in continuing.

  - As Glen said, there is a wider need for capability exchange and
    advertisement.  This presentation tries to address that need.

  - I didn't see *any* other statement of requiremets and goals for
    capabilities.  The geopriv presentation was about solving a
    specific problem, not about the wider issue.  Is Hannes saying
    that the goals and requirements don't address geopriv, or any
    wider issue?

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Tue, 08 Nov 2005 18:51:55 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Cc: 
Subject: http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt
Message-Id: <[email-masked]>
Date: Tue,  8 Nov 2005 13:54:48 -0500 (EST)

  The discussion in the meeting was about size issues with Diameter &
RADIUS.  But RADIUS already has size issues.  People try to send 100's
of long string attributes via RADIUS, and it doesn't work.

  Maybe a general method to extend RADIUS would help for Diameter, and
large packets?

  How does the issues raised about flags interact with the
capabilities problem statement?  They appear to overlap.

  Alan DeKok.

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

Delivery-date: Tue, 08 Nov 2005 18:19:07 +0000
Date: Tue, 08 Nov 2005 13:18:08 -0500
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: draft-aboba-radex-fixes - State attribute

Bernard,
	wrt State attribute;  there was a case in the past where a vendor decided 
that their client would sent a State attribute with Null data to start a 
certain proprietary sequence.  Non-Vendor's clients would fail on this 
server due to this expectation.

You should make it clear that a new Access-Request should not contain a 
State attribute.  State should always come from a server, and prior 
context.  Not manufactured by the client.

Dave.

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

Delivery-date: Mon, 07 Nov 2005 16:41:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Slides for IETF 64
Date: Mon, 7 Nov 2005 08:42:29 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C5E377.3003B590
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Are available here:

http://www.drizzle.com/~aboba/IETF64/radext/

If you haven't already sent slides to the chairs, please do so ASAP. 

------=_NextPart_000_0006_01C5E377.3003B590
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Are available here:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"http://www.drizzle.com/~aboba/IETF64/radext/">http://www.drizzle.=
com/~aboba/IETF64/radext/</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If you haven&#8217;t already sent slides to the =
chairs,
please do so ASAP. <o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0006_01C5E377.3003B590--

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

Delivery-date: Sat, 05 Nov 2005 23:01:32 +0000
Content-class: urn:content-classes:message
Subject: WG: Radius Location issues
Date: Sat, 5 Nov 2005 23:58:59 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>

joel got the impression that his mail bounced. here is a forward. =20

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =
Im Auftrag von Joel M. Halpern
Gesendet: Samstag, 5. November 2005 13:45
An: [email-masked]
Betreff: Radius Location issues

The open issues 27, 28, and 29 I raised have been resolved to my =
satisfaction.

Yours,
Joel M. Halpern

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

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

Delivery-date: Sat, 05 Nov 2005 21:45:26 +0000
Date: Sat, 05 Nov 2005 16:45:18 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Radius Location issues

The open issues 27, 28, and 29 I raised have been resolved to my satisfaction.

Yours,
Joel M. Halpern

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

Delivery-date: Sat, 05 Nov 2005 21:36:40 +0000
Content-class: urn:content-classes:message
Subject: issue 74 - radius-geopriv
Date: Sat, 5 Nov 2005 22:35:26 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

hi all,=20

with issue #74 bernard raised a question with regard to the usage of rfc
3576. avi proposed text is:=20

"
We need to change the paragraph from:

The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request.

to:
The COA message may instruct the
   access network to generate an Authorize-Only Access-Request (Access-
   Request with Service-Type set to "Authorize-Only") in which case the
   NAS MUST include the location infromation in this Access-Request if
it
included the location information is previous Access-Requests.
"

i would like to ask whether this issue can be closed now?

ciao
hannes

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

Delivery-date: Sat, 05 Nov 2005 06:36:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue:  Clarification of Framed-IPv6-Prefix in RFC 3162
Date: Fri, 04 Nov 2005 22:36:33 -0800

Issue:  Clarification of Framed-IPv6-Prefix in RFC 3162
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: November 4, 2005
Reference:
Document: Issues & Fixes -01
Comment type: T
Priority: S
Section: New
Rationale/Explanation of issue:

Section 2.3 of RFC 3162 states:

      This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user.  It MAY be used in Access-Accept
      packets, and can appear multiple times.  It MAY be used in an
      Access-Request packet as a hint by the NAS to the server that it
      would prefer these prefix(es), but the server is not required to
      honor the hint.  Since it is assumed that the NAS will plumb a
      route corresponding to the prefix, it is not necessary for the
      server to also send a Framed-IPv6-Route attribute for the same
      prefix.

This raises several issues:

a.  What is the expected behavior of the NAS on receiving 
Framed-IPv6-Prefix?   Is the NAS expected to use the prefix only on the link 
between itself and the CPE?

b. Does the receipt of a Framed-IPv6-Prefix imply that the NAS is supposed 
to announce the prefix using RS?  Or does this require allocation of a new 
value of Framed-Routing?

c. Since the prefix length can be between 0 and 128, can Framed-IPv6-Prefix 
be used to send a /128?  What does the NAS do in that case?  What if the NAS 
also receives a Framed-Interface-Id attribute?

Here are my (strawman) answers:

a. The NAS plumbs a route for the prefix.  It also advertises the prefix via 
RS/RA.  The NAS does not do anything else unless it is explicitly told to do 
so (e.g. in Framed-Routing).

b. Yes.  A new value of Framed-Routing is not required to cause the prefix 
to be announced via RS.  Framed-Routing is intended to be used only with 
routing protocols (primarily RIPv2), rather than with RS/RA or Prefix 
Delegation.

c. Framed-IPv6-Prefix can be used to send a /128.  If received, the NAS will 
plumb a route for the prefix.  However, it will not announce the /128 via 
RS, only the /64.  If the NAS also receives a Framed-Interface-ID attribute 
it will use it if the protocol involved requires an Interface-ID (e.g. PPP). 
  Otherwise, it will ignore the attribute.

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

Delivery-date: Fri, 04 Nov 2005 21:55:19 +0000
Content-class: urn:content-classes:message
Subject: Hokey mailing list:  Bar-meeting on Handover keying design
Date: Fri, 4 Nov 2005 16:54:36 -0500
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: <[email-masked]>
Cc: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>

=20
Hi,

This is a solicitation for folks interested in a Bar-meeting (Bar
pre-BoF or whatever the meeting ends up being) discussing handover
keying (I call it HOKEY, and have created a semi-formal proposal in case
we end up needing a BOF name for Dallas, who knows it does not hurt to
have these things handy :) ). I have a link to an old draft from April
down at the bottom of this email, but unfortunately, I did not have time
to write a new version of the draft. The old draft may be enough to
initiate some discussion. Please let me know if you are interested in
participating. We will decide on the "happy hour" time and location :)

Info for mailing list at the bottom.

Regards,

Madjid Nakhjiri

Handover Keying (HOKEY)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The recent "AAA Key Management" guidelines as well as several IEEE and
WiMAX specification documents attest to the increasing popularity of
approach of striving to benefit from the interaction with the
authentication (AAA) servers during the network entry to provision
further keying materials for support of other networking applications or
handovers to other networks.=20

Recent attempts in applying these methods to access technologies with
mobility support (such as WiMAX) has shown that the existing
specifications may needs to be further examined or extended from the
point of view of handover keying or networking application keying
support.

It seems to be more efficient to instead initiate a well-thought and
documented design with a first-hand focus on mobility and handover
keying and authorization mechanisms. The initial goal of this activity
can be to examine the combination of the EAP and AAA documentations to
utilize the EAP keying framework and the AAA infrastructure for handover
keying and provide an appropriate key hierarchy that can handle the
requirements stated in "AAA key management" and further venturing into
other network applications that may need keying support.

A background problem statement can be found at

http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt

A mailing list for discussing handover keying is set up.=20
Feel free to subscribe, I am expecting activity after the meeting.
However, the meeting is only tentatively scheduled for Tuesday evening
9-10 PM somewhere in a IETF meeting area to be announce it on the list
or on the wall somewhere.=20

The list address is [email-masked], you can send emails but you
cannot see emails if you are not subscribed. To subscribe:

Send a message to "[email-masked]" with the subject
"maillist-subscribe" or "maillist-unsubscribe" depending on what you
wish to do. In the body of the message should be the following.=20

listname=3DHOKEY
subscribers=3Dyouremailaddress

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

Delivery-date: Wed, 02 Nov 2005 16:39:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IANA policies (RFC 3575)
Date: Wed, 02 Nov 2005 08:39:29 -0800

There was a question on IANA allocation of values for existing RADIUS 
attributes.

Here is what RFC 3575 Section 2.1 says:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Designated Expert is defined as follows:

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that any allocation will be
   accompanied by a published RFC.

So the process is to request allocation of a value from IANA, and get a 
Designated Expert assigned by the AD to review the request.  The results of 
the expert review are then discussed on the mailing list.

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

Delivery-date: Wed, 02 Nov 2005 15:59:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER:  RADEXT WG last call on RFC 3576 MIBs
Date: Wed, 02 Nov 2005 07:59:44 -0800

This is a reminder of an RADEXT WG last call in progress on the RFC 3576 
MIBs.  These documents are being considered for publication as Informational 
RFCs. The documents are available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt

RADEXT WG last call will last until Monday, November 14, 2005. Please send 
comments to the RADEXT WG mailing list ([email-masked]) in the 
format described in the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/

If you have read the documents, please respond to this WG Last Call, if only 
to say "I have read the documents and I am OK with them."

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

Delivery-date: Wed, 02 Nov 2005 15:57:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER: RADEXT WG last call on RFC 2618bis-2621bis
Date: Wed, 02 Nov 2005 07:57:12 -0800

This is a reminder that RADEXT WG last call on RFC 2618bis-2621bis is in 
progress.  These documents are being considered as Proposed Standards 
(2618bis, 26819bis) and Informational (2620bis, 2621bis). The documents are 
available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt 
(Proposed Standard) 
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt 
(Proposed Standard) 
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt 
(Informational) 
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt 
(Informational)

RADEXT WG last call will last until Monday, November 14, 2005. Please send 
comments to the RADEXT WG mailing list ([email-masked]) in the 
format described in the RADEXT Issues list:
http://www.drizzle.com/~aboba/RADEXT/

Note:  so far no WG last call comments have been received.  If you have read 
the documents, please respond to the WG last call, even if only to say "I am 
OK with them".

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