[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DISCUSS and COMMENT: draft-ietf-radext-design
The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.
In *addition* to 8-bit spaces. Not to replace it.
Well... there was a previous SHOULD recommendation. Now there is a new
one (use the old the new).
There are a couple of problems with this. First, if you really mean
to change the recommendation, then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.
We could add that, but I don't think it's critical.
Not very, but I think if we change an earlier requirement it would be
helpful to add the Updates pointer so that people who review older RFCs
are more likely to remember to check the new one, too.
Secondly, while I agree with the advice of going for 16 bits, the
document is silent on some of the issues involved in such a change,
- Does RADIUS dictionary software support the VSA format for 16 bits, 8
bits, or both?
All major products already support many non-RFC VSA formats, including
This is very good! Can you say something along these lines in the
document, too, because it goes a long way towards resolving any issues
the change has.
- How do you cleanly print or report VSAs when you do not know if the
field size is 8 or 16 bits? I realize that this situation already
exists since the format was never required to be followed, but
your new recommendation makes a potential problem much more likely
to appear. Previously, you could print something like Vendor = ACME,
Code = 17, Contents = ABCDEF0011... Now you couldn't do that.
The *current* implementations have the same problem. If they receive
a VSA from an unknown vendor, and it's not in the RFC format, they have
*no* idea what format to use.
Are you saying that no implementation is capable of by default printing
out text like I had in my example above?
- Can a vendor who moved from 8 bits to 16 bits deal with this?
Vendors cannot create VSAs of both 8 and 16 bits with the same
Vendor-Id. Some have tried, and have quickly fixed their product when
If vendors want to "switch" to using 16-bit types, they need to use a
Ok. I didn't think that was the case but clearly you have the
operational experience on this.
I think it would be essential to spell this out in the draft -- its
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.