every time I post a reply to a thread I think a million kittens (for
herding) are born Joe, so it evens out. Here's another kitten to kill...

Something very left field for me, but I believe important, is that we need
to also publish the out-of-band publication point of the trust material.

I mentioned this to Joe some time ago and was very correctly told "out of
scope" but I believe its nonsensical to exclude physical publication, eg in
newspapers of record for at least 3 economies worldwide, of the hash of the
public key as a standing event.

In-band only has some issues for me, if we are talking about trust.

-George

On Mon, Oct 5, 2015 at 9:14 AM, Joe Abley <jab...@hopcount.ca> 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.
>
> 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
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to