Re: Long-term IETF evolution thoughts

[Melinda Shore <[e-mail]>]

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