In the past, when organizations found themselves in the same situation that ICANN seems to find itself in here (at least as outlined by yourself, below) they have done what ICANN has done and is trying to do now, which is to pass the document on to a neutral third party for “safe keeping”. One thing the IETF used to do was insist that when/if such a document was remedied to its care, that it ALSO claimed change control over same.
A potential outcome here is that IETF would now insist on change control over how ICANN would manage this process going forward, e.g. its no longer an ICANN operational document, its an IETF process document - at which time ICANN may find that its flexibility is reduced, if it is going to be compliant with operational documents it initially wrote. It has happened before. manning bmann...@karoshi.com PO Box 6151 Playa del Rey, CA 90296 310.322.8102 On 8October2015Thursday, at 10:06, David Conrad <d...@virtualized.org> wrote: > 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 > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
