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.
Framework document discusses deployments. Problem statement and requirements
is what you are looking for (RFC 4058).
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.
Again, this is in the scope of the problem statement and requirements.
Alper
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.
Yours,
Joel M. Halpern
At 11:34 AM 5/26/2006, Dave Crocker wrote:
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.
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf