From nobody Fri Jul 14 10:41:37 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85513144F; Fri, 14 Jul 2017 10:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bnqzVPWAiMEM; Fri, 14 Jul 2017 10:41:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F0B126CD6; Fri, 14 Jul 2017 10:41:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BA5F6B80D56; Fri, 14 Jul 2017 10:41:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dnsext@ietf.org Message-Id: <20170714174124.BA5F6B80D56@rfc-editor.org> Date: Fri, 14 Jul 2017 10:41:24 -0700 (PDT) Archived-At: Subject: [dnsext] STD 88, RFC 3596 on DNS Extensions to Support IP Version 6 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 17:41:29 -0000 RFC 3596 has been elevated to Internet Standard. STD 88 RFC 3596 Title: DNS Extensions to Support IP Version 6 Author: S. Thomson, C. Huitema, V. Ksinant, M. Souissi Status: Standards Track Stream: IETF Date: October 2003 Pages: 8 Characters: 14093 Obsoletes: RFC 3152, RFC 1886 See Also: STD 88 I-D Tag: draft-ietf-dnsext-rfc1886bis-03.txt URL: https://www.rfc-editor.org/info/rfc3596 DOI: 10.17487/RFC3596 This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This document is a product of the DNS Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jul 27 07:41:52 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF9132038 for ; Thu, 27 Jul 2017 07:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DFF9yMbmQ64e for ; Thu, 27 Jul 2017 07:41:47 -0700 (PDT) Received: from smtp123.iad3a.emailsrvr.com (smtp123.iad3a.emailsrvr.com [173.203.187.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CA0129B4C for ; Thu, 27 Jul 2017 07:41:47 -0700 (PDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9DA025772; Thu, 27 Jul 2017 10:41:46 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5D5C5574A; Thu, 27 Jul 2017 10:41:41 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-96-255-4-80.washdc.fios.verizon.net [96.255.4.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 27 Jul 2017 10:41:46 -0400 From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_75186491-4E2B-4E54-BCC6-B2C9F1C0DED4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Jul 2017 10:41:41 -0400 References: Cc: Alain.Durand@icann.org, ray@isc.org To: dnsext@ietf.org Message-Id: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 14:41:50 -0000 --Apple-Mail=_75186491-4E2B-4E54-BCC6-B2C9F1C0DED4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Colleagues=20 The RRType experts received the application below,=20 I have been selected as the expert, after reviewing the application it = meets all criteria for acceptance.=20 This message is to solicit any reasons that the applications should not = be accepted.=20 The last day for comment on the application is August 8=E2=80=99th.=20 Any reports of implementations experience would be helpful.=20 Olafur > Begin forwarded message: >=20 > From: Ray Bellis > Subject: [dns-rrtype-applications] New RR Application - DOA > Date: July 25, 2017 at 11:41:43 AM EDT > To: dns-rrtype-applications@ietf.org >=20 > Please find attached an RR application template for the "DOA" RR type. >=20 > The link to the I-D describing the RR is: >=20 > = >=20 > I am obviously recusing myself from evaluation of this application :) >=20 > Please address any questions to both authors of the I-D. >=20 > Ray > _______________________________________________ --Apple-Mail=_75186491-4E2B-4E54-BCC6-B2C9F1C0DED4 Content-Type: multipart/mixed; boundary="Apple-Mail=_18A01689-D1B4-4230-960B-8DCC7D36775B" --Apple-Mail=_18A01689-D1B4-4230-960B-8DCC7D36775B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Colleagues 
The RRType experts = received the application below, 
I have been = selected as the expert, after reviewing the application it meets all = criteria for acceptance. 

This message is to solicit any reasons = that the applications should not be accepted. 
The last day for comment on the application is August = 8=E2=80=99th. 

Any reports of implementations experience would be = helpful. 

Olafur


Begin forwarded message:

