Alan,
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, such as: - 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 16 bits.
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 *everyone* complained. If vendors want to "switch" to using 16-bit types, they need to use a new vendor-id.
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 important information!
Jari -- 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/>