Antonio - I'm not well-informed enough about the specifics of the PANA problem space and framework to make definitive recommendations. I was mostly making an observation, based on my experience, of another reaction someone might have to a particular technology/design/protocol. - Ralph On 5/26/06 11:50 AM, "Antonio F. Gómez Skarmeta" <skarmeta@xxxxxxxxx> wrote: > Ralph Droms escribió: > >> Dave - one quick follow on to your observation about "will not work" that >> falls somewhere between "will not work" and "don't like it". There is >> another possibility: "works, but there's a much simpler way to meet the same >> requirements"... >> >> >> > > Which one? and why it is better? > > Antonio > >> - Ralph >> >> >> On 5/26/06 11:34 AM, "Dave Crocker" <dhc2@xxxxxxxxxxxx> 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