[I meant to send this yesterday but got distracted. Happens a lot.] | From: Paul Wouters <p...@nohats.ca>
| I worked on the esp= / ike= mess yesterday by reviving the test case. Good. I'll say it again, perhaps more clearly: I'm willing to work on the parsing, but I'd like clear and accurate explanation of what we (think) the syntax is now. I don't really want to have to infer it from the code. It would be great to know what people actually use (i.e. what not to break). Oh, and what has been documented. That's the starting point. The next step would be a proposed rational design. | Also something I should not have put so much time in :( Those keywords | are a true mess, and it will get worse with EC. We need to deal with: | | esp=/ah= or phase2alg= ? | | same of different parser for phase2alg= versus ike= (phase1alg) ? | | default proposal for ikev1 and ikev2, not the v1tov2 mess we have now. | | allowing v2 style: esp=aes,3des,sha1,md5 ? Use that to build v1 style? | perhaps using a new keyword default-proposal or something ? | | (v1 proposals are sets, v2 proposals are items) | | rip out the crappy parser hacks scattered everywhere for these | options. | | fix the passert that the testing/lib/libswan/algparse now shows? | | fix parsing (eg esp=modp1024) | | deal with GROUP names. some are modp, some are dh, but the entire list | has no common name. Perhaps use group= ? | | pfsgroup= | | confusion of esp=3des-sha1-modp1536 bs esp=3des-sha1;modp2048 | | deal with rsasigkey= versus ecsigkey or start using pubsigkey= ? | | fix up AES CCM/GCM keywords, do not require silly "null" for auth All that is useful, but since I don't know what exists, I don't really understand what that list means. | To me this is a higher priority than fixing "_". But the "_" fix is | something that can be done in a day, and I guess should just be done | now. The above is not :( Fixing _ is done already. And it took longer to talk about than to do it. But doing it was complicated by already obsolete documentation. Let me emphasize: talking about it is important, especially for user-visible changes. And accurate documentation needs to be a higher priority. The serious mess of natt-related options ought to be cleaned up too. Now, while I remember how the option handling works. But first, I would like to clearly know which options are actually important and used. I'm still wondering about nat- vis natt-. _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
