Re: [DNSOP] [Technical Errata Reported] RFC6781 (4844)

All,

The new text looks good to me.

Best regards,
   Matthijs

On 26-10-16 10:59, RFC Errata System wrote:
> The following errata report has been submitted for RFC6781,
> "DNSSEC Operational Practices, Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6781&eid=4844
>
> --------------------------------------
> Type: Technical
> Reported by: Marcos Sanz <sanz@denic.de>
>
> Section: 4.1.2
>
> Original Text
> -------------
>    initial:  Initial version of the zone.  The parental DS points to
>       DNSKEY_K_1.  Before the rollover starts, the child will have to
>       verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
>       it is needed during the rollover, and we refer to the value as
>       TTL_DS.
>
>    new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>       generates a second KSK, DNSKEY_K_2.  The key is provided to the
>       parent, and the child will have to wait until a new DS RR has been
>       generated that points to DNSKEY_K_2.  After that DS RR has been
>       published on all servers authoritative for the parent's zone, the
>       zone administrator has to wait at least TTL_DS to make sure that
>       the old DS RR has expired from caches.
>
>    DS change:  The parent replaces DS_K_1 with DS_K_2.
>
> Corrected Text
> --------------
> initial:  Initial version of the zone.  The parental DS points to
>     DNSKEY_K_1.  Before the rollover starts, the child will have to
>     verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
>     it is needed during the rollover, and we refer to the value as
>     TTL_DS.  Also, we refer to the TTL value of the DNSKEY_K_1 RR as
>     TTL_DNSKEY.
>
> new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>     generates a second KSK, DNSKEY_K_2.  The new DNSKEY RRSet that
>     includes DNSKEY_K_2 is published at the child.  After waiting at
>     least TTL_DNSKEY, DNSKEY_K_2 (or the DS RR generated from it, that
>     is DS_K_2) is provided to the parent.
>
> DS change:  The parent replaces DS_K_1 with DS_K_2.  After that DS RR
>     has been published on all servers authoritative for the parent's
>     zone, the zone administrator has to wait at least TTL_DS to make
>     sure that the old DS RR has expired from caches.
>
> Notes
> -----
> I just corrected what is fundamentally flawed. RFC 7583 section 3.3.1 provides a much detailed explanation of the process.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
> --------------------------------------
> Title               : DNSSEC Operational Practices, Version 2
> Publication Date    : December 2012
> Author(s)           : O. Kolkman, W. Mekking, R. Gieben
> Category            : INFORMATIONAL
> Source              : Domain Name System Operations
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>