[DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-maintain-ds-03: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Wed, 31 August 2016 14:37 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A824D12DBB3; Wed, 31 Aug 2016 07:37:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kuehlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.31.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147265426567.13340.172620262528927458.idtracker@ietfa.amsl.com>
Date: Wed, 31 Aug 2016 07:37:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Nds-jrDm4rDAERi0uBEawT5ryis>
Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-maintain-ds@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
Subject: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-maintain-ds-03: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 31 Aug 2016 14:37:46 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-maintain-ds-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One technical comment:
How does the client know that the parent supports the DNSSEC Delete
Algorithm and it actually can turn of DNSSEC after a while? What how long
is a while? Would it be possible to define a reply message from the
parent to the client to confirm that the deletion was understood?

One more or less editorial comment:
I agree with Spencer that the use of normative language in the security
section is odd. All used SHOULDs should be lower case. But I would also
recommend to rephrase to give clear guidance, e.g.

OLD:
"A parent zone might also consider sending an email to its
   contact addresses to give the child zone a warning that security will
   be enabled after a certain amount of wait time - thus allowing a
   child administrator to cancel the request."

NEW:
"A parent zone may send an email to its
   contact addresses to give the child zone a warning that security will
   be enabled after a defind amount of wait time - thus allowing a
   child administrator to cancel the request."

OR:
"A parent zone MAY send an email to its
   contact addresses to give the child zone a warning that security will
   be enabled after a defined amount of wait time - thus allowing a
   child administrator to cancel the request."