[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last call on extensions document?
Peter Deacon wrote:
> In most cases where an attribute of type IP Address needs to be defined
> there will be a need for an IPv6 analogue of that same attribute.
> There are implementation costs and operational costs associated with the
> approach of segregating address families. Costs can be reduced somewhat
> with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.
> 1. Multiple attributes need to be defined.
With 1000+ new attributes and TLVs, I'm not sure this is an issue.
> 2. Operators entering an IP Address into fields need to make sure they
> select the correct attribute based on the address family they are
That's a UI problem. The system in which they enter the IP should
know (a) the address family, and (b) the relevant attribute. There's no
reason to force the admin to make those choices.
> Operators may enter a hostname and have the system enter the resolved
> address. In this case the operator may have no knowledge of the address
> family or it may change tomorrow!
Which is a disaster for maintainable systems. Having the RADIUS
response change because of modifications to DNS is terrible. I strongly
oppose that kind of setup.
> The system will need to provide additional intelligence during the name
> lookup process to select the proper attribute based on address family
> for each instance.
It can send multiple attributes. Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.
Why select? If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
send that in RADIUS?
> We can live without however much like gigawords I believe with the new
> attribute space comes some opportunity to improve the standard framework
> for future attributes.
While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
above use-cases *require* it. The same result can be achieved with
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.