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

From: Suzanne Woolf <[email-masked]>
Date: Fri, 2 Oct 2015 12:10:18 -0400

Hi,

Just took a whirlwind tour through correspondence to date on this draft, need to review more closely.

On Sep 29, 2015, at 2:21 PM, David Conrad <[email-masked]> wrote:

> On Sep 29, 2015, at 2:53 AM, Shane Kerr <[email-masked]> wrote:
>>> On Mon, Sep 28, 2015 at 07:59:00AM -0400, Joe Abley wrote:
>>>> This document describes existing practice, and provides guidance for
>>>> people who need to bootstrap a validator using the mechanisms provided
>>>> by ICANN back in 2009/2010 when the root zone was first published.
>>> 
>>> Preempting a WGLC, I support the document.  It states its aim of
>>> documenting existing practices, and it does so clearly.
>> 
>> I agree completely. I am actually confused as to why it is not already
>> an RFC.
> 
> +1

Well, as a technicality, I don't see that this draft was ever adopted by the WG. 

That is, however, almost entirely irrelevant to getting it published; it's our job to make the process machinery serve the IETF and the larger community, not the other way around :-) 

Tim and I will confer on the discussion since Prague and propose a path forward shortly. 

thanks,
Suzanne

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Oct 2015 11:00:49 -0700

Hi,

>>> I agree completely. I am actually confused as to why it is not already

