Subject: Re: (radius) More detail on Proxy

From: David Bolen <[email-masked]>
Date: Mon, 1 Mar 99 13:50:12 EST

"Dale E. Reed Jr." <[email-masked]> writes:

> I'd like to see some added clarity on order here.

I think that order should be enforced (as is true of all like
attributes in a packet) but that order when compared to other
attributes need not be maintained.  In other words, treat them as
other attributes are treated.  If we want extra text here, we can just
reinforce the general behavior description.

> Server implementation:
> 1. as in the proposed text
> 2. the server stores the received Proxy-States but does not forward them to the
> next hop server. The server retrieves the Proxy-States when replying to the
> client.
> I don't think either are incorrect. 

For (1) are you saying that Carl's initial text was incorrect?  While
not how I've implemented things, it seemed to me his approach was ok.
For (2), it seems to me to satisfy the RFC requirements just fine.
It's just an implementation suggestion, not a requirement.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen              \  Internet: [email-masked]    /
  |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
 / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
\-----------------------------------------------------------------------/
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Mon, 01 Mar 1999 11:00:39 -0800

> reinforce the general behavior description.

Some implementations require Proxy-State to be before the reply 
attributes, which is causing problems with us because we attach
Proxy-State at the end.
 
> not how I've implemented things, it seemed to me his approach was ok.

No.

> It's just an implementation suggestion, not a requirement.

It actually could be a way to kee the packets small, especially over
many-hop requests.

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Mar 1999 14:22:06 -0500

> attributes, which is causing problems with us because we attach

  Some implementations are hard-coded to look for attributes in a
certain order, at certain places.  e.g. first user-name, then
password, then others.

  Such implementations are wrong.

  The RFC does NOT specify where the attributes are placed in a
packet.  If I wanted a hard-coded non-extensible machine-dependent
data structure, I'd ask for one.  No thanks.

  Alan DeKok.
-