[DNSOP] Moving parent-child-update documents forward

Dan York <dan-ietf@danyork.org> Wed, 06 November 2013 13:50 UTC

Return-Path: <dan-ietf@danyork.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305CC11E821E for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2013 05:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+Vdmg3MrKig for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2013 05:49:55 -0800 (PST)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 923D411E81F0 for <dnsop@ietf.org>; Wed, 6 Nov 2013 05:49:55 -0800 (PST)
Received: by mail-vc0-f177.google.com with SMTP id ib11so6473226vcb.8 for <dnsop@ietf.org>; Wed, 06 Nov 2013 05:49:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=V3tkVxuvphB5wUdAvp/+l+aZ0sI88Qcie08NNgEym3Q=; b=EK44QEKitLrMYirs9W7admTQeJnRlM5Bp5FXYS+y9P8KITWUtrFo+FEhZTkL9F/yVO k2XiPkeHVKyEwEVEOZSlzpnMeZrn1mQ0xgOIIUj4DyxhHUi/3XnYwAg27XUrH/fLOl7W uPGICp1YmV/GcRmbtiYOQ5I3tgMnjXVUKOnkW3gmm30G4/0tNe6Y/XcezRlJqMutlkjK F8U40rO5zEst/uNGzO3U/UvJKUvxW7icXBi7ORpw/TXCLEY0jevdq5XZ0ENh0DBHv+Eh b1eLlGiNChmUQgUxME/tlZO4maS8cnEUnOqY2qC3xrlTuq+iLrU/5bJFEaaK9hBVOxVF o+kg==
X-Gm-Message-State: ALoCoQlFSbEpQt2xy42QmsayjN0jnXbR1WzGfyxCkO1HqmwXLW0F1wrQVPA9jn2C25NShtK9kvKq
MIME-Version: 1.0
X-Received: by 10.58.44.72 with SMTP id c8mr12072vem.37.1383745794943; Wed, 06 Nov 2013 05:49:54 -0800 (PST)
Received: by 10.58.251.70 with HTTP; Wed, 6 Nov 2013 05:49:54 -0800 (PST)
X-Originating-IP: [31.133.144.251]
Date: Wed, 06 Nov 2013 05:49:54 -0800
Message-ID: <CANdQK6Z6AD8RAkatTm=uzDzsBVNmQkbT5K=E9jaa0D5qagdHWA@mail.gmail.com>
From: Dan York <dan-ietf@danyork.org>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="089e013cc1fc91492a04ea826cae"
Subject: [DNSOP] Moving parent-child-update documents forward
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Nov 2013 13:50:00 -0000

Peter & Tim,

Unfortunately we ran out of time in the DNSOP session yesterday and I don't
feel we left with a plan to move forward on the various
"parent-child-update" documents and scenarios.  However I think it is
*critical* that we DO move forward with these documents as this issue is
one of the big barriers for smoother operation of DNSSEC.

I think there was a strong sense in the room that we definitely need to
work on this overall issue and I think at the end we were getting hung up
on some process points (and I admit that *I* was contributing to that
confusion)... and then we simply ran out of time.

What do you see as a path forward here?  How can we progress these
documents?

The point I was trying to make in the final minutes was that we need
something *more* than just these documents to help get these solutions
actually out there and deployed.  I think we need to provide operational
guidance to registrars and registries on the different mechanisms for
updating these type of DNS records and explain the options that we have
available.  We need to make it easy for them to understand how the
mechanisms fit together and can be used in different situations.

But I think that kind of document can be written separately from moving the
other documents forward (and yes, I'm willing to help with text and not
just say that "someone" should write a doc).

I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as working
group documents and continue to move them along - we've had significant
discussion on these over the past several meetings and also on the lists:

http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
http://tools.ietf.org/html/draft-hardaker-dnsop-csync-01

Similarly, I think Mark's draft could be another one to consider adopting
for situations where people want to operate the push-style model:

http://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-00

I think we need some more discussion on that document before we adopt it (I
haven't seen any on the list, or did I miss it?) but I don't see any issue
with ALSO having a document like it as a working group document.  There
will be multiple models for different situations.

Additionally, I think Paul's document on use cases is one that we should be
bringing back into circulation (thanks, Matthijs, for the pointer after
Paul mentioned it yesterday):

http://tools.ietf.org/html/draft-wouters-dnsop-secure-update-use-cases-00

Anyway - I think we do need to move this whole area of work forward as
rapidly as we can.

My 2 cents,
Dan

--
Dan York, dan-ietf@danyork.org
http://danyork.me   http://twitter.com/danyork