[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Discussion of Issue 146 (fwd)
The text of RADEXT Issue 146 is quoted below.
It is not clear to me what action should be taken on the three sub-
issues of Issue 146. This leads to the "can be discussed now" part.
From a procedural perspective, if we are to redefine the equations used
to derive counter objects, we have changed the definition of the
objects. The correct way to change the definition of existing objects
is to deprecate the olds ones and add new ones. Perhaps this formality
can be waived with objects that are "advisory" in nature, such as
statistics. Advice would be appreciated.
From a practical perspective, it would be helpful to know what has been
implemented. I'd like to request that anyone on the list who has
implemented RFC 2618-21 report as to how these objects were implemented.
If the implementation matches the disputed text, then perhaps the better
thing to do is to add clarification as to the existing behavior.
That does not, of course, preclude deprecating the objects and adding
new ones with more desirable behavior.
Guidance is solicited.
-- Dave
<quote>
Issue-1:
Stefaan asked:
Some questions we have regarding the existing RFCs (since you are
updating these) we found while writing our draft:
1) Is the definition of TotalIncomingPackets in RFC2618 on page 6
correct? I believe there is something wrong with it.
Glen replied:
I think that you are right. With the curent definition, it appears that
"Successfully Received" could be negative, since we're subtracting
counters from TotalIncomingPackets that were not include in the sum.
Also, I guess that "AccessRequests + PendingRequests + ClientTimeouts =
Successfully Received" just below should read "AccessRequests +
PendingRequests + ClientTimeouts = Successfully Transmitted".
Nagi commented:
My understanding is that RFC-2618 considers that an Access Response
(Accept or Reject or Challenge) counter MUST be incremented before it is
validated. i.e., either one of Malformed responses or bad authenticators
or packets dropped counters will be incremented if the packet is
invalid.
Do you interpret the same from the RFC-2618. If yes, I would like to
know what are the reasons for this. Isn't that an Access Response
counter MUST be incremented only after the packet is found *valid*.
If you are convinced that the approach in RFC-2618 is OK, then I would
say that the first two equations hold good. i.e., Your statement above
(saying Successfully_Received could be negative) is incorrect. Am I
right? or missing something?
Issue-2:
Stefaan asked:
3) radiusAuthClientPendingRequests: upon retransmission this counter
is decremented. So a retransmitted packet is not considered as being
pending, although such restransmissions can still be considered as
being pending requests.
Glen replied:
Yup, it probably shouldn't be decremented on retransmissions, especially
since it's already decremented on timeouts.
Nagi commented:
My understanding is that Pending requests should be decremented on
receiving an Access response and on an expiry of timeout. It looks
obvious to me that Pending requests should be incremented on a
retransmission (to the same server).
Please see the text
"This variable is incremented when an Access-Request is sent and
decremented due to receipt of an Acess-Accept, Access-Reject or
Access-Challenge, a timeout or retransmission."
I suspect that the text is misleading. The text should be:
"This variable is incremented when an Access-Request and retransmission
is sent and decremented due to receipt of an Acess-Accept, Access-Reject
or Access-Challenge, a timeout "
Do you guys agree?
Issue-3:
See the equation:
AccessRequests + PendingRequests + ClientTimeouts = Successfully
Received
I agree with you that left hand side value should be equal to
"Successfully Transmitted". Also "AccessRequests +
AccessRetransmissions = Successfully Transmitted" equation holds good. =
Right?
Requested changes:
Nagi and Stefaan raised the issue and suggested some text to resolve
the issue in the above thread. Please note that a conclusion
was not reached and can be discussed now.
</quote>
--
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/>