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
