|
> Date: Thu, 25 Feb 2010 15:55:43 +0100 > From: mail@stefan-winter.de > To: leslie@thinkingcat.com > CC: mikem@open.com.au; Bernard_Aboba@hotmail.com; d.b.nelson@comcast.net > Subject: Re: draft-ietf-radext-dynamic-discovery-01.txt > > Hi, > > sorry for being so late to get back to you. > > > You may find that S-NAPTR (RFC3958) does the trick for you. > > Indeed it does! After looking through 3958, it looks like an almost > perfect match. It's not quite a 100%, but if I may, I'd like to solicit > your opinion on what could be done to make it so. In very short terms: > > The service my draft describes is "roaming" based on NAI user names > (which are derived from DNS domain names). It can, among others, be used > with the protocol RADIUS over TLS. On first glance, it would thus seem > prudent to register a service "roaming" and an application type > "radius.tls" for the S-NAPTR DDDS application, like > > host -t NAPTR restena.lu > > restena.lu has NAPTR record 100 10 "a" "roaming:radius.tls" "" radius-1.restena.lu. > > > That is unfortunately barely short of what's needed. Roaming consortia > are usually selective about who they peer with. It may be possible that > one realm participates in "n" roaming consortia, and thus has multiple > NAPTR records for those. Iterating through all NAPTR resolutions and > trying which TLS connection will actually be accepted is one way of > course, but not very efficient and might cause end-user delays. A unique > per-consortium label would be beneficial here. > > The short and cheap solution is to use a label "x-consortium" to avoid > writing an RFC for the consortium and circumvent IANA registration. In > our specific case, we could do x-eduroam. > > But I was wondering about a more elegant solution to this, that doesn't > force operators to flee to dimension x-. If the service label were to > contain a sub-space with arbitrary but unique consortium handles, this > would be rather elegant. I'm envisaging sth like > > restena.lu has NAPTR record 100 10 "a" "roaming#eduroam:radius.tls" "" radius-1.restena.lu. > > restena.lu has NAPTR record 100 10 "a" "roaming#3gpp:radius.tls" "" radius-1.restena.lu. > restena.lu has NAPTR record 100 10 "a" "roaming#wimax:radius.tls" "" radius-1.restena.lu. > > > This would of course require charging IANA with handling a "sub-registry" below "roaming", and I'm not sure if that's what's wanted. To take the load off IANA, it can also be imagined to ensure uniqueness of the sub-space by piggybacking it on an established namespace registry, like DNS names of the consortia. Like > > restena.lu has NAPTR record 100 10 "a" "roaming#eduroam.org:radius.tls" "" radius-1.restena.lu. > > restena.lu has NAPTR record 100 10 "a" "roaming#3gppnetworks.org:radius.tls" "" radius-1.restena.lu. > restena.lu has NAPTR record 100 10 "a" "roaming#wimaxforum.com:radius.tls" "" radius-1.restena.lu. > > Do you think such a "wildcard" subspace allocation would fly? > > Thanks for any advice, > > Stefan Winter > > |