I've since been told that the draft doesn't actually document current practice (don't know the details), so this probably needs to be fixed.

> Well, as a technicality, I don't see that this draft was ever adopted by the WG.

Perhaps that might be a good next step?

Regards,
-drc

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 4 Oct 2015 14:27:15 -0400

All,

Your co-chair is a little confused.

> I've since been told that the draft doesn't actually document current practice (don't know the details), so this probably needs to be fixed.

What "needs to be fixed"? That the draft doesn't document current practice? Given that's the stated goal, I'd appreciate clarification from the authors on what they think needs to be done before it meets that goal, and whether they're willing to work on it.
> Perhaps that might be a good next step?

Might be. I was attempting to suggest a shorter path to publication might be possible, given the extensive record of discussion on the document over several years-- we've been known to do a combined adoption/WGLC on a document not expected to need much work in the WG.

But judging by your comment above, it's hard to say how much work remains to be done on it, since we've also got folks eager to preempt WGLC altogether.

Authors?

thanks,
Suzanne

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Oct 2015 11:31:04 -0700

> Your co-chair is a little confused.

Sorry about that.

On Oct 4, 2015, at 2:00 PM, David Conrad <[email-masked]> wrote:
> What "needs to be fixed"? That the draft doesn't document current practice?

Yes.  I received a comment in response to my "+1" that the draft differs from current practice. I haven't had time to pursue the details, but wanted to flag this to indicate my "+1" was premature. I believe the document should reflect current practice.

Regards,
-drc

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 4 Oct 2015 14:35:56 -0400

>> Your co-chair is a little confused.

No worries, it happens all the time….
> Yes.  I received a comment in response to my "+1" that the draft differs from current practice. I haven't had time to pursue the details, but wanted to flag this to indicate my "+1" was premature.…

Agreed, and it suggests that adoption might indeed be the right next step if folks want to continue to work on it. We're happy to proceed as the authors and the WG prefer.

thanks,
Suzanne

---

From: "Joe Abley" <[email-masked]>
Date: Sun, 04 Oct 2015 15:31:52 -0400

Hi David,

> I've since been told that the draft doesn't actually document current practice (don't know the details), so this probably needs to be fixed.

If you could share who told you that, that might be a good starting point :-)

> Perhaps that might be a good next step?

We have other examples in recent history of an informational draft that documents current practice being published as an AD-sponsored document; examples that spring to mind are RFC 5855 and RFC 7108. But regardless of what mechanism is used to publish the document, we need to be sure that it has been well-reviewed in this working group. Certainly it's clear that it's not worth publishing if it doesn't document what it claims to document.

In my opinion, the draft in this space that really does want to be a dnsop document is draft-jabley-dnsop-validator-bootstrap.

Regardless of whether draft-jabley-dnssec-trust-anchor proceeds as a wg draft, or as an AD-sponsored individual submission, or is dropped altogether, I really think we want the recommended mechanisms by which a validator sets itself up to be predictable and solid. That's important for validators running on a server with live human technical operators, validators running on home gateways and other embedded environments and everything in-between.

Joe

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 5 Oct 2015 14:50:50 +0200

> What "needs to be fixed"? That the draft doesn't document current practice? Given that's the stated goal, I'd appreciate clarification from the authors on what they think needs to be done before it…

As far as I'm aware, the document does document current practice. At least, what it describes was true back in 2010 when I wrote the code and as far as I know nothing as changed (i.e., the published files has not changed).

> Might be. I was attempting to suggest a shorter path to publication might be possible, given the extensive record of discussion on the document over several years-- we've been known to do a combine…

I'm not sure what adoption would give us as the document aims to document current practice, and nothing - except clarifications - is up for discussion.

	jakob

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Oct 2015 09:08:38 -0400

On 5 Oct 2015, at 8:50, Jakob Schlyter wrote:

>>> I've since been told that the draft doesn't actually document 
>>> current practice (don't know the details), so this probably needs to 
>>> be fixed.
>>
>> What "needs to be fixed"? That the draft doesn't document current 
>> practice? Given that's the stated goal, I'd appreciate clarification 
>> from the authors on what they think needs to be done before it meets 
>> that goal, and whether they're willing to work on it.
>
> As far as I'm aware, the document does document current practice.

It does not. It describes a mixture of some of the current practice and 
some aspirational hopes for how things might be done. Further, it is 
incomplete in many aspects.

> At least, what it describes was true back in 2010 when I wrote the 
> code and as far as I know nothing as changed (i.e., the published 
> files has not changed).

The document goes well beyond describing the files, and this is where it 
fails. Further, the files are not the only way that the trust anchor is 
published, so the document is fairly incomplete.

>> Might be. I was attempting to suggest a shorter path to publication 
>> might be possible, given the extensive record of discussion on the 
>> document over several years-- we've been known to do a combined 
>> adoption/WGLC on a document not expected to need much work in the WG.
>
> I'm not sure what adoption would give us as the document aims to 
> document current practice, and nothing - except clarifications - is up 
> for discussion.

If it is not up for discussion, then the document should not be 
progressed in the IETF at all. Instead, the description of the ICANN's 
publication methodology should be published by ICANN.

This WG should instead consider a very different document: how the IETF 
thinks that the DNSSEC trust anchors should be published in order to 
help DNS operators. Joe Abley has an expired (?) draft on this topic. A 
discussion of what ICANN and others should do for publication seems 
quite relevant to the aims of this WG.

--Paul Hoffman

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 5 Oct 2015 15:32:11 +0200

On 5 okt. 2015, at 15:08, Paul Hoffman <[email-masked]> wrote:

> It does not. It describes a mixture of some of the current practice and some aspirational hopes for how things might be done. Further, it is incomplete in many aspects.

If it is incomplete, we need to fix that.

> The document goes well beyond describing the files, and this is where it fails. Further, the files are not the only way that the trust anchor is published, so the document is fairly incomplete.

Trust anchors may be published in other ways, but IMHO that is out of scope for this document. As far as I know, IANA does not published the trust anchor in other ways.

"This document describes the distribution of the DNSSEC trust anchors
 from IANA.  This document is concerned only with the distribution of
 trust anchors for the root zone, although the data formats and the
 publication and retrieval methods described here can be adapted for
 other uses."

> If it is not up for discussion, then the document should not be progressed in the IETF at all. Instead, the description of the ICANN's publication methodology should be published by ICANN.

The file formats are not up for discussion, as existing implementations depend on them. The description on how to interpret the contents are of course up for discussion. I'm just saying we need to be careful what we change, if we choose to change things that's been in production for over 5 years.

> This WG should instead consider a very different document: how the IETF thinks that the DNSSEC trust anchors should be published in order to help DNS operators. Joe Abley has an expired (?) draft on this topic. A discussion of what ICANN and others should do for publication seems quite relevant to the aims of this WG.

Although I agree with that, I still find it useful to publish this draft as document how things are done today. If the world did not use the published trust anchors as designed, that is (to some extent) failure. Still, it documents (or apparently tries to) the plan as it were back in 2010.

	jakob

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 5 Oct 2015 09:37:55 -0400

From my high tech gadget

> On Oct 5, 2015, at 09:32, Jakob Schlyter <[email-masked]> wrote:
> 

My opinion (and mine alone here) is if this document does not describe current behavior it should not go out. 

Could ICANN not document what they do now ? 

Also the IAB just updated their root server requirements RFC, 2870. 

Tim

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Oct 2015 09:39:06 -0400

On 5 Oct 2015, at 9:32, Jakob Schlyter wrote:

>> The document goes well beyond describing the files, and this is where 
>> it fails. Further, the files are not the only way that the trust 
>> anchor is published, so the document is fairly incomplete.
>
> Trust anchors may be published in other ways, but IMHO that is out of 
> scope for this document.

But that is the scope given in both the title and the abstract of the 
document.

>> progressed in the IETF at all. Instead, the description of the 
>> ICANN's publication methodology should be published by ICANN.
>
> The file formats are not up for discussion, as existing 
> implementations depend on them. The description on how to interpret 
> the contents are of course up for discussion. I'm just saying we need 
> to be careful what we change, if we choose to change things that's 
> been in production for over 5 years.

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.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Oct 2015 09:52:30 -0400

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.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 05 Oct 2015 10:14:07 -0400

Hi Paul,

On 5 Oct 2015, at 9:52, Paul Hoffman wrote:

> 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

---

From: George Michaelson <[email-masked]>
Date: Mon, 5 Oct 2015 09:42:39 -0500

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 <[email-masked]> 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.
>>
>> by ICANN because it is ICANN who can describe what the publication process
>> is today.
>>
>
> 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).
>
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 05 Oct 2015 10:55:03 -0400

> to also publish the out-of-band publication point of the trust material.

This draft is exclusively concerned with publishing trust anchors out-of-band of the protocol.

> public key as a standing event.

This draft aims to document current practice. To my knowledge, nobody has ever published a trust anchor (or even a pointer to it) in print media.

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

Me too, hence the decision by ICANN to publish trust anchors using out-of-band mechanisms in 2009/2010, as this draft aims to document.

Joe

---

From: George Michaelson <[email-masked]>
Date: Mon, 5 Oct 2015 10:06:33 -0500

If its on the internet, its not out of band.

On Mon, Oct 5, 2015 at 9:55 AM, Joe Abley <[email-masked]> wrote:

> This draft aims to document current practice. To my knowledge, nobody has
> ever published a trust anchor (or even a pointer to it) in print media.
>
> Me too, hence the decision by ICANN to publish trust anchors using
> out-of-band mechanisms in 2009/2010, as this draft aims to document.
>
>
> Joe
>

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 05 Oct 2015 11:54:23 -0400

> If its on the internet, its not out of band.

Then there's no out-of-band (by your use of the phrase) distribution of trust anchors today.

I think it's fair to say that your understanding of the phrase is not universal, incidentally, in age where the Internet provides transport for phone calls, text messages, television, radio, ad proofing in newspapers, and even postal mail.

Joe

---

From: Richard Lamb <[email-masked]>
Date: Mon, 5 Oct 2015 15:58:13 +0000

Sheesh..I thought we were talking about engineering issues.

Speaking only as the humble engineer who helped develop the publication methods and wrote the software that generates all the pieces, the most recent draft does describe what my programs, scripts, and other pieces do.  If there is any technical variance, please let me know I don’t pretend to be perfect.  I run another copy of some of the pieces on my KSK rollover test setup now, so id like to know.

I have no opinion regarding the more abstract discussion regarding where such a description belongs and look to learn from those better versed in that subject.

-Rick

From: DNSOP [mailto:[email-masked]] On Behalf Of George Michaelson
Sent: Monday, October 5, 2015 8:07 AM
To: Joe Abley <[email-masked]>
Cc: dnsop WG <[email-masked]>; Paul Hoffman <[email-masked]>
Subject: Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>

On Mon, Oct 5, 2015 at 9:55 AM, Joe Abley <[email-masked]<mailto:[email-masked]>> wrote:

Joe

---

From: George Michaelson <[email-masked]>
Date: Mon, 5 Oct 2015 11:06:37 -0500

FWIW I think the document should go ahead, with pretty minor edit about the
current practice/should stuff. I think it was good to author a document on
whats currently done even if people want other things done.

(I don't mean my other things, I mean other peoples other things. one does
not refer to oneself in the third person unless mad)

-G

On Mon, Oct 5, 2015 at 10:58 AM, Richard Lamb <[email-masked]>
wrote:

> Speaking only as the humble engineer who helped develop the publication
> methods and wrote the software that generates all the pieces, the most
> recent draft does describe what my programs, scripts, and other pieces do.
> If there is any technical variance, please let me know I don’t pretend to
> be perfect.  I run another copy of some of the pieces on my KSK rollover
> test setup now, so id like to know.
>
>
>
> I have no opinion regarding the more abstract discussion regarding where
> such a description belongs and look to learn from those better versed in
> that subject.
>
>
>
> -Rick
>
>
>
>
>
>
>
> *From:* DNSOP [mailto:[email-masked]] *On Behalf Of *George
> Michaelson
> *Sent:* Monday, October 5, 2015 8:07 AM
> *To:* Joe Abley <[email-masked]>
> *Cc:* dnsop WG <[email-masked]>; Paul Hoffman <[email-masked]>
> *Subject:* Re: [DNSOP] Expiration impending:
> <draft-jabley-dnssec-trust-anchor-11.txt>
>
>
>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Oct 2015 16:50:21 +0000

>Could ICANN not document what they do now ?

In there world of "there's so many things to do" - a few weeks back,
off-list, there was a start of a discussion to alter the list of editors
(namely, add me) of the draft.

Aside - if I recall correctly, years ago, Joe announced the -00 as "what
ICANN does" not something up for debate but something that would be ideal
if the IETF had some comment on. (The new-fangled IETF archives don't seem
to have an obvious way to look at messages from September 2010 or October
2010 when I suspect the mail triggering this idea arrived.  If anyone
knows where the old-hangled mailman archives are, it would be helpful.)

I see this -11 document as something that can be an RFC, not a WG product.
 I.e., an individual submission with advice from the WG.  The intent is to
have an immutable, reviewed technical document published for the technical
community.  The RFC series seems appropriate.

I could be wrong.

My offer to be added as an editor was to take on any edits that might be
needed.  I don't know (off the top of my head) if any are.  Perhaps it
would be more useful to have a document shepherd than an editor to get
this -11 into an RFC.

---

From: manning <[email-masked]>
Date: Mon, 5 Oct 2015 11:37:00 -0700

Out of band was discussed very early on with DNSSEC.  John Gilmore and I talked about it at the INET’98 conference.
A problem is transitive trust.  At some point you leave the DNS trust hierarchy and have to trust assertions in a different trust domain.
Sometimes several other trust domains…  I think trying to bound the problem space into a single trust domain is prudent, if only because stepping outside that space is quite large and may not be wise for an IETF document.

That said, if the RZM folks don’t document how they handle transitive trust, I would be much more worried.

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

On 5October2015Monday, at 7:42, George Michaelson <[email-masked]> wrote:

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Oct 2015 15:35:50 -0400

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:

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

Yes, definitely.

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

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

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

> 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

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 05 Oct 2015 16:12:48 -0400

Hi Paul,

> is, by resolver software developers, is woefully incomplete.

I am confused by that. The KSK maintainer publishes trust anchors for 
the root zone. Software developers produce code that consumes those 
trust anchors. Perhaps we are missing a shared understanding of the word 
"publish" here, but I don't see what common KSK publication practice 
you're referring to.

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

I don't understand the comment about the title or the abstract (see 
above).

I fully agree that the document should use actual URLs for the current 
KSK. As far as I can see, all the URLs mentioned in the document are 
URLs that work today, and have been stable since 2010. I don't see any 
speculation about other URLs.

Can you explain more fully what problem you see?

> It should not talk about the publication of possible future KSKs 
> because that is not what ICANN is doing now.

I don't understand that, either. The scheme developed at ICANN in 
2009/2010 was designed to facilitate publication of multiple trust 
anchors, specifically to allow future KSK rolls. You're saying we 
shouldn't document that because a KSK roll hasn't happened, yet?

Joe

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Oct 2015 16:43:14 -0400

On 5 Oct 2015, at 16:12, Joe Abley wrote:

>> that says nothing about the most common KSK publication practice, 
>> that is, by resolver software developers, is woefully incomplete.
>
> trust anchors. Perhaps we are missing a shared understanding of the 
> word "publish" here, but I don't see what common KSK publication 
> practice you're referring to.

Hrm. I'm pretty sure that most people would agree that software is 
published, and that config comes with that published software. The KSK 
is often part of that config.

Of course "the KSK maintainer publishes trust anchors for the root 
zone". So do other organizations. It seems like many people who say they 
want this document published want this document to be how ICANN/IANA 
publishes the trust anchors.

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

Maybe you are thinking that only ICANN can publish the trust anchor? If 
so, I would certainly disagree. Anyone can publish it, and that's a 
feature.

> Can you explain more fully what problem you see?

    The URL for retrieving the CSR is 
<http://data.iana.org/root-anchors/
    key-label.csr>, with "key-label" replaced by the key label of the
    corresponding KSK.

    The URL for retrieving a signed X.509 certificate is <http://
    data.iana.org/root-anchors/key-label.crt>, with "key-label" again
    replaced as described above.

Those are templates, not URLs. ICANN does not publish anything at 
http://data.iana.org/root-anchors/key-label.csr (unless you consider 
giving a 404 to be publishing...).

