> > 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@xxxxxxxx > >https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf