Dave Crocker escribió:
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.
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.
I totally agree with your statement, I was just thinking about sending
a message in this line.
I am (at least I thought I am) a scientific and as such I prefer to
work with statement and lemas that allow me to reason with them.
Although in some of the messages I have read there are more perceptions
or opinions but too little technical criticism.
In that sense I will like to see clear indication of what is not
adequate and wrong in a more technical fashion, hence it will allow
people to debate on it an a least explain the reason in objectives and
not subjective ways
My 2 cents on this
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.
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?
d/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
--
------------------------------------------------------------
Antonio F. Gómez Skarmeta
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: +34-968-364607
fax: +34-968-364151
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf