[radext] Fwd: Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off

[Nick Lowe <[e-mail]>]

On Tue, Oct 6, 2015 at 5:57 PM, Bernard Aboba <[e-mail]> wrote:
> Comments below.
>>
>> RFC 2865
>> ========
>
> [BA]  Not sure why you are referring to RFC 2865 here.  This is a Draft
> Standard RFC that covers authentication/authorization.   There is no
> material in this document relating to accounting.

Correct. I meant to say this was in the context of RFC 2866. I typed
that autonomously and managed to miss that while proof reading. Sorry,
it was a flat out mistake.

>> Acct-Status-Type
>>
>> Description
>>
>> This attribute indicates whether this Accounting-Request marks
>> the beginning of the user service (Start) or the end (Stop).
>>
>> It MAY be used by the client to mark the start of accounting for
>> the NAS (for example, upon booting) by specifying Accounting-On
>> and to mark the end of accounting for the NAS (for example, just
>> before a scheduled reboot) by specifying Accounting-Off.
>>
>> Where Accounting-On or Accounting-Off is specified, a
>> Called-Station-Id attribute SHOULD NOT be present. In the case
>> that one is present, the value MUST be global to the NAS.
>
> [BA] What does "global to the NAS" mean?  Are you referring to a globally
> unique MAC Address?

This is taken from Alan's wording:

http://freeradius.org/rfc/acct_status_type_subsystem.html

"with a value for Called-Station-Id that is global to the NAS"

I wanted to mandate that the value must be something that applies to
the whole NAS. It is not and cannot be a value that scopes to a
subsystem and must therefore constant to all Accounting-On and
Accounting-Off forms of Accounting-Request packets that a NAS sends.

Perhaps it would be better to state the reverse, that any value must
not scope to subsystem on the NAS. How would you word this? Omit this
entirely? Any suggestions?

I would prefer to prohibit a Called-Station-Id being present outright
for Accounting-On and Accounting-Off. I cannot see that it serves a
legitimate purpose but realise there may be too much of a
compatibility implication pushing for this.

The intent is for NASes that are currently sending Accounting-On and
Accounting-Off that are scoped to a subsystem to stop doing so.

>> For IEEE 802.11, this attribute SHOULD be used to store the
>> BSSID (upper case only),
>
>> The Called-Station-Id SHOULD be UTF-8 encoded.
>
> [BA]  This seems to contradict the text before that which seems to imply
> that the BSSID is encoded in ASCII.   Allowing UTF-8 encoding of the BSSID
> could introduce interoperability issues so that is not a good idea.

UTF-8 being a general superset of ASCII, my thoughts were that it
would be easier to treat the whole thing as being UTF-8 encoded rather
than thinking about it being ASCII encoded up and until the first : is
encountered after which point UTF-8 is used.

That was my reasoning behind writing it like that anyway.

I felt it was unneeded complexity that could easily becomes too
nuanced without giving a tangible benefit.

I'll reword this if you think there could be significant
interoperability issues.

>
>> For IEEE 802.11 in particular, the Called-Station-Id SHOULD be
>> UTF-8 encoded as the SSID may be UTF-8 encoded.
>
> [BA] It would appear to me that only the SSID may be UTF-8 encoded.  So why
> don't we just say that?

As above, I'll reword this if you feel there could be significant
interoperability issues.