Subject: The Identifier field

From: Pat Calhoun <[email-masked]>
Date: Wed, 10 Jan 2001 16:43:43 -0800 (PST)

[ed: I hate this cross-posting, but it seems necessary :(]

Tony brought up a question some time ago as to the usefulness of the
Identifier field. I believe that no justification was provided at the time for
the existence of the field. In the process of editing the base protocol, it
came to me the reason why such a field may be required.

Assume for a moment that we are a NAS, and that two authorization messages are
sent for the same user (let's assume for the moment that these are for
different services). When either of the responses are received, how would the
NAS know to match request and the response. The obvious answer is to require
that the NAS walk through the whole message, looking for clues (e.g. service
type). This is rather cumbersome.

The Identifier field DOES provide such a hint. However, we need to make sure
that the Identifier field IS NOT modified in transit towards the home server
(as it is done in RADIUS), because there really is no need to do so, and it
does complicate the protocol. 

So I propose keeping the Identifier field, but adding text that it is ONLY of
use to the initiator of a request to match up the response.

Does this make sense?

PatC

---

From: Tony Johansson <[email-masked]>
Date: Wed, 10 Jan 2001 16:47:02 -0800

Good point and I think this make sense to keep the Identifier field as state
below.

BR,

/Tony

---

From: Barney Wolff <[email-masked]>
Date: Thu, 11 Jan 2001 09:19:03 -0500

Pat, in RADIUS the id comes back to the originator of a request,
and whether it's modified between proxies is not visible to the
requester.  Why would you want to impose further requirements
above that?  To be sure, a stateless proxy would have to keep
the id unchanged, because it won't notice when the response
comes back, but a stateful proxy will, and can therefore obey
the requirement while still generating a useful id of its own.

You can argue that Proxy-State provides the same opportunity
for fast lookup, but the AVP is not in a fixed position, while
the id is part of the header.

The justification of the field is that it allows the receiver of
a response to do an efficient lookup of its request state.  That
motive stays the same for DIAMETER, and helps proxies as well as
NAS's - but only if the proxy can set the id.  I see no benefit
to disallowing that.  There's already an unmodifiable AVP for
session-id, and we don't need two.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Jan 2001 06:22:37 -0800 (PST)

> session-id, and we don't need two.

ok, I can buy that. However, I am not sure that I want to describe how proxies
make use of the Identifier field, or should I? I believe that I will simply
add text stating that the id is used to match request and replies, and leave
it at that. *However* please keep in mind that the ID only is not really that
useful. Let's consider a NAS that issues an accounting message with the ID set
to 4. As it turns out, it ALSO receives an unsolicited message from a home
server with the ID set to 4. Since it is not the originator of the message,
then it should attempt to ignore the ID field. 

So my text was that the ID, the Session-Id and the command-code are used on
the NAS to match request and replies.

PatC