Templates are speculative: you can plug in different values that change 
over time. That is not what ICANN publishes. Yes, you designed it to be 
a template, but that is not what ICANN publishes.

If this document is going to be published by anyone, it should state 
exactly how ICANN publishes things, not how it might it different future 
circumstances.

> shouldn't document that because a KSK roll hasn't happened, yet?

There is a difference between "how ICANN publishes the KSK" and "how 
ICANN might publish the KSK". Please pick the one you want so that the 
WG can decide if that's what they want you to publish. Mixing those two 
ideas up will not help anyone who is reading the published document.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 05 Oct 2015 17:00:07 -0400

On 5 Oct 2015, at 16:43, Paul Hoffman wrote:

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

Ah, that helps explain the disconnect.

> zone". So do other organizations. It seems like many people who say 
> they want this document published want this document to be how 
> ICANN/IANA publishes the trust anchors.

That understanding of "publish" had never occurred to me, to be honest.

If someone cuts an article out of the Toronto Star and sticks it on a 
message board for other people to see, is it reasonable to say that that 
person published the article? Or did the Toronto Star publish it?

> [...]
>
> Maybe you are thinking that only ICANN can publish the trust anchor? 
> If so, I would certainly disagree. Anyone can publish it, and that's a 
> feature.

That does indeed seem to be a disagreement.

