Subject: [DNSOP] Final shepherding comments for draft-ietf-dnsop-delegation-trust-maintainance-10

From: Tim Wicinski <[email-masked]>
Date: Wed, 16 Apr 2014 18:58:45 -0400

https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

All

Please take a look at version -10 of this draft. I believe that the 
authors have addressed all the issues that were raised during the very 
comment period.

I believe that draft-ietf-dnsop-delegation-trust-maintainance-10 has 
reach working group consensus.  I urge folks to give it one last look 
and if there is anything you wish to raise, please raise directly, 
otherwise silence is agreement.

I want to thank all the individuals who contributed comments and feedback.

tim

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 17 Apr 2014 10:52:21 +0200

Hi,

By adding text on using this technique for bootstrapping the chain of
trust, there are some inconsistencies:

1.
In the Abstract it says:

   "This document does not address the initial configuration of
   trust anchors for a domain."

But now it does (minimally).

2.
In Section 4.1:
I would like to see a different rewording for the Signer rule to reflect
the initial enrollment scenario (see other mail). I'll repeat it here:

(unless the parent uses the CDS / CDNSKEY RRset for initial enrollment,
in that case the parent validates the CDS / CDNSKEY though some other
means (see Section 6.1 and the Security Considerations.))

3.
In Section 6.1:
Two typos: enrolment -> enrollment, delgation -> delegation.

Best regards,
  Matthijs

On 04/17/2014 12:58 AM, Tim Wicinski wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Apr 2014 09:20:10 -0700

At Wed, 16 Apr 2014 18:58:45 -0400,

> otherwise silence is agreement.

Just from a quick scan, I'm afraid this point wasn't addressed:

http://www.ietf.org/mail-archive/web/dnsop/current/msg11648.html

If it's based on a consensus that it's not worth noting, I'm fine with
that (after all, I now understand the rationale, so my comment is for
helping future readers, not me), but as far as I know there was not
even any followup/discussion on it, so I guess it was simply buried in
the volume of the recent traffic.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Apr 2014 13:08:27 -0400

> But now it does (minimally).

True.
I updated it to be "This document does not address the initial
configuration of trust anchors for a domain in depth", but that
sounded stupid, so I just yanked it out.
Thanks.

> means (see Section 6.1 and the Security Considerations.))

Thanks.

> Two typos: enrolment -> enrollment, delgation -> delegation.

Doh! I just ran spellcheck and it found a bunch of other typos too --
one day I'll learn to type...

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 18 Apr 2014 10:18:04 -0400

Thanks Matthijs and Jinmei for the final review, and Warren for the 
final edits.

I'm taking that latest version:
	https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

is the latest and apparently the last version.  I'll submit this to the 
IESG unless I hear any major protest, as we appear to be back in consensus.

tim

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 18 Apr 2014 17:06:22 +0200

op 18-04-14 16:18, Tim Wicinski schreef:
> Thanks Matthijs and Jinmei for the final review, and Warren for
> the final edits.
> 
> is the latest and apparently the last version.  I'll submit this to
> the IESG unless I hear any major protest, as we appear to be back
> in consensus.

Tim,

This isn't major protest, but just due to too little time to put my
thoughts into writing after reviewing so many changes over the last
week (sorry, I also have a day job).

On of the things I haven't reviewed thoroughly enough is the
detection/polling/pushing methods in the draft.
The way it is described now in the draft feels like "we're in a hurry
so we don't care, you might as well just push a freaky proprietary
button somewhere but we're not going to tell you which one"
I think we can do better than that.

I would have expected somebody to mention "notify" as a detection
method that I think would be of great help for the detection of
CDNSKEY/CDS changes.
I just haven't gotten around to phrasing the correct words on how
notify could be used to have a parental agent detect CNDSKEY/CDS
changes to be pulled.

But we do use examples in the draft that I think are freakier than
notify, and I feel they give too much bad advise on methods that could
be used. It's not described well enough that a detection mechanism for
CDNSKEY/CDS changes is just as important for adoption of this idea to
be automated. I think we should either mention a standardized method
in the draft, or write a separate draft on how to notify a parental
agent for CDNSKEY/CDS changes and mention that in this draft, or this
will not be widely implemented.
This based on feedback I got from registrars.

So I think the wording on detecting/pushing/polling are not clear and
unbiased enough, I just did't have time to send text.
I hope someone with more time during Easter agrees.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Apr 2014 08:46:24 -0700

> I think we can do better than that.

Maybe, but I don't. If we have a standardized version of that button, it will probably over HTTP. For that, we would need to have a discovery mechanism for "where is my parent's web site with the button", which is very hard. It is possible, and could even be signaled in the DNS with a URL RR (thank you Patrik!), but that will take a lot more discussion. I propose that if people want to do that, it be done as a update to this document.

> method that I think would be of great help for the detection of

The question is the same as above: notify whom?

> This based on feedback I got from registrars.

To me, the polling option is well-described and the most likely one to be used because it takes so much less new stuff.

--Paul Hoffman