Subject: [radext] AD Review of draft-ietf-radext-radsec-10

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 12 Jan 2012 14:37:25 +0100

Hi,

This is the AD review of draft-ietf-radext-radsec-10. The document is in
good shape and I am sending it to IETF Last Call. Please address the
comments below together with the other IETF Last Call comments. 

Technical comments are marked T and Editorial comments are marked E. 

T1. The Intended status of the document is Experimental. I would suggest
to add some text to clarify: 
- what is the scope of the experiment - any specific features,
behaviors, performance, scalability data that would validate the
experiment and allow for possible migration of the document to Standards
Track in the future
- any restrictions in deployment or other operational considerations
that should be known by operators or implementers? 

T2. In Section 4: 

>  As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
   bidding attacks on the peer communication.

This (non-)recommendation is not clear to me. Actually if no other
transport works for a given RADIUS entity or between a client and a
server a fallback to RADIUS/UDP will always happen because this is the
current standard and mandatory-to-implement transport. What is meant
here - I think - is to RECOMMEND that manual administrative interfaces
be made available for configuration of transport and that these
interfaces be used to select the preferred transport between clients and
servers. 

E1. Section 2.3

> after completing the TCP handshake, immediately negotiate TLS
       sessions.  The following restrictions apply: according to
       [RFC5246] or its predecessor TLS 1.1.  The following restrictions
       apply:

'The following restrictions apply' appears twice - drop one of them

E2. Add reference to RFC 6421 and link to it from Appendix C.

Thanks and Regards,

Dan