[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap



Mauricio Sanchez writes...
 
<quote>

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

</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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>