To state the context I had been working from (hence the confusion):

  - the KSK maintainer publishes a set of trust anchors
  - other people might well re-package them for one reason or another
  - in general, anybody who is hard-coding trust anchors in their 
published software is doing it wrong

>> I fully agree that the document should use actual URLs for the 
>> current KSK. As far as I can see, all the URLs mentioned in the 
>> document are URLs that work today, and have been stable since 2010. I 
>> don't see any speculation about other URLs.
>
>>
> The URL for retrieving the CSR is <http://data.iana.org/root-anchors/

OK, I agree they are templates.

I disagree that it makes sense to publish URLs that refer to just the 
key label used by the currently active KSK. That would make this 
document inaccurate as soon as a KSK roll occurred, despite the fact 
that it aims to document the way that the current and future successor 
trust anchors are published.

The "key-label" token is intended to be taken from the root-anchors.xml 
file, which is cited with a stable URL.

You might argue that this is messy, and I might agree. But I would 
suggest that it's the only reasonable way to describe the current trust 
anchor publication mechanism used by ICANN.

> exactly how ICANN publishes things, not how it might it different 
> future circumstances.

Fully agree, with the opposite conclusion.

> WG can decide if that's what they want you to publish. Mixing those 
> two ideas up will not help anyone who is reading the published 
> document.

ICANN might well choose different formats, URL schemes, whatever in the 
future.

The current format, URL scheme, whatever is as is written in the 
document.

The trust anchor publication strategy was designed to handle successor 
keys, and this document aims to describe that strategy.

Joe

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Oct 2015 17:16:11 -0400

On 5 Oct 2015, at 17:00, Joe Abley wrote:

>>> I am confused by that. The KSK maintainer publishes trust anchors 
>>> for the root zone. Software developers produce code that consumes 
>>> those trust anchors. Perhaps we are missing a shared understanding 
>>> of the word "publish" here, but I don't see what common KSK 
>>> publication practice you're referring to.
>>
>> published, and that config comes with that published software. The 
>> KSK is often part of that config.
>
> message board for other people to see, is it reasonable to say that 
> that person published the article? Or did the Toronto Star publish it?

Including config in published software is publishing. Sticking something 
on a message board is barely so, if at all.

>> If so, I would certainly disagree. Anyone can publish it, and that's 
>> a feature.
>

Got it. Yep, we disagree.

> published software is doing it wrong

Bashing the dead horse so that it doesn't kill any more kittens: if this 
is about "how ICANN does X", it really doesn't matter what you or I 
think about who is doing stuff wrong, even when we agree.

>>> document are URLs that work today, and have been stable since 2010. 
>>> I don't see any speculation about other URLs.
>>
>>>

It sounds like you don't want to limit the document to what many people 
have asked, namely to document ICANN's current methods for publishing 
the KSK. That's a fine desire, but it is quite sloppy to conflate the 
two.

> The "key-label" token is intended to be taken from the 
> root-anchors.xml file, which is cited with a stable URL.

The term "key-label" does not appear in Section 2.1, so there is not 
even a description of how to fill in the template.

> suggest that it's the only reasonable way to describe the current 
> trust anchor publication mechanism used by ICANN.
>> ICANN might publish the KSK". Please pick the one you want so that 
>> the WG can decide if that's what they want you to publish. Mixing 
>> those two ideas up will not help anyone who is reading the published 
>> document.
>
> ICANN might well choose different formats, URL schemes, whatever in 
> the future.
>

...and is thus speculative. If the WG wants to publish a speculative 
document, that's fine, but that's not what people have said so far, and 
not how the document describes itself.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 05 Oct 2015 17:20:54 -0400

On 5 Oct 2015, at 17:16, Paul Hoffman wrote:

>> that it aims to document the way that the current and future 
>> successor trust anchors are published.
>
> It sounds like you don't want to limit the document to what many 
> people have asked, namely to document ICANN's current methods for 
> publishing the KSK. That's a fine desire, but it is quite sloppy to 
> conflate the two.

I think we've passed the point of diminishing returns on this point (if 
not this thread).

My perspective remains that the document does exactly what you 
characterise it as not doing. Perhaps it's time to sit back and wait for 
others here to express an opinion.

> even a description of how to fill in the template.

That sounds like a change we could make that would aid clarity. Thanks 
-- we'll review and see what we can do.

Joe

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 5 Oct 2015 17:42:26 -0400

All,

First, thanks to the engaging on this.

On Oct 5, 2015, at 5:20 PM, "Joe Abley" <[email-masked]> wrote:
> 
> Perhaps it's time to sit back and wait for others here to express an opinion.

I'd like to hear opinions from others in the WG with an operational interest in the DNSSEC root trust anchor. 

Does this document meet a need you have? If so, how well does it meet the need, and what would it take (if anything) for the document to meet that need more effectively?

I'm trying not to put the mechanics (whether/how/by whom published) ahead of the actual purpose of publishing.

thanks,
Suzanne

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Oct 2015 09:19:13 +1100

For BIND is is essentially useless as we use DNSKEYs as our trust
anchors.  You can go from a DNSKEY to a DS record.  You can't go
from a DS record to a DNSKEY, you can only select from a set of
DNSKEYs the one or more (not that I expect that to ever happen)
that matches a DS.

