[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft of extensions format
On Thu, 2 Sep 2010, Alan DeKok wrote:
I think this boils down to my advocating for a flat model where each
item stands alone while the draft is advocating a hierarchical model
where each items identity is strictly dependent on its parent.
Pretty much, yes. That's a result of adding the TLV format, which is
breaks the flat model wide open.
There are many ways of representing the same structured data. Purely
hierarchical approach advocated in the draft suffers from the multiple
inheritance problem.
When I say TBD.1 it means User-Name (Type 1) encoded in whatever TBD is.
(TLV, Extension..etc)
Under the drafts scheme the attributes defined would be:
Input
Output
Input.Octets
Input.Packets
Output.Octets
Output.Packets
Yes. It's not optimal, but it's been proven to work in 3GPP2 and WiMAX.
Under my recommendation the attribute picture is flattened:
Input (TLV Attribute)
Output (TLV Attribute)
Octets (Attribute)
Packets (Attribute)
How do you encode the TLV's? As 16 bit quantities? They must be,
because otherwise all 256 attributes would be already allocated.
Yes, my proposal is the type field be a 16-bit or 14-bit field to save a
byte on fragment and extra flag bits.
And this suggestion is largely the Diameter Group attribute. If we go
down that path, it would be preferable to use a method compatible with
Diameter, rather than one which is slightly different.
My thinking is the definition is more important than the wire format.
The wire format is out of sight out, out of mind. The universally
standardized definition of attributes is what I am most concerned with.
If it looks like diameter so be it..
1. More flexibility. Existing attributes that were never labeled as
groupable can be grouped. For example I could create a generic TLV
container labeled 'suspect' containing all attributes that an
intermediate proxy does not like.
What is the use-case?
And we've had that discussion already on this list. The consensus was
that there are just too many uncertainties and confusions with that
approach. What does it mean when a User-Name is grouped inside of a new
TLV? How do existing proxies deal with that data? Do you put the
User-Name outside of the TLV, and also inside?
These issues *must* be answered before your proposal can move forward.
This was just a hypothetical to provide an example usage of which I have an
infinite supply so if you need more just ask and I'll rattle off more use
cases until everyone is satisfied.
In this case its my attribute I define what the group means.. My TLV
attribute is labeled Proxy-Suspects and it means everything in the group is
an attribute an intermediate proxy server in the chain did not "like".
Its proxied by servers who do not support/understand it the same as any
other unknown or specifically unsupported attribute would be per this
draft and other RFCs.
Since the TLV is an attribute type in itself the system must understand
what the type means before it can do anything with the data contained
within it. The User-Name attribute inside the TLV is characterized by its
container and semantics associated with the definition of the type.
Example...
TLV - Proxy-Suspects
- TLV Proxy-Suspect-Attribute
- User-Name = Rumpelstiltskin
Proxy-Suspect-Reason = Too-Big
- TLV Proxy-Suspect-Attribute
Framed-IP-Address = 127.0.0.1
Proxy-Suspect-Reason = Policy-Reject
2. "Like" attributes within TLVs can be reused. In the example above
Octets and Packets need only be defined once and then apply to Input,
Output and maybe a future "Combined" TLV container. To some extent this
is just a schema/definition argument.
That is an admirable goal, and one which the document does not meet.
Existing information (3GPP2, WiMAX, vendors, etc.) shows that the re-use
isn't much of a problem, as it has been done.
Again, what is the use-case for this?
I think fundamentally there is a difference in the efforts you cite have a
finite scope to a specific problem domain. The WG is defining a broadly
scoped attribute that applies to many disparate problem domains and so
what is workable in these cases may not be ideal in the general case.
3. The standard VSA space can be extended with less complexity/wholesale
change to existing infrastructure as every attribute definition stands
alone and is therefore fully compatible with the current model.
What is the use-case? How is it "less complex"? How is encapsulating
User-Name in a TLV "fully compatible" with current RADIUS?
The issue is the attributes are defined based on their parents and don't
standalone and so don't fit with the current flat model of defining
attributes with integer values as self-contained entities. Subgroups
require implementation infrastructure change to support.
Again assume TLV grouping is *NOT* used in this case. The drafts scheme
has a dual use to extend the standard space AND support TLVs. The problem
is it should in my opinion be possible for a client to use use extended
attributes without having to support TLVs and the sub attribute encoding
scheme that go with them.
My recommendation is easier because each attribute retains a unique
integer identity as is current practice for all standard attributes and
most VSAs and thus easier for client vendors to implement extended
attributes within their existing systems if they do not also have a need
to support TLVs.
1. What is allowed in a group may or may not simply be defined by
declaration in a dictionary. Need a concept to declare constraints
(LDAP "object classes"). I would argue you would need this anyway if
there was interest in for example declaring minimum required sub
attributes for a specific TLV.
2. There is a strange aspect in that the additional space has to be
"bootstrapped". Either hardwired or configuration to say standard space
2^8 goes to a TBD extension attribute along the same lines as
Vendor-Specific (26) in the implementation.
Please propose something *concrete*, with use-cases.
In terms of definition of attributes RADIUS is traditionally very loosely
structured. Attributes you don't understand can be tolerated even tho
there is no way to communicate the information attribute x was ignored.
Subsequently new features such as Disconnect/CoA enforced a more strict
interpretation in which unknown attributes mandate a NAK response by the
NAS.
Loose vs strict structure is a subjective space and I can cite an example
that would lean in either direction.
My suggestion WRT definition is to always define the minimal requirements
in terms of sub-attributes for the use of any TLV and the possible
sub-attributes whenever a TLV is defined in an RFC.
In terms of adherence only Recommend they are followed and give clients or
servers the option of rejecting TLVs if the constraints are not met.
Ideally these semantics would be defined with the TLV attribute and can be
stronger or weaker based on the semantics of the specific TLV.
Anyway after looking over the draft again I have some (un)related comments:
I think fragmentation support for 'jumbo' attribute values is a good
thing however with the draft there does not seem to be a way to do both
TLV grouping and attributes with large payloads at the same time. IIRC
wimax VSAs support this. Could perhaps just get rid of TLV format and
reuse the extended type as TLV?
The discussions Avi and & had were that we couldn't see a use-case for
TLVs needing more than 253 octets of data. The WiMAX VSAs do *not*
support TLVs having large payloads.
I double checked and I don't believe this is correct.. See:
http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/html/WiMAX_Overview6.html
I have found other material that explicitly say the continuation flag may
be used specifically with WiMax TLVs allowing up to 4k or so TLVs.
In any event this statement seems a little confusing to me. On one hand
you introduce a container that supports fragments but on the other hand
say that there is no use case in TLVs supporting fragments.
In terms of a use case my Proxy-Suspects TLV would work here as well as it
needs to potentially be larger than 2^8 for cases where the proxy server
does not like multiple attributes.
In RADIUS everything is a "TLV" .. If it were labeled Container TLV or
something similar to disambiguate the data types actual intended use it
would be less confusing (to me).
RFC 2865 defines Attributes. The acronym TLV does not appear in any
standards-track RADIUYS document.
TLV is universally understood to mean Type-Length-Value which all RADIUS
attributes are. This is the source of my confusion.
To the extent relationship between TLVs and attributes need to be
defined your correct. At the same time however it's not required when
TLVs are not used. In my view an important difference.
It's semantics. Calling a new attribute 1234 or 241.1 makes little
difference.
So can we call them 1234 or maybe both? :)
regards,
Peter
--
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/>