Subject: (radius) Closing loopholes

From: Carl Rigney <[email-masked]>
Date: Thu, 25 Feb 1999 13:05:25 -0800 (PST)

As though I haven't generated enough traffic already...

Without passing any value judgements, I'd like to hear from any
implementers who have run into problems interoperating as a result of
people misreading or missingg anything in RFC 2138 and 2139 (and
especially any cases of willful misinterpretation due to poor phrasing
on the author's part), or making assumptions not supported by actual
chapter or verse.  There's no need to mention again anything mentiond
on the list in the last week, and feel free to omit names, but I want
to nail down all the fuzzy points I can hear of so that when this goes
to Draft Standard, there can be no more finger-pointing or
blame-escaping by the unrighteous.  Note that if someone just hasn't
implemented something, I don't need to hear that.  I'm just looking for
cases where interoperability has slipped through the cracks in the
language.  Again, no names needed; I'm looking for ways to improve the
draft, not finger pointing.  And no need to tell me anything that's
been mentioned in the last week; that's all covered or will be within
a few hours.

Feel free to email me privately if you prefer, or raise it on the list,
but I'd like to hear it today if at all possible.  If you can't get to
it today, I'd appreciate hearing about it eventually anyway, but today
or tonight would be best.

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

---

From: Aydin Edguer <[email-masked]>
Date: Mon, 1 Mar 1999 18:11:31 -0500 (EST)

> I suppose our thorniest incompatibilities have shown up when trying to
> map our (non-flat) interface naming scheme into the puny 16 bits that the
> radius spec allows for NAS-Port.

It was already agreed that this will be expanded to allow the full 32-bits
of NAS-Port, there are just very few vendors who are taking advantage of
the change.

This change was decided at the Memphis IETF (IETF 38):

  Date: Thu, 3 Apr 1997 01:50:35 -0800 (PST)
  Subject: (radius) Agenda for 38th IETF Tue 4/8 15:30-17:30

     Allow NAS-Port to use 32 bits, not just 16?

  Date: Mon, 25 Aug 1997 23:47:40 -0700 (PDT)
  Subject: (radius) 38th IETF RADIUS Working Group Minutes

     NAS-Port should be updated to allow use of all 32 bits, not just 16.

-

---

From: Carl Rigney <[email-masked]>
Date: Mon, 1 Mar 1999 22:43:19 -0800 (PST)

>         2)) 32 bits would help more

The new draft permits 32 bits for NAS-Port.

The PM-4 (and I think Ascend's Max, but don't know for sure) breaks
that down as:

2 bits for shelf number (extensible into higher-bits)
4 bits for slot number
5 bits for line number (to support future densities)
5 bits for channel number

But vendors can use whatever scheme they like.

--
Carl
-