Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>

[Suzanne Woolf <[e-mail]>]

On Oct 8, 2015, at 1:06 PM, David Conrad <[e-mail]> wrote:

> Hi,
> 
>> On Oct 8, 2015, at 9:40 AM, Andrew Sullivan <[e-mail]> 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 know David knows this, but in the interests of completeness: there is an institutional path for communications between "the IETF" and "ICANN"; it's a liaison relationship between the IAB, as keeper of liaisons and other outside relationships for the IETF, and the ICANN Board of Directors. (Jonne Soininen is the current liaison manager, cc'd). 

However, there's no need to stand on any such formality unless we want to, and I see no sign that we do. 

> 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?

Nothing, IMHO. This sounds like you'd be OK with publishing the document as an Informational RFC, mod making sure it's accurate as a current description, and you don't much care which document stream does it-- correct?

Thanks very much for the input.

Anyone else?


thanks,
Suzanne