Hi Hector, On Fri, Jun 28, 2013 at 11:56 AM, Hector Santos <hsantos@xxxxxxxx> wrote: > I believe this is all part of improving the IETF Electronic Diversity > picture. Just like we have to deal with greater people personal > globalization diversity issues, there is also greater technology and legal > diversity issues to deal with. So many tools, so many languages, so many > OSes, so many devices and communications API platforms, where are the > proposals for better, new "IETF Global Commons?" Guidelines for technical > writing for the new world engineers to use, etc. I think that computational code written in C, pretty much the lowest common denominator, is just fine. I don't think there is any greater diversity now that then was 10 or 20 years ago at that level. In fact, I think there is less. > For me, when I saw this RFC, the things crossed my mind: > > - I have trouble with the licensing statement. The RFC describes public > domain technology. It requires passing this thru your lawyer(s) to see if > it can used in our commercial product lines. Sorry, the standard simplified BSD license is required for code in RFCs. The authors couldn't change it. But if you are doing a serious commercial product and you don't have a lawyer checking such things anyway, you are a fool. > - Far too big to distribute via a RFC. Provide a link to some RFC site. > Note, I'm just saying in general. I did not read in detail if > the RFC already included links to the official source code. Nonsense. An RFC should be self contained and IO don't see what's "too big" about this one. The code is in a relatively compact region of the RFC, so you can read the text and skip the code, if you want, without undue effort. > - Because it was too big, it requires a stripper/parser, although a good > power programmer can quickly macro-clean it up. The RFCSTRIP tool, well, > what language is that? I'm not an *nix person. So this adds to the > complexity for the Windows shops to get at these hashing functions. Of > course, its a piece of cake for a sharp programmer, but even the sharpest > knives eventually get dull. This is just nonsense. If you are going to do anything serious with code, you need a source code editor. With that, it is no big deal to extract and test the code. Although I would agree that making the RFCSTRIP tool available over the web, as many other tools are, would be reasonable. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx > -- > HLS > > > On 6/28/2013 4:53 AM, Dearlove, Christopher (UK) wrote: >> >> I'd actually tried the authors, but no reply yet (only a few days). I also >> tried the RFC Editor thinking they might have e.g. XML from which extraction >> might have been easier, but also no response yet. And I had found several >> libraries, but not the RFC code. I can't see any suggestion that the library >> you indicate includes that code, it also bills itself as a C++ library, >> which the RFC code is not (and also not what I want, but that's not a >> subject for this list). >> >> But the broader point is that if it's worth the IETF publishing the code >> as an RFC, it's worth making the code available straightforwardly. >> >> For me, a thanks to Tony Hansen, who did the extraction for me. (That >> makes me feel a little guilty, why should he do my work I could have done?) >> But the point of posting on this list was to say that the code should be >> available so that each person wanting that code doesn't have to do that >> again. >> >> Christopher >> >