[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Discussion of Issue 146 (fwd)
Dave,
I'm not in favor of deprecating and adding the new objects either. The
comments I quoted hold good for the then implementation I worked on. I
don't know what other implementation's interpretations are.
One way could be to do the math once again and ensure that the equations
hold good for at least the intended interpretations. If there is a
problem, then there is something wrong and a clarification should be
added.
Thanks
Nagi.
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Monday, November 28, 2005 10:28 PM
> To: radiusext@ops.ietf.org
> Subject: 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/>
>
--
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/>