On 6/12/16 6:31 AM, Marc Petit-Huguenin wrote:
1. Make it easier for people to be involved in the IETF. I think that it is incomplete. The goal should be something like "Make it easier for people that can produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet to be involved."
Not to split hairs but Jari didn't say that the goal is to have more people involved in the IETF. My reading of his post was that he'd identified four things in service of the goals of the IETF, which were left unstated. Not sure if that's a good thing or a bad thing - I'd hate to see us rabbit hole on IETF goals while trying to have this discussion.
Personally I think that the barrier of entry to contribute to the IETF is already very low.
I think the formal barriers are low but it really is difficult for people outside the current process to know where to start. I've talked with people who have points they want to raise and who aren't getting anywhere on the mailing list, and when I suggest the write it up as an internet draft a number of them have reacted as if I was asking them to write a paper for submission to a refereed journal - they see it as a very big deal indeed. So, I think there are opportunities to socialize how the IETF works to lower the perceived barriers to contribution.
3. Focus on linking open standards to code, operationals, and interoperability. My view on this evolved these last years. Few years ago I was convinced that developing a reference implementation at the same time than a specification and testing it against other people implementations was the right way to to find bugs in the specification. I even applied that idea when RFC 6940 was developed. Sure I found hundred of issues in the draft (and got "punished" for it by becoming - with Dean Willis - informal editors of the draft). But, in spite of my best efforts, my implementation could not cover 100% of the specification, so if on the one hand that made the specification better, on the other hand it certainly did not made the specification good by any of my standards.
I think this is a fair point but I'd like to mention what I thought was one of the more interesting things to happen at an IETF hackathon, which is that one group found they couldn't implement a draft in its current form because it was wrong, and they needed to go back and fix the specification. I understand that you're arguing that formal methods would provide greater coverage, and I agree (and I hope you'll set up a small side meeting or some such on this in Berlin), but I don't think it's a minor point that an implementation gives you an implementation. Ultimately we're not publishing standards just to publish standards (well, not usually, and we shouldn't be) but because it bears some relationship to what's going on in the world and because these documents reflect an actual need (and given the amount of work being done in the IETF these days I'd like to see us become a little more rigorous about rejecting work of questionable utility). Melinda