Hi Joe, The idea of defining one payload format for carrying information in EAP methods sounds useful. Then, someone only has to define something once and it is available (at least from a specification point of view) in all EAP methods.
In practice, this obviously requires code changes and there is the question of what you would like to carry in there. Do we have some good examples on what we would like to carry? My experience from various research projects is that everyone is very excited to define a new container but nobody tries to figure out what should be carried in it. Using the Diameter format is OK for me. I wonder, however, whether the idea is to have automatically all the RADIUS and Diameter attributes / AVPs available for exchange in EAP methods? Furthermore, if someone believes that something is useful for exchange in an EAP method does this mean that this new extension gets automatically registered for the RADIUS and Diameter AVP/attribute space? Ciao Hannes >Hannes said: >> >> I understand the issue of defining channel bindings. >> draft-ietf-emu-chbind-00 does this but it does not define payloads. >> Do we really need to split this aspect into separate drafts? >> >[Joe] Not necessarily. > >> The aspect of having the possibility to carry an opaque blob in EAP >> (based on a Diameter AVP) format is a totally different subject. >> >[Joe] Are you suggesting that the AAA payloads document is the >right focus? If not then what would you suggest? > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
