#1, p4 - Figure 1 - should that be "CAP authorized"? #2, p4 - I can see why you might not want to make figure 1 longer, but it seems to stop short - shouldn't it end with the Peer and CAP doing stuff together? Maybe add another figure that shows the latter exchange? #3, p5 - if you could tie the various actions described back to figure 1, that'd help the reader I think. (I'm not insisting on that, just asking:-) #4, p5 - Would this entire description benefit from more 2119 language? (As above:-) #5, p5 - "If either the peer or the SAP does not support ERP/AAK, it should fall back to full EAP authentication." Is that right? I guess I wondered if the first fallback might be ERP without AAK and then "full" EAP but maybe I'm confused. #6, p5, 2nd para - s/The SAP may/The SAP MAY/ or s/may/can/? And in that same para s/it is silently/it MUST be silently/ (if that's a new MUST I guess?) #7, p5 - "The rIK is used to protect this message." Is that right? How is rIK used to protect the message when the message contain rIK? I also wondered what "protect" means exactly - are the flags etc. all protected and how? #8, p5 - If I'm an authenticated user and I send the message at step 2 to the SAP, then can I get the SAP to forward the message to anything on the Internet? If not, where does it say how that's controlled? I guess the SAP knows based on its config and/or the authentication state of the peer but if so you should probably say that? #9, p5 - Does the SAP need to verify the integrity of the message at step 2? You don't say. If it doesn't then bad things might be enabled... #10, p5/6 - the key hierarchy text is dense (like me:-) It'd have helped me to know which keys are new and which KDFs are used. How come rIK isn't mentioned? What does "can be used to derive" mean? That's probably all just my ignorance of ERP though but there's not enough here to understand what's going on. I suspect best will be to fix whatever else needs fixing and then return to this at the end. #11, p7 - I assume that the 'E' flag is set (value 1) to indicate early-authentication and unser (valule 0) to indicate that early-authentication is not in use. That may be a general EAP or ERP convention or it may be worth saying, I dunno. (There are a few occurrences of this.) #12, p7 - In 5.2 you say reserved bits MUST be set to zero and ignored on reception, but in 5.1 you don't say "ignored on receiption." Is there a real difference or is that just an editorial glitch? #13, p7 - Are there any I18N considerations applying to the CAP-Identifier or keyName-NAI TLVs? I seem to recall hearing recent discussion about that somewhere else but can't recall if that'd apply here or not. (And so I don't know if something ought be said about I18N here.) #14, p7 - In 5.2 is the behaviour for handling the SEQ field well defined? If that's done elsewhere, a reference to that would seem needed or else someone might do something different here. #15, p8 - You can only have one keyName-NAI in the message and that MAY have either the home domain name or the domain name to which the peer is currently attached for ite realm part. How does anyone know which to include when? Seems underspecified or missing a reference? #16, p8 - How are CAP-Identifier and "Sequence number" TLVs "associated"? #17, p8 - Is the sequence number TLV called "Sequence"? If not, then are you allowed spaces in TLV names? #18, p8 - Exactly how is the sequence number used in the calculation of the pMSK for each CAP? Can these be re-used? (Across reboots?) Do they need to be random? That all needs stating I think. #19, p8 - cryptosuite - do you really need all three? Why not just make one mandatory to implement? #20, p8 - authentication tag - where is the input to the HMAC function specified? (Its not here anyway.) I think someone needs to say how this is calculated. That means both the plaintext (message) input (e.g. are any header bits in/excluded?) and the key input (which key?). It could be that this just needs a reference if its done the same as some other RFC. An example would be great to give. #21, p8 - authentication tag, I think you need to say what to do if this doesn't verify - just ditch the packet? #22, p8 - You need references for the HMAC functions. #23, p8 - Should/are the choices for cryptosuites in some IANA registry? If not, why not? If so, where? #24, p9/10 - a bunch of the message field comments from 5.2 apply also to 5.3 #25, p9 - Maybe I'm misreading the diameter notation - is it clear how many sub-TLVs are allowed to be in the ERP/AAK-Key TLV? Are they just presented and read in the order given? Do all four sub-TLVs need to be present each time? #26, p10 - From when is the lifetime of the pMSK calculated? (Same for the pRK-lifetime field.) Are these signed or unsigned 32-bit values? #27, p10 - Use one of "foo-lifetime" or "foo Lifetime" consistently. #28, p10 - I'm guessing that the lifetimes of some keys are related (maybe pIK and pMSK?) but you need to say so if that's the case. #29, p10 - What's an example of when the foo-lifetime sub-TLVs don't need to be present (i.e. why is this SHOULD and not MUST) #30, p10 - Can there be zero elements in the list of cryptosuites? Is there a MAX number of elements? #31, p10 - The list of cryptosuites desription says "The server SHOULD include this if the...was not acceptable and is being rejected." That's pretty ambiguous. What's the exception to the SHOULD? Does "is being rejected" mean that this MUST NOT be present when things worked ok? #32, p10 - 5.4 talks about the "rRK Lifetime" but earlier you had a "pRK Lifetime" (or "pRK-lifetime") - what's up with the change there? #33, p11 - Section 7 says a new message "should" be defined - who's gonna do that where? Seems odd that its not here. #34, p11 - section 8, 1st bullet says "*The* algorithm..." I think you mean the algorithm for calculating the authentication tag, but you need to say that. #35, p11 - How are KDFs named/replaced? #36, p11 - Is it ok for "different sequence numbers" to mean "just increment" or not? Is it ok for sequence numbers to be re-used say after the peer reboots? I think you need to say. #37, p11 - Its not clear to me how the replay detection scheme works.