Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update)

From: <[email-masked]>
Date: Mon, 9 Sep 2002 15:15:43 +0300

Hi Pete,

Doing final edits on the next version of the base.

> Should we say instead, "or a vendor specific experimental Application
> Identifier."?  Or should we delete the last clause, as all Application
> Identifiers are now assigned by IANA, regardless of whether
> vendor-specific or not?

I think they should be assigned by IANA on a first come, first serve
basis.
 
> Also from Section 1.2.4:
> 
>    This is why "disk writing" accounting servers should advertise
>    themselves as "Relays" that can handle any Application ID, 
> including
>    Vendor-Specific.
> 
> There is an issue with this text that was raised by Glen Zorn but
> never resolved: I think we mean to say "can handle any *Accounting*
> Application ID.".  A disk-writing accounting server can handle only
> ACR and ACA, not just any command.  Remember, the standards-track
> application IDs that can appear in CER are split into normal App-IDs
> and Accounting App-IDs.  I think a "disk writing" accounting server
> should advertise support for the Relay applicationin an Accounting
> App-ID *only*.  Also, I don't think such a server can handle any
> Vendor-Specific application, because such an application can never
> include standards-track commands such as ACR/ACA under the current
> rules, as I understand them.

I agree with adding the word Accounting, I'm not sure what else you anted
to add.

>   3.3  Diameter Command Naming Conventions
> 
>      Diameter commands typically includes one or more English words
> 
> Should be, "Diameter command names typically include"

Got it.

>   3  Diameter Header
>   ...
>       Command-Code values in the range 0xfffff0 through 0xffffff are
>                                        ^^^^^ this is only 16 
> 	commands.  It's conceivable that even a 
> 	single application may need more.  Should we 
> 	use 0xffff00 through 0xffffff 
> 	instead?  If so, also need to correct the 
> 	range in Section 11.2.1.

I'm just following the guidelines of the AD.  If we increased it, it
will just get knocked back down during IESG review.

> Should we clarify here that experimental use = vendor specific?  I.e.,
> "Command-Code values in the range 0xfffff0 through 0xffffff are
> reserved for use by vendor specific, experimental commands."

Not sure that would help anything ...
 
> Also, remove extra space between "ID" and "AVP" in the last line.

ACK.

>   11.3  Application Identifiers
> 
>      As defined in section 2.4, the Application Identifier is used to
>      identify a specific Diameter Application. There are 
> standards-track
>      application ids and vendor specific application ids.
> 
>      IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
>      standards-track applications; and 0xff00000000 - 0xfffffffe for
>      vendor specific applications.
>   
>      Both Application-Id and Acct-Application-Id AVPs use the same
>      Application Identifier space.
> 
>      Vendor-Specific Application Identifiers, encoded in the Vendor-
>      Specific-Application-Id Grouped AVP, with the Vendor-Id 
> AVP set to
>      the vendor's enterprise number, is for Private Use.
> 
> I don't think this is strictly true anymore.  The Vendor-Specific
> Application Identifiers are now from the experimental range
> 0xff00000000 - 0xfffffffe and are in fact managed by IANA.  Or perhaps
> I've misinterpreted the intention here?
> 
> If the experimental command code space is to be managed by IANA, this
> IANA Considerations section is inadequate.  It needs to give the
> assignment policy (Expert Review, First-come-first-served, etc.).
> 
> We could leave the space for Private Use (I actually favor this
> alternative), but I think that brought up the routing concerns raised
> by Bernard - then we would need to parse the AVPs to find out how to
> route the command.  Also such a policy conflicts with the language in
> section 3 under "Command Codes", which I quoted above.

I'll take care of this in a follow on mail.

John

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2002 05:46:40 -0700 (PDT)

> I agree with adding the word Accounting, I'm not sure what else you anted

The point is that a "disk writing" accounting server cannot handle new
commands unless it understands them. This means that it can only handle
Accounting App-IDs that don't involve a new command -- but there is no way
for it to determine whether this is true or not.

---

From: Pete McCann <[email-masked]>
Date: Mon, 9 Sep 2002 10:22:23 -0500

> for it to determine whether this is true or not.

Yes, and this is true for both standards-track and vendor-specific
applications.  Additionally, there is no way to tell whether a
vendor-specific application is "Authorization" or "Accounting" because
there is only one type of Vendor-Specific Application ID AVP in the
CER/CEA (not that it would have helped anyway due to the above).

Upon further reflection, I think we should just strike the offending
paragraph in section 1.2.4:

>   themselves as "Relays" that can handle any Application ID, including
>   Vendor-Specific.