If you are going to publish trust anchors they should be easy to
use.  No one types in DS or DNSKEY records so data length really
shouldn't be a consideration.  They are all entered using cut-and-paste.
There is no reason to only publish DS records.

Mark

In message <[email-masked]>, Suzanne Woolf writ
es:
> Does this document meet a need you have? If so, how well does it meet the nee
> d, and what would it take (if anything) for the document to meet that need mo
> re effectively?
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 05 Oct 2015 18:23:00 -0400

Moin!

On 5 Oct 2015, at 17:42, Suzanne Woolf wrote:

> I'd like to hear opinions from others in the WG with an operational 
> interest in the DNSSEC root trust anchor.
>
> Does this document meet a need you have? If so, how well does it meet 
> the need, and what would it take (if anything) for the document to 
> meet that need more effectively?
Having written an implementation of what is in the document and knowing 
at least two much more clueful people who also did that I think this 
document fills a need. Having people distinguish their configuration 
from their code and instead using code to get the initial trust anchor 
with it IMHO certainly serves a purpose.

So yes we should publish this, and as is is fine with me.

So long
-Ralf

---

From: manning <[email-masked]>
Date: Mon, 5 Oct 2015 17:28:54 -0700

it might be useful to review/consider how the IETF NOMCOM does or did its selections.   At one point, they used, as a salt, stock values as published on a particular date and time.
the USG does the same type of thing with the CBD.  <http://www.gpo.gov/help/about_commerce_business_daily.htm>  …  If I had anything to say about it, I’d prefer the KSK publication
process include publication in one or more archival systems.   But that is outside the IETF purview.   I’d let this draft be published as a description of the in-baliwick, in-band, how we use the DNS protocol to publish trust anchors as used by the IANA, once upon a time.   And be done with this for now.

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

On 5October2015Monday, at 14:16, Paul Hoffman <[email-masked]> wrote:

>>>>> 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.
>>>> 
>>>> I am confused by that. The KSK maintainer publishes trust anchors for the root zone. Software developers produce code that consumes those trust anchors. Perhaps we are missing a shared understanding of the word "publish" here, but I don't see what common KSK publication practice you're referring to.
>>> 
>>> Hrm. I'm pretty sure that most people would agree that software is published, and that config comes with that published software. The KSK is often part of that config.
>> 
>>> Of course "the KSK maintainer publishes trust anchors for the root zone". So do other organizations. It seems like many people who say they want this document published want this document to be how ICANN/IANA publishes the trust anchors.
>> 
>> If someone cuts an article out of the Toronto Star and sticks it on a message board for other people to see, is it reasonable to say that that person published the article? Or did the Toronto Star publish it?
> 
> Including config in published software is publishing. Sticking something on a message board is barely so, if at all.
> 
>> 
>>> [...]
>>> 
>>> Maybe you are thinking that only ICANN can publish the trust anchor? If so, I would certainly disagree. Anyone can publish it, and that's a feature.
>> 
>> - in general, anybody who is hard-coding trust anchors in their published software is doing it wrong
> 
> Bashing the dead horse so that it doesn't kill any more kittens: if this is about "how ICANN does X", it really doesn't matter what you or I think about who is doing stuff wrong, even when we agree.
> 
>> 
>>>> I fully agree that the document should use actual URLs for the current KSK. As far as I can see, all the URLs mentioned in the document are URLs that work today, and have been stable since 2010. I don't see any speculation about other URLs.
>>> 
>>>> 
>>> Those are templates, not URLs. ICANN does not publish anything at http://data.iana.org/root-anchors/key-label.csr (unless you consider giving a 404 to be publishing...).
>> 
>> I disagree that it makes sense to publish URLs that refer to just the key label used by the currently active KSK. That would make this document inaccurate as soon as a KSK roll occurred, despite the fact that it aims to document the way that the current and future successor trust anchors are published.
> 
> It sounds like you don't want to limit the document to what many people have asked, namely to document ICANN's current methods for publishing the KSK. That's a fine desire, but it is quite sloppy to conflate the two.
> 
>> The "key-label" token is intended to be taken from the root-anchors.xml file, which is cited with a stable URL.
> 
> The term "key-label" does not appear in Section 2.1, so there is not even a description of how to fill in the template.
> 
>> You might argue that this is messy, and I might agree. But I would suggest that it's the only reasonable way to describe the current trust anchor publication mechanism used by ICANN.
>>> If this document is going to be published by anyone, it should state exactly how ICANN publishes things, not how it might it different future circumstances.
>> 
>>>>> It should not talk about the publication of possible future KSKs because that is not what ICANN is doing now.
>>>> 
>>>> I don't understand that, either. The scheme developed at ICANN in 2009/2010 was designed to facilitate publication of multiple trust anchors, specifically to allow future KSK rolls. You're saying we shouldn't document that because a KSK roll hasn't happened, yet?
>>> 
>>> There is a difference between "how ICANN publishes the KSK" and "how ICANN might publish the KSK". Please pick the one you want so that the WG can decide if that's what they want you to publish. Mixing those two ideas up will not help anyone who is reading the published document.
>> 
>> ICANN might well choose different formats, URL schemes, whatever in the future.
>> 
>> The current format, URL scheme, whatever is as is written in the document.
>> 
>> The trust anchor publication strategy was designed to handle successor keys, and this document aims to describe that strategy.
> 
> ...and is thus speculative. If the WG wants to publish a speculative document, that's fine, but that's not what people have said so far, and not how the document describes itself.
> 
> --Paul Hoffman
>

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 06 Oct 2015 10:52:43 +0200

Hi,

On 05/10/15 23:42, Suzanne Woolf wrote:
> I'd like to hear opinions from others in the WG with an
> operational interest in the DNSSEC root trust anchor.

It documents a procedure we implemented, and a stable reference would
be a good thing.

> Does this document meet a need you have? If so, how well does it
> meet the need, and what would it take (if anything) for the
> document to meet that need more effectively?

