Re: [DNSOP] (no subject)

Antoin Verschuren <antoin.verschuren@sidn.nl> Mon, 14 April 2014 08:04 UTC

Return-Path: <Antoin.Verschuren@sidn.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EC61A038E for <dnsop@ietfa.amsl.com>; Mon, 14 Apr 2014 01:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.522
X-Spam-Level: **
X-Spam-Status: No, score=2.522 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JHqzxYn7foy for <dnsop@ietfa.amsl.com>; Mon, 14 Apr 2014 01:04:39 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id B21F21A0397 for <dnsop@ietf.org>; Mon, 14 Apr 2014 01:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=b5/LZKfeSr2FP8rThRJsTnDAjSiNtCc9Z5lF7IFfcJ4=; b=g+2IYZKMC5FwUzqEzXCVixnDjwAbpjeuaJU13S4Mjs9Seg/1dz8cXz6ShV7VDWOOnc4n3CgnpwwMuuoYirDyXiUBeG0EHhH7V8ntfChfFXT3jrtRX+UNk1d1/d/ONp9kFmpno11p9cmbN/LtiFaV7tpWF2JLtb7KfG/zF7Yn9rY=
Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id s3E84ZBN004778-s3E84ZBP004778 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL) for <dnsop@ietf.org>; Mon, 14 Apr 2014 10:04:35 +0200
Received: from [94.198.152.220] (94.198.152.220) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 14 Apr 2014 10:04:34 +0200
Message-ID: <534B9691.5020104@sidn.nl>
Date: Mon, 14 Apr 2014 10:04:33 +0200
From: Antoin Verschuren <antoin.verschuren@sidn.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <CAHw9_iK6zL4fDVzC795Cq8FDxdE3THhLLkDDUPRZEjqcz70mNQ@mail.gmail.com>
In-Reply-To: <CAHw9_iK6zL4fDVzC795Cq8FDxdE3THhLLkDDUPRZEjqcz70mNQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.198.152.220]
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/MCkkOs_uVUyF98g960DFYpHFU3w
Subject: Re: [DNSOP] (no subject)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 08:04:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

op 11-04-14 23:12, Warren Kumari schreef:
> 
> Can folk please let us know if they would prefer: A: The child
> SHOULD remove the CDS/CDNSKEY RR from the zone once the parent has
> published it (currently documented behavior) or
> 
> B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a 
> small edit to the doc)

I can remember the arguments against leaving them in the zone. They were:

- -Leaving them in the zone makes the zone larger for a longer period of
time, consuming more memory and bandwith for master-slave transfers. I
think this is only minor, but it is an argument.

- -Zones that do not support CDNSKEY/CDS don't have those records in the
zone as well, so a provision by the server what to do in absence of
the records should be made anyway for backward compatibility.

- -If a zone is transfered to an operator not (yet) supporting
CDNSKEY/CDS, what's the procedure for removing the records from the
zone if they were compulsary?

That's why we concluded that it was not compulsory to leave them in
the zone, or even have them in the zone, but no harm should be done if
people left them in the zone.

I think the current text assumes people should allways remove the
records. That I think is wrong. The text should say:

- -It's ok to leave the records in the zone.

- -It's also ok to take the records out of the zone, but if you do so,
please follow these rules about the order to take them out: State rules.

Because the procedure HOW to take the records out consumes more text,
it looks like that's the standard procedure, but it isn't. That should
be made more clear. Both leaving them in and taking them out are ok
with me. So the text I would go with would be:

C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
parent has published it, and this is how to do that safely.


- -- 
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: antoin.verschuren@sidn.nl
XMPP: antoin.verschuren@jabber.sidn.nl
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJTS5aRAAoJEDqHrM883AgnkmkH+gINnriK4+jXSt60Fxv5RCSB
s5HlL+D5ddfI9yq25p1Y/D438bqsSzOhiAufh3c9FVOmS36rTC3VJO2S5AcTLcOx
IiCAI1yZW8zft6JEDGvz8ZGz/oA0lHuxIhrZLbMIGwDN4NPcAMOVsn/WbRrZ/7Eg
ibrNrJ5ws87CzVyLIe0R6+ZQ/x65vyryai/Oq2plK6wXmmPPQPz5rw+da3qD2HI2
3b5VeIAGuo4TRgPZbF4Byo6BILZynTN0y5WQxzlTfX0OsRMQIdKQp3/C++uXCSTl
4kULKymoa6qjNuaxfBz3zuo+yQjdOv50iX0ULxx+GBC151iiTWD0bjJMggKSxhE=
=rHOE
-----END PGP SIGNATURE-----