Hi, > On Oct 8, 2015, at 9:40 AM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > > On Mon, Oct 05, 2015 at 09:39:06AM -0400, Paul Hoffman wrote: >> Fully agree. That is why this should not be an IETF document, and instead it >> should be written and published by the organization that is responsible for >> the formats and publication methods. > > I don't really care how this happens, but I note that both previously > and currently staff of that organization seem to use the RFC series to > publish technical specification documents. Generally policy documents > don't get published as RFCs, but other documents do. > > I am not too sure I see why it'd be helpful to create a completely new > publication mechanism for such specifications from ICANN.
Speaking only for myself (which I presume is the case for anyone discussing IETF-related goop)... I'd like to try to get away from the "I" word, err... acronym, as that seems to cause some people to knee-jerk in unhelpful ways. If I can generalize a bit: There is a file. A bunch of independent people want to use the contents of that file. They also want some level of assurance (not absolute) that The Bad Guys haven't mucked with the contents of that file. The folks who currently generate the file do a bunch of things to provide some level of assurance that most (not all) folks think provide a useful level of assurance. Now, in order for the independent people to verify the contents of the file, the folks who _currently_ generate the file need to publish the things they do. The folks who _currently_ generate the file could publish the things they do on their website, but the folks _currently_ generate the file may not do so in the future and the independent people would then have to worry about whoever takes over the role of generating the file will change things in non-backwards compatible ways, resulting in much gnashing of teeth. So instead of the folks who _currently_ generate the file publishing stuff on their own website, they turn to a neutral, third party, voluntary standards development organization and say "hey, this is how we provide some level of assurance for the content of the file a bunch of independent folk care about. We'd like to turn it into one of your standards, any thoughts?" If the standards development organization accepts this, it means the folks who _currently_ generate the file won't pull the rug out from under the independent folks who use the file (not that they would, but having the assurance that they won't is often helpful in convincing developers to use the file). It also means if/when the folks who generate the file change, the new folks who generate the file will have a standard to conform to. This strikes me as a good thing. It also implies that people in the standards development organization can change how the file is secured and that's OK, because the folks who _currently_ generate the file go to great lengths to try to get input from "the community" (whatever that is) and that input is actually welcomed. What am I missing? Thanks, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
