Alan, > Richard Pruss wrote: > > So in summary it is not simply a question of software, the EAP proposal > > impacts less elements and reuses existing software. > > Let's assume that PANA is the best solution. Let's also assume that > it's easy to deploy PANA on the client machines, and all intermediate > devices.
There is no such thing as "PANA deployment on intermediate devices". There is PANA Client co-located with EAP peer (e.g., RG) and PANA Authentication Agent co-located with EAP Authenticator (e.g., BRAS). > The question that's left is: What is the remaining expense to > deploy PANA? > > A: New server software at every ISP, with fail-over, redundancy, etc. > A: Sysadmin training, knowledge, etc. And if we grow a PANA protocol out of DHCP, none of that happens? You are assuming that just because some hack-under-the-cover-of-an-extension uses the same DHCP header none of (or, a little of) the above is required. > Where do they get this software and expertise? Right now, many sites > use Open Source DNS, DHCP, and RADIUS software. There is no equivalent > PANA software. Where do they get the expertise to administer these > systems? No sysadmin is familiar with PANA. There's no readily > available pool of information on the net that helps them through common > configurations or problems. There is no PANA book from O'Reilly. There > are no PANA Q&A mailing lists. There is no group of sysadmins who > understand PANA, and can help newcomers. If that's strategy we need to follow, than let's stop defining any new protocols right now, instead start reusing existing protocol headers for anything we need, forever. Many times IETF protocols get accepted into other SDO's architecture without waiting for book publications, training courses, materials, etc. That's hardly a show-stopper for the industry. Btw, there already is open source PANA implementation. > In contrast, leveraging existing AAA systems means that they simply > upgrade their existing AAA software. Any "new" configurations (e.g. > EAP) are widely documented on the net, with readily available examples, > how-to's, complaints about bugs, fixes, mailing lists, books, user > communities, etc. PANA transports EAP and does not impact RADIUS/Diameter (if that's what you mean by "AAA systems"). > Building that knowledge base is tremendously expensive, and it > *doesn't* show up as a line item on the budget. It shows up as every > sysadmin getting 50% less work done for a month as they bootstrap their > PANA knowledge. Alan, maybe you are still remembering the day when the author of the dhcp-auth was claiming it to be as simple as defining and transporting EAP payload. Those days are long gone. Please take a look at the latst I-D. Now PANA (or PPP) is growing out of DHCP with its own messages, options, state machines, end points -- all distinct from standard DHCP. So, any sysadmin/developer/etc.'s knowledge/books/notes/scripts/etc on DHCP is useless for dhcp-auth. > I'm not assuming that the DHCP proposal is cost-free. But on the > server side, the costs are significantly lower than PANA. Please see above. Regards, Alper > Alan DeKok. > _______________________________________________ > dhcwg mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
