Transport Layer Security (TLS) Encryption for RADIUS
RFC 6614

Shouldn't there be some considerations of key management in line with RFC 4107?

Section 2.3 says the following with respect to use of TLS with PKIX certificates:

       *  Peer validation always includes a check on whether the locally
          configured expected DNS name or IP address of the server that
          is contacted matches its presented certificate.  DNS names and
          IP addresses can be contained in the Common Name (CN) or
          subjectAltName entries.  For verification, only one of these
          entries is to be considered.  The following precedence
          applies: for DNS name validation, subjectAltName:DNS has
          precedence over CN; for IP address validation, subjectAltName:
          iPAddr has precedence over CN.

It's good to specify the preference order, but you don't provide a precise definition of what it means to match the expected DNS name (IP address is more straightforward). You might find it helpful to cite RFC 6125 here.

Section 4 states:

   Ongoing work in the IETF defines multiple alternative transports to
   the classic UDP transport model as defined in [RFC2865], namely
   RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS
   [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS.

Is there a document that summarizes the experiment with these three technologies and that defines criteria for evaluating the success of each approach?

  The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two editorial
  issues.  Please consider them.

  (1) Section 2.3:
       x.y.z
      Did you mean to fill in a real section number here?

  (2) Note Section 3.4 (1) )
      Missing open paren?

I agree with Stephen's discuss and Peter's comment positions.  Based on the email exchanges it looks like their issues will be resolved in -12.

- I don't get why this is going for experimental rather than PS.
I'd prefer the latter really. 

- You should define dynauth as a term or add a reference.

- Seems odd to prefer a 3DES ciphersuite over an AES one. An
explaination for that would be good. (Maybe its just existing
code?)

- Section 3, 1st bullet should I think talk about a list of trust
points and say that that includes the CA public key and not just
its name.

- Please fix x.y.z, I doubt there's that section in 5246.

- (Blatent self-promotion:-) Might it be useful to think about
using draft-farrell-decade-ni as a(nother) way to represent
certificate fingerprints?

- Why only allow configuration of URIs for subjectAltName? I
don't get why you don't include dNSName for example.

- What does it mean to say the client is unique identified
by the cert fingerprint? What happens when I get my certificate
renewed?

- I'm not sure why a reader in ten years will care that "Radiator
is compliant to version 2 of RadSec..." (compliant to *this*
protocol would be fine of course if those are the same but then
why not say that?)

- "(link to RFC once issued here)" is not really very finished
text is is?

- The mandatory TLS ciphersuites listed do not provide PFS.

This document needs a scrub to make sure that all TLAs other than those with a * in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt are expanded on first use and where the definition is contained in another document the term is provided with a reference on first use. 

radsec seems to have a lot of different spellings.