Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call

From: [email-masked] (Patrice Calhoun)
Date: Tue, 7 Dec 1999 08:15:51 -0800

>
>Carl,
>
>	My sense as a RADIUS operator/user is that its best to offer
>whatever clues we can in the RFCs and try to reduce the need for
>"implementor imagination".  My recent experience is that implementor clue
>density is dropping just as fast as operator clue density.
>
>	In the old Internet, the clue density was high enough that
>reasonable things would happen.  In the new Internet, the sum(clue) has
>remained a constant while the number of participants keeps growing rapidly.
>
>	I find Pat's argument "Since people have done it using their
>own imaginations, let's leave it out and let the future implementors
>use their own imaginations as well" truly frightening as an operator.

hmmm.. and the current text isn't? My reasoning for asking that the
text (specifically those two paragraphs, not all of the proxy section)
be removed, is that it REALLY only adds confusion.

Certainly you can't say that the text in the draft provides enough
of a base that developers wouldn't have to use their imagination!

Now, if we, as a WG, decide that we want to define exactly how this can
be achieved, then we could, but again, this would take a REALLY LONG TIME (TM).

>
>	Proxy Servers are deployed and are useful in certain circumstances.
>I would advocate keeping the proxy server documented in the RFC.  I
>don't care whether that is packaged as at present or whether it gets moved
>into a clearly non-normative appendix.

See above comment. I am not requesting that all proxy server text be
removed. Only the text that doesn't add anything useful, with the exception
of confusion.

PatC

>
>Ran
>[email-masked]
>
>
>-
>To unsubscribe, email [email-masked]' with
>'unsubscribe ietf-radius' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Ran Atkinson <[email-masked]>
Date: Tue, 07 Dec 1999 11:41:55 -0500

% hmmm.. and the current text isn't? 

	Correct.  The current text isn't.

% My reasoning for asking that the
% text (specifically those two paragraphs, not all of the proxy section)
% be removed, is that it REALLY only adds confusion.

	Disagree.  It reduces confusion.

% Certainly you can't say that the text in the draft provides enough
% of a base that developers wouldn't have to use their imagination!

	It significantly increases the probability of something
sensible being implemented, IMHO.
 
% Now, if we, as a WG, decide that we want to define exactly how this can
% be achieved, then we could, but again, this would take a REALLY LONG TIME 

	I understand that you have a different perspective than I do about
retaining the current text.  I don't think anyone has proposed reconstituting
the working group.

Best wishes,

Ran
[email-masked]

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Tue, 7 Dec 1999 12:00:04 -0500 (EST)

> of a base that developers wouldn't have to use their imagination!

How would the following text work as a compromise:

A forwarding server SHOULD perform its forwarding function in a
pass through manner, where it sends retransmissions on as soon 
as it gets them.

This, of course, means that we are recommending the pass-through
retransmission strategy, and it is implicit that there are other
permissible strategies which certainly require a good reason before you
select them, and probably require careful design to work well.

The only problem I can see with my propsed text is that as clue density
drops implementors seem to grep the RFC for MUST and only read those lines
;-(.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net: Local Ties... World Class Connections

Better is open rebuke than hidden love.

-

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 7 Dec 1999 09:45:57 -0800 (PST)

Carl,

	I think having  the  two paragraphs about  retransmissions  is
GOOD.   It leaves scope  for implementation and  does not restrict the
usage.   There  are  several implementaitons   that do  it today.   An
Example of one such RADIUS server is Cisco's Access Registrar.

Personally, I   think     this   scope    is   important  in     Proxy
environments.  Please leave scope  for  people to use imagination  and
innovation, for that is Internet is where it is today.

Thanks.
Gopal 
Cisco Systems

-