Unbound implements the draft in open source, in its own command-line
tool 'unbound-anchor'.  It combines a compiled-in root-anchor, with
RFC5011 rollover and this draft.  At the first start it has failover
over from the initial anchor to the next option, and this draft is the
fallback.  On subsequent invocations it keeps state, a rolling anchor
that it keeps track of.  If RFC5011 tracking fails, it uses this draft
to fetch the xml file with the new key.  The tool is
organisation-agnostic and can also be configured to perform the same
mechanics in another environment (eg. test environments).

Best regards, Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Oct 2015 12:40:15 -0400

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.

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Thu, 8 Oct 2015 10:06:47 -0700

Hi,

> On Oct 8, 2015, at 9:40 AM, Andrew Sullivan <[email-masked]> wrote:
> 

Speaking only for myself (which I presume is the case for anyone discussing IETF-related goop)...

I'd like to try to get away from the "I" word, err... acronym, as that seems to cause some people to knee-jerk in unhelpful ways.

If I can generalize a bit:

There is a file. A bunch of independent people want to use the contents of that file. They also want some level of assurance (not absolute) that The Bad Guys haven't mucked with the contents of that file. The folks who currently generate the file do a bunch of things to provide some level of assurance that most (not all) folks think provide a useful level of assurance.

Now, in order for the independent people to verify the contents of the file, the folks who _currently_ generate the file need to publish the things they do. The folks who _currently_ generate the file could publish the things they do on their website, but the folks _currently_ generate the file may not do so in the future and the independent people would then have to worry about whoever takes over the role of generating the file will change things in non-backwards compatible ways, resulting in much gnashing of teeth.

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?

Thanks,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Oct 2015 14:08:17 -0400

>From my POV, nothing.  Paul seemed to be suggesting that the current
arrangements should be published somehow other than as "an IETF
document".  Maybe he meant "send it up the Independent Submissions
editor with ICANN staff on the top".  I don't really know.

If that is what he meant, then I think the distinction is not that
interesting.  IME nobody except a tiny fraction of IETF participants
makes the ISE/IETF product distinction. 

If it's not what he meant, then I see no value in creating a new
publication path.

IMO, what is current practice, whatever it is, ought to be in the
document.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 08 Oct 2015 12:15:40 -0700

> editor with ICANN staff on the top".  I don't really know.

I did. To me, an organization that wants to publish its procedures 
should do so itself. If that organization wants to duplicate those 
procedures in the RFC series, then it should do so through the ISE, not 
wasting the time of the IETF.

> makes the ISE/IETF product distinction.

My preference is not because of the distinction of the series, but in 
the review process. I am sure that, no matter how often we say "this is 
documenting current practice only", people in the IETF will want to make 
changes based on different design preferences. That is a waste of 
everyone's time.

> If it's not what he meant, then I see no value in creating a new

Agree. (Mind you, if ICANN published many procedure documents in the RFC 
series, it might be worth considering having an ICANN stream in the 
future, but that consideration is likely to cause so much consternation 
it is not worth trying.)

> IMO, what is current practice, whatever it is, ought to be in the

Fully agree.

--Paul Hoffman

---

From: manning <[email-masked]>
Date: Thu, 8 Oct 2015 17:30:00 -0700

In the past, when organizations found themselves in the same situation that ICANN seems to find itself in here (at least as outlined by yourself, below)
they have done what ICANN has done and is trying to do now, which is to pass the document on to a neutral third party for “safe keeping”.   One thing
the IETF used to do was insist that when/if such a document was remedied to its care, that it ALSO claimed change control over same.

A potential outcome here is that IETF would now insist on change control over how ICANN would manage this process going forward,  e.g. its no longer
an ICANN operational document, its an IETF process document - at which time ICANN may find that its flexibility is reduced, if it is going to be compliant 
with operational documents it initially wrote.  It has happened before.   

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2015 01:10:39 -0000

>In the past, when organizations found themselves in the same situation that ICANN seems to find itself in here
>(at least as outlined by yourself, below)

That would suggest it'd be more appropriate for the independent
stream, wouldn't it?

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 8 Oct 2015 21:31:19 -0400

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

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

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

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

---

From: David Conrad <[email-masked]>
Date: Thu, 8 Oct 2015 18:45:43 -0700

Suzanne,

> (Jonne Soininen is the current liaison manager, cc'd).

Jonne's email address looks suspiciously like Andrew's :)

> This sounds like you'd be OK with publishing the document as an Informational RFC,

Yes.

> mod making sure it's accurate as a current description,

Most important and prerequisite to the above.

> and you don't much care which document stream does it-- correct?

Don't have an opinion as the only thing I know about streams is that crossing them is "bad".

Regards,
-drc

---

From: manning <[email-masked]>
Date: Thu, 8 Oct 2015 19:25:04 -0700

perhaps…  I think (well it used to work this way) that regardless of HOW it comes under IETF purview, once it does,
it is no longer under the change control of the submitting organization. 

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

On 8October2015Thursday, at 18:10, John Levine <[email-masked]> wrote:

>> they have done what ICANN has done and is trying to do now, which is to pass the document on to a neutral third
>> party for �safe keeping�.   One thing

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 09 Oct 2015 07:41:38 -0400

On 8 Oct 2015, at 22:25, manning wrote:

> perhaps…  I think (well it used to work this way) that regardless of 
> HOW it comes under IETF purview, once it does,

I think this is a bit of a red herring.

When we published RFC 7108 as an independent submission there was no 
suggestion that the IETF expected to wield change control over the 
operations of L-Root. The process involved the ISE reaching out for 
multiple independent reviews and, once satisfied, pushing it upstream. 
My impression is that there was a desire that the document be clear and 
accurate, but no ambition to moderate its content more generally.

The only outcome I can see if we tried the same approach with 
dnssec-trust-anchor is that we will want future mechanisms for trust 
anchor publication (since the current mechanisms can, should and surely 
will be improved) we will want mention of them also to appear in the RFC 
series, updating or obsoleting the earlier guidance as appropriate.

That successor document could contain the revised guidance within its 
pages, or it could provide a stable reference to wherever the revised 
guidance now lives. Either way this doesn't seem like much of an 
inconvenience.

