Just relaying to the list the comments I made at the mic in the WG session on Monday...
I did not agree with any of the four choices offered by the chairs to the WG for the resolution of the RFC 7788 / .home issue. I've spent a good bit time over the past four years helping people try to implement standards that we create for technologies such as IPv6, DNSSEC, TLS, etc. Developers often attempt to use the RFCs and many wind up finding it too confusing of an experience. A few observations: - Some developers don't pay attention to (or don't see) the "errata" that exists on some of the RFCs. (There was a comment in the room on Monday that some views of the RFCs don't make it easy to find the errata - I've not explored that myself to confirm.) [1] - Some developers don't understand how our systems work with regard to "updates". They don't understand that an RFC may be updated by another RFC and that update may fundamentally alter the original RFC. They are generally told "you need to implement RFC <####> - go do it!" and are left to figure that out. In talking to a couple of developers over the years, they just go to their favorite search engine, enter the RFC number and pretty much take the first link they find (which may or may not be one of our primary repositories). I think the easier we can make it for developers to figure out how to implement our standards, the better the chance for more deployment. If we want HOMENET to be widely used, we need to make the standards as easy to understand and implement. To me that means a couple of things with regard to RFC 7788 and the .home issue: 1. I would NOT publish any changes we want to make as "errata". 2. I would NOT publish a new RFC that "updates" RFC 7788. 3. I would NOT publish a new RFC that is filled with "internal" analysis of how the process broke down AND THEN also updates RFC 7788. (Someone seeking to implement the standard is not going to want to wade through the analysis.) I think the cleanest, simplest thing we can do *for the implementers* is to publish a new RFC that *obsoletes* RFC 7788. We can then promote the new RFC as the definitive standard for HNCP. RFC 7788 can get a big "Obsolete" warning in the places we publish it - and documentation and other new RFCs can reference the new RFC. Just my 2 cents, Dan [1] I also know that RFCs are sometimes copied to other locations on the Internet where things such as errata and update links are sometimes lost. I realize that's not something we can really address - and we can only hope developers seek out the "official" source - but that is also a reality. -- Dan York Senior Content Strategist, Internet Society [email protected]<mailto:[email protected]> +1-802-735-1624 Jabber: [email protected]<mailto:[email protected]> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
