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

["Paul Hoffman" <[e-mail]>]

A document called "DNSSEC Trust Anchor Publication for the Root Zone" 
that says nothing about the most common KSK publication practice, that 
is, by resolver software developers, is woefully incomplete.

If instead the document is supposed to be about current ICANN 
publication only, then the document should be retitled, given a better 
abstract, and give the actual URLs for the current KSK and describe the 
formats used for the current data. It should not make speculation about 
other URLs nor about other format options. It should not talk about the 
publication of possible future KSKs because that is not what ICANN is 
doing now.


On 5 Oct 2015, at 10:14, Joe Abley wrote:

> Hi Paul,
>
> On 5 Oct 2015, at 9:52, Paul Hoffman wrote:
>
>> Given that the title and abstract of this document disagree with what 
>> many people here have said they want the document to discuss, if the 
>> WG adopts this work item, please adopt an exact description of what 
>> is wanted with the expectation that this draft could be changed to 
>> fit the description.
>>
>> I still believe the description of the document people want is best 
>> done by ICANN because it is ICANN who can describe what the 
>> publication process is today.
>
> I think we're conflating a couple of things that could perhaps be 
> better considered separately.

Yes, definitely.

> 1. This document could be published by ICANN through the IETF if they 
> want to make it part of the historical record (what we did in 
> 2009/2010) and also provide a reference to current practice that is 
> easier to find (and doesn't have DRAFT written all over it) than the 
> current reference that I think is only buried within root-dnssec.org. 
> There's precedent for this, see e.g. RFC 7108 which was published as 
> an individual submission. If we followed the same path, we'd be 
> looking at dnsop to review for clarity and accuracy, but we wouldn't 
> be asking for adoption.

If the main issue is "it's too hard to find the current publication 
procedure", then ICANN should (and can) fix this easily. We can also 
take the stupid "DRAFT" designation off.

Publishing an RFC about how ICANN published something in 2010 seems like 
a waste of time, even for historical purposes. It will cause more 
confusion than benefit.

> 2. The current draft was originally written by me as ICANN staff and 
> Jakob as an ICANN contractor. If there's a need to add current ICANN 
> staff to the author list to make it look more official, surely we 
> could do that (as we did with 7108, actually, which was published 
> after I left ICANN).

No one has even vaguely suggested this, and if they do, I'd be happy to 
try to talk them out of it.

> 3. If ICANN prefers not to see this draft published in the RFC series, 
> then that's a good reason not to do it. The value in this document 
> (wherever it is published) lies in it being real, which means we need 
> ICANN's support, e.g. through references in the KSK maintainer's DPS. 
> If that's the preference, let's hear so, clearly. Right now it's 
> difficult to distinguish between individual contributors' opinions and 
> the desires of the IANA Functions Operator.

You are fully and painfully aware of how difficult it is to get "ICANN" 
to state a preference. I'm bringing this up as an individual who has 
read the document carefully and believes that the document only 
partially matches current publication practice for the trust anchor, 
even if the document is retitled and has a more accurate abstract.

> 4. If there are elements in the current text that don't match current 
> practice, then let's hear what they are.

Current practice for what? Publication? Publication by ICANN? It is 
somewhat unfair to ask this question when WG participants have different 
expectations for the document.

> So far comments to that effect are causing some alarm, but without 
> details it's hard to know what to do with them.

Bosh. I gave you details off-line last week, and you acknowledged them. 
It is clear that people commenting on this thread are not reading the 
document listed in the subject line carefully, because most /all who 
have said that they want the document published follow up with a 
description of something that does not match the the current document.

--Paul Hoffman