Aside from the motivation to provide a useful technical specification in 
a place where it can be easily found, I continue to feel that it is 
important that significant infrastructural elements of the Internet be 
described in the RFC series, even if they don't contain IETF working 
group output. This is our historical record. We would be doing a 
disservice to future enquiring minds if we chose to do otherwise.

Joe

---

From: manning <[email-masked]>
Date: Fri, 9 Oct 2015 09:20:20 -0700

On 9October2015Friday, at 4:41, Joe Abley <[email-masked]> wrote:

> When we published RFC 7108 as an independent submission there was no suggestion that the IETF expected to wield change control over the operations of L-Root. The process involved the ISE reaching out for multiple independent reviews and, once satisfied, pushing it upstream. My impression is that there was a desire that the document be clear and accurate, but no ambition to moderate its content more generally.
> 
> The only outcome I can see if we tried the same approach with dnssec-trust-anchor is that we will want future mechanisms for trust anchor publication (since the current mechanisms can, should and surely will be improved) we will want mention of them also to appear in the RFC series, updating or obsoleting the earlier guidance as appropriate.
> 
> That successor document could contain the revised guidance within its pages, or it could provide a stable reference to wherever the revised guidance now lives. Either way this doesn't seem like much of an inconvenience.
> 
> Aside from the motivation to provide a useful technical specification in a place where it can be easily found, I continue to feel that it is important that significant infrastructural elements of the Internet be described in the RFC series, even if they don't contain IETF working group output. This is our historical record. We would be doing a disservice to future enquiring minds if we chose to do otherwise.
> 
> 
> Joe
> 

If true, then this is a swing back to “old school” IETF thinking and RFC editor function… which is (IMHO) an outcome to be devoutly wished.  
It does beg the question however, why is this even being discussed in an IETF WG if its not expected to be IETF WG product?   

/Wm

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 09 Oct 2015 12:30:03 -0400

On 9 Oct 2015, at 12:20, manning wrote:

>> Aside from the motivation to provide a useful technical specification 
>> in a place where it can be easily found, I continue to feel that it 
>> is important that significant infrastructural elements of the 
>> Internet be described in the RFC series, even if they don't contain 
>> IETF working group output. This is our historical record. We would be 
>> doing a disservice to future enquiring minds if we chose to do 
>> otherwise.
>
> [...]
>
> It does beg the question however, why is this even being discussed in 
> an IETF WG if its not expected to be IETF WG product?

My assumption was that there's value in awareness in this venue, and 
that any competent shepherd will require positive indications of review 
from the relevant technical community, and this is it. Apologies if 
people feel differently, though; despite appearances to the contrary, 
I'm not simply on a mission to drown everybody in mail.

Following discussion here and off-list with various people, it seems 
clear to me that the best path forward for this document is the 
independent submission stream. This worked well for 7108 which is 
similar to this document in various respects.

So to clear up the lingering ambiguity, the authors are not requesting 
adoption of this document by the working group; we'll pick it up with 
the ISE. I will be bothering those who have demonstrated an opinion in 
due course for reviews for Nevil.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Oct 2015 15:08:32 -0400

On Fri, Oct 09, 2015 at 07:41:38AM -0400, Joe Abley wrote:
> operations of L-Root.

Independent submissions are not IETF products.  I think that's what
Bill (and Paul, for that matter) are talking about.

> dnssec-trust-anchor is that we will want future mechanisms for trust anchor
> publication (since the current mechanisms can, should and surely will be
> improved) we will want mention of them also to appear in the RFC series,
> updating or obsoleting the earlier guidance as appropriate.

Those sound like "should be IETF products" in a way that the current
case doesn't.  I still think this is all an artificial and distracting
distinction, but Bill and Paul are right that if you're just trying to
publish "here's how we do it" without any helpful changes from the
IETF the ISE is the way to handle the document.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Oct 2015 15:13:27 -0400

On Fri, Oct 09, 2015 at 12:30:03PM -0400, Joe Abley wrote:
> adoption of this document by the working group; we'll pick it up with the
> ISE.

For whatever it's worth, I think this outcome shows that the IETF is
no longer able to take uncontroversial descriptions of what people are
doing them and process them with anything like the dispatch they
deserve.  I think that's unfortunate and is another symptom of the
IETF losing its relevance to the wider Internet, which is just going
to go off without us if we cannot handle what is happening there.

Best regards,

A (emphatically, speaking for myself only)

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 09 Oct 2015 12:25:26 -0700

Andrew Sullivan wrote:
> ...
>
> For whatever it's worth, I think this outcome shows that the IETF is no longer able to take uncontroversial descriptions of what people are doing them and process them with anything like the dispatch they deserve. I think that's unfortunate and is another symptom of the IETF losing its relevance to the wider Internet, which is just going to go off without us if we cannot handle what is happening there.

if i had sought IETF help with DLV, we might have a problem statement
final draft by now, instead we're finally killing it having learned
everything and done everything we needed to learn and do.

when david ulevitch created the "afasterinternet.com" web site i thought
he was just being cheeky. no longer. he needed client-subnet for his
business, that year, not this year. i didn't and still don't like that
protocol and i fear its long term implications, but i understand why he
did it the way he did it.

those of you who witnessed the failed DNS MODA effort, or the successful
RRL or RPZ efforts, now know my thinking.

when randy bush started referring to IETF as the IVTF (V = Vendor), i
thought he was just being cranky. no longer.

