Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-syncronization-02.txt> (Child To Parent Synchronization in DNS) to Proposed Standard
Patrik Fältström <paf@frobbit.se> Sat, 09 August 2014 07:08 UTC
Return-Path: <paf@frobbit.se>
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 D9C0D1A0329; Sat, 9 Aug 2014 00:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Level:
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, 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 86UkZdCu1sC6; Sat, 9 Aug 2014 00:08:29 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8CF1A02EA; Sat, 9 Aug 2014 00:08:28 -0700 (PDT)
Received: from [192.168.0.43] (h25n18-sto-a13.ias.bredband.telia.com [81.237.133.25]) by mail.frobbit.se (Postfix) with ESMTPSA id 8C0522293B; Sat, 9 Aug 2014 09:08:25 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_EDBE67F5-7933-43AD-8C89-1DA1170FB8CE"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <20140808151621.1148.70609.idtracker@ietfa.amsl.com>
Date: Sat, 09 Aug 2014 08:59:03 +0200
Message-Id: <48F98FE4-A6A2-4787-8EDE-A6991AB9C6C5@frobbit.se>
References: <20140808151621.1148.70609.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/u7vFXOzAAg-LL0L1mOwyQrCi0rU
Cc: dnsop@ietf.org, IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-syncronization-02.txt> (Child To Parent Synchronization in DNS) to Proposed Standard
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: Sat, 09 Aug 2014 07:08:31 -0000
In general I think this is good stuff, but I do not think the document can be published yet. What I ask for I hope should be easy to fix though. 1. I see, specifically at the end, some confusion (I think) between use of "parent" and "parental agent". I.e. I think the term "parent" is in use for example when discussing out-of-balliwick NS records. 2. It is not described in detail enough how the actual queries should be sent, and allowing the parental agent to do just however they want seems kind of crazy. Either this is built upon the fact a direct query to a server is sent (i.e. not only must the response be signed and validated, but also AA flag must be set on the response) or not. If not, I want some discussion about caching implications. 3. Regarding caching, I specifically want a scenario described when a zone is moving from one DNS provider (one child) to another, and the loosing DNS provider is not cooperating. 4. A step by step example of how a child is changing NS records 5. A step by step example of how a child is changing glue 6. A step by step example of how out-of-balliwick NS records are thought to be treated (just saying they are problematic is not enough for me) I.e. a lot of what I ask for is to clarify with examples a lot of the text around 4.3. Having such text, together with a SHOULD and not MUST, will definitely not lead to interoperability. Patrik On 8 aug 2014, at 17:16, The IESG <iesg-secretary@ietf.org> wrote: > > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: > - 'Child To Parent Synchronization in DNS' > <draft-ietf-dnsop-child-syncronization-02.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies how a child zone in the DNS can publish a > record to indicate to a parental agent that it may copy and process > certain records from the child zone. The existence of and value > change of the record may be monitored by a parental agent and acted > on as appropriate. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > >
- [DNSOP] Last Call: <draft-ietf-dnsop-child-syncro… The IESG
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-sy… Warren Kumari
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-sy… Patrik Fältström
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-sy… joel jaeggli
- Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-sy… 神明達哉