From: = Ray Bellis <ray@bellis.me.uk>
Subject: = [dns-rrtype-applications] New RR Application - DOA
Date: = July 25, 2017 at 11:41:43 AM = EDT
To: = dns-rrtype-applications@ietf.org

Please find attached an RR application template for the "DOA" = RR type.

The link to the I-D describing the = RR is:

<https://www.ietf.org/internet-drafts/draft-durand-doa-over-dns-= 02.txt>

I am obviously recusing = myself from evaluation of this application :)

Please address any questions to both authors of the I-D.

Ray
= --Apple-Mail=_18A01689-D1B4-4230-960B-8DCC7D36775B Content-Disposition: attachment; filename=template.txt Content-Type: text/plain; x-unix-mode=0644; name="template.txt" Content-Transfer-Encoding: 7bit A. Submission Date: 2017-07-25 B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [X] Data RR [ ] Meta-RR C. Contact Information for submitter (will be publicly posted): Name: Ray Bellis Email Address: ray@isc.org International telephone number: +1 650 423 1423 Other contact handles: D. Motivation for the new RRTYPE application. Please keep this part at a high level to inform the Expert and reviewers about uses of the RRTYPE. Most reviewers will be DNS experts that may have limited knowledge of your application space. The proposed RR is a data RR that facilitates an implementation of an architecture similar to the Digital Object Architecture (DOA) within the DNS. Small objects may be contained directly within the RR, or the RR can contain a reference to the object's location (e.g. via a URL or Handle System handle). E. Description of the proposed RR type. This description can be provided in-line in the template, as an attachment, or with a publicly available URL. See draft-durand-doa-over-dns-02 NB: Whilst further updates to the draft text are likely, the RR format is considered stable. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? No existing RRTYPE fills that need. G. What mnemonic is requested for the new RRTYPE (optional)? Note: If a mnemonic is not supplied, not allowed, or duplicates an existing RRTYPE or CLASS mnemonic, the Expert will assign a mnemonic. The request mnemonic is "DOA". H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new subregistry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. Two subregistries are created, with initial contents and modification procedures described in the aforementioned I-D. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No changes or special processing are required. J. Comments: --Apple-Mail=_18A01689-D1B4-4230-960B-8DCC7D36775B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________

