Re: The Emperor Has No Clothes: Is PANA actually useful?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joel M. Halpern wrote:
I have to disagree.
Firstly, if many of us reading the document can not figure out what problem it is solving, then the framework is not doing its job. Secondly, if there are existing, viable, deployed solutions to the problem that the WG is attempting to solve then the WG needs to explain somewhere (the framework document would seem the obvious place) why there is a need for a new solution.

I am not claiming that the PANA protocol can't work. As was said many years ago "with sufficient thrust, pigs will fly." But that does not make flying pigs a good thing.


Flying pigs would add RFC 2549 a totally new meaning, incrementing
put through dramatically :)

Joel M. Halpern wrote:

EAP over IP (or UDP, or link) is about authenticating the user. If a media independent technique better than just using a browser is needed, then solve that problem. Personally, I would find the work far more persuasive if it did not also try to solve the problem of creating an IPSec association to the access device, nor of the authorization selection problem.
And spell out in clear English what use case needs that problem solved.
I can read between the lines and start to guess. But the document is quite unclear. The appendix about DSL is not helpful in that regard.


Here in germany DTAG.de, the infrastructure supplier for most aDSL providers
does use PPPoE exclusively, authorization by PAP. It would be nice to
connect an aDSL modem directly to a WLAN and let everybody use his own
personal account via the AP. Alas - eavesdropping ...

If PANA could come in here?

I dont know PANA at all right now. That is why I dont know what harm it does.
Can anybody tell me what to look for?


> At 11:34 AM 5/26/2006, Dave Crocker wrote:

Although not a guaranteed way to distinguish among criticisms, it can be helpful to categorize them as either "It will not work" versus "I don't like it". The former indicates a basic technical flaw, and the latter a matter of preference.

If it is common for readers of a specification to fail to understand what it is for then it has, perhaps, the most basic kind of technical flaw. How can a specification succeed if there is confusion about its implementation or use?

By contrast observations such as "there are better solutions" moves into the fuzzier and more subjective realm of trying to predict market preferences. The IETF is not very good at making these predictions. Absent any indication of actual harm that would ensue

from publishing a specification, fear that no one will adopt it or

that there will be multiple solutions seems an inappropriate basis for denying publication. (On the other hand, strong indication of community interest in deplying a specification is supposed to be a factor in deciding whether to charter the work in the first place; however as Sam noted, we are rather late in the process.)

In any event, I would claim that concerns over who will use PANA fall into the "I don't like it" category, since it basically seeks to make statements about market preferences, which is a small step

from personal preferences.


Having looked over this thread and the -framework document a bit, I find myself unclear which of the two lines of concern is being pursued, although I impressed by the degree of confusion about PANA after what appears to be considerable effort to understand it. This does not bode well for community understanding, and that of course does not bode well for adoption and use.


There are more complicated protocols that have been implemented, like
netbios over tcp, without thought of their impact on security.

I have burnt my fingers running netbios (samba) on a system (linux) I
deemed imune against hackers. I dont want to run that risk again.

I dont see the pit I might fall in - but I cannot see very far right
now, because of thouse high walls around me :)

Still that is not a reason against documenting it. Just giving more
insight would be welcome.

I would find it particularly helpful to have a concise statement

from someone who says that PANA will not work. Cannot be

implemented (properly) by virtue of technical errors or documentation too confusing to understand. Or cannot be deployed and used, by virtue of administrative complexity or, again, documentation too confusing to understand.

Absent this, I will ask why it is productive to note that the emperor is pursuing an idiosynchratic sartorial style?



Kind regards
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@xxxxxxxxxxxxxxxx
mail: peter@xxxxxxxxxxxxxxxxxxxxx
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]