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.
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.
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).
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.
4. If there are elements in the current text that don't match current
practice, then let's hear what they are. So far comments to that effect
are causing some alarm, but without details it's hard to know what to do
with them.
I am not advocating for any particular direction -- I'd just like to
move this draft *somewhere*, whether that's towards the IESG or towards
the garbage can of history. Every time we rev the doc without just to
stop it expiring, another kitten dies.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
