[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT WG Last Call on Status-Server Document
Alan DeKok writes...
> > I think clients should allow Access-Accept responses to
> > status-server messages sent to the accounting port. Even
> > if it's not the expected message, it shows that the server
> > is alive.
>
> Ok. I've updated the draft, and will issue a new version
> shortly.
Hmm. IIRC, the consensus of the room at the RADEXT WG meeting at IETF-73
was that this was a bad idea. I realize this was probably the only
substantive comment received during WGLC on this draft. However, it's only
one opinion.
<WG Chair hat on>
I think document editors need to be careful to avoid adding technical
changes to WG drafts at the request of just one commenter. If that one
comment happens to represent WG consensus, then fine. If the one comment is
simply one individual's opinion, then maybe not so fine. I also realize
that in RADEXT, these days, it's sometimes hard to distinguish. :-(
<WG Chair hat off>
> > Also, towards the end of section 4.2 the draft says:
> >
> > Some server implementations accept both Access-Request and
> > Accounting-Request packets on the same port, and do not
> > distinguish between "authentication only" ports, and "accounting
> > only" ports. Those implementations SHOULD reply to Status-Server
> > packets with an Access-Accept packet.
Yeah, but isn't that extremely broken behavior? I know we're documenting
existing behavior, but do we have to document the most broken parts? I
thought the idea was to support the needs of RADSEC with respect to server
"liveness", and in doing so, re-use an existing mechanism. Otherwise, there
are probably lots of other broken behaviors in RADIUS implementations that
could be documented. You know... "A bug, once documented, becomes a
feature". :-( Where do we draw the line?
--
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/>