Basically, it is impossible to create a disk-writing accounting server
without knowing that no additional commands are defined by the given
application, or by providing the additional command functionality in
another network entity.  It was a nice thought, but it just doesn't
work.

-Pete

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2002 07:52:45 -0700 (PDT)

> CER/CEA (not that it would have helped anyway due to the above).

It seems that the only way this could be made to work is to add bits in
the application-id field to differentiate between authorization/accounting
applications, and also between new commands/no new command applications.
I'm not clear that this is necessary, though (see below for simpler
solution).

> another network entity.  It was a nice thought, but it just doesn't

Originally, a new application-ID required a new command, and therefore
there was no reason to expect that a "disk writing" accounting server
could handle anything other than the standard Accounting application-ID.
In some ways this original formulation is very clean -- the accounting
server just advertises the standard accounting application, and there is
no reason to get another application-ID unless you're defining a new
command. In this case, deleting the paragraph has no ill effects, and I'd
agree with you.

However, now my understanding is that we are allowing allocation of new
application IDs without a new command. This has the troublesome effect of
breaking interoperability as a result of trivial changes (e.g. adding a
vendor-specific AVP).

Although we have put language in the draft discouraging allocation of new
application IDs without good reason, in practice, this has had no effect
-- virtually every accounting usage in Diameter is now requesting an
application ID, whether it is necessary or not.

So it seems to me that we have a choice of either putting some teeth into
the allocation policy (e.g. going with "expert review" before allocation
of an application ID) or putting bits into the application-ID to allow the
accounting server to distinguish the new AVP case from the new command
case.

If we don't do either of these things, the likely outcome is that Diameter
will end up being less extensible than RADIUS.

---

From: Pete McCann <[email-masked]>
Date: Mon, 9 Sep 2002 16:58:41 -0500

> command. In this case, deleting the paragraph has no ill effects, and I'd

Accounting is also "lumped in" with the various authorization
applications now, so there are no Application IDs that apply only to
accounting or only to authorization.  Also, the vendor-specific
application IDs only come in one flavor.

 > will end up being less extensible than RADIUS.

I would like to keep FCFS allocation policy if at all possible.

I think the best way to add the bits of which you speak would be to
differentiate more strongly between the Accounting and Authorization
Application-ID AVPs.  In other words, Accounting applications must be
"pure" in the sense that they only use ACR/ACA.  It may be the case
that the same Application ID appears inside both Authorization and
Accounting Application-ID AVPs during CER/CEA, but this really means
that a server supports two different aspects of a protocol: 1) the
authorization state machine and any associated machinery, and 2) the
ACR/ACA commands and all of the mandatory AVPs associated with the
application.  This way, we could define the "Relay" Application ID,
when it appears inside an Accounting Application-ID AVP, to mean that
the server supports ACR/ACA for any application.  Also, we should
create 2 AVPs to hold vendor-specific application IDs: one for
authorization, the other for accounting.  The accounting applications,
even when vendor-specific, are not allowed to use any commands other
than ACR/ACA.  A "disk-writing" accounting server could then
interoperate with any accounting application, even if it were
negotiating with a proxy that didn't know the semantics of the
application, because accounting applications are guaranteed to be
"pure" (only use ACR/ACA) throughout the system.

Would that work?

-Pete

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Sep 2002 14:11:42 -0700 (PDT)

> "pure" in the sense that they only use ACR/ACA.

In most cases, that should be sufficient, but I don't know that I would
require it in every case. It is conceivable that someone could come up
with an accounting application that required a new command, no?

> It may be the case
> the server supports ACR/ACA for any application.

That would work most of the time. But if someone did come up with an
accounting application that needed a new command, how would they indicate
that it *didn't* use ACR/ACA?

> Also, we should

99% of the time, I think it would. But I'm curious as to how we would
handle the other 1%.

---

From: Pete McCann <[email-masked]>
Date: Tue, 10 Sep 2002 09:20:23 -0500

Bernard Aboba writes:
 > It is conceivable that someone could come up

Maybe we should say that's not an accounting application.  Or rather,
if it still used ACR/ACA, that part would be accounting, but the new
command would be an authorization application.

 > 99% of the time, I think it would. But I'm curious as to how we would

We currently don't have any formal definition of what an accounting
application is, so let's just define the problem away by saying that
*only* ACR/ACA can be a part of an accounting application, and
anything else is part of the corresponding authorization application.
If an application doesn't use ACR/ACA, then it's not an accounting
application.  If it uses ACR/ACA + some other commands, then only the
ACR/ACA part is the accounting, but the other commands are
authorization.  You could always advertise support for each one
separately in CER/CEA, or advertise as an accounting relay to say you
support all applications' ACR/ACA commands but nothing else.

-Pete