Subject: Re: (radius) documents wedge over track confusion

From: Carl Rigney <[email-masked]>
Date: Thu, 16 Dec 1999 14:35:41 -0800 (PST)

(Primarily to Randy Bush, but cc'ed to the mailing list for those
interested.)
 
> an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended
> to replace 2139

It is intended to replace 2139.

When RADIUS and RADIUS Accounting were submitted to the IESG long ago
(to become 2058 and 2059) the IESG at that time asked that RADIUS
Accounting be done as informational instead of proposed standard.
Since the RADIUS Accounting client uses acknowledged buffered UDP
(storing packets locally and retransmitting until acknowledged) it's
been very reliable in practice.

I'd be quite happy to have RADIUS Accounting enter the standards track,
if the IESG would prefer that, or to remain informational.  Thousands
of ISPS have been using it for years to account for millions of users,
so in practice it's been very solid.

If the IESG is more comfortable classifying RADIUS Extensions as
"Experimental" than "Informational" that's fine by me; Experimental
better captures its nature.  The intent is to describe some more
attributes that are being used, but that not everyone is likely to want
(The Appletalk Remote Access attributes are very useful to vendors that
implement ARA, and not of interest to vendors that don't, for
example).

Note that nothing in the RADIUS draft depends on the Accounting draft,
it just allocates numbers for accounting and provides a pointer to the
other draft to define their usage.  Likewise nothing in the Extensions
draft depends on the tunneling drafts, it just mentions which attribute
numbers are reserved for use by tunneling and provides a pointer to the
draft defining them, because I thought it would be convenient for
implementers to know where to go to find each attribute.  If that
tangles things up I could rip the pointers back out, but I'd prefer to
leave the pointers in - cross-references are a good thing when future
implementers try to figure out what's where.

--
Carl Rigney
[email-masked]
925-737-2111

>From owner-ietf-radius Thu Dec 16 11:50:41 1999
>From: Randy Bush <[email-masked]>
>To: [email-masked]
>Subject: (radius) documents wedge over track confusion
>Message-Id: <[email-masked]>
>Date: Thu, 16 Dec 1999 11:45:34 -0800
>Sender: [email-masked]
>
>some documents have wedged at the iesg.  essentially we became confused
>which track they were or should be on.
>
>the confusion seems to be that some of the documents seem to specify
>protocol, use words like MUST etc., but have been called as informational.
>bernard tells me that this is because they rely on rfc2139 which is
>informational, and was so classified because the specified transport was
>feared not to be sufficiently reliable.
>
>an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended
>to replace 2139, and if it solves 2139's problems sufficiently to be
>standards track and therefore clear the logjam.
>
>i will append my notes as of last eve.
>
>randy
>
>  o RADIUS Extensions [Informational]
>	<draft-ietf-radius-ext-05.txt> 
>
>relies on 2139 which is infomational.
>
>but this one might be experimental because
>
>This memo suggests several additional Attributes that can be added to
>RADIUS to perform various useful functions.  These Attributes do not
>have extensive field experience yet and should therefore be
>considered experimental.
>
>but wg chair asked for info.
>
>  o Implementation of L2TP Compulsory Tunneling via RADIUS
>    [Informational]
>	<draft-ietf-radius-tunnel-imp-05.txt>
>
>should be proposed standard, because it specifies protocol, uses MUST, etc.,
>but was requested as informational.  it says:
>
>This document discusses implementation issues arising in the
>provisioning of compulsory tunneling in dial-up networks using the L2TP
>protocol.  This provisioning can be accomplished via the integration of
>RADIUS and tunneling protocols. Implementation issues encountered with
>other tunneling protocols are left to separate documents.
>
>  o RADIUS Accounting Modifications for Tunnel Protocol
>    Support [Informational]
>	<draft-ietf-radius-tunnel-acct-05.txt>
>
>relies on 2139 which is infomational, and i was told to ask as info and it
>sez info on the draft.  but it looks like it specifies protocol.
>
>  o RADIUS Accounting [Informational]
>	<draft-ietf-radius-accounting-v2-02.txt>
>    Note: Requires draft-ietf-radius-tunnel-auth
>
>relies on 2139 so should be informational.  but it looks like a proposed
>standard, though the wg chair asked for informational.  it says:
>
>This document describes a protocol for carrying accounting information
>between a Network Access Server and a shared Accounting Server.
>
>-30-
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Barney Wolff <[email-masked]>
Date: Thu, 16 Dec 1999 19:15 EST

Well, I contract for a fairly large ISP, with annual dial revenue in
the $several-hundred-million range.  Every call journal comes out of
the NAS via RADIUS.  Every caller is authenticated via RADIUS.  Nobody
in five years has ever suggested that we use anything else.  Ok?

Barney Wolff

> Date: Thu, 16 Dec 1999 15:56:09 -0800

> it would sure be nice to have users, as opposed to vendors, telling us how
> happy the users are.
-

---

From: Carl Rigney <[email-masked]>
Date: Thu, 16 Dec 1999 16:38:17 -0800 (PST)

At 03:36 PM 12/16/99 -0800, Matt Holdrege wrote:
>I think they should all be standards track. Both Radius and Radius 
>accounting should be draft standard and the others should be proposed standard.
>Radius extensions draft.... should be Experimental.

That would all be fine by me.

---

From: Barney Wolff <[email-masked]>
Date: Mon, 20 Dec 1999 16:07 EST

I would have said it differently:  When the anticipated recouped
revenue is exceeded by the anticipated additional cost, it's time
to stop trying to avoid the loss of the last penny of revenue.

Barney Wolff  <[email-masked]>

> Date: Mon, 20 Dec 1999 12:38:34 -0800
> 
> > Phrased differently, billing is a statistical method of recouping costs.
> > Statistical errors in the data can be adequately corrected in the math.
> 
> i anticipate a bit of a problem explaining this to the lawyers and
> accountants at the isp for which i work.
-

---

From: Barney Wolff <[email-masked]>
Date: Tue, 21 Dec 1999 11:46 EST

Oh.  And here I thought the NAS would retry if it didn't get a
response.  Silly me - I thought we were discussing RADIUS.

Barney

> From: Patrice Calhoun <[email-masked]>
> Date: Tue, 21 Dec 1999 06:59:06 -0800
> 
> I really find this thread quite amusing. Nothing in the protocol even allows
> for one to identify packet loss, so how can you get ANY guarantees that
> you even KNOW what you've lost? Be it 0.00001 or 10%!
> 
> PatC
-