Subject: [AAA-WG]: Table vs. command definitions

From: Patrice Calhoun <[email-masked]>
Date: Thu, 1 Feb 2001 16:32:00 -0800 (PST)

All,

I have thought about having a table some more, and actually tried to create
the table in the specs. Unfortunately, it isn't *quite* that simple. Let us
assume for the moment that I am working on the base spec. I can defined the
AVPs in the table, and state which command (defined in *that* spec) they may,
or may not, be present.

However, what do I do when I get to the Mobile IP extension?

Here is an analogy. The RADIUS spec contains the table, and whether each
attribute may be present in the access-* or not. The accounting one has it's
own attributes, but the table also includes the attributes defined in the
authentication/authorization spec. This is necessary because an incomplete
table is worthless.

Back to the Mobile IP extension. A table in that extension will require that I
pull in AVPs from:
	1. base protocol
	2. Strong Crypto
	3. Accounting
	4. Resource Managemnt

This will make a REALLY big table. Less than this is useless, and the SAME
problem exists for the NASREQ extension. The alternative is to add ALL of the
NASREQ and Mobile IP AVps into the Accounting, Strong Crypto and Resource
Management extensions. 

Either way, it's ugly and evil

So far Glen was in favor of tables, and I haven't heard anyone else in favor
of tables. I would REALLY like to NOT include tables in the documents, and
leave them as-is.

Comments, PLEASE! (even those NOT in favor of tables!)

Thanks,

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 3 Feb 2001 16:41:19 -0800

Pat Calhoun [mailto:[email-masked]] writes:

> All,
>
> I have thought about having a table some more,

Me, too.

> and actually tried
> to create

Well, yes, an incomplete table _is_ worthless, but I don't think that's why
it's necessary to "pull in" attributes from the other spec.  The real driver
is RADIUS' pathetically small namespace.  Why not create a new attribute
(Acct-Username) instead of reusing the Username attribute from the AA spec?
Not enough space.  Presumably, we won't have this problem w/Diameter...

> NASREQ and Mobile IP AVps into the Accounting, Strong Crypto and Resource

Not the _only_ alternative (see above).

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 5 Feb 2001 05:17:20 -0800 (PST)

> Not enough space.  Presumably, we won't have this problem w/Diameter...

ok, looks like we have two choices:

	1. Don't do the table
	2. Do the table, and completely revamp all the drafts to no longer
	   re-use AVPs from other extensions. That means that Acct-Num-Of-Packets
	   (short form) would be defined in all extensions that need accounting
	   and the same with user-name, ad nauseum.

Comments?

PatC

---

From: Erik Guttman <[email-masked]>
Date: Mon, 5 Feb 2001 18:03:49 +0100 (MET)

> > it's necessary to "pull in" attributes from the other spec.  The real >
driver > is RADIUS' pathetically small namespace.  Why not create a new >
attribute > (Acct-Username) instead of reusing the Username attribute from >
the AA spec? > Not enough space.  Presumably, we won't have this problem >
w/Diameter... > 
> 	   and the same with user-name, ad nauseum.

I think there are further problems with whacking the namespace.  
What's the difference between Acct-Username and Username?  Yuck.

But I don't understand why it is a problem to have a table in, say,
the Accounting draft, which cites attributes defined in the base
draft, or even other drafts - as long as the citations are clear.
All the docs will progress together (to standards track).