--Apple-Mail=_18A01689-D1B4-4230-960B-8DCC7D36775B-- --Apple-Mail=_75186491-4E2B-4E54-BCC6-B2C9F1C0DED4-- From nobody Thu Jul 27 08:13:39 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBC0129A96 for ; Thu, 27 Jul 2017 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bXfSP2CE6_wN for ; Thu, 27 Jul 2017 08:13:36 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021F2127869 for ; Thu, 27 Jul 2017 08:13:36 -0700 (PDT) Received: from [46.227.151.81] (port=54169 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dakTk-0003h2-5H (Exim 4.72) for dnsext@ietf.org (return-path ); Thu, 27 Jul 2017 16:13:32 +0100 To: dnsext@ietf.org References: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> From: Ray Bellis Message-ID: <82315b27-eff5-81a1-0322-c94d918afe11@bellis.me.uk> Date: Thu, 27 Jul 2017 16:13:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 15:13:38 -0000 On 27/07/2017 15:41, Olafur Gudmundsson wrote: > Any reports of implementations experience would be helpful. ISC has implemented the DOA RR in our development version of BIND9 per the format described in draft-durand-doa-over-dns-02 (albeit using a private RR code until such time as this application is approved and a code allocated) Ray From nobody Thu Jul 27 09:05:10 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9212EC4B for ; Thu, 27 Jul 2017 09:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 06panEt4mLvV for ; Thu, 27 Jul 2017 09:05:07 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E551E131CE4 for ; Thu, 27 Jul 2017 09:05:06 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h199so84830619ith.0 for ; Thu, 27 Jul 2017 09:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vrFLDDXvRchiBprHh7/6o3vTCyQDydaPSKilefdPL+g=; b=fEnNmul/i9u4UmPtYdm0M4HTtLEZ+AWBQ/gBO3hX0RHnGS2UstMtMiBSgZlc79/0MI iWxEwkiM73o0RDRK/ObCpsFNgAgb87lf56B8K/cESIf8vxBgYQ12dPA09VdpzKZntIQr BmXiq2v8ss2EA4D6MixmmYWX/t+wauPHrkCVLkiQ5a4/efYjiQJTYWyQTCv9v1NgnuyY lZ/M/XR660etPM4OqX/FJFjWIaYv6JN3uOcrOqOEYRDl3/ewcquiKvCtKQMc/EsyRMGq oAUQu8n9KnHILWDseuXyFzLTeroMcK7pJLLXU0p4FEUlkbxSxDEmSIt/a5LGsqVVt9/U 9bDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vrFLDDXvRchiBprHh7/6o3vTCyQDydaPSKilefdPL+g=; b=rsCeBVTIRG8FGIsJuttTU1saSfVxfDDkmxyBwbZNOu/luIGH8BWnOTHykgvclCxIoX 3YirJKl2E8ZMn53EYa4/qgakp6t0ZjpVIgPyJonHFybOgk1wFI8bcljucAgkd4w1SB4V tp2M4Oywpq5Bryt1sQTW7CGd9pOWnVlyC6s66X/qRc007yNotaCyVl6d3t84v4q7Dlvw z1DHLY/eZv9OwAUdTLuTC4BiOcGsBm6YZlwiRAM9P6B0Riej5e5ON7k8VdNNiLusb9G7 30hmPZvgT19ckkwGQBIUvvItWKwjslBbANZPGj3S41XCkUt6r1TxxB2bfodBfhVy1Pls I/ug== X-Gm-Message-State: AIVw112nicYJvatPRWigGoN+BiyAfh+oOSIMpSnamqZhW8h0nlUujxUu 6iJ8RBKeCGyqIyBJHi8vRAfqlVQV8A== X-Received: by 10.36.166.76 with SMTP id r12mr5241321iti.158.1501171506243; Thu, 27 Jul 2017 09:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.84.2 with HTTP; Thu, 27 Jul 2017 09:04:50 -0700 (PDT) In-Reply-To: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> References: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> From: Donald Eastlake Date: Thu, 27 Jul 2017 12:04:50 -0400 Message-ID: To: Olafur Gudmundsson Cc: IETF DNSEXT WG , Alain Durand , ray@isc.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 16:05:08 -0000 When ever I see DOA, I think "Dead On Arrival" but I don't have any good short alternative to suggest... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Thu, Jul 27, 2017 at 10:41 AM, Olafur Gudmundsson wrote: > Dear Colleagues > The RRType experts received the application below, > I have been selected as the expert, after reviewing the application it me= ets > all criteria for acceptance. > > This message is to solicit any reasons that the applications should not b= e > accepted. > The last day for comment on the application is August 8=E2=80=99th. > > Any reports of implementations experience would be helpful. > > Olafur > > > Begin forwarded message: > > From: Ray Bellis > Subject: [dns-rrtype-applications] New RR Application - DOA > Date: July 25, 2017 at 11:41:43 AM EDT > To: dns-rrtype-applications@ietf.org > > Please find attached an RR application template for the "DOA" RR type. > > The link to the I-D describing the RR is: > > > > I am obviously recusing myself from evaluation of this application :) > > Please address any questions to both authors of the I-D. > > Ray > > > _______________________________________________ > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From nobody Thu Jul 27 13:53:56 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C13612EB8C for ; Thu, 27 Jul 2017 13:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MHIGLPJy5SEG for ; Thu, 27 Jul 2017 13:53:51 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4A712EC32 for ; Thu, 27 Jul 2017 13:53:51 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id v29so49252032qtv.3 for ; Thu, 27 Jul 2017 13:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6u2Wag0fojjMDsdbJsD5aqI/DEsEcX6DAV1KDFSLphU=; b=D/RASf1zkn5veeEZM1DEMpKPgux80M5zdnoOOwR+6egU3ugV3D0MeyIPccd5awHZT5 cGQIB1EX25HjbD1KCbTfTcYvxNpjioidPpUCO6yB2gAUqzTBJeMF/rY4ODpRA0/xgYpL fi/XRbekCZGUwATmkCU/DEzeINIfy0+zuQQydZvtHqEuXXnhswKkz3GpYQzm748FCTzc tQEfw6matqSh1g0XPmGRbb+swYl6LDGRLgtAuNMhJ/j7aFjV7ipB/d0NecR6Fu1OLu+D r5oFyVcauVJPZivqf/gZ8riyK5g3lfd4j7uKXbyqYtrUVod4ibqMUmiL6aLk4bZjOkDA k4Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6u2Wag0fojjMDsdbJsD5aqI/DEsEcX6DAV1KDFSLphU=; b=sVfZy/jYdkXSnjG2TU+OAT4nz979sUcg0mDSRenA6AkMbSTWGHIVvH6S33wfxTnQQx QwA9zaCdiT1gNGTqCONI3xKaOo7u2/MPJOlr3+/72R8HHx9O5fxmu/2wulgY02+y/sFh OB21jworWI/uUIrZ3NmL3iTTEJy7vqZ9LYrasJatRVMFwU1RShGmKIOtLHtu4UJGFJYw yRxHKRCHQVYxpwVA+ebn9NKYzBQXaHnvPuztBPzKXLgHgjpMbrxrWJ266MyR+hP2Evjs 3sbmEqVfzy/JiWFgz7Fk0wFpL0jozF1emE6PdmZDTNXcYRoK2bIs9OlvVK4ziWe2YMRF YzbQ== X-Gm-Message-State: AIVw113LJ534AyMnOCBvucrW4yXKUlD4dA0U4XpAoEWF+rfgo/yYAPgl iCJikgBbax6f8s1ihjGfv09JdQ68gA== X-Received: by 10.237.59.72 with SMTP id q8mr7923097qte.199.1501188830302; Thu, 27 Jul 2017 13:53:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.59.248 with HTTP; Thu, 27 Jul 2017 13:53:19 -0700 (PDT) In-Reply-To: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> References: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> From: Ted Hardie Date: Thu, 27 Jul 2017 13:53:19 -0700 Message-ID: To: Olafur Gudmundsson Cc: DNSEXT Working Group , Alain Durand , ray@isc.org Content-Type: multipart/alternative; boundary="94eb2c1914aef89937055552c216" Archived-At: Subject: Re: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 20:53:54 -0000 --94eb2c1914aef89937055552c216 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Olafur, I do not think think specification retains some ambiguities at the moment. A couple of issues: In section 3.1.2, the document says: 'For the value 2 ("URI") the DOA-DATA contains a UTF-8 encoded string representing the URI from which the DOA object can be obtained.' This is appears to assume a limited set of URI types related to client/server retrieval (what happens if this has "mailto: ogud@ogud.com" as a value? or bitcoin:mumble?). In general, actually listing the acceptable URI schemes is more useful and can easily be made part of an extensible registry. In section 3.1.3, the document says "For the value 3 ("HDL") the DOA-DATA contains a UTF-8 encoded string representing the handle from the Handle System [RFC3650] from which the DOA object can be obtained." RFC 3650 limited the set of characters appropriate for Handles to Version 3 of the UCS (see section 3). I don't follow the current work, but it seems that this document either needs to preserve that restriction or to point to later documents that removed it. Note also that section 6.1 of RFC 3650 argued explicitly against using the DNS for the Handle system. Since DOAs are currently distributed with the Handle system, it would likely be useful to indicate why an RR for this purpose works now when it did not on publication of the core Handle documents. This statement: "DNS software implementing the DOA RR type MUST NOT drop or otherwise refuse to handle the DOA RRs containing an unknown or unsupported DOA-location and MUST treat the DOA-DATA portion of the RR as an abstract opaque field." seems to amount to "DNS software must not fail when serving syntactically correct data in an RR." That's rather an odd thing to say, and I kind of wonder why it belongs in a document registering this RR type. Perhaps some more data on this point is required or perhaps the statement can be removed= . In general, I think the authors would do well to look back at the history of the URN-related DNS systems (possibly with a large adult beverage in hand). What they propose in this draft is somewhere between a generic URI pointer to a handle, a re-implementation of the data URI scheme in the DNS, the DDDS without all that pesky NAPTR business, and a way of storing opaque strings of no known utility. There are already ways to do most of this, in other words, and its not clear what lumping them together here is really that good at doing. While engaged in that review, I really hope that they go back through Chip Sharp's description of the DOA system ( https://www.internetsociety. org/doc/overview-digital-object-architecture-doa). I think it does a good job of reviewing why many of the most valued elements of the DOA (e.g. persistenc) are properties created by assurances from the issuers and not by the protocol itself. Thinking on that more may inspire them to adjust this proposal. regards, Ted On Thu, Jul 27, 2017 at 7:41 AM, Olafur Gudmundsson wrote: > Dear Colleagues > The RRType experts received the application below, > I have been selected as the expert, after reviewing the application it > meets all criteria for acceptance. > > This message is to solicit any reasons that the applications should not b= e > accepted. > The last day for comment on the application is August 8=E2=80=99th. > > Any reports of implementations experience would be helpful. > > Olafur > > > Begin forwarded message: > > *From: *Ray Bellis > *Subject: **[dns-rrtype-applications] New RR Application - DOA* > *Date: *July 25, 2017 at 11:41:43 AM EDT > *To: *dns-rrtype-applications@ietf.org > > Please find attached an RR application template for the "DOA" RR type. > > The link to the I-D describing the RR is: > > > > I am obviously recusing myself from evaluation of this application :) > > Please address any questions to both authors of the I-D. > > Ray > > > _______________________________________________ > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > --94eb2c1914aef89937055552c216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Olafur,

=
I do not think think specification retains some ambiguities at the mo= ment.=C2=A0 A couple of issues:

In section=C2=A0 3.1.2, the do= cument says: 'For the value 2 ("URI") the DOA-DATA contains a= UTF-8 encoded string representing the URI from which the DOA object can be= obtained.'=C2=A0=C2=A0 This is appears to assume a limited set of URI = types related to client/server retrieval (what happens if this has "ma= ilto:ogud@ogud.com&q= uot; as a value? or bitcoin:mumble?).=C2=A0 In general, actually listing th= e acceptable URI schemes is more useful and can easily be made part of an e= xtensible registry.

In section 3.1.3, the document says "= For the value 3 ("HDL") the DOA-DATA contains a UTF-8 encoded str= ing representing the handle from the Handle System [RFC3650] from which th= e DOA object can be obtained."=C2=A0 RFC 3650 limited the set of chara= cters appropriate for Handles to Version 3 of the UCS (see section 3).=C2= =A0 I don't follow the current work, but it seems that this document ei= ther needs to preserve that restriction or to point to later documents that= removed it.=C2=A0 Note also that section 6.1 of RFC 3650 argued explicitly= against using the DNS for the Handle system.=C2=A0 Since DOAs are currentl= y distributed with the Handle system, it would likely be useful to indicate= why an RR for this purpose works now when it did not on publication of the= core Handle documents.

This statement:

"DNS= software implementing the DOA RR type MUST NOT drop or otherwise refuse to= handle the DOA RRs containing an unknown or unsupported DOA-location and M= UST treat the DOA-DATA portion of the RR as an abstract opaque field."=

seems to amount to "DNS software must not fail when serving sy= ntactically correct data in an RR." That's rather an odd thing to = say, and I kind of wonder why it belongs in a document registering this RR = type.=C2=A0 Perhaps some more data on this point is required or perhaps the= statement can be removed.

In general, I think the authors wou= ld do well to look back at the history of the URN-related DNS systems (poss= ibly with a large adult beverage in hand).=C2=A0 What they propose in this = draft is somewhere between a generic URI=C2=A0 pointer to a handle, a re-im= plementation of the data URI scheme in the DNS, the DDDS without all that p= esky NAPTR business, and a way of storing opaque strings of no known utilit= y.=C2=A0 There are already ways to do most of this, in other words, and its= not clear what lumping them together here is really that good at doing.
While engaged in that review, I really hope that=C2=A0 they go back th= rough Chip Sharp's description of the DOA system ( https://www.internetsociety.org/doc/overview-digital-= object-architecture-doa).=C2=A0 I think it does a good job of reviewing= why many of the most valued elements of the DOA (e.g. persistenc) are prop= erties created by assurances from the issuers and not by the protocol itsel= f.=C2=A0 Thinking on that more may inspire them to adjust this proposal.
regards,

Ted
On Thu, Jul 27, 2017 at 7:41 AM, Olafur Gudmun= dsson <ogud@ogud.com> wrote:
<= div style=3D"word-wrap:break-word">Dear Colleagues=C2=A0
The RRType exp= erts received the application below,=C2=A0
I have been selected a= s the expert, after reviewing the application it meets all criteria for acc= eptance.=C2=A0

This message is to solicit any reas= ons that the applications should not be accepted.=C2=A0
The last = day for comment on the application is August 8=E2=80=99th.=C2=A0
=
Any reports of implementations experience would be helpful.= =C2=A0

Olafur


Begin forwarded message:

From: Ray Bellis <ray@bellis.me.uk>
Subject: [dns-r= rtype-applications] New RR Application - DOA
Date: July 25, 2017 at 11= :41:43 AM EDT
Please find attached an RR application template for the "DO= A" RR type.

The link to the I-D describing the RR is:

&l= t;https://www.ietf.org/internet-drafts/draft-= durand-doa-over-dns-02.txt>

I am obviously recusing myse= lf from evaluation of this application :)

Please address any questio= ns to both authors of the I-D.

Ray

______________________________________________= _


___________________= ____________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

--94eb2c1914aef89937055552c216-- From nobody Thu Jul 27 15:51:34 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87705131E6C for ; Thu, 27 Jul 2017 15:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nN7Gv3vX9ZQB for ; Thu, 27 Jul 2017 15:51:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB96131600 for ; Thu, 27 Jul 2017 15:51:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 98779349757; Thu, 27 Jul 2017 22:51:28 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 8C1C3216C1E; Thu, 27 Jul 2017 22:51:28 +0000 (UTC) Date: Thu, 27 Jul 2017 22:51:28 +0000 From: Evan Hunt To: Donald Eastlake Cc: Olafur Gudmundsson , Alain Durand , ray@isc.org, IETF DNSEXT WG Message-ID: <20170727225128.GC38856@isc.org> References: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnsext] Fwd: [dns-rrtype-applications] New RR Application - DOA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:51:32 -0000 On Thu, Jul 27, 2017 at 12:04:50PM -0400, Donald Eastlake wrote: > When ever I see DOA, I think "Dead On Arrival" but I don't have any > good short alternative to suggest... I have the exact same reaction, and would have suggested changing it to DOARC if I'd noticed this draft earlier in the process, but given that there are already experimental implementations, I guess this suggestion has been rendered moot and nonoperative even before I made it. If only I could think of a pithy way to express that concept... -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Jul 28 07:05:07 2017 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3497E120721 for ; Fri, 28 Jul 2017 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XZsKBMMQT3Ro for ; Fri, 28 Jul 2017 07:05:04 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC75131C04 for ; Fri, 28 Jul 2017 07:05:04 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id d10so11520385qtb.4 for ; Fri, 28 Jul 2017 07:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Hvd5M675/s0ZBmkshMVcTN6nbKWcQ94+bHBCDiTowo=; b=cVqkoeVYLqlvkKmBx7Yy2MEQvnfqZ9WJiGEe55iKfFEF8Aq8/Gm+UGaBD1TK8Qvy7v MMM8+G1w1UCGCU05iw7P1u4z7PKMEAv7lbKlIngR6MTCobthpsV+k2dobDkleoCBbAbC zK/ZhADpOr6+aPx8IPg44SlhKHOvukHnE/tGxseGZ8QnXCZ85kyAlDdWc6/SUlT3oqcZ Kax1ua4UnqQ0LTxMbfD36pYwE4NGFTS320CPDVLtjUQXcylher222x199PTtd2cx0/JF 5jp1FMkAN60aktw7uJe8NvlWpDtjAJ3IDkoQDJ5mqWcdRjtRqgT5SDlIPJx+JQRJLbv7 /HrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Hvd5M675/s0ZBmkshMVcTN6nbKWcQ94+bHBCDiTowo=; b=FOKPWz4eT1S5aVJQ6puQsiRA9i37C5O1zP3MedYWqkc2BLtfnctjrVqvmxicdWEnhR VEKfj5q8sYIznMNu6jRHgUdErkvnkU5IE48wxDqU8+SSYlUMwzAWiwjG4UcfdRy4NM38 aBCnuW/8X62ycDOQRZ54T8ox9NBt5DQgqfPDsbtdFsT9KwLaktQvAhabw0V52k6FgeX7 RE0KoADCMNrBK5eRy0NpOviPzFhI60cQQ28JDB+/hZbUlY5UjnWqje7vGzl54C4A4w2d mrvdXVTgkHHihuaFVBFqLOiQaJf/7Z3iLt6M3zBp9WLLxDD0J9xzVirHoz4NCWk1Eh2A NZTA== X-Gm-Message-State: AIVw1104Spb7BpvUF+cmOjvWo2D+GjRuEny7Ccr5wCXXV6mDMBYlEvqy OTWKYRBr6cOn9w== X-Received: by 10.200.51.13 with SMTP id t13mr11357292qta.28.1501250703663; Fri, 28 Jul 2017 07:05:03 -0700 (PDT) Received: from ?IPv6:2601:181:c381:c20:79c8:d533:65e1:e059? ([2601:181:c381:c20:79c8:d533:65e1:e059]) by smtp.gmail.com with ESMTPSA id r49sm16012026qte.34.2017.07.28.07.05.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Jul 2017 07:05:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <20170727225128.GC38856@isc.org> Date: Fri, 28 Jul 2017 10:05:01 -0400 Cc: Donald Eastlake , Alain Durand , ray@isc.org, IETF DNSEXT WG , Olafur Gudmundsson Content-Transfer-Encoding: quoted-printable Message-Id: <528C592E-EC3D-4039-97E0-8FD74A137B36@gmail.com> References: <9E44247D-8543-49F2-A8E2-892B3D34C16F@ogud.com> <20170727225128.GC38856@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [dnsext] [dns-rrtype-applications] New RR Application - DOA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:05:06 -0000 (I co-chair DNSOP, but no hat here.) > On Jul 27, 2017, at 6:51 PM, Evan Hunt wrote: >=20 > On Thu, Jul 27, 2017 at 12:04:50PM -0400, Donald Eastlake wrote: >> When ever I see DOA, I think "Dead On Arrival" but I don't have any >> good short alternative to suggest... >=20 > I have the exact same reaction, and would have suggested changing it > to DOARC if I'd noticed this draft earlier in the process, but given = that > there are already experimental implementations, I guess this = suggestion has > been rendered moot and nonoperative even before I made it. If only I = could > think of a pithy way to express that concept... Without more information about a deployed base, it=E2=80=99s hard to = understand possible ramifications of change in the mnemonic, but I = respectfully suggest the requester could change the requested mnemonic = if they want.=20 I suspect the expert can also suggest or support such a change in the = interest of avoiding confusion in other contexts, even though RFC 6895 = doesn=E2=80=99t explicitly say so. Suzanne