internet protocol development should look nothing like today's IETF or
today's W3C, and instead become like the XMPP Standards Foundation
(https://en.wikipedia.org/wiki/XMPP_Standards_Foundation).

some soul-searching may be required. "stop helping me so hard, damn it."

-- 
Paul Vixie

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 9 Oct 2015 15:58:35 -0400

On Oct 9, 2015, at 12:30 PM, Joe Abley <[email-masked]> wrote:

> My assumption was that there's value in awareness in this venue, and that any competent shepherd will require positive indications of review from the relevant technical community, and this is it. Apologies if people feel differently, though; despite appearances to the contrary, I'm not simply on a mission to drown everybody in mail.

Please note for the record that the chairs supported this course of action.

This wasn't the first time that WG discussion seemed useful for a document that would benefit from review in the WG even though not a WG document. It will not, I hope, be the last.

> So to clear up the lingering ambiguity, the authors are not requesting adoption of this document by the working group; we'll pick it up with the ISE. I will be bothering those who have demonstrated an opinion in due course for reviews for Nevil.

This sounds like the right course of action to me from what we've seen here.

thanks,
Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 9 Oct 2015 17:49:01 -0400

(no hats)

On Oct 9, 2015, at 3:25 PM, Paul Vixie <[email-masked]> wrote:

> no longer. he needed client-subnet for his

I think client-subnet was actually an interesting example of several things.

When it was originally brought to the IETF, people didn't like it, so it didn't get through the WG (DNSEXT?). The Options registry policy at the time was, I think, Standards Action, so they couldn't get an IANA-registered codepoint, either.

As Paul points out, they wrote their technology and started using it anyway.

The registry policy was changed, partly because of cases like this, to Expert Review, and a codepoint was requested, without an RFC. It was granted, so the technology could be extended by the use of a registered codepoint.

The original authors of the draft came back to the DNSOP chairs and expressed an interest in documenting the protocol anyway. We encouraged them to do that-- we figured that since there's a properly registered codepoint, and the technology is in use even though DNSEXT five years ago didn't like it, documented is better than not.

The current client-subnet document describes the technology currently in use, and suggests that the protocol could be revised, in light of experience, to work better, including making it easier for clients to opt out.

I would hope that when that protocol revision is undertaken that the authors will be willing to document it in the IETF, and that they get the review they need to help them make a better protocol.

If we succeed, there will be a better protocol, and review in the IETF will be part of why it's better, and it will be documented in an RFC.

If we fail, there may or may not be a better protocol, but the IETF will have nothing to do with it, and it may never be documented in an RFC. 

I'd like to see the first option happen. I think it's entirely possible, and will do what I can to enable it. 

Suzanne

---

From: Richard Lamb <[email-masked]>
Date: Sat, 31 Oct 2015 18:36:11 +0000

Given that there are least three implementations based on this draft in widespread use, IMHO, I believe this draft should move forward as is.  As mentioned below, a stable reference would be useful for implementers like myself. -Rick

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of W.C.A. Wijngaards
Sent: Tuesday, October 6, 2015 1:53 AM
To: [email-masked]
Subject: Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>

Hi,

> interest in the DNSSEC root trust anchor.

It documents a procedure we implemented, and a stable reference would be a good thing.

> meet that need more effectively?

Unbound implements the draft in open source, in its own command-line tool 'unbound-anchor'.  It combines a compiled-in root-anchor, with
RFC5011 rollover and this draft.  At the first start it has failover over from the initial anchor to the next option, and this draft is the fallback.  On subsequent invocations it keeps state, a rolling anchor that it keeps track of.  If RFC5011 tracking fails, it uses this draft to fetch the xml file with the new key.  The tool is organisation-agnostic and can also be configured to perform the same mechanics in another environment (eg. test environments).

Best regards, Wouter

---

From: Mehmet Akcin <[email-masked]>
Date: Sat, 31 Oct 2015 11:45:01 -0700

This is a good suggestion. I support it.

Mehmet

On Saturday, October 31, 2015, Richard Lamb <[email-masked]> wrote:

> Given that there are least three implementations based on this draft in
> widespread use, IMHO, I believe this draft should move forward as is.  As
> mentioned below, a stable reference would be useful for implementers like
> myself. -Rick
>
>
> From: DNSOP [mailto:[email-masked] <javascript:;>] On Behalf Of
> W.C.A. Wijngaards
> To: [email-masked] <javascript:;>
> Subject: Re: [DNSOP] Expiration impending:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> > On Oct 5, 2015, at 5:20 PM, "Joe Abley" <[email-masked]
> <javascript:;>>
> > wrote:
> >>
> Unbound implements the draft in open source, in its own command-line tool
> 'unbound-anchor'.  It combines a compiled-in root-anchor, with
> RFC5011 rollover and this draft.  At the first start it has failover over
> from the initial anchor to the next option, and this draft is the
> fallback.  On subsequent invocations it keeps state, a rolling anchor that
> it keeps track of.  If RFC5011 tracking fails, it uses this draft to fetch
> the xml file with the new key.  The tool is organisation-agnostic and can
> also be configured to perform the same mechanics in another environment
> (eg. test environments).
>
> Best regards, Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWE4vbAAoJEJ9vHC1+BF+NxPMQAIAmFaUaF6ZKQvzMLZ+yAuDm
> 66MaTO2i68q6LH3ZHCEl6dXMz3sGL+8RaKCN1IK6EyvXUIoCaulkJdbem4MeFsGk
> /w1Bxxfybgao5+pBPd3Ciz6caYfMHrfkqFL7broBsCLNBlfwVUEUPBJpfYQbF8i+
> TQaqyGm/oH2VPtFq03HL/o/CJUgbZNQWT1CKdzEEuoyrmyotzXQkfsnXrW79t/hW
> tt8Aeq5VSHpBbkSlrq8EYDunhjwQKgJwhx/YUVpqF/JrjO7KDqzO7QabYY4i1h95
> LTdcZmrWUfKSPnzN0lD3MSmSvJMMgz18VBXQLO2cHj0QDaDFd9pe0mud0em9gIPz
> hLhyWvbxeNasT8CbH5vwJ77p/6xmhMsYT4C2EHtJacPmG9Y4BfUDyo1d0hec0eF5
> uLmpbp+TCicd3dHNNcIPWjDcxyCT7lTNOLPS78fSOhdju2khijn9b7RPnTqjtmUV
> Wf8IIYnN0fIapymNsiNXqarV3uC8ly7XhnqK+XQ6z7KgArh/OkrFcGiJAcHn1wlr
> mSkSKeeGpF8snSlbnMX9+Y9TvBCFrNOP+awzDvKqBnV3yS5Cu2bPottH9Yp/xs96
> E36eMwX35WUuh7uOCKR4IswpjChds0jSW75oJ6GYb9ItLfy6ehuGbyUFD2AW130y
> SrOmADZfr8SG6aGxUokH
> =4snr
> -----END PGP SIGNATURE-----
>
> [email-masked] <javascript:;>
> [email-masked] <javascript:;>