The thing is, making these tables will be a heck of a lot of work.
I would be willing to take a stab at it, but we'll need several
reviewers to go over it line by line.  Volunteers?  (Glen, I'm
assuming you'll be first in line! :-)

Erik

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 5 Feb 2001 08:59:45 -0800 (PST)

> > > Well, yes, an incomplete table _is_ worthless, but I don't think that's
> why > > it's necessary to "pull in" attributes from the other spec.  The
> real > driver > is RADIUS' pathetically small namespace.  Why not create a
> new > attribute > (Acct-Username) instead of reusing the Username attribute
> from > the AA spec? > Not enough space.  Presumably, we won't have this
> problem > w/Diameter... > 

Agreed.

> assuming you'll be first in line! :-)

I can tell you right now that the base protocol *will* be the worst, since the
User-Name is included in every extension!

PatC

---

From: Erik Guttman <[email-masked]>
Date: Mon, 5 Feb 2001 19:04:22 +0100 (MET)

Pat,

> I can tell you right now that the base protocol *will* be the worst, since
> the User-Name is included in every extension!

Why not just cover whichever AVPs are used by the command
codes standardized in the document in question?

In RADIUS (RFC 2865) the table is set up like this:

   5.44.  Table of Attributes

      The following table provides a guide to which attributes may be found
      in which kinds of packets, and in what quantity.

      Request   Accept   Reject   Challenge   #    Attribute
      0-1       0-1      0        0            1   User-Name

       ...

In DIAMETER, we could set it up like this:

      Session-      Session-      Session-           
      Termination-  Termination-  Termination-  AVP  Attribute
      Ind           Request       Answer         #   Name

       1             1             1             1   User-Name

       ...
       
In DIAMETER NASREQ, we it could be:

      AA-     AA-    AA-        DIAMETER- DIAMETER- DIAMETER- AVP  Attribute
      Request Answer Challenge- EAP-      EAP-      EAP-       #   Name
                     Ind        Request   Answer    Ind

      0-1     0-1    1+         0-1       0-1       1          1   User-Name
      
      ...

This isn't so bad.  It will really pay off to do this exercise though,
since it will force us to pin down exactly how many of each of the
required and recommended AVPs to put into each command.  I can see
in just doing User-Name there's some ambiguity between the grammar
and the text.

Erik

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Feb 2001 13:38:46 -0800

> 	   and the same with user-name, ad nauseum.

It may seem nauseating to you (maybe it's just the amount of typing involved
in the documents?) but it seems clean and straightforward (if somewhat
inelegant) to me.  The benefit is that the documents (and extension
sub-protocols) are self-contained, so that you don't have to chase through
multiple docs to find AVP and message definitions.  For that matter, I can
see no good reason to maintain the artificial separation between accounting
and the other 2 As, just because RADIUS did it that way.  Why is there such
a thing as an accounting "extension"?  If this is a AAA protocol, the
defining one of the As as an extension seems silly -- accounting is
integral, not extensional.  So I would propose that each of the extension
docs (and the base, for that matter) define its own accounting AVPs (and
messages, if necessary).  If done right, this approach could eliminate many
of the irritating idiosyncrasies in RADIUS (such as sticking a phone number
in the User-Name attribute just because the RFC says that the User-Name
Attribute MUST be present.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 5 Feb 2001 14:04:46 -0800 (PST)

> inelegant) to me.  

Trust me... after the number of revisions and re-writes of these documents,
the tables are irrelevant (as far as amount of typing). However, I don't want
to do something that is useless, hence my (largely unanswered) questions. Erik
and I worked REAL hard some time back to slim down the documents, and I am
(and have been) somewhat reluctant to bloat them again.

> The benefit is that the documents (and extension
> multiple docs to find AVP and message definitions.  

I assumed you really didn't mean what you typed. Each document would, at best,
describe the all the AVPs and how they are used with the messages defined in
the particular extension. Or were you actually proposing that the same table
(all AVPs + all commands) be defined in all extensions?

> For that matter, I can
> a thing as an accounting "extension"?  

I will assume this wasn't really a question, given that you are co-author of
the said document.

> If this is a AAA protocol, the

So, if I understand correctly, you would propose that the base protocol ONLY
include AVPs that are used within the base protocol. The accounting extension
would be propagated to the Mobile IP and NASREQ extension, with duplicate
messages and AVPs. NASREQ and Mobile IP would not use any of the AVPs in the
base protocol.

I am OK with doing such a change, if the WG really thinks this is the way to
go. I know that as a developers, I REALLY hate to have to duplicate
unnecessary code, and this would in fact cause some duplication. But it
actually might make the specs more modular.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Feb 2001 14:35:21 -0800

> (and have been) somewhat reluctant to bloat them again.

Just because something is large doesn't mean that it's bloated, any more
than smallness makes it elegant.

> the particular extension.

I thought that that was what I said.

> Or were you actually proposing that the
> same table

None of the above.  I think that Diameter started out to be
"base+extension", not "base+extension1+extension2+part of extension3" &
that's what I'm saying it should be.
> I will assume this wasn't really a question, given that you are

No, it really was a question, and I'm questioning the existence of such a
document.  I admit that I rather blindly went along with the idea of an
accounting extension for some timel however, onfurther reflection I've come
to see it as basically just a holdover from RADIUS,

> include AVPs that are used within the base protocol.

Yes and no.  Are there accounting requirements for the base protocol?  If
so, define those accounting AVPs and messages as part of the base protocol;
if not, then don't.

> The
> accounting extension

If the Mobile IP and NASREQ extensions are actually that, then presumably it
is because they have unique requirements which are not satisfied by a
one-size-fits-all base protocol.  I imagine that this uniqueness extends to
accounting, as well.  Some of the messages and AVPs may be syntactic
duplicates, but semantically different; some may be missing altogether and
yet others may be special purpose inventions.

> unnecessary code, and this would in fact cause some duplication.

If the messages are _actually_ duplicates, then the duplication of code
should be practically non-existent; if, however, the messages/AVPs are
_almost_ but not quite the same, I would argue that the deserve their own
code anyway.

> But it

Code, too.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 5 Feb 2001 14:41:20 -0800 (PST)

Glen,

Given this discussion, I am much more in favor of pulling the accounting
extensino into the base protocol, as opposed to duplicating it in the Mobile
IP and NASREQ extension.

Would this work for you?

PatC

---

From: Erik Guttman <[email-masked]>
Date: Tue, 6 Feb 2001 18:41:03 +0100 (MET)

Glen, Pat,

>> Glen wrote:
>>> For that matter, I can see no good reason to maintain the artificial 
>>> separation between accounting and the other 2 As, just because RADIUS 
>>> did it that way.  Why is there such a thing as an accounting "extension"?

> Pat replied:
>> I will assume this wasn't really a question, given that you are
>> co-author of the said document.

> to see it as basically just a holdover from RADIUS,

Its Feb 6.  Feb 18 is the -00 cut-off date for internet drafts.
Lots and lots of review has gone into the current Diameter docs.
What you are suggesting is a major rewrite.  Apart from the work
involved, there is a big risk of messing up the documents.  Time
is short and I don't think there is much to be gained by folding
the docs together.  

Does anyone on the AAA WG list support Glen's proposal of a major
re-editing of the Diameter spec (merging in Accounting)?

> Pat wrote:
>> The accounting extension would be propagated to the Mobile IP and NASREQ
>> extension, with duplicate messages and AVPs. NASREQ and Mobile IP would 
>> not use any of the AVPs in the base protocol.

> yet others may be special purpose inventions.

I like the idea of adding tables.  I suggested that we have tables in
each draft which introduces command codes - for those command codes.
We simply give a reference to the draft in which the AVPs are defined
if they aren't defined in the same document.  There is no problem using
AVPs from the base protocol in the tables in other drafts.  I don't
agree there's a problem that needs to be solved.  Am I missing something?

This is a big job and there's not much time left.  Let's stop arguing
about this and get to work.  Otherwise we won't have tables in the -00
draft.

Erik