* In section 5.1 (para 3) - The following sentence does not make sense to me. Message i2 is the information the AAA server receives from the last hop in the AAA proxy chain which is not necessarily the authenticator.
Specifically I do not follow the last clause and what it is referring to. Are you stating that the element in the AAA proxy chain may not be the authenticator? If so, I would omit the clause as it seems obvious to me since you are talking about a chain. * How does authenticated vs non-authenticated information get denoted in a AAA message? Given that some information can be authenticated at an early point in the chain and some must be deferred until the last node this would need to be denoted as authenticated vs non-authenticated information. And who validated it? <WARNING: may be stupid question by somebody who does not know Radius/Diameter> * s/thatwere/that were/ * section 5.2 s/have gone lost/have got lost/ * It is not clear to me if the EAP server is to reflect the values from the EAP client in the response message or if it should reflect values from the NAS/AAA path. * Is it reasonable/possible that a policy would pull some attribute from the AAA path that is not supplied by the EAP client and therefore need to reflect it to the EAP client as part of the response? Or is the set of values to be reflected back to the EAP client restricted by the set of values that it supplies? * Section 7.2 - I am afraid I don't understand what this new RADIUS attribute is supposed to be carrying. I am doubly confused since the introductory text in sections 7 and 7.1 talk about the values of i1, but my understanding is that i1 is sent from the NAS to the peer, using some unknown protocol and then from the peer to the EAP server using an EAP method and thus the reason for the RADIUS attribute is confusing. I would understand it better if we are talking about sending i2 data for things which are not already RADIUS attributes, but that does not seem to be how the text is designed. This might just be talking about the EAP method to be used, but this is also confusing since that is not something I would expect the NAS to be involved in. I might have gotten a better grasp on this, and I think that part of my problem is that I think that this could be a mis-named attribute. I now understand that this is dealing with what is the method that is being used to talk between the EAP peer and the NAS. I think it is partly misleading because this is only part of what is carrying the EAP data layer (along with a AAA layer currently) and thus is not completely true. It might be better to call it the Peer-NAS transport layer or something similar. * Section 8 - You are talking about this information as being validated by the AAA server as oppose to being validated for consistency against the i1 data by the EAP server. Is this what you are really intended? _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
