Re: [DNSOP] New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt

[Antoin Verschuren <[e-mail]>]

Hi Matt,

I cannot help noticing that draft-pounsett-transferring-automated-dnssec-zones is providing the same solution as an earlier draft draft-koch-dnsop-dnssec-operator-change.
This draft has already gone through a review process, and is considered to be done content wise by the authors.

The reason why draft-koch-dnsop-dnssec-operator-change has never made it to WG adoption in DNSOPS is because of IPR that is now also targeting your draft.
There is currently discussion on this IPR on the REGEXT mailinglist because draft-ietf-eppext-keyrelay, which is the standardization of the provisioning parameters for this secure operator change concept is stalled for a long time as well because of this IPR.

Can I ask you how your draft is different from draft-koch-dnsop-dnssec-operator-change to justify a new attempt?
Wouldn’t the IPR pose the same adoption issues as draft-koch-dnsop-dnssec-operator-change?

The authors of draft-koch-dnsop-dnssec-operator-change are willing to revive the draft and ask for WG adoption by DNSOPS as well.
As co-author of that draft and the original inventor of the secure dns-operator change method, I’m open to see how that draft can be improved by your attempt, and see if we could work together to get this concept described in an Informational RFC.

draft-ietf-eppext-keyrelay is stalled in IESG review for 328 days now, and I wouldn’t want the DNSOPS WG to waste the same time while the IPR issue is not resolved.
Instead, I think it would be wise to jointly address both the Informational concept description and provisioning solution and if members of DNSOPS have any input to the IPR discussion on the REGEXT mailinglist, I would invite them to contribute.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: [phone]






Op 31 okt. 2016, om 04:49 heeft Matthew Pounsett <[e-mail]> het volgende geschreven:

> Hi all.
> 
> I've submitted an update for the below draft which I'd like the working group to eventually consider for adoption.  If there's time in the agenda, I'd like to ask the chairs for some time to discuss this in Seoul.
> 
> As with the previous version, I'm looking for some specific feedback on a few things.
> 
> 1) I believe this draft represents operational experience that could be added to RFC6781.  While it doesn't (intentionally) change anything in 6781, I think the additional operator change procedure justifies the "updates" meta-data in the draft.  With the increase in gTLDs and the expected future increase in gTLD transfers I think it's important to put this information in front of operators searching for advice, which makes having it appear as a link from the 6781 meta-data important.  I'd like to get the group's feeling on that.
> 
> 2) RFC 6781 does not explicitly describe the timings of each step in the operator change procedure, leaving that as an exercise for the reader to obtain by reading earlier sections of the RFC.  The -01 version of this draft followed that style for a couple of reasons: first, so as not to unnecessarily duplicate any information; second, to avoid unintentionally introducing any ambiguity or update to the information in 6781.  I've been of two minds on that, however.  I felt that the aim of this draft–to provide advice to inexperienced operators–was not well served by leaving a prose description of the procedure out.  With the recent publication of errata for § 4.1.2, my opinion has tipped slightly the other way, and so I've added text to describe the steps and their timings.
> 
> 3) I don't believe this draft raises any *new* security considerations, so I've done my best to incorporate by reference the security considerations from 6781.  I'd like to know your thoughts on this as well.
> 
> 
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: 30 October 2016 at 23:29
> Subject: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt
> To: Matthew Pounsett <[e-mail]>
> 
> 
> 
> A new version of I-D, draft-pounsett-transferring-automated-dnssec-zones-02.txt
> has been successfully submitted by Matthew Pounsett and posted to the
> IETF repository.
> 
> Name:           draft-pounsett-transferring-automated-dnssec-zones
> Revision:       02
> Title:          Change of Operator Procedures for Automatically Published DNSSEC Zones
> Document date:  2016-10-31
> Group:          Individual Submission
> Pages:          7
> URL:            https://www.ietf.org/internet-drafts/draft-pounsett-transferring-automated-dnssec-zones-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-pounsett-transferring-automated-dnssec-zones/
> Htmlized:       https://tools.ietf.org/html/draft-pounsett-transferring-automated-dnssec-zones-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pounsett-transferring-automated-dnssec-zones-02
> 
> Abstract:
>    Section 4.3.5.1 of [RFC6781] "DNSSEC Operational Practices, version
>    2" describes a procedure for transitioning a DNSSEC signed zone from
>    one (cooperative) operator to another.  The procedure works well in
>    many situations, but makes the assumption that it is feasible for the
>    two operators to simultaneously publish slightly different versions
>    of the zone being transferred.  In some cases, such as with TLD
>    registries, operational considerations require both operators to
>    publish identical versions of the zone for the duration of the
>    transition.  This document describes a modified transition procedure
>    which can be used in these cases.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop