From nobody Thu Jun 1 06:04:50 2017 Return-Path: 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 211D112EC2A; Thu, 1 Jun 2017 06:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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 vxMV8OgAINaW; Thu, 1 Jun 2017 06:04:47 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 C191D12EC28; Thu, 1 Jun 2017 06:04:46 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id 19so35508323qke.2; Thu, 01 Jun 2017 06:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F771uD0mOUt/qc8cW+wmhuSTz7ckAA0f/6xWQ6Z5K1w=; b=tUjSMf9qV2DedHwV1kMwqeRAg5x/+CPeBcCBJ2sgVRwaT3A7M22RwCnieYBoZTLFZs kVa5XDI72RyhBrNLByC3bMu2sz503aRxi0sjcb0D9ZwNJfwZpLIAr2z/vT9jb/BUTt68 Dw3CJKXTlBAdD5XpN/74SLCguOB88X6K7Jd05C/JF4YRb47uixEcKMxr5WGlUlYiwLPy Z9L4vIux9OrzFWoJPgap9r5H85Woz+bS/nJLsB7wxi5oIYe5ne838ejahBn/OwwFX+dB y5CvTmdZEyE8r24J9aje7W7OYnGI5UaHCKRTXSwBqQw2d07/g8HchIR8jyJQoNsj1d5o 9Stw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F771uD0mOUt/qc8cW+wmhuSTz7ckAA0f/6xWQ6Z5K1w=; b=XJ3kUL1me6Kx2yMjkRjNRweU2nrq5uIaP0bGB+QX3ASPoqLZGCf//YkSPu/8N1qCky nXFYuBreDUUIQyWVtV9Sa7Qxh06f/xhfTrkPFRuTV20VQLwAYUVOz2mtZTgUJ/RddnB7 GLCkAmBHYZUMkIV0dORtr1y8nBvc+Whk1wbw+KUudR44nVrvmokdPNR+5YjuF6ptyKVP SxT30xr//xcrgkyi4+klpOpawPll1SSvP87Nm/xqmaeL2aVZHD29tdsZsqo46pU95nsi HIlHlY32gwE66JamV176NtAZrd7e8vlMTf0QiTvh/TphrcoRCinKbmCBYotkP0Bdg32k sOhw== X-Gm-Message-State: AODbwcC7TfQD1NgREZFYp5w5X6rUSJDECiRdoeql05U0YFJ86PpAtTVG Tq2uFLkpOsq8gkD64So= X-Received: by 10.55.191.6 with SMTP id p6mr1477404qkf.162.1496322285991; Thu, 01 Jun 2017 06:04:45 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:1018:a4e0:80e0:4817? ([2601:18f:801:600:1018:a4e0:80e0:4817]) by smtp.gmail.com with ESMTPSA id g6sm12462553qkb.48.2017.06.01.06.04.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 06:04:44 -0700 (PDT) From: Ralph Droms Message-Id: <2CB78C49-F906-411E-AC32-A18577B476A7@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_39037713-4E4C-459F-8A14-4181246271DD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 1 Jun 2017 09:04:43 -0400 In-Reply-To: <38aae5ba-80d5-1f5c-0263-459de3ed7bda@cisco.com> Cc: draft-ietf-dnsop-sutld-ps.all@ietf.org, "dnsop@ietf.org" To: Benoit Claise References: <03bebcc5-ba95-9bbe-be07-6efb2034f9d6@cisco.com> <38aae5ba-80d5-1f5c-0263-459de3ed7bda@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] AD review: draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:04:49 -0000 --Apple-Mail=_39037713-4E4C-459F-8A14-4181246271DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the review and helpful comments, Benoit. Ted, Warren - I'm login to be tied up with some family stuff through the = weekend. If none of us get to it, I can process Benoit's comments = Monday. - Ralph > On May 30, 2017, at 11:22 AM, Benoit Claise wrote: >=20 > Dear authors, >=20 > Here is my AD review. >=20 >=20 > -=20 > This section presents a list of problems that have been identified > with respect to the assignment of Special-Use Domain Names. > Solutions to these problems, including their costs or tradeoffs, = are > out of scope for this document.=20 >=20 > There is a broad diversity of opinion about this set of problems. > Not every participant agrees that each of the problems enumerated = in > this document is actually a problem. This document takes no = position > on the relative validity of the various problems that have been > enumerated. Its focused purposes are to enumerate those problems, > provide the reader with context for thinking about them and provide = a > context for future discussion of solutions. >=20 > So you want to write something such as ... regardless of whether the = problems are valid ones AND regardless of the ownership (IETF, IANA, = ICANN, or ...)=20 > And it seems that you didn't try to categorize the problems per = ownership (this is an IETF or ICANN problem, as an example). > I guess that this is the way you approached this document, right? You = should document this. >=20 > -=20 > gTLD Generic Top-Level Domain, as defined in in section 2 of RFC > 7719 [RFC7719] >=20 > gTLD is not strictly defined in RFC7719, only TLD >=20 > - correct the .home section in 4.2.7, which is solved with Errata ID: = 4677=20 >=20 >=20 > MINOR > -=20 > [SDO-ICANN-DAG] > Internet Assigned Numbers Authority, "Special-Use Domain > Names registry", October 2015, > > full-04jun12-en.pdf = > >=20 > Don't you have a more up to date reference (2012)? > First page of this document is: "Currently the namespace consists of = 22 gTLDs and over 250 ccTLDs operating on various models." > - > o There are several Domain Name TLDs that are in use without due > process for a variety of purposes [SDO-ICANN-COLL = ]. The status of > these names need to be clarified and recorded to avoid future > disputes about their use. >=20 > I don't understand the sentence "There are several Domain Name TLDs = that are in use without due > process for a variety of purposes", with a reference that speaks = about "Name Collision in the DNS". >=20 >=20 > EDITORIAL: > - "in in". Two occurences in > TLD Top-Level Domain, as defined in in section 2 of RFC 7719 > [RFC7719] > gTLD Generic Top-Level Domain, as defined in in section 2 of RFC > 7719 [RFC7719] >=20 > - OLD: > Special-Use Domain Name A Domain Name listed in the Special-Use > Domain Names registry. > NEW: > Special-Use Domain Name A Domain Name listed in the Special-Use > Domain Names registry [SDO-IANA-SUDR]. >=20 > - OLD: > The history of RFC 6762 is = documented in substantial detail in > Appendix H = >=20 > NEW:=20 > The history of RFC 6762 is = documented in substantial detail in > Appendix H of RFC 6762 = >=20 > - Expand SSAC on the first occurrence. > =20 > Regards, Benoit >=20 --Apple-Mail=_39037713-4E4C-459F-8A14-4181246271DD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thanks for the review and helpful comments, Benoit.

Ted, Warren - I'm login to be tied up with some family stuff through the weekend.  If none of us get to it, I can process Benoit's comments Monday.

- Ralph

On May 30, 2017, at 11:22 AM, Benoit Claise <bclaise@cisco.com> wrote:

Dear authors,

Here is my AD review.


- 
   This section presents a list of problems that have been identified
   with respect to the assignment of Special-Use Domain Names.
   Solutions to these problems, including their costs or tradeoffs, are
   out of scope for this document. 

   There is a broad diversity of opinion about this set of problems.
   Not every participant agrees that each of the problems enumerated in
   this document is actually a problem.  This document takes no position
   on the relative validity of the various problems that have been
   enumerated.  Its focused purposes are to enumerate those problems,
   provide the reader with context for thinking about them and provide a
   context for future discussion of solutions.

So you want to write something such as  ... regardless of whether the problems are valid ones AND regardless of the ownership (IETF, IANA, ICANN, or ...) 
And it seems that you didn't try to categorize the problems per ownership (this is an IETF or ICANN problem, as an example).
I guess that this is the way you approached this document, right? You should document this.

- 
gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
7719 [RFC7719]

gTLD is not strictly defined in RFC7719, only TLD

- correct the .home section in 4.2.7, which is solved with Errata ID: 4677 


MINOR
- 

   [SDO-ICANN-DAG]
              Internet Assigned Numbers Authority, "Special-Use Domain
              Names registry", October 2015,
              <https://newgtlds.icann.org/en/applicants/agb/guidebook-
              full-04jun12-en.pdf>

Don't you have a more up to date reference (2012)?
First page of this document is: "Currently the namespace consists of 22 gTLDs and over 250 ccTLDs operating on various models."

-
   o  There are several Domain Name TLDs that are in use without due
      process for a variety of purposes [SDO-ICANN-COLL].  The status of
      these names need to be clarified and recorded to avoid future
      disputes about their use.

I don't understand the sentence "There are several Domain Name TLDs that are in use without due
      process for a variety of purposes", with a reference that speaks about "Name Collision in the DNS".


EDITORIAL:
- "in in". Two occurences in
TLD Top-Level Domain, as defined in in section 2 of RFC 7719
[RFC7719]
gTLD Generic Top-Level Domain, as defined in in section 2 of RFC
7719 [RFC7719]

- OLD:
   Special-Use Domain Name  A Domain Name listed in the Special-Use
      Domain Names registry.
NEW:
   Special-Use Domain Name  A Domain Name listed in the Special-Use
      Domain Names registry [SDO-IANA-SUDR].

- OLD:
   The history of RFC 6762 is documented in substantial detail in
   Appendix H

NEW: 
   The history of RFC 6762 is documented in substantial detail in
   Appendix H of RFC 6762

- Expand SSAC on the first occurrence.
 
Regards, Benoit

--Apple-Mail=_39037713-4E4C-459F-8A14-4181246271DD-- From nobody Thu Jun 1 08:35:34 2017 Return-Path: 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 5DE9C129557 for ; Thu, 1 Jun 2017 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=D/uBPvDT; dkim=pass (1024-bit key) header.d=yitter.info header.b=RFnTlUVM 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 oToeirsqV8-v for ; Thu, 1 Jun 2017 08:35:30 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CE5129549 for ; Thu, 1 Jun 2017 08:35:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 27BF2BE228 for ; Thu, 1 Jun 2017 15:35:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1496331300; bh=MbFe0Us9e1CHm2Ju0hluc6dgGNTBN2bbE3GpKhSe6kI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=D/uBPvDTTjTsgId2NuVh0M1e25ed2bQ3/fE7X9GadMlF+Gxkhm2Mx+ftutrw83mDW XPfT1MJHbsUFDgbuG3rORe7I6vEwvK77Lj7f5Nt4uh0pBwW0ZhZq9SUWYvdIVAXxou enmyxYzuY4IoULWIqhpU6T1aIfwuRosbiK6cUuks= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WqHUCQfTwDk for ; Thu, 1 Jun 2017 15:34:58 +0000 (UTC) Date: Thu, 1 Jun 2017 11:34:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1496331298; bh=MbFe0Us9e1CHm2Ju0hluc6dgGNTBN2bbE3GpKhSe6kI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RFnTlUVM+unnKl7e5sE0sriUPwKnIysP2s4RQQm8qgl57AkznBGLFbTgmk5xI8qSl JUawUN0DVX3uS2E2XXanA1U3He9Jq3fxy5hRBa56kaIsDLJge/pEy2A+EVHHSpBlMO OxHL/ebObGhctunCZ/TgHH5fG5g4rhGgBo6zViN8= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170601153456.n3brxhimjrgq2kip@mx4.yitter.info> References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> <20170526015222.C1FE979B8C4F@rock.dv.isc.org> <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 15:35:32 -0000 On Wed, May 31, 2017 at 07:44:46PM +0000, Edward Lewis wrote: > I ask because of the issues raised in the thread regarding the number of keys assumed in the operation. Automated Updates apparently (to me) was defined with more than one active secure entry point in mind, but in practice, the only operating example I've witnessed of Automated Updates relies on a single active secure entry point. > Remember that when DNSEXT selected the TA rollover mechanism, many of us believed that signing the root was a pipe dream akin to the single trust anchor for the RPKI. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jun 1 11:43:46 2017 Return-Path: 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 102061293E1 for ; Thu, 1 Jun 2017 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 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, 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 4XHGS88Nl7Yu for ; Thu, 1 Jun 2017 11:43:43 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905B7126CD6 for ; Thu, 1 Jun 2017 11:43:43 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Jun 2017 11:43:41 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 1 Jun 2017 11:43:41 -0700 From: Edward Lewis To: "dnsop@ietf.org" Thread-Topic: [Ext] New Version Notification for draft-lewis-domain-names-07.txt Thread-Index: AQHS2wWRw/3JU6iKt02Q/k2waEmjdKIQijgA Date: Thu, 1 Jun 2017 18:43:40 +0000 Message-ID: References: <149634200834.22148.11053291160137889938.idtracker@ietfa.amsl.com> In-Reply-To: <149634200834.22148.11053291160137889938.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3579173020_1337687836" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] FW: [Ext] New Version Notification for draft-lewis-domain-names-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 18:43:45 -0000 --B_3579173020_1337687836 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Draft "domain names" has been kind of orphaned with the demise of the IAB's Internet Names and Identifier's Program. It is referenced by the DNSOP WG draft https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-04, so I thought I'd bring this up here (again). "Again" meaning I had gotten some review of it in 2015 on this list as a non-WG item. The reason for this update (-07) was a realization I missed one document in the reference section - merely that. But while I was at it, I thought I'd ask for suggestions with what to do with this draft if just to have it in a referenceable "place" when the problem statement draft nears publication. (I'm unsure whether this ought to be adopted by the WG or whether it should go some other route.) On 6/1/17, 14:33, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-lewis-domain-names-07.txt has been successfully submitted by Edward Lewis and posted to the IETF repository. Name: draft-lewis-domain-names Revision: 07 Title: Domain Names, A Case for Clarifying Document date: 2017-06-01 Group: Individual Submission Pages: 16 URL: https://tools.ietf.org/html/draft-lewis-domain-names-07 Abstract: This document researches the origin of the term Domain Name in the Request for Comments document series, documenting that the term did not originate in the documents defining the Domain Name System. The document describes how the term came to be used, how the DNS followed, and surveys the diverse ways Domain Names have been interpreted within various protocols over time. The purpose of this is to give a solid foundation for work on Domain Names across all protocols making use of Domain Names. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --B_3579173020_1337687836 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjGCAf8wggH7AgEBMHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUaZQ/gpZwfdSWFw7o U/EcYiBEuMYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcw NjAxMTg0MzQwWjANBgkqhkiG9w0BAQEFAASCAQCSAHNeJukhuwUdT6yzYOtfOJ8J7pUKmfRv ueGRgLi4rWYLpnNfpUrbkszdSRZyqqR07nAKQuhowng1yKvNJgiYQWyngrJVJEeSrn2FBOqz flcyE6vUJgyibCNIw+Oj8Kmx4Ht66ABkGFL+ApSwT9ywVFKjmD5/9M43moQFRxhKBD4HTXAs tB0SlLBAYynvJVJeiirbWNyhfyYsR9mjUyqO3CgS+BjKn2ZqcKN1XqZ23yRpevewfQTYduZG VK4YTsargReWjivcgURviHqsrwDmFvlZ9W9UTECNsAeFMepA7aHiOzvn/iY4uELrkuTt3GrQ hHx7Fd3WcsnTs4TZbYMU --B_3579173020_1337687836-- From nobody Thu Jun 1 17:17:49 2017 Return-Path: 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 A2163129471 for ; Thu, 1 Jun 2017 17:17:48 -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 xItV0F7Wd1Kv for ; Thu, 1 Jun 2017 17:17:47 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 598B3129468 for ; Thu, 1 Jun 2017 17:17:47 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 0522D24AE0A; Fri, 2 Jun 2017 00:16:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3A5EF160082; Fri, 2 Jun 2017 00:16:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1D3DC160081; Fri, 2 Jun 2017 00:16:27 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VVvGeMgKMZZZ; Fri, 2 Jun 2017 00:16:27 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A62AE160045; Fri, 2 Jun 2017 00:16:26 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B31607ABA55C; Fri, 2 Jun 2017 10:16:24 +1000 (AEST) To: Edward Lewis Cc: Michael StJohns , "dnsop@ietf.org" From: Mark Andrews References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> <20170526015222.C1FE979B8C4F@rock.dv.isc.org> <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com> In-reply-to: Your message of "Wed, 31 May 2017 19:44:46 +0000." Date: Fri, 02 Jun 2017 10:16:24 +1000 Message-Id: <20170602001624.B31607ABA55C@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 00:17:49 -0000 In message , Edward Lewis writes: > > How many operational instances of "Automated Updates" [RFC 5011] are there? DLV.ISC.ORG is formally doing RFC 5011. DLV.ISC.ORG is listed as a managed-key in named's distribution. We have not performed a key rollover however. > Besides the root zone KSK, I don't know of any. I do some monitoring of > DNSSEC practices, years ago I noticed one TLD appearing to follow > RFC 5011's semantics. But in recent looks that TLD seems to have > abandoned the practice (I've never made contact to confirm). In a scan > of second-level names a month ago, I found only traces of revoked keys > (KSK and ZSK!). You can't tell if a zone is following RFC 5011 or not without asking the operators or the operators stating so publically. This statement really should be published in the DNS. > I ask because of the issues raised in the thread regarding the number of > keys assumed in the operation. Automated Updates apparently (to > me) was defined with more than one active secure entry point in mind, but > in practice, the only operating example I've witnessed of Automa > ted Updates relies on a single active secure entry point. > > I've asked around (tool developers) and, so far, no other examples have > popped up. I'm sure there are some out there. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jun 5 13:59:18 2017 Return-Path: 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 520C0129409 for ; Mon, 5 Jun 2017 13:59:08 -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, 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 foM0TUL1uHyI for ; Mon, 5 Jun 2017 13:59:07 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 0641E1271FD for ; Mon, 5 Jun 2017 13:59:06 -0700 (PDT) Received: from lxdnp04n.corp.intranet (emailout.qintra.com [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v55Kx6SV063759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Jun 2017 14:59:06 -0600 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v55Kx0QY039409; Mon, 5 Jun 2017 14:59:00 -0600 Received: from lxdnp32k.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id v55Kx0eT039402 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 5 Jun 2017 14:59:00 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v55Kx0QV060502; Mon, 5 Jun 2017 14:59:00 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v55Kx0AJ060486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jun 2017 14:59:00 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.48]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Mon, 5 Jun 2017 15:59:00 -0500 From: "Woodworth, John R" To: "'John R Levine'" , Paul Vixie CC: "dnsop@ietf.org" , "Woodworth, John R" Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt Thread-Index: AQHSnbpT47rvPQsRPkWRkkFy61wAdaGWsFGAgACeBTuASreHgIAAA5uAgA3+oACAAAgvgIAAAYoAgAAAUICAAAHSAIAnKFvA Date: Mon, 5 Jun 2017 20:58:59 +0000 Message-ID: References: <20170511165852.34338.qmail@ary.lan> <59149F29.6090908@redbarn.org> <5914A0B7.805@redbarn.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:59:08 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of John R Levine > Sent: Thursday, May 11, 2017 1:41 PM > To: Paul Vixie > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt > > >> You might want to talk to large providers that do v6 now. > >> With only one exception I can think of, they have no plans > >> to do synthesized v6 rDNS, and they routinely block port 25 > >> from all their consumer networks. > > > > i'd like to meet your friends. but i'd also like them write an > > rfc about it. > > You've met a lot of them at M3AAWG. Also see draft-ietf-dnsop-isp-ip6rdn= s > > I hope we are not so foolish as to repeat the NAT fiasco and stick our > fingers in our ears becuse the rest of the world doesn't work in a way > some of us might prefer. > > The reality is that if you want people to accept your v6 mail, your mail > hosts need rDNS, and not rDNS that looks like it was autogenerated by > kludges like BULK. > Looks like the radioactive spider that bit me was from the control group because there was no tingling of my spidey sense :) I echo the point of email servers being assigned a real rDNS to cut down on heartburn. Thankfully one of BULK's features ensures real RRs can easily coexist within a synthesized range. BTW: kludge seems harsh for a carefully thought-out solution /John > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Tue Jun 6 06:38:59 2017 Return-Path: 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 06BFE128DE7 for ; Tue, 6 Jun 2017 06:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 yZUolU7avSgF for ; Tue, 6 Jun 2017 06:38:57 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 190CB128CFF for ; Tue, 6 Jun 2017 06:38:57 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id g66so23039502vki.1 for ; Tue, 06 Jun 2017 06:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnQqrTaNRbJ5CWK8KQBDnf7cjIWM6nMuQ4jwL/7lxag=; b=Rt8bSncOYAc29dP6Sh8Md8V27Djrt01xlyeAw4vlNB+/NHSmBedhyBWOFOPHvaPYa0 HrsLT5HbKQpIJrRbogIwBf32ugK4W1cJaTzO/QMUk0QhU6fKQd3TcnQ761WDHXKZCwXF y39ay25HZlx1imNF88Fz0ZXCzlV8qXPkYMj6s4Y0lBWBp0Gw+a5VwRpCyz1VamTmjdYl DVT8yCNmi6NaLhvrdD56tPTso/fq2SUl2JmyX8ztx+2+pnL7JOaWtSUFLqFfPBUtW9L0 elFZv+CZboXyF1KKkNFNNwiQfQfj3EnyBzUJJ8QsGLdutsnj9shvBq5cvdoyUMSMJ6r6 AzzA== 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=lnQqrTaNRbJ5CWK8KQBDnf7cjIWM6nMuQ4jwL/7lxag=; b=eaHEJzAcCz7CDr8cJ4PB3jIs11qhUkAf1osmdvNAK+N480gvslCxRd8dou86MEGRdT DD/qNjd7TD2n37YRK/mE8p+g1vRveS6bMOOsH53JyZ3juH4vTio6/WgjjtkGotVXU61X D/g6nWQoCTwwEmR7ezzYHCd3l0TLi4ejD+jC7cF27TpO5EaTrIr/rvtmWYdHNjTE1Fg2 oBYCccMsxtIwO+m528u8XBLMWjIkPeXbQHg+eH5WzFy+HSZKatOQubFY/SIS2s/oXPPZ Fs0q9T+t9eCPAxWDrwK/MuSBiB39qiuUsckg4N9NQb8g66saHFpXo+AgSopn0DGFG1KJ HSNw== X-Gm-Message-State: AODbwcC3Wny5/K1tgUjAzLbXyw/AqhFjfqofVEeCf/Jr10Q55m6TrrnO xoDOezchOHtPmCPXAgwlcGqA2A+OwXU1 X-Received: by 10.31.173.134 with SMTP id w128mr2127764vke.125.1496756336080; Tue, 06 Jun 2017 06:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.198 with HTTP; Tue, 6 Jun 2017 06:38:15 -0700 (PDT) In-Reply-To: <2CB78C49-F906-411E-AC32-A18577B476A7@gmail.com> References: <03bebcc5-ba95-9bbe-be07-6efb2034f9d6@cisco.com> <38aae5ba-80d5-1f5c-0263-459de3ed7bda@cisco.com> <2CB78C49-F906-411E-AC32-A18577B476A7@gmail.com> From: Warren Kumari Date: Tue, 6 Jun 2017 09:38:15 -0400 Message-ID: To: Ralph Droms Cc: Benoit Claise , draft-ietf-dnsop-sutld-ps.all@ietf.org, "dnsop@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] AD review: draft-ietf-dnsop-sutld-ps X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 13:38:59 -0000 Hi Ralph, Just checking if you might get to this? If not I *think I can do it at ~noon eastern. W On Thu, Jun 1, 2017 at 9:04 AM, Ralph Droms wrote: > Thanks for the review and helpful comments, Benoit. > > Ted, Warren - I'm login to be tied up with some family stuff through the > weekend. If none of us get to it, I can process Benoit's comments Monday. > > - Ralph > > On May 30, 2017, at 11:22 AM, Benoit Claise wrote: > > Dear authors, > > Here is my AD review. > > > - > This section presents a list of problems that have been identified > with respect to the assignment of Special-Use Domain Names. > Solutions to these problems, including their costs or tradeoffs, are > out of scope for this document. > > There is a broad diversity of opinion about this set of problems. > Not every participant agrees that each of the problems enumerated in > this document is actually a problem. This document takes no position > on the relative validity of the various problems that have been > enumerated. Its focused purposes are to enumerate those problems, > provide the reader with context for thinking about them and provide a > context for future discussion of solutions. > > So you want to write something such as ... regardless of whether the > problems are valid ones AND regardless of the ownership (IETF, IANA, ICANN, > or ...) > And it seems that you didn't try to categorize the problems per ownership > (this is an IETF or ICANN problem, as an example). > I guess that this is the way you approached this document, right? You should > document this. > > - > gTLD Generic Top-Level Domain, as defined in in section 2 of RFC > 7719 [RFC7719] > > gTLD is not strictly defined in RFC7719, only TLD > > - correct the .home section in 4.2.7, which is solved with Errata ID: 4677 > > > MINOR > - > > [SDO-ICANN-DAG] > Internet Assigned Numbers Authority, "Special-Use Domain > Names registry", October 2015, > full-04jun12-en.pdf> > > Don't you have a more up to date reference (2012)? > First page of this document is: "Currently the namespace consists of 22 > gTLDs and over 250 ccTLDs operating on various models." > > - > o There are several Domain Name TLDs that are in use without due > process for a variety of purposes [SDO-ICANN-COLL]. The status of > these names need to be clarified and recorded to avoid future > disputes about their use. > > I don't understand the sentence "There are several Domain Name TLDs that are > in use without due > process for a variety of purposes", with a reference that speaks about > "Name Collision in the DNS". > > > EDITORIAL: > - "in in". Two occurences in > TLD Top-Level Domain, as defined in in section 2 of RFC 7719 > [RFC7719] > gTLD Generic Top-Level Domain, as defined in in section 2 of RFC > 7719 [RFC7719] > > - OLD: > Special-Use Domain Name A Domain Name listed in the Special-Use > Domain Names registry. > NEW: > Special-Use Domain Name A Domain Name listed in the Special-Use > Domain Names registry [SDO-IANA-SUDR]. > > - OLD: > The history of RFC 6762 is documented in substantial detail in > Appendix H > > NEW: > The history of RFC 6762 is documented in substantial detail in > Appendix H of RFC 6762 > > - Expand SSAC on the first occurrence. > > > Regards, Benoit > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jun 6 12:39:59 2017 Return-Path: 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 128EB1252BA; Tue, 6 Jun 2017 12:39:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149677799803.3841.7503913286788962129@ietfa.amsl.com> Date: Tue, 06 Jun 2017 12:39:58 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:39:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Special-Use Domain Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-05.txt Pages : 27 Date : 2017-06-06 Abstract: The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-05 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 6 12:50:09 2017 Return-Path: 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 7CDB5126E64 for ; Tue, 6 Jun 2017 12:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2zv8X4hMAIt4 for ; Tue, 6 Jun 2017 12:50:07 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BC8126B6D for ; Tue, 6 Jun 2017 12:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=558; q=dns/txt; s=iport; t=1496778606; x=1497988206; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=IyEZ19VvvwoP/ZRdIPpz+vV2T/4t61/jAp14u+Bk8T0=; b=iBXM4WFGWWa7qeYfCDG57JgpOutJcYaCA8UyULbATqJ+XwVq3eKrgLw/ n3ovAjCPEreq5h/nlbrIMkygpYV7MU8mPjhXpZqlNKjm34slnqVFqMHgH Itk7EBdcyajVPDi80LpaB7flPG5F651m8TQ2abPWtYhFadd+KgcD1wJ6D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAADTBjdZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYNzihlzpxGCECyFeAKDJBgBAgEBAQEBAQFrKIUZAwMjFT8?= =?us-ascii?q?SCw4MAiYCAlcGAQwIAQGKJhCtYIImi34BAQEBAQEBAQEBAQEBAQEBAQEggQuFV?= =?us-ascii?q?oILgnWDJoRWgmEBBJ40hyaMDoFuGFWEaYNLhnCMJog7HziBCjAhCBsVhgGBTT4?= =?us-ascii?q?2AYlLAQEB?= X-IronPort-AV: E=Sophos;i="5.39,307,1493683200"; d="scan'208";a="655234267" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2017 19:50:02 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v56Jo22w001176; Tue, 6 Jun 2017 19:50:02 GMT To: Suzanne Woolf , "dnsop@ietf.org" References: <149677799818.3841.17984226801430375069.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <7a3dc653-51bf-c465-012d-c837f8a29ac0@cisco.com> Date: Tue, 6 Jun 2017 21:50:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149677799818.3841.17984226801430375069.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] New Version Notification - draft-ietf-dnsop-sutld-ps-05.txt => IETF LC requested. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:50:08 -0000 Regards, Benoit. > A new version (-05) has been submitted for draft-ietf-dnsop-sutld-ps: > https://www.ietf.org/internet-drafts/draft-ietf-dnsop-sutld-ps-05.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-05 > > Please note that it may take a couple of minutes from the time of submission > until the diff is available at tools.ietf.org. > > IETF Secretariat. > > . > From nobody Tue Jun 6 13:08:15 2017 Return-Path: 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 E9A75127286; Tue, 6 Jun 2017 13:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4irR3ClC9x6f; Tue, 6 Jun 2017 13:08:12 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 7D14012009C; Tue, 6 Jun 2017 13:08:09 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 181CF31D32; Tue, 6 Jun 2017 22:08:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id AC7DE190C30; Tue, 6 Jun 2017 22:04:37 +0200 (CEST) Date: Tue, 6 Jun 2017 22:04:37 +0200 From: Stephane Bortzmeyer To: draft-klensin-dns-function-considerations.authors@ietf.org Cc: dnsop@ietf.org Message-ID: <20170606200437.GA23271@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.8 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:08:14 -0000 draft-klensin-dns-function-considerations is an interesting document so I take the liberty to copy dnsop, which may be interested. A few remarks about the -01 version: It does not seem to mention other naming systems, except a short reference to "blockchains" (there are many of naming systems, each with different strengthes and weaknesses than the DNS). I do not suggest to enumerate them all, rather to note they exist, and The Solution may not be a replacement of the DNS but a coexistence of the DNS with other naming systems (I have trouble believing that one day, we will have One Perfect Naming System). > 3.1. Multiple address types In this section, and in some others, I think that you mix problem description and solutions. For this problem (getting both A and AAAA records with a single query), there is the solution you mention (QTYPE=ADDR) but there is also having several questions in the Question section. Same issue in "3.13.2. Extensions and Deployment Pressures -- The TXT RRTYPE" where you mention a solution (new RR types) and not another one (TXT records below the apex). > perceived discrimination against some languages Scripts, not languages. And "perceived" is offensive: it _is_ a discrimination (although we agree there is no obvious solution). > it does not appear that any of them are as satisfactory as a system > with query privacy designed in might be. Both QNAME minimization (RFC 7816) and DNS encryption (RFC 7858) have seen very little deployment today, so I don't think we can already conclude they are not satisfactory. > The DNS model of master and slave servers, with the latter > initiating updates based on TTL values, The slaves don't use the TTL values, don't they? > a subject that is intensely controversial with regard to who should > control those servers [the root name servers], how they should be > distributed and where they should be located. The problem is only partly technical. For instance, with today's DNS, it is already possible to have more root name servers (not thousands, OK, because of the size of the priming response, but dozens, certainly). This would partially address the problem. > A key design element of the original network object naming systems > for the ARPANET, largely inherited by the DNS, was that the names > were identifiers and their being highly distinguishable and not > prone to ambiguity was important. If the main (and may be only) goal were to have unambiguous identifiers, digits would have been sufficient (a SHA-256 hash is an unambigous identifier, see RFC 6920). Unlike what you say, from the beginning, domain names have been expressing "thoughts and concepts". With a few exceptions, nobody registers "opaque" domain names. Editorial: > including a model for negotiating extended functionality [RFC2671] It is now RFC 6891. > and hard to illustrate in ASCII-only Internet-Drafts and RFCs We now have RFC 7997 :-) > Whether that would be desirable on not Or not? From nobody Tue Jun 6 13:18:01 2017 Return-Path: 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 C928A129504; Tue, 6 Jun 2017 13:17:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , bclaise@cisco.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> Date: Tue, 06 Jun 2017 13:17:55 -0700 Archived-At: Subject: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:17:56 -0000 The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Special-Use Domain Names Problem Statement' as Informational RFC 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 2017-06-20. 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 The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jun 6 14:05:16 2017 Return-Path: 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 6688F128BB6 for ; Tue, 6 Jun 2017 14:05:14 -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, RP_MATCHES_RCVD=-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 8rOh8BJmHfIM for ; Tue, 6 Jun 2017 14:05:13 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E621200B9 for ; Tue, 6 Jun 2017 14:05:12 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dILf5-000JB0-Qf; Tue, 06 Jun 2017 17:05:11 -0400 Date: Tue, 06 Jun 2017 17:05:05 -0400 From: John C Klensin To: Stephane Bortzmeyer cc: dnsop@ietf.org Message-ID: In-Reply-To: <20170606200437.GA23271@sources.org> References: <20170606200437.GA23271@sources.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 21:05:14 -0000 Stephane, Thanks for reading the draft and for your comments. I will study them and see what I can do and will get back to you if I have questions. One general observation: I've tried, when mentioning possible alternate approaches, to provide a partial existence proof that alternatives are possible that could do the job or improve things, not to propose solutions or to be comprehensive able possibilities. Fro example, the blockchain example was mentioned because it is one way -- a way that has gotten a lot of attention lately -- to have an authoritative structured name system without having a hierarchical system and centrally-managed root. I didn't mean to suggest that it was the only such option (it isn't) or the best one (I suspect it is not). As to whether DNSOP wants to get involved, while there are operational issues in the summary I'm trying to make, I see most of them as being consequences of protocol choices that were either poor to start with (like the underspecification of CLASS), poor (more historically than at present) implementations, or that just have not held up (i.e., failed 30-odd years ago to adequately predict the present). So, while I'm sure there are people on the DNSOP list who are, or should be, very interested in the question of whether we are pushing the DNS past its practical limits, I don't see that as specifically an operational problem. Instead, I see it as an issue that affects much of the IETF. That is especially true if, as one person who commented believes, a transition to a DNSng could be more difficult and take longer than the IPv4-> IPv6 transition. In addition, while I would welcome help or even a contributor or co-author or two, I think there are a number of reasons why the contents of this I-D are more appropriately an Independent Submission than any sort of IETF stream document (even an Informational one) that would require a consensus determination. best, john --On Tuesday, June 6, 2017 22:04 +0200 Stephane Bortzmeyer wrote: > draft-klensin-dns-function-considerations is an interesting > document so I take the liberty to copy dnsop, which may be > interested. > > A few remarks about the -01 version: > > It does not seem to mention other naming systems, except a > short reference to "blockchains" (there are many of naming > systems, each with different strengthes and weaknesses than > the DNS). I do not suggest to enumerate them all, rather to > note they exist, and The Solution may not be a replacement of > the DNS but a coexistence of the DNS with other naming systems > (I have trouble believing that one day, we will have One > Perfect Naming System). > >> 3.1. Multiple address types > > In this section, and in some others, I think that you mix > problem description and solutions. For this problem (getting > both A and AAAA records with a single query), there is the > solution you mention (QTYPE=ADDR) but there is also having > several questions in the Question section. > > Same issue in "3.13.2. Extensions and Deployment Pressures -- > The TXT RRTYPE" where you mention a solution (new RR types) > and not another one (TXT records below the apex). > >> perceived discrimination against some languages > > Scripts, not languages. And "perceived" is offensive: it _is_ a > discrimination (although we agree there is no obvious > solution). > >> it does not appear that any of them are as satisfactory as a >> system with query privacy designed in might be. > > Both QNAME minimization (RFC 7816) and DNS encryption (RFC > 7858) have seen very little deployment today, so I don't think > we can already conclude they are not satisfactory. > >> The DNS model of master and slave servers, with the latter >> initiating updates based on TTL values, > > The slaves don't use the TTL values, don't they? > >> a subject that is intensely controversial with regard to who >> should control those servers [the root name servers], how >> they should be distributed and where they should be located. > > The problem is only partly technical. For instance, with > today's DNS, it is already possible to have more root name > servers (not thousands, OK, because of the size of the priming > response, but dozens, certainly). This would partially address > the problem. > >> A key design element of the original network object naming >> systems for the ARPANET, largely inherited by the DNS, was >> that the names were identifiers and their being highly >> distinguishable and not prone to ambiguity was important. > > If the main (and may be only) goal were to have unambiguous > identifiers, digits would have been sufficient (a SHA-256 hash > is an unambigous identifier, see RFC 6920). Unlike what you > say, from the beginning, domain names have been expressing > "thoughts and concepts". With a few exceptions, nobody > registers "opaque" domain names. > > Editorial: > >> including a model for negotiating extended functionality >> [RFC2671] > > It is now RFC 6891. > >> and hard to illustrate in ASCII-only Internet-Drafts and RFCs > > We now have RFC 7997 :-) > >> Whether that would be desirable on not > > Or not? From nobody Wed Jun 7 04:48:10 2017 Return-Path: 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 81F3E129B41; Wed, 7 Jun 2017 04:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 UBea0G1Qmosu; Wed, 7 Jun 2017 04:48:06 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 4C9D1127011; Wed, 7 Jun 2017 04:48:06 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:44467) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dIZRT-000jxW-ez (Exim 4.89) (return-path ); Wed, 07 Jun 2017 12:48:03 +0100 Date: Wed, 7 Jun 2017 12:48:03 +0100 From: Tony Finch To: Stephane Bortzmeyer cc: draft-klensin-dns-function-considerations.authors@ietf.org, dnsop@ietf.org In-Reply-To: <20170606200437.GA23271@sources.org> Message-ID: References: <20170606200437.GA23271@sources.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 11:48:08 -0000 Stephane Bortzmeyer wrote: > > > The DNS model of master and slave servers, with the latter > > initiating updates based on TTL values, > > The slaves don't use the TTL values, don't they? That section is a bit weird. Efforts to use very short (or zero) TTLs to simulate nearly-simultaneous updating may work up to a point but appear to impose very heavy loads on servers and distribution mechanisms that were not designed to accommodate that style of working. Similar observations can be made about attempts to use dynamic, "server-push", updating rather than the traditional DNS mechanisms. While those might work better than ordinary short TTLs and update mechanisms as specified in RFC 1034 and 1035, they imply that a "master" server must know the identities of (and have real time access to all of) its slaves, defeating many of the advantages of caching, particularly those associated with reduction of query traffic across the Internet. It doesn't mention the venerable and widely-deployed NOTIFY, and seems to muddle up replication to authoritative servers and cacheing in resolvers. If it is supposed to be talking about somthing of current relevance, it should refer explicitly to draft-ietf-dnssd-push or whatever other developments the author has in mind. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: Northerly 5 or 6, becoming cyclonic 5 to 7, perhaps gale 8 later in southeast. Moderate or rough. Fair. Good. From nobody Wed Jun 7 07:16:48 2017 Return-Path: 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 90AE71270A3 for ; Wed, 7 Jun 2017 07:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BEDradm7fB2G for ; Wed, 7 Jun 2017 07:16:39 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A204E12EC68 for ; Wed, 7 Jun 2017 07:16:39 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dIblE-000Lhc-8e; Wed, 07 Jun 2017 10:16:36 -0400 Date: Wed, 07 Jun 2017 10:16:30 -0400 From: John C Klensin To: Tony Finch , Stephane Bortzmeyer cc: dnsop@ietf.org Message-ID: <399EC4C37472864C97500D1E@PSB> In-Reply-To: References: <20170606200437.GA23271@sources.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 14:16:41 -0000 --On Wednesday, June 7, 2017 12:48 +0100 Tony Finch wrote: > Stephane Bortzmeyer wrote: >> >> > The DNS model of master and slave servers, with the latter >> > initiating updates based on TTL values, >> >> The slaves don't use the TTL values, don't they? > > That section is a bit weird. > > Efforts > to use very short (or zero) TTLs to simulate > nearly-simultaneous updating may work up to a point but > appear to impose very heavy loads on servers and > distribution mechanisms that were not designed to accommodate > that style of working. Similar observations can be made > about attempts to use dynamic, "server-push", updating > rather than the traditional DNS mechanisms. While those > might work better than ordinary short TTLs and update > mechanisms as specified in RFC 1034 and 1035, they imply > that a "master" server must know the identities of (and > have real time access to all of) its slaves, defeating many > of the advantages of caching, particularly those associated > with reduction of query traffic across the Internet. > > It doesn't mention the venerable and widely-deployed NOTIFY, > and seems to muddle up replication to authoritative servers > and cacheing in resolvers. If it is supposed to be talking > about somthing of current relevance, it should refer > explicitly to draft-ietf-dnssd-push or whatever other > developments the author has in mind. It is indeed muddled. Thanks to both of you for pointing that out. I will try to fix. The references are another issue - while I've tried to pick up references as I went along, there are _many_ things that have been discussed, proposed, or even adopted that I haven't picked up, partially because I just don't follow some of the work closely enough. Pointers to them would be appreciated, as would text to go with them. At least in retrospect, someone closer to DNS issues than I am should have written the document I hope this will become and written it several years ago. No one did. The IAB Identifier Program could have taken it on, but they didn't (mostly, AFAICT, for good reasons) and the IAB has now closed it. I don't believe that posting a note to the IETF (or DNSOP) list saying "someone should do this" has ever been particularly productive, especially not in the last few years. WGs like DNSOP appear to be focused on responses to demands for services and behavior from the DNS that can be defined, implemented, and deployed in the relatively short term (as I think they should be -- see earlier response to Stephane). Because I am concerned about weakening the DNS for its original function and the amount of time and energy that appears to be going into "solutions" that just cannot work (the quest for fully-equivalent names, not even limited to pointers to subtrees, comes to mind), my view is that we need to start asking fundamental questions about how far it is sensible to push the boundaries of the DNS, saying in essence about many things that "we need a naming system and database for something, the DNS is out there, so let's put it in the DNS". So, driven by some other issues, including concerns that some of the proposals to "fix" the DNS (or just "fix" IDNs) could weaken it for other purposes, some apparent real disconnects in the broader Internet community about the purpose of the DNS and criteria for DNS success, and the degree to which I believe that some of the requirement are real but that trying to make proposed solutions fit in the DNS prevents work on more comprehensive and effective solutions, I finally started writing. Again, if anyone with the right background wants to be more actively involved, I would really welcome that. best, john From nobody Thu Jun 8 06:31:40 2017 Return-Path: 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 4CE9D12EAF8; Thu, 8 Jun 2017 06:31:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tjw.ietf@gmail.com, The IESG , dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, Tim Wicinski , rfc-editor@rfc-editor.org, terry.manderson@icann.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149692869930.14792.9367832744164720378.idtracker@ietfa.amsl.com> Date: Thu, 08 Jun 2017 06:31:39 -0700 Archived-At: Subject: [DNSOP] Protocol Action: 'Aggressive use of DNSSEC-validated Cache' to Proposed Standard (draft-ietf-dnsop-nsec-aggressiveuse-10.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 13:31:39 -0000 The IESG has approved the following document: - 'Aggressive use of DNSSEC-validated Cache' (draft-ietf-dnsop-nsec-aggressiveuse-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ Technical Summary This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a range, and positive answers from wildcards. This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. It may also help increase resilience to certain DoS attacks in some circumstances. Working Group Summary Well reviewed by WG, nothing from the WG ML to suggest dissent. Document Quality Quality appears good. Personnel Document Shepherd: Tim Wicinski AD: Terry Manderson; was Joel who hand-balled it to Warren, and he is an author.. From nobody Fri Jun 9 08:25:35 2017 Return-Path: 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 48741129B5D for ; Fri, 9 Jun 2017 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=umich.edu 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 OPRm--MDY6qC for ; Fri, 9 Jun 2017 08:25:26 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 65787129AE8 for ; Fri, 9 Jun 2017 08:25:26 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id o9so16453047yba.3 for ; Fri, 09 Jun 2017 08:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jHSWTteYqwWwJWraO8NTH/js/RuCO/kjOfXWQQEGOFk=; b=rO5Dmx5lgk/kHCCu3X2dwLHsJRk3yDv5RP5Ge0D5CaEdvYy5a65cH6k57NiMX9rHxM Tql+VNy3NLv+y7I5d/PCYp5UtIY7qjc7mfM9g3FAB2bx9KCv6RRFxIoHP4Whea+L8TE2 6LbgakE0kRzqs8qhy3IHW8wO0GDRrolskQJjGwR+Q53mSzUpsZbPhWrgELsyuHbWurVh s2MS/yKUMmpUxT8kV8QPDk/sGqtA+PDKicMa2ZU6Yab4WsU2+1Op4pVcKYOUsTeokp75 lQdXLHzWrQG1BISkM0HGcdXLZlFXp89ROO1CdK0gQDt1A9y5NTr67XuA4nGkINyKHZ+w 9+3w== 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=jHSWTteYqwWwJWraO8NTH/js/RuCO/kjOfXWQQEGOFk=; b=KsRTFBwNdLo4Gs21kY9IGEt6D9+Cw0x99pWan20Z1Vi1mWtg3+mtvLMkpKMQgMdaNW jV4+uVO6V7VmBCFMhqrsoA1AWOgnrts/WRPUkzkVeQPLUuSsOhzqwwlnR9OAyQY9aJ/H RlxTFREfvc/deaM0E6x+6aRgDAyOBP5azkNzQIviQOa9s0ULwwp1laTvb1RCohbjX19n 0JgmtK967UBEHOu8vFiF/2sY7nvR5y5OdB8sBg957TVdvslCozOJA0BiABfU4pDnEHEB fN7wtRuV3EgEDy1Luq9t5opCh+/WoyVhKosv0055hinmO6cKvCGhKlWC0kVdzS5uuIvG r8UQ== X-Gm-Message-State: AODbwcAAjRi56tOm2Jd/Yghpr04PPnMdc1OHH1znjfokaulVdr4zOuGE oZzg3wFB12M9yDscvEQrCTpHP8LFQwILRu0= X-Received: by 10.37.39.68 with SMTP id n65mr1453018ybn.91.1497021925447; Fri, 09 Jun 2017 08:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.77 with HTTP; Fri, 9 Jun 2017 08:25:24 -0700 (PDT) In-Reply-To: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> From: Bob Harold Date: Fri, 9 Jun 2017 11:25:24 -0400 Message-ID: To: ietf@ietf.org Cc: draft-ietf-dnsop-sutld-ps@ietf.org, IETF DNSOP WG Content-Type: multipart/alternative; boundary="94eb2c134f8a166a6005518894e7" Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 15:25:29 -0000 --94eb2c134f8a166a6005518894e7 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 6, 2017 at 4:17 PM, The IESG wrote: > > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: - 'Special-Use Domain Names > Problem Statement' > as Informational RFC > > 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 2017-06-20. 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 > > > The Special-Use Domain Names IANA registry policy defined in RFC 6761 > has been shown through experience to present unanticipated > challenges. This memo presents a list, intended to be comprehensive, > of the problems that have been identified. In addition it reviews > the history of Domain Names and summarizes current IETF publications > and some publications from other organizations relating to Special- > Use Domain Names. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ballot/ > > > No IPR declarations have been submitted directly on this I-D. Minor nit: 4.1.2. Special-Use Domain Names Last part of the last sentence:"they can only use the mDNS protocol be used for resolving that Domain Name." Looks like "be used" is redundant and should be removed. -- Bob Harold --94eb2c134f8a166a6005518894e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 6, 2017 at 4:17 PM, 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: - 'Special-Use Domain Names=
Problem Statement'
=C2=A0 <draft-ietf-dnsop-sutld-ps-05.txt> as Informational RFC
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 2017-06= -20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In eith= er case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0The Special-Use Domain Names IANA registry policy defined in R= FC 6761
=C2=A0 =C2=A0has been shown through experience to present unanticipated
=C2=A0 =C2=A0challenges.=C2=A0 This memo presents a list, intended to be co= mprehensive,
=C2=A0 =C2=A0of the problems that have been identified.=C2=A0 In addition i= t reviews
=C2=A0 =C2=A0the history of Domain Names and summarizes current IETF public= ations
=C2=A0 =C2=A0and some publications from other organizations relating to Spe= cial-
=C2=A0 =C2=A0Use Domain Names.




The file can be obtained via
https://datatracker.ietf.org/doc/dra= ft-ietf-dnsop-sutld-ps/

IESG discussion can be tracked via
https://datatracker.ietf.org/= doc/draft-ietf-dnsop-sutld-ps/ballot/


No IPR declarations have been submitted directly on this I-D.
<= div>
=C2=A0Minor nit:

4.1.2.=C2=A0 Special-Use = Domain Names

Last part of the last sentence:"= they can only use the=C2=A0mDNS protocol be used for resolving that Domain = Name."
Looks like "be used" is redundant and s= hould be removed.

--=C2=A0
Bob Harold

--94eb2c134f8a166a6005518894e7-- From nobody Mon Jun 12 06:52:08 2017 Return-Path: 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 9832C1286B1; Mon, 12 Jun 2017 06:52:06 -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] 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 tcaiWkY04qyb; Mon, 12 Jun 2017 06:52:03 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 BDF66126D05; Mon, 12 Jun 2017 06:52:02 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 00E9A280589; Mon, 12 Jun 2017 15:52:01 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id EF3CA280651; Mon, 12 Jun 2017 15:52:00 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id E8655280589; Mon, 12 Jun 2017 15:52:00 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id E516D6000082; Mon, 12 Jun 2017 15:52:00 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id D673140E20; Mon, 12 Jun 2017 15:52:00 +0200 (CEST) Date: Mon, 12 Jun 2017 15:52:00 +0200 From: Stephane Bortzmeyer To: ietf@ietf.org Cc: dnsop@ietf.org Message-ID: <20170612135200.ya3tivlhg2dhe3ry@nic.fr> References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.6.12.134516 Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 13:52:07 -0000 On Tue, Jun 06, 2017 at 01:17:55PM -0700, The IESG wrote a message of 42 lines which said: > The IESG has received a request from the Domain Name System > Operations WG (dnsop) to consider the following document: - > 'Special-Use Domain Names Problem Statement' > as Informational RFC For an issue which is quite contentious and sensitive, I think there are some points in the document that deserve a change. Biggest point: the IESG decided to freeze the RFC 6761 process I regret this decision (RFC 6761 is still in force, it has not been deprecated or updated) and, unfortunately, registration of new Special-Use Domain Names is now impossible (pending an action on RFC 6761 that will probably never come). So, de facto, a regular process has been shut down, leaving the IETF without a possibility to register these domain names. Now, on the draft: * Section 3 says "No formal coordination process exists between the IETF and ICANN" This is not true, there is a formal liaison and it is even mentioned laster, in section 4.1.4. This issue was mentioned during the WGLC * Section 3 says "Use of the registry is inconsistent -- some Special-Use Domain Name RFCs specify registry entries, some don't; some specify delegation, some don't." There is no inconsistency here. RFC 6761 says (in its section 5) that the reservation of a Special-Use Domain Name is free to choose the rules regarding resolution, as long as they are properly explained. * Section 4.2.2 says "the fact of its unilateral use by The Tor Project without following the RFC 6761 process" The onion TLD was in use in Tor since 2004, nine years before the publication of RFC 6761. It is grossly unfair to reproach not following an unpublished RFC. It was mentioned a long time ago * Section 4.2.3 says "But it shares the problem that such names cannot be assumed either to be unique or to be functional in all contexts for all Internet-connected hosts." Unfortunately, because of the wide use of censorship through lying DNS resolvers, this problem is now part of our daily life. It would be nice if a name had the same global signification, but it is no longer true. From nobody Mon Jun 12 07:42:44 2017 Return-Path: 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 A2347129526 for ; Mon, 12 Jun 2017 07:42:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 eg_l5k74NeN5 for ; Mon, 12 Jun 2017 07:42:33 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 7206412706D for ; Mon, 12 Jun 2017 07:42:33 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id c10so128125550qtd.1 for ; Mon, 12 Jun 2017 07:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iI2EgHe2vxd3I6Q7t3vjWXpCdMS0MUG0+jUTZj9M3JQ=; b=aM0Zkzlz4L3ZuCRxJBqUNcttj8yts7WeUGAu+H76THImdJgxljyRXKHWpJheEaI765 irhNiDftvBJY8hLsrnQy2XhvGTVgVQvliJ0mOfL9eEL8lMDSHUBjkOucI6spm/max0ve 5NUoQzDayrGEgTd97kZuXhcBb3upfx5gXT4A65CXATkKqlfTaN8WyPcxMxW4h+dMREk9 lf+c6JLsFeGbtgm9vciCEAutf9rCYXLQtVY/g739yRMN0CzRgp3+TDFcwc7MydKoxTAr rLQY2ZKiYNW7ikPcXgKR2KSvKsJisf82ZJhr70K4ih3b4mVd5FWMooCREWCJGJ4Tmv8Y QJOQ== 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=iI2EgHe2vxd3I6Q7t3vjWXpCdMS0MUG0+jUTZj9M3JQ=; b=cyQnuQidk5bQO9M6x4SOeH/UDsAGeUdY5bq0ZtpKcpYMTDKWq574212ki7hKSx6W0H U+umfQ5W/O7TsA2eo0qnRjpelS+IDE4oFvCUVU2GOw3qTQvguPtSV26i3Mhhcx2vBxK0 tALwfyJrzvIVCE9xnskc6P9fPNLl85JXQbaDpnaSm6F/m8hhQv/W0C9GNWVfU2dOhKh1 RMtOPLU9b3h3UrDNWHBhXl1Ucfi0iJFZQrZwNK8xaeJwo77eEFACFz6XMm/YOoZBX7ed OCx5jMw8dSKh46H4xijI9L5lOnSdj6RUpK3WXdO6+xNu+Dsv1u4qjv7XwZxS24mcpoNa rVHw== X-Gm-Message-State: AODbwcCtXW4RzTb1fCiqLGMg5mmHgU7jdfIqiUBAQObPXc0B/y/VIMfn CG0Qds27+iBLdA2B X-Received: by 10.237.47.39 with SMTP id l36mr52736358qtd.44.1497278552543; Mon, 12 Jun 2017 07:42:32 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x78sm6731154qkb.44.2017.06.12.07.42.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 07:42:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <20170612135200.ya3tivlhg2dhe3ry@nic.fr> Date: Mon, 12 Jun 2017 10:42:30 -0400 Cc: ietf , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9619F7EF-668D-4275-9AB9-E4565D04C085@fugue.com> References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> <20170612135200.ya3tivlhg2dhe3ry@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:42:37 -0000 On Jun 12, 2017, at 9:52 AM, Stephane Bortzmeyer = wrote: > Biggest point: the IESG decided to freeze the RFC 6761 process > I regret this decision (RFC > 6761 is still in force, it has not been deprecated or updated) and, > unfortunately, registration of new Special-Use Domain Names is now > impossible (pending an action on RFC 6761 that will probably never > come). So, de facto, a regular process has been shut down, leaving the > IETF without a possibility to register these domain names. The point of publishing this document is to get a step closer to fixing = this problem. > Now, on the draft: >=20 > * Section 3 says "No formal coordination process exists between the > IETF and ICANN" This is not true, there is a formal liaison > and it is even mentioned > laster, in section 4.1.4. This issue was mentioned during the WGLC > = What is meant here is not that the IETF and ICANN don't communicate, but = rather that the IETF doesn't have a formal process for saying to ICANN, = specifically, "don't use this name." It's all informal. It is done = through the liaison, it's true, but there's no set of instructions to = follow which, having been followed, we can point to and say "we followed = the process." We could replace the first sentence as follows: "Although the IETF and = ICANN do have a liaison relationship through which special-use = allocations can be discussed, there exists no formal process for = coordinating these allocations." Would that work? > * Section 3 says "Use of the registry is inconsistent -- some > Special-Use Domain Name RFCs specify registry entries, some don't; > some specify delegation, some don't." There is no inconsistency > here. RFC 6761 says (in its section 5) that the reservation of a > Special-Use Domain Name is free to choose the rules regarding > resolution, as long as they are properly explained. The point here is not that every name should be treated the same, but = that every RFC that does a 6761 allocation should specify how/whether = the name is delegated every 6761 allocation should be added to the = special-use names registry. How about the following change: o Use of the registry is inconsistent -- some Special-Use Domain Name RFCs specifically add registry entries, some don't; some = specify how and whether special-use name delegations should be done,=20 some don't. > * Section 4.2.2 says "the fact of its unilateral use by The Tor > Project without following the RFC 6761 process" The onion TLD was in > use in Tor since 2004, nine years before the publication of RFC > 6761. It is grossly unfair to reproach not following an unpublished > RFC. It was mentioned a long time ago > = This was not intended as a reproach, but I see why you read it that way. = How about this: The situation was somewhat forced, both by the fact of its unilateral use by The Tor Project before the RFC 6761 process became available, > * Section 4.2.3 says "But it shares the problem that such names cannot > be assumed either to be unique or to be functional in all contexts for > all Internet-connected hosts." Unfortunately, because of the wide use > of censorship through lying DNS resolvers, this problem is now part of > our daily life. It would be nice if a name had the same global > signification, but it is no longer true. Andrew McConachie brought up the same issue. Unfortunately I think = this is out of scope for this document, but several people have = expressed interest in formally documenting this issue=E2=80=94I think = Andrew Sullivan expressed a similar sentiment at the mic in Chicago. = You might want to discuss this with them and see if there's work to do. From nobody Mon Jun 12 08:00:48 2017 Return-Path: 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 A6EF412EB2D for ; Mon, 12 Jun 2017 08:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no 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 ZlKXbv4BaW7f for ; Mon, 12 Jun 2017 08:00:38 -0700 (PDT) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (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 7B03B12EB26 for ; Mon, 12 Jun 2017 08:00:38 -0700 (PDT) Received: by mail-lf0-f44.google.com with SMTP id p189so52367450lfe.2 for ; Mon, 12 Jun 2017 08:00:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pkeKeP/Pix+rN9UQd7pdxJidKhjWTuh1mc9XiI+F0qM=; b=QjGW+Od5j86GNouoP7G6WQfe1cfnDtnmx9x7af77pKlX4rUNLXIiCEDUhvH4LKm0Zy cQ13p4mgYcyMUK/V0ATzxy8hugwez7yBECy+548NmXpqcnG5ASNw6KUnbxuMBgV7gU4K hCRs6vstJyEY3PisTUaknnAnQEEHRrMcwOSzagcGNfyk+XhvLGSeOMFW9x2W4aeTZiUV mIcNJeQ243VZpX+hANb8vbs3Ly5UmgCKkUDOuQJidOWj5ymuL5m03ANHomC8vh0juTqD FY2V5rDSd8cLgCd6WQ4HfcpjKIknOxHDJpzqhDwWxqckg0gdhXOtvWH3dYyZNJP/DjRs Z4pQ== X-Gm-Message-State: AODbwcCvZzXDUR8xfcJkVkn/sfTrmNplr8GrXkvdrOod0OoBpkUpVXQP 4nfk+1Lm3UFmXPdd X-Received: by 10.80.144.40 with SMTP id b37mr32105838eda.36.1497279636118; Mon, 12 Jun 2017 08:00:36 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:b984:270f:516c:29c8]) by smtp.gmail.com with ESMTPSA id e31sm5260449eda.15.2017.06.12.08.00.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 08:00:35 -0700 (PDT) Date: Mon, 12 Jun 2017 17:00:34 +0200 From: Job Snijders To: Stephane Bortzmeyer Cc: ietf@ietf.org, dnsop@ietf.org Message-ID: <20170612150034.f4etrpuhbnvbzpzz@hanna.meerval.net> References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> <20170612135200.ya3tivlhg2dhe3ry@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170612135200.ya3tivlhg2dhe3ry@nic.fr> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170428 (1.8.2) Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:00:41 -0000 On Mon, Jun 12, 2017 at 03:52:00PM +0200, Stephane Bortzmeyer wrote: > On Tue, Jun 06, 2017 at 01:17:55PM -0700, > The IESG wrote > a message of 42 lines which said: > > > The IESG has received a request from the Domain Name System > > Operations WG (dnsop) to consider the following document: - > > 'Special-Use Domain Names Problem Statement' > > as Informational RFC > > For an issue which is quite contentious and sensitive, I think there > are some points in the document that deserve a change. > > Biggest point: the IESG decided to freeze the RFC 6761 process > I regret this decision (RFC > 6761 is still in force, it has not been deprecated or updated) and, > unfortunately, registration of new Special-Use Domain Names is now > impossible (pending an action on RFC 6761 that will probably never > come). So, de facto, a regular process has been shut down, leaving the > IETF without a possibility to register these domain names. > > > * Section 4.2.2 says "the fact of its unilateral use by The Tor > Project without following the RFC 6761 process" The onion TLD was in > use in Tor since 2004, nine years before the publication of RFC > 6761. It is grossly unfair to reproach not following an unpublished > RFC. It was mentioned a long time ago > ---- OLD: The situation was somewhat forced, both by the fact of its unilateral use by The Tor Project without following the RFC 6761 process, and because a deadline had been set by the CA/Browser Forum [SDO-CABF-INT] after which all .onion PKI certificates would expire and no new certificates would be issued, unless the .onion Special-Use Top-Level Domain Name were to be recognized by the IETF. NEW: The situation was somewhat forced, both by the fact that use of the .onion domain name by the Tor Project predates the process described in RFC 6761 by 9 years, and because a deadline [CABF-DEADLINE] had been set by the CA/Browser Forum [CABF] after which all PKI certificates for internal names would expire and no new certificates would be issued. At the time .onion was considered an internal name. IETF recognition of the .onion as a Special-Use Top-Level Domain Name facilitated the development of a certificate issuance process specific to .onion domain names [CABF-BALLOT144]. [CABF-DEADLINE] should link to https://www.digicert.com/internal-names.htm [CABF] should link to https://cabforum.org/ [CABF-BALLOT144] should link to https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ ---- I wasn't there, but reading ballot-144, some cabforum mails, and https://blog.torproject.org/blog/landmark-hidden-services-onion-names-reserved-ietf it appears to me that all parties involved were actively trying to fix a long standing broken situation. Kind regards, Job From nobody Mon Jun 12 08:13:06 2017 Return-Path: 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 D2913129411 for ; Mon, 12 Jun 2017 08:13:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 3FiBcV3BVTJS for ; Mon, 12 Jun 2017 08:13:02 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 BBB05127078 for ; Mon, 12 Jun 2017 08:13:02 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c10so129315852qtd.1 for ; Mon, 12 Jun 2017 08:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N+QfH0lURpQc7OIk1u+AraG6AtzhNlWcdQbpjCC/ghY=; b=Yr+wibPKNGUmcyjltHN9T36hVT/UZg5ADlH4albBkUpCVHQksRg/oZEUbWlAQvtwGG gSDAWEiij6+VgWJ5e2KnAaDKhL6PJ/0YYQ24EV9g745N/K1fbKHLvb2pBNJVfED830r8 Qi6CL2I6XfUqBVcC9DP0QerpJ5g/yGKQ3hXWT5L0A16qQq829f9XEyIUoEx1CJ0ttrfo urV7yOvdPeR36IjBzEIijt6Kdf7v0ETN5InEccazzKZU+aXO+hwPWl0U2yw0HPe6zGkJ 7o76fbUfBeDFMwu/bzABeljwWhLZ8wmVrENqSEXDkf/NGIYleMwFjiRiEy3CL+itntzu EJdA== 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=N+QfH0lURpQc7OIk1u+AraG6AtzhNlWcdQbpjCC/ghY=; b=O/+fhmOKWJTQ+RjL2+3ZOq594sZLIUW1p+HjMe7i7CrRizFXUPLuC1FoeOYxEm4SKL vv51vFuuH2yPn/Z1PtWDi00sPfGeD052NCWux8zOZWNiDjZG2jAYzcCjKRyKkHvxG8ws /6S93StfvFmSLMEWfXeCcDIBUDGLIlsb67TCWhmemZANM3VPQoJ7iRLwAn72nGB90qBw jmXa0LmQCDmPC/bDv1TE96iPBMxiakFPQYkAG8zJ4If2sAvo6nL4bEusAgODDNjXW5nH Ukp6R5pLrH1wJ4e5kZEHvDBaUlO+bDOPUMbYoE30ug8kNqNoubXFRvfk1x2Q2hXRvtz7 st9g== X-Gm-Message-State: AODbwcBWjwOoEDwL9ZiwGjBbURAVxeseofomQUB7rNu8Z68F2jAy2lwM w79SvLNsKHshiV/k X-Received: by 10.237.61.231 with SMTP id j36mr68968568qtf.111.1497280381789; Mon, 12 Jun 2017 08:13:01 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id o41sm4935986qtc.26.2017.06.12.08.13.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 08:13:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <20170612150034.f4etrpuhbnvbzpzz@hanna.meerval.net> Date: Mon, 12 Jun 2017 11:12:59 -0400 Cc: Stephane Bortzmeyer , "dnsop@ietf.org WG" , ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7FA9EF11-83AF-4B1B-88D4-151108A47057@fugue.com> References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> <20170612135200.ya3tivlhg2dhe3ry@nic.fr> <20170612150034.f4etrpuhbnvbzpzz@hanna.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:13:05 -0000 On Jun 12, 2017, at 11:00 AM, Job Snijders wrote: > NEW: > The situation was somewhat forced, both by the fact that use of the > .onion domain name by the Tor Project predates the process described > in RFC 6761 by 9 years, and because a deadline [CABF-DEADLINE] had > been set by the CA/Browser Forum [CABF] after which all PKI > certificates for internal names would expire and no new certificates > would be issued. At the time .onion was considered an internal name. > IETF recognition of the .onion as a Special-Use Top-Level Domain = Name > facilitated the development of a certificate issuance process > specific to .onion domain names [CABF-BALLOT144].=20 >=20 > [CABF-DEADLINE] should link to = https://www.digicert.com/internal-names.htm > [CABF] should link to https://cabforum.org/ > [CABF-BALLOT144] should link to = https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-name= s/ Thanks, I think this is better text. > I wasn't there, but reading ballot-144, some cabforum mails, and=20 > = https://blog.torproject.org/blog/landmark-hidden-services-onion-names-rese= rved-ietf > it appears to me that all parties involved were actively trying to fix = a > long standing broken situation. Yes, that's what it looked like to me as well. From nobody Mon Jun 12 08:15:14 2017 Return-Path: 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 38A3F126FB3; Mon, 12 Jun 2017 08:15:12 -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] 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 siq9W18xccsb; Mon, 12 Jun 2017 08:15:11 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 D6CB6120726; Mon, 12 Jun 2017 08:15:10 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1A6B928067B; Mon, 12 Jun 2017 17:15:09 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 13B872806B3; Mon, 12 Jun 2017 17:15:09 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 0CEF628067B; Mon, 12 Jun 2017 17:15:09 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 06FB46079321; Mon, 12 Jun 2017 17:15:09 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id F3C3B40E20; Mon, 12 Jun 2017 17:15:08 +0200 (CEST) Date: Mon, 12 Jun 2017 17:15:08 +0200 From: Stephane Bortzmeyer To: Ted Lemon Cc: Job Snijders , Stephane Bortzmeyer , "dnsop@ietf.org WG" , ietf@ietf.org Message-ID: <20170612151508.s7xf5aamnme5ridb@nic.fr> References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> <20170612135200.ya3tivlhg2dhe3ry@nic.fr> <20170612150034.f4etrpuhbnvbzpzz@hanna.meerval.net> <7FA9EF11-83AF-4B1B-88D4-151108A47057@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FA9EF11-83AF-4B1B-88D4-151108A47057@fugue.com> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000564, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.6.12.150916 Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:15:12 -0000 On Mon, Jun 12, 2017 at 11:12:59AM -0400, Ted Lemon wrote a message of 31 lines which said: > Thanks, I think this is better text. Me too (no longer talks of "unilateral" use) From nobody Mon Jun 12 08:17:33 2017 Return-Path: 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 53F9A126FB3 for ; Mon, 12 Jun 2017 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 a97DW6W0tEaF for ; Mon, 12 Jun 2017 08:17:25 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 2ABE3127342 for ; Mon, 12 Jun 2017 08:17:25 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id w1so129169318qtg.2 for ; Mon, 12 Jun 2017 08:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E55qGa17/5orOBadChvN+ZY7WU+4I8GVP/9iap3v0sw=; b=VLk1n7LjlGr/xl3CTMu7ycniuv33linwQGpcSxI0Qrsu+PuDYFfyXOiuhqt8J4Iq7O szY4Eo01waqv26LEbgVMUwy3Ce67O6yaE8GW1S3yNoEr/5BIFEVVL0lYDKvA58OwBsD/ B9bGR6sirKYRxq3Q9huCQx2NNDuyFKc3l/SdT7WgQSfcb9KmlJl2mCNgzQmJl53y0rk+ gQBBOF9twNB2LBUN7CsVjyCImGSn+kySb0Mn3rj/lw0fDoPS4f53lVpx//l2pXtyQNBP e0ZdG6NuT8+mxWOyzl7+5Scu5jRU6bp5Npn2+0y6D2wdFCAskoR7tyZrPurAyCZy0cfZ TlOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=E55qGa17/5orOBadChvN+ZY7WU+4I8GVP/9iap3v0sw=; b=H1VNPlc+PecYjLw5jGAGPvtaYnBeJpVF911K8y2FCpxhKJ4qXLrgCxO3HOoe9uI6l2 sgcWNYzpow83tZ2a31vzkRAnvIq+cS4vcQh7HGy9CzJKJwd97aNI56Uvn3uAwZI8OA6/ B6D8n1Tp32WJ66ZO5McwDwtPMYZda6D1Kf45jBXdiVuGlqK4Y0NA22iXaMX20S5yZrbL tdD4XMDvdz3pwD3/tO6KjEAzM0D8MMp39OrvX5F7lGBX3bA09YYK0UxIJ9nyRMgpn2GW dBUFuJG6eY9aK2ggbWBeE5Qk1a1BFbL3JDu9W7pw99MTp3DI6YcCUph8el4vDUzwkQpQ n+SQ== X-Gm-Message-State: AKS2vOy2UAsxx2XOLc+Rs6YMxUjqjzwfX5tlZ1b/OW4tvAmu6ZdkgTeZ rNJfnAf4s3feS5KM X-Received: by 10.55.86.199 with SMTP id k190mr42146276qkb.70.1497280644353; Mon, 12 Jun 2017 08:17:24 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j6sm4923261qkd.0.2017.06.12.08.17.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 08:17:23 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8665EF6E-0DE7-49C0-8263-7827973BC937" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 12 Jun 2017 11:17:22 -0400 In-Reply-To: <20170612151508.s7xf5aamnme5ridb@nic.fr> Cc: Job Snijders , "dnsop@ietf.org WG" , ietf@ietf.org To: Stephane Bortzmeyer References: <149678027581.3850.9197039878287017082.idtracker@ietfa.amsl.com> <20170612135200.ya3tivlhg2dhe3ry@nic.fr> <20170612150034.f4etrpuhbnvbzpzz@hanna.meerval.net> <7FA9EF11-83AF-4B1B-88D4-151108A47057@fugue.com> <20170612151508.s7xf5aamnme5ridb@nic.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:17:27 -0000 --Apple-Mail=_8665EF6E-0DE7-49C0-8263-7827973BC937 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 12, 2017, at 11:15 AM, Stephane Bortzmeyer = wrote: > Me too (no longer talks of "unilateral" use) "unilateral" isn't a criticism. It's what happened. There's a reason = that it happened. I don't think we should minimize that. I disagree = with the idea that was advanced by some folks in dnsop during the .onion = discussion that the unilateral use of the name was bad. It was common = practice at the time.= --Apple-Mail=_8665EF6E-0DE7-49C0-8263-7827973BC937 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jun 12, 2017, at 11:15 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:
Me too (no longer = talks of "unilateral" use)

"unilateral" isn't a criticism.   It's = what happened.   There's a reason that it happened.   I don't = think we should minimize that.   I disagree with the idea that was = advanced by some folks in dnsop during the .onion discussion that the = unilateral use of the name was bad.   It was common practice at the = time.
= --Apple-Mail=_8665EF6E-0DE7-49C0-8263-7827973BC937-- From nobody Mon Jun 19 14:22:15 2017 Return-Path: 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 1611D126BFD for ; Mon, 19 Jun 2017 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 WpExMYgBMafe for ; Mon, 19 Jun 2017 14:22:12 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 EB4721200FC for ; Mon, 19 Jun 2017 14:22:11 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id a199so43797980qkb.2 for ; Mon, 19 Jun 2017 14:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=qE4ndpqqHFxtKQVEtz+s0FgWR8UWx2QSxefcpgoBL9Q=; b=nD6jQcBKxoFFu/YuJP19UFEM8U9STfsalcwAtTuwHWkV+40HT7iiW8Rzp3B1uwNF1W 5nPX/YsmAAH59xjsxtKRQyS7z3aMESqZiySlDkaPIoQLbU1ir2GiFJiTuSi5DB5T9LGF QLjod+6CSDwnU3bqX5HAHWdcJXVV2lHRS8isyKip04np18PLFYshBcvMWSQgHWx6kMPa 83AHDXu27kwg1DMJW4eSwwixNhTLz/cyTchX55ObgmYAWy38TNNe9TZADbFgsrryrYPq ywPdMmE4R9bMuhlYQhEl1tsFHfKVOqmnBI0XYNij/VktzLKbesxWgezh8gpnV/NKxrti 0dPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=qE4ndpqqHFxtKQVEtz+s0FgWR8UWx2QSxefcpgoBL9Q=; b=g7zYCL3jOszRa/iqoIstAW87anKnd/T0s00A5jL0nrc08QzhB54HNta3fWh9PTT/aH oEGYrEYKKu7Ccb3HOvFfvPh9Sm87mIJ8IEmIjnJj+hEB+34pSpCNcEYLO5EE9Om4Qurq uC14gxaSrORIShB6TmY5YGkXOSAGHztUdxspJw96ythQGGq11vOGtjvOXzcSCNLJFLPk D753jnRa71x9SANy5Tj4NUdI5rlxSavaWa8UjigTVH10Xi5el+JKoP3gwxMEIsIxezv3 IvMXvChRWwUhjLoUDaygINBZLqmRFFevEwAJyyEM54GS9+l8Cy1PDhokBrMUHBr4sfx9 LJuw== X-Gm-Message-State: AKS2vOyubllH8M6x+paTQbqQjVKUJb5E9NgSjbTzGdtg9mFH16nsruAI B96SkF7OAlbjamOe7YE= X-Received: by 10.55.160.196 with SMTP id j187mr19159337qke.145.1497907330940; Mon, 19 Jun 2017 14:22:10 -0700 (PDT) Received: from ?IPv6:2601:181:c381:c20:fd6f:527b:53cd:e5fd? ([2601:181:c381:c20:fd6f:527b:53cd:e5fd]) by smtp.gmail.com with ESMTPSA id j54sm7889621qtc.59.2017.06.19.14.22.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Jun 2017 14:22:10 -0700 (PDT) From: Suzanne Woolf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <681AC410-2F7D-449E-9521-8512EEFB8BD9@gmail.com> Date: Mon, 19 Jun 2017 17:22:07 -0400 To: dnsop Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DNSOP] IETF 99: Call for agenda items, and draft cutoff reminder X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 21:22:14 -0000 Hi all, IETF 99 is advancing rapidly upon us=E2=80=A6. DNSOP has two sessions scheduled in the preliminary agenda, Tuesday = 15:50-17:50 and Thursday 18:10-19:10. In the interests of managing that = time well, we=E2=80=99d like to hear from you ASAP if you=E2=80=99re = asking for agenda time. As always=E2=80=94 we=E2=80=99ll prioritize work that will advance WG = drafts, and new work that=E2=80=99s already gained some interest on the = mailing list. Note also that the draft cutoff is in two weeks, on July 3. If you=E2=80=99= ve got a WG draft with pending changes, or a draft you=E2=80=99d like = the WG to consider for adoption, please have the latest and greatest = version submitted by then. thanks, your faithful chairs (Tim & Suzanne) From nobody Tue Jun 20 09:20:43 2017 Return-Path: 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 EF680131BAC; Tue, 20 Jun 2017 09:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149797563284.24962.2742952678813993170@ietfa.amsl.com> Date: Tue, 20 Jun 2017 09:20:32 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:20:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : DNS Transport over TCP - Operational Requirements Authors : John Kristoff Duane Wessels Filename : draft-ietf-dnsop-dns-tcp-requirements-00.txt Pages : 12 Date : 2017-06-20 Abstract: This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. It also describes some of the consequences of this behavior and the potential operational issues that can arise when this best common practice is not upheld. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-tcp-requirements-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 23 00:41:55 2017 Return-Path: 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 AD95C129C36; Fri, 23 Jun 2017 00:41:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149820371366.17326.16615854829782545228@ietfa.amsl.com> Date: Fri, 23 Jun 2017 00:41:53 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 07:41:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : A DNS Query including A Main Question with Accompanying Questions Authors : Jiankang Yao Paul Vixie Ning Kong Xiaodong Li Filename : draft-yao-dnsop-accompanying-questions-03.txt Pages : 11 Date : 2017-06-23 Abstract: This document enables DNS initiators to send a main question accompanying with several related questions in a single DNS query, and enables DNS responders to put the answers into a single DNS response. This extension enables a range of initiators to look up "X, or failing that, Y" in a better way than both current alternatives. This mechanism can reduce the number of DNS round- trips per application work-unit. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-03 https://datatracker.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 23 01:26:57 2017 Return-Path: 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 5683312EA8D for ; Fri, 23 Jun 2017 01:26:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 AfGnvaIlfBZC for ; Fri, 23 Jun 2017 01:26:53 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id DDD50129B60 for ; Fri, 23 Jun 2017 01:26:50 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.224]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApVonG0ExZFlVdKw--.10430S2; Fri, 23 Jun 2017 16:26:46 +0800 (CST) Date: Fri, 23 Jun 2017 16:26:33 +0800 From: "Jiankang Yao" To: dnsop Reply-To: yaojk X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20170623162604407257182@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart564116435613_=----" X-CM-TRANSID: AQAAf0ApVonG0ExZFlVdKw--.10430S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr43tFW3KFW8WrWrtF47urg_yoWrAr1kpa 9xtrZrKa4qqr18Cr97Jw18XF4UKa93JrW7JFn5Kr10vwn0kF1qqF48KayFva47Ca4xAr9F qF1Ivw1DW3WYvFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvCb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lc2xSY4AK 67AK6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2Kf nxnUUI43ZEXa7IU5dEf7UUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 08:26:56 -0000 This is a multi-part message in MIME format. ------=_001_NextPart564116435613_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGVsbG8sDQogICAgIA0KICAgICBCYXNlZCBvbiBTZW91bCBJRVRGJ3MgZGlzY3Vzc2lvbiwgSSBy ZWZpbmUgdGhlIGludHJvZHVjdGlvbiBvZiB0aGlzIGRvY3VtZW50IHRvIGV4cGxhaW4gdGhlIG1v dGl2YXRpb24gYW5kIGNvbXBhcmUgd2l0aCBvdGhlciBtZWNoYW5pc21zLg0KdGhlIGtleSB0ZXh0 IGlzIGhlcmU6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgU29tZXRpbWVzLCB3aGVuIEROUyBsb29rdXAgb2YgWCwg YW4gYXBwbGljYXRpb24gd2lsbCBsb29rdXAgWSBpZiBYDQogICBmYWlscy4gIEZvciBleGFtcGxl cywgdGhlIGluaXRpYXRvciBtYXkgZmFsbCBiYWNrIHRvIEEgcmVjb3JkIGlmIHRoZQ0KICAgbG9v a3VwIG9mIE1YIHJlY29yZCBmYWlscy4NCg0KICAgU29tZSBpbml0aWF0b3JzIGRvIGl0IGluIHNl cXVlbmNlLCBYIGFuZCBhZnRlciBhIGZldyBzZWNvbmRzLCB0aGVuIFkuDQogICBBbHRob3VnaCBp dCBpcyBzaW1wbGUsIHRoaXMgbGVhZHMgdG8gdW5wbGVhc2FudCB3YWl0aW5nIHdoZW5ldmVyIFgN CiAgIHRpbWVzIG91dCBvciBhbnN3ZXJzIG5lZ2F0aXZlbHkuDQoNCiAgIFNvbWUgaW5pdGlhdG9y cyB1c2UgY29uY3VycmVudCBYL1kgbG9va3VwcyBhbmQgYSBzdGF0ZSBtYWNoaW5lIHRvDQogICBk ZWNpZGUgd2hldGhlciB0byB1c2UgWCBvciBZLiAgSWYgYW4gYW5zd2VyIHRvIFkgYXJyaXZlcyBi dXQgbm9uZSB0bw0KICAgWCwgdGhlIGluaXRpYXRvciBuZWVkcyB0byB3YWl0IGEgbGl0dGxlIG9y IGVsc2UgZmFsbCBiYWNrIHRvIFkNCiAgIGluYXBwcm9wcmlhdGVseS4gIENvbmN1cnJlbnQgbG9v a3VwIGlzIGZhc3RlciBpZiB0aGUgWCBsb29rdXAgdGFrZXMNCiAgIHRpbWUgYW5kIGZhbGxpbmcg YmFjayB0byBZIGlzIGFwcHJvcHJpYXRlLCBidXQgcmF0aGVyIGNvbXBsZXgsIHdpdGgNCiAgIGZv dXIgc3RhdGVzIHRvIHRlc3QsIGFuZCB0aGUgaW5pdGlhdG9yIG5lZWRzIHRvIHdhaXQgZm9yIGFu IGFuc3dlciB0bw0KICAgWCBvciBhIHRpbWVvdXQgYmVmb3JlIGl0IGNhbiB1c2UgWS4NCg0KICAg VGhpcyBkb2N1bWVudCBlbmFibGVzIGEgcXVpY2tlciwgbW9yZSBlYXNpbHkgdGVzdGVkIGZhaWxv dmVyLiAgVGhlcmUNCiAgIGlzIG5vIG5lZWQgdG8gdGVzdCBkaWZmZXJlbnQgYW5zd2VyIHNlcXVl bmNlcywgdGhlcmUncyBubyBuZWVkIGZvciBhDQogICBzdGF0ZSBtYWNoaW5lLCB0aGVyZSdzIG5v IG5lZWQgZm9yIHRpbWVvdXRzIGJleW9uZCByZWNlaXZpbmcgdGhlDQogICByZXBseS4gIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIGJ5IHdoaWNoIEROUyBpbml0aWF0b3JzIGNhbg0K ICAgc2VuZCBhIG1haW4gcXVlc3Rpb24gYWNjb21wYW55aW5nIHdpdGggc2V2ZXJhbCByZWxhdGVk IHF1ZXN0aW9ucyBpbiBhDQogICBzaW5nbGUgRE5TIHF1ZXJ5LCBhbmQgZW5hYmxlcyBETlMgcmVz cG9uZGVycyBwbGFjZSBhbGwgcmVsYXRlZA0KICAgYW5zd2VycyBpbnRvIGEgc2luZ2xlIEROUyBy ZXNwb25zZS4gIFRoaXMgbWVjaGFuaXNtIGNhbiByZWR1Y2UgdGhlDQogICBudW1iZXIgb2YgRE5T IHJvdW5kLXRyaXBzIHBlciBhcHBsaWNhdGlvbiB3b3JrLXVuaXQsIGJ5IGNhcnJ5aW5nDQogICBz ZXZlcmFsIHJlbGF0ZWQgcXVlcmllcyBpbiBhIHNpbmdsZSBxdWVyeSB0cmFuc2FjdGlvbi4gIEl0 IGhhcyB0aGUNCiAgIGZvbGxvd2luZyBhZHZhbnRhZ2VzIGNvbXBhcmVkIHRvIG90aGVyIHNvbHV0 aW9ucy4NCg0KICAgbyAgQ29tcGFyZWQgdG8gc2VxdWVudGlhbCBsb29rdXBzOiBJdCdzIHJvdWdo bHkgYXMgc2ltcGxlLCBidXQgbXVjaA0KICAgICAgZmFzdGVyIGluIGNhc2UgYSBmYWxsYmFjayB0 byBZIGlzIG5lY2Vzc2FyeS4NCg0KICAgbyAgQ29tcGFyZWQgdG8gdGhlIGNvbmN1cnJlbnQgbWVj aGFuaXNtOiBJdCBpcyBzbGlnaHRseSBmYXN0ZXIgKGlmDQogICAgICB0aGUgaW5pdGlhdG9yIG5l ZWRzIHRvIHdhaXQgZm9yIGFuIFggdGltZW91dCkgYW5kL29yIHByZXZlbnRzDQogICAgICBpbmFw cHJvcHJpYXRlIGZhbGxiYWNrIChpZiB0aGUgYW5zd2VyIHRvIFggYXJyaXZlcyB0b28gbGF0ZSks IGFuZA0KICAgICAgaXQgaGFzIGEgc2ltcGxlciBzdGF0ZSBtYWNoaW5lLg0KDQogICBUaGlzIG1l Y2hhbmlzbSBjYW4gYWxzbyBiZSB1c2VkIGluIHRoZSBzY2VuYXJpb3Mgd2hlbiB0aGUgYXBwbGlj YXRpb24NCiAgIG5lZWRzIG1vcmUgcmVjb3JkcyBvZiB0aGUgc2FtZSBkb21haW4gbmFtZSBvciBp dHMgc3ViLWRvbWFpbiBuYW1lLg0KICAgRm9yIGV4YW1wbGVzLCB3aGVuIGFza2luZyBhYm91dCBh IFFUWVBFPUEgUlJzZXQsIGEgUVRZUEU9QUFBQSBSUnNldA0KICAgbWF5IGFsc28gYmUgb2YgdXNl IFtSRkMgNTMyMV07IFdoZW4gYXNraW5nIGZvciBzb21lIFJSc2V0IG9mDQogICB3d3cuZXhhbXBs ZS5jb20gYWJvdXQgQSBhbmQgQUFBQSwgcmVjb3JkcyBvZiBhIHN1Yi1kb21haW4gbmFtZSBzdWNo DQogICBhcyBfNDQzLl90Y3Aud3d3LmV4YW1wbGUuY29tIGZvciBUTFNBIG1heSBiZSBvZiBpbnRl cmVzdFtSRkMgNjY5OF0uDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KDQoNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHMNCkRhdGU6IDIwMTctMDYtMjMgMTU6NDENClRvOiBYaWFvRG9uZyBMZWU7IE5pbmcgS29uZzsg UGF1bCBWaXhpZTsgSmlhbmthbmcgWWFvOyBYaWFvZG9uZyBMaQ0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15YW8tZG5zb3AtYWNjb21wYW55aW5nLXF1ZXN0aW9u cy0wMy50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlhby1kbnNvcC1hY2NvbXBh bnlpbmctcXVlc3Rpb25zLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBKaWFua2FuZyBZYW8gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogZHJhZnQteWFvLWRuc29wLWFjY29tcGFueWluZy1xdWVzdGlvbnMNClJldmlzaW9uOiAwMw0K VGl0bGU6IEEgRE5TIFF1ZXJ5IGluY2x1ZGluZyBBIE1haW4gUXVlc3Rpb24gd2l0aCBBY2NvbXBh bnlpbmcgUXVlc3Rpb25zDQpEb2N1bWVudCBkYXRlOiAyMDE3LTA2LTIzDQpHcm91cDogZG5zb3AN ClBhZ2VzOiAxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC15YW8tZG5zb3AtYWNjb21wYW55aW5nLXF1ZXN0aW9ucy0wMy50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15YW8t ZG5zb3AtYWNjb21wYW55aW5nLXF1ZXN0aW9ucy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFvLWRuc29wLWFjY29tcGFueWluZy1xdWVzdGlvbnMt MDMNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LXlhby1kbnNvcC1hY2NvbXBhbnlpbmctcXVlc3Rpb25zLTAzDQpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXlhby1kbnNvcC1hY2Nv bXBhbnlpbmctcXVlc3Rpb25zLTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBlbmFi bGVzIEROUyBpbml0aWF0b3JzIHRvIHNlbmQgYSBtYWluIHF1ZXN0aW9uDQogICBhY2NvbXBhbnlp bmcgd2l0aCBzZXZlcmFsIHJlbGF0ZWQgcXVlc3Rpb25zIGluIGEgc2luZ2xlIEROUyBxdWVyeSwN CiAgIGFuZCBlbmFibGVzIEROUyByZXNwb25kZXJzIHRvIHB1dCB0aGUgYW5zd2VycyBpbnRvIGEg c2luZ2xlIEROUw0KICAgcmVzcG9uc2UuICBUaGlzIGV4dGVuc2lvbiBlbmFibGVzIGEgcmFuZ2Ug b2YgaW5pdGlhdG9ycyB0byBsb29rIHVwDQogICAiWCwgb3IgZmFpbGluZyB0aGF0LCBZIiBpbiBh IGJldHRlciB3YXkgdGhhbiBib3RoIGN1cnJlbnQNCiAgIGFsdGVybmF0aXZlcy4gIFRoaXMgbWVj aGFuaXNtIGNhbiByZWR1Y2UgdGhlIG51bWJlciBvZiBETlMgcm91bmQtDQogICB0cmlwcyBwZXIg YXBwbGljYXRpb24gd29yay11bml0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ= ------=_001_NextPart564116435613_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
hello,
    
     Based on Seoul IETF's discussion, I refine t= he=20 introduction of this document to explain the motivation and compare w= ith=20 other mechanisms.
the key text is here:
---------------------------------------------
1.  Introduction
 
   Sometimes, when DNS lookup of&n= bsp;X, an application will lookup Y if = X
   fails.  For examples, the = initiator may fall back to A record if&= nbsp;the
   lookup of MX record fails.
 
   Some initiators do it in s= equence, X and after a few seconds, the= n Y.
   Although it is simple, this&nbs= p;leads to unpleasant waiting whenever X
   times out or answers negatively= .
 
   Some initiators use concurrent = X/Y lookups and a state machine to
   decide whether to use X or=  Y.  If an answer to Y arrives&nbs= p;but none to
   X, the initiator needs to = wait a little or else fall back to = ;Y
   inappropriately.  Concurrent lookup&= nbsp;is faster if the X lookup takes
   time and falling back to Y=  is appropriate, but rather complex, with
   four states to test, and t= he initiator needs to wait for an answe= r to
   X or a timeout before it&n= bsp;can use Y.
 
   This document enables a quicker= , more easily tested failover.  There
   is no need to test differe= nt answer sequences, there's no need for&nbs= p;a
   state machine, there's no need&= nbsp;for timeouts beyond receiving the
   reply.  This document describes=  a method by which DNS initiators can
   send a main question accompanyi= ng with several related questions in a
   single DNS query, and enables&n= bsp;DNS responders place all related
   answers into a single DNS = response.  This mechanism can reduce the
   number of DNS round-trips per&n= bsp;application work-unit, by carrying
   several related queries in a&nb= sp;single query transaction.  It has the
   following advantages compared to&nbs= p;other solutions.
 
   o  Compared to sequential = lookups: It's roughly as simple, but much
      faster in case a&n= bsp;fallback to Y is necessary.
 
   o  Compared to the concurr= ent mechanism: It is slightly faster (if
      the initiator needs&nbs= p;to wait for an X timeout) and/or prev= ents
      inappropriate fallback = (if the answer to X arrives too late),&= nbsp;and
      it has a simpler&n= bsp;state machine.
 
   This mechanism can also be = ;used in the scenarios when the application<= /DIV>
   needs more records of the = same domain name or its sub-domain name.
   For examples, when asking about=  a QTYPE=3DA RRset, a QTYPE=3DAAAA RRset
   may also be of use [RFC&nb= sp;5321]; When asking for some RRset of
   www.example.com about A and AAA= A, records of a sub-domain name such
   as _443._tcp.www.example.com for TLS= A may be of interest[RFC 6698].
 
 
--------------------------------------------
 
 
 
Jiankang Yao
 
From: internet-drafts
Date: 2017-06-23 15:41
To: XiaoDong Lee; Ning Kong; Paul=20 Vixie; Jiankang Yao; Xiaodong Li
Subject: New Version Notification for=20 draft-yao-dnsop-accompanying-questions-03.txt
 
A new version of I-D, draft-yao-dnsop-accomp= anying-questions-03.txt
has been successfully submitted by Jiankang&= nbsp;Yao and posted to the
IETF repository.
 
Name: draft-yao-dnsop-accompanying-questions
Revision: 03
Title:=20 A DNS Query including A Main Question w= ith Accompanying Questions
Document date: 2017-06-23
Group: dnsop
Pages: 11
URL:           = ; https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-q= uestions-03.txt
Status:         https://= datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/
Htmlized:       https://tools.ietf= .org/html/draft-yao-dnsop-accompanying-questions-03
Htmlized:       https://datatracke= r.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03
Diff:          &nbs= p;https://www.ietf.org/rfcdiff?url2=3Ddraft-yao-dnsop-accompanying-questio= ns-03
 
Abstract:
   This document enables DNS initi= ators to send a main question
   accompanying with several related&nb= sp;questions in a single DNS query,
   and enables DNS responders to&n= bsp;put the answers into a single DNS
   response.  This extension enabl= es a range of initiators to look up
   "X, or failing that, Y" in=  a better way than both current
   alternatives.  This mechanism c= an reduce the number of DNS round-
   trips per application work-unit.
 
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;        
 
 
Please note that it may take a cou= ple of minutes from the time of submiss= ion
until the htmlized version and diff are=  available at tools.ietf.org.
 
The IETF Secretariat
 
------=_001_NextPart564116435613_=------ From nobody Fri Jun 23 03:55:00 2017 Return-Path: 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 9BBBD1200ED for ; Fri, 23 Jun 2017 03:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 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, 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 QnLmC11XF9fA for ; Fri, 23 Jun 2017 03:54:56 -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 E13A5128B51 for ; Fri, 23 Jun 2017 03:54:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 22478B810AB; Fri, 23 Jun 2017 03:54:34 -0700 (PDT) To: olafur+ietf@cloudflare.com, pwouters@redhat.com, bclaise@cisco.com, warren@kumari.net, suzworldwide@gmail.com, tjw.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: Ondrej.Caletka@cesnet.cz, dnsop@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170623105434.22478B810AB@rfc-editor.org> Date: Fri, 23 Jun 2017 03:54:34 -0700 (PDT) Archived-At: Subject: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:54:58 -0000 The following errata report has been submitted for RFC8078, "Managing DS Records from the Parent via CDS/CDNSKEY". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5049 -------------------------------------- Type: Technical Reported by: Ondřej Caletka Section: 4 Original Text ------------- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 0 CDNSKEY 0 3 0 0 The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 0" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Corrected Text -------------- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 00 CDNSKEY 0 3 0 AA== The keying material payload is represented by a single octet with the value 00. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 00" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Notes ----- RFC 7344 defines both CDS and CDNSKEY record wire and presentation format to be identical to DS and DNSKEY wire and presentation format defined in RFC 4034. In case of CDNSKEY record, RFC 4034 section 2.2 requires that: > The Public Key field MUST be represented as a Base64 encoding of the Public Key. As Base64 encoding encodes 6 bits into one character, one character alone can never be a valid Base64 sequence. The proper encoding of one-byte long sequence with binary value of 00 is AA==. In case of CDS record, RFC 4034 section 5.3 requires that: > The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits Although the value of a single 0 fulfils this requirement per se, it's not properly parsable by many implementations since it is expected to be even number of hex digits to align with octet boundaries in the wire format. So proper form of CDS record should contain two zeroes in place of the digest. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8078 (draft-ietf-dnsop-maintain-ds-06) -------------------------------------- Title : Managing DS Records from the Parent via CDS/CDNSKEY Publication Date : March 2017 Author(s) : O. Gudmundsson, P. Wouters Category : PROPOSED STANDARD Source : Domain Name System Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Jun 23 04:37:50 2017 Return-Path: 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 BFD51127342 for ; Fri, 23 Jun 2017 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cloudflare.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 CE5U_F0KGlso for ; Fri, 23 Jun 2017 04:37:46 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 96BB812EAB2 for ; Fri, 23 Jun 2017 04:37:46 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i2so32126412qta.3 for ; Fri, 23 Jun 2017 04:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZZdBB2QBUSch+d3wr6ued/H2MV6JVOnl1z4x+v7sdNE=; b=YcJbWWyq76ZUaX9wEkxtv9rVfuZvbCxMyM/pnujSGy0epenTMk6AomRB2boU2tobWv qrB4j0Jmvyh08ygfJTCK060TaFs2RmXVcSryDQsNUbWAWix/J5XM7S/QYqb5kA3Oj335 yCCKA/4+OISDybNvX+/UwM5zxq3muLEDhUjHc= 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=ZZdBB2QBUSch+d3wr6ued/H2MV6JVOnl1z4x+v7sdNE=; b=jTKiY4CqU7834fxJDqNQn8ySY/w6ENvbeeXMJ6Nd1MzgY8F9vQSCerfpxjHFjnHJul eecDzs5+ngJCaJrrl/UXkMv1jGPM3jJcVTzXrY6ODesDSbsc2zE8XiSjKihjLxp9ouIK Q6v0I0lCh3H9CSh04XvavvMLw/e7xfRlZ6MDFlIr3tTkK2K9AMo96lgCtm048LPQvudp jHzCAK/h9hEdjaAmI1olvJaMpjqiINP6eKUXJXMXxYtQ9XcBW7+F0m8ANKg7p1PT/llj AJB5K9aP/vnBFyUdI0I+Tk+02z1AlTmpi4SFAuigjLwvD12pFqAd/F900jCQTD2VMCGC qGdw== X-Gm-Message-State: AKS2vOzi//GucY0JgGzMHUw9BaHIv9EuWk8n4Q5ToOP3Nft0PZY45E3i BNFtFYldqi8nPjj5+22n4Vf7tO/G3LIt X-Received: by 10.237.40.97 with SMTP id r88mr9333869qtd.27.1498217865743; Fri, 23 Jun 2017 04:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.181 with HTTP; Fri, 23 Jun 2017 04:37:45 -0700 (PDT) Received: by 10.140.94.181 with HTTP; Fri, 23 Jun 2017 04:37:45 -0700 (PDT) In-Reply-To: <20170623105434.22478B810AB@rfc-editor.org> References: <20170623105434.22478B810AB@rfc-editor.org> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Fri, 23 Jun 2017 12:37:45 +0100 Message-ID: To: RFC Editor Cc: Warren Kumari , Olafur Gudmundsson , tjw.ietf@gmail.com, pwouters@redhat.com, Ondrej.Caletka@cesnet.cz, dnsop@ietf.org, suzworldwide@gmail.com, bclaise@cisco.com Content-Type: multipart/alternative; boundary="94eb2c068b34af1f9b05529f0704" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 11:37:49 -0000 --94eb2c068b34af1f9b05529f0704 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The errata is correct. =C3=93lafur sent from phone On Jun 23, 2017 11:54, "RFC Errata System" wrote: > The following errata report has been submitted for RFC8078, > "Managing DS Records from the Parent via CDS/CDNSKEY". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5049 > > -------------------------------------- > Type: Technical > Reported by: Ond=C5=99ej Caletka > > Section: 4 > > Original Text > ------------- > The contents of the CDS or CDNSKEY RRset MUST contain one RR and only > contain the exact fields as shown below. > > CDS 0 0 0 0 > > CDNSKEY 0 3 0 0 > > The keying material payload is represented by a single 0. This > record is signed in the same way as regular CDS/CDNSKEY RRsets are > signed. > > Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the > DNSKEY algorithm is what signals the DELETE operation, but for > clarity, the "0 0 0 0" notation is mandated -- this is not a > definition of DS digest algorithm 0. The same argument applies to > "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by > [RFC4034], Section 2.1.2. > > > Corrected Text > -------------- > The contents of the CDS or CDNSKEY RRset MUST contain one RR and only > contain the exact fields as shown below. > > CDS 0 0 0 00 > > CDNSKEY 0 3 0 AA=3D=3D > > The keying material payload is represented by a single octet with > the value 00. This record is signed in the same way as regular > CDS/CDNSKEY RRsets are signed. > > Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the > DNSKEY algorithm is what signals the DELETE operation, but for > clarity, the "0 0 0 00" notation is mandated -- this is not a > definition of DS digest algorithm 0. The same argument applies to > "CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second field is mandated = by > [RFC4034], Section 2.1.2. > > Notes > ----- > RFC 7344 defines both CDS and CDNSKEY record wire and presentation format > to be identical to DS and DNSKEY wire and presentation format defined in > RFC 4034. > > In case of CDNSKEY record, RFC 4034 section 2.2 requires that: > > The Public Key field MUST be represented as a Base64 encoding of the > Public Key. > > As Base64 encoding encodes 6 bits into one character, one character alone > can never be a valid Base64 sequence. The proper encoding of one-byte lon= g > sequence with binary value of 00 is AA=3D=3D. > > In case of CDS record, RFC 4034 section 5.3 requires that: > > The Digest MUST be represented as a sequence of case-insensitive > hexadecimal digits > > Although the value of a single 0 fulfils this requirement per se, it's no= t > properly parsable by many implementations since it is expected to be even > number of hex digits to align with octet boundaries in the wire format. S= o > proper form of CDS record should contain two zeroes in place of the diges= t. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8078 (draft-ietf-dnsop-maintain-ds-06) > -------------------------------------- > Title : Managing DS Records from the Parent via CDS/CDNSKEY > Publication Date : March 2017 > Author(s) : O. Gudmundsson, P. Wouters > Category : PROPOSED STANDARD > Source : Domain Name System Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > --94eb2c068b34af1f9b05529f0704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The errata is correct.

=C3=93lafur

sent from phone

<= div class=3D"gmail_quote">On Jun 23, 2017 11:54, "RFC Errata System&qu= ot; <rfc-editor@rfc-editor.= org> wrote:
T= he following errata report has been submitted for RFC8078,
"Managing DS Records from the Parent via CDS/CDNSKEY".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5049

--------------------------------------
Type: Technical
Reported by: Ond=C5=99ej Caletka <Ondrej.Caletka@cesnet.cz>

Section: 4

Original Text
-------------
=C2=A0 =C2=A0The contents of the CDS or CDNSKEY RRset MUST contain one RR a= nd only
=C2=A0 =C2=A0contain the exact fields as shown below.

=C2=A0 =C2=A0 =C2=A0 CDS 0 0 0 0

=C2=A0 =C2=A0 =C2=A0 CDNSKEY 0 3 0 0

=C2=A0 =C2=A0The keying material payload is represented by a single 0.=C2= =A0 This
=C2=A0 =C2=A0record is signed in the same way as regular CDS/CDNSKEY RRsets= are
=C2=A0 =C2=A0signed.

=C2=A0 =C2=A0Strictly speaking, the CDS record could be "CDS X 0 X 0&q= uot; as only the
=C2=A0 =C2=A0DNSKEY algorithm is what signals the DELETE operation, but for=
=C2=A0 =C2=A0clarity, the "0 0 0 0" notation is mandated -- this = is not a
=C2=A0 =C2=A0definition of DS digest algorithm 0.=C2=A0 The same argument a= pplies to
=C2=A0 =C2=A0"CDNSKEY 0 3 0 0"; the value 3 in the second field i= s mandated by
=C2=A0 =C2=A0[RFC4034], Section 2.1.2.


Corrected Text
--------------
=C2=A0 =C2=A0The contents of the CDS or CDNSKEY RRset MUST contain one RR a= nd only
=C2=A0 =C2=A0contain the exact fields as shown below.

=C2=A0 =C2=A0 =C2=A0 CDS 0 0 0 00

=C2=A0 =C2=A0 =C2=A0 CDNSKEY 0 3 0 AA=3D=3D

=C2=A0 =C2=A0The keying material payload is represented by a single octet w= ith
=C2=A0 =C2=A0the value 00. This record is signed in the same way as regular=
=C2=A0 =C2=A0CDS/CDNSKEY RRsets are signed.

=C2=A0 =C2=A0Strictly speaking, the CDS record could be "CDS X 0 X 00&= quot; as only the
=C2=A0 =C2=A0DNSKEY algorithm is what signals the DELETE operation, but for=
=C2=A0 =C2=A0clarity, the "0 0 0 00" notation is mandated -- this= is not a
=C2=A0 =C2=A0definition of DS digest algorithm 0.=C2=A0 The same argument a= pplies to
=C2=A0 =C2=A0"CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second = field is mandated by
=C2=A0 =C2=A0[RFC4034], Section 2.1.2.

Notes
-----
RFC 7344 defines both CDS and CDNSKEY record wire and presentation format t= o be identical to DS and DNSKEY wire and presentation format defined in RFC= 4034.

In case of CDNSKEY record, RFC 4034 section 2.2 requires that:
> The Public Key field MUST be represented as a Base64 encoding of the P= ublic Key.

As Base64 encoding encodes 6 bits into one character, one character alone c= an never be a valid Base64 sequence. The proper encoding of one-byte long s= equence with binary value of 00 is AA=3D=3D.

In case of CDS record, RFC 4034 section 5.3 requires that:
> The Digest MUST be represented as a sequence of case-insensitive hexad= ecimal digits

Although the value of a single 0 fulfils this requirement per se, it's = not properly parsable by many implementations since it is expected to be ev= en number of hex digits to align with octet boundaries in the wire format. = So proper form of CDS record should contain two zeroes in place of the dige= st.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8078 (draft-ietf-dnsop-maintain-ds-06)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Managing DS R= ecords from the Parent via CDS/CDNSKEY
Publication Date=C2=A0 =C2=A0 : March 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: O. Gudmundsson, P. Wout= ers
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Domain Name System= Operations
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--94eb2c068b34af1f9b05529f0704-- From nobody Fri Jun 23 17:16:01 2017 Return-Path: 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 2ABF112EB74; Fri, 23 Jun 2017 17:07:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dnsop@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283617.7840.3987649677825968322.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:16 -0700 Archived-At: Subject: [DNSOP] dnsop - Requested sessions have been scheduled for IETF 99 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:16 -0000 Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (2:00:00) Tuesday, Afternoon Session II 1550-1750 Room Name: Congress Hall II size: 350 --------------------------------------------- dnsop Session 2 (1:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dprive dnssd homenet appsawg apparea dhc Second Priority: v6ops intarea trans Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks --------------------------------------------------------- From nobody Sat Jun 24 06:26:26 2017 Return-Path: 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 10B5712871F for ; Sat, 24 Jun 2017 06:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Dh__Cxu9WPIt for ; Sat, 24 Jun 2017 06:26:22 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 866AC127342 for ; Sat, 24 Jun 2017 06:26:22 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id r67so46545701ota.1 for ; Sat, 24 Jun 2017 06:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dr7c+l/w5JT1B18CeO3tJDGCx3JTiXZxL2O8NpiE3Ro=; b=bwOEgTqxOZ0ob+bnT5mSPK3WRrfMoXtSnnQeoEPczC6imlTUhMEKL/7NVJ0Kdxbgee Y35CKwmXazGBu34S3s9kpVo47TGAcvc2wknWAo2Dlw11Uv2MeFnQOv8Kt16JzMYQ+BKL AaqG4W+sCFyqXiVfMe0lt6yyPq3zBS0Gz9ZOvGJnwJDF9Iyv1XY2gw4ouIHZnDgdrFGK /2eb+YUcz5WIXL3xmwZSPGoCqS1p96w6DEeeuJ3ljhL0bE/rRr/6cM92M1125Nx+wlcN prvO5wV6c9X7ZIINck4nQtdbkx+pZTESlriH6qX7XnVpDTLcufA1EMAzfeRkCGF35bjW qXyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dr7c+l/w5JT1B18CeO3tJDGCx3JTiXZxL2O8NpiE3Ro=; b=b0mQvjhIzZVBC1y8FzRHa/xtYTvyd/KTh0foXhs7RuLnDS46khMhIuc6+8MVXoexnP 796/I0N09XJpuclHe114kYuB8sjJONt3j6qpIAQzQu1aPzOr3vA4Ede96lFKS3TaSc+x fVOZ907cmZr6DO/vFEZpEYFQOHiLQ4/gV7Q+bkAdxrLNKOWKBhDYfYoCX24KUp97Q+D5 GnzkRY7Zny2g9GzguaL002rIsU5hXymmSdRyIq5Qbh5feetcLPyxsBGLNywv1D0YpWrE TNQwXpD6I3k1+Hc0R4wakFLEUcVZpXOQf0WHIgyOm0UzR+hbHbXNN2YEduuEMUHEgK96 fzsA== X-Gm-Message-State: AKS2vOymGeuCr97HYqMMusqQYXuFY2vMO1QzG5itzqvYtDrKl1LCUpwT NOEa/4LhJI/os2usCU3bXZeyxgBX3w== X-Received: by 10.157.21.39 with SMTP id u36mr6337140otf.187.1498310781851; Sat, 24 Jun 2017 06:26:21 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Sat, 24 Jun 2017 06:25:41 -0700 (PDT) In-Reply-To: References: <20170623105434.22478B810AB@rfc-editor.org> From: Dick Franks Date: Sat, 24 Jun 2017 14:25:41 +0100 X-Google-Sender-Auth: v_3doeh0PgWVYJh0NjXOWU5y_os Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Cc: RFC Editor , tjw.ietf@gmail.com, Ondrej.Caletka@cesnet.cz, IETF DNSOP WG , suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson Content-Type: multipart/alternative; boundary="94eb2c18d616ea5ba20552b4a947" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 13:26:25 -0000 --94eb2c18d616ea5ba20552b4a947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comments in line below On 23 June 2017 at 12:37, =C3=93lafur Gu=C3=B0mundsson wrote: > The errata is correct. > I beg to disagree. In each case, CDS 0 0 0 0 CDNSKEY 0 3 0 0 the final "0" is a conventional token representing a zero-length key field. In neither case is it an attempt to specify a single octet key value. A zone file parser is expected to recognise the zero algorithm field and hence abstain from attempting to parse the non-existent key. The fact that the placeholder is unparseable should be regarded not as an error but a useful feature designed to root out under-performing zone file parsers. However, all of this confusion could have been avoided if RFC8078 had also specified the corresponding RDATA wire format in each case. Although this erratum should be rejected as it stands, it clearly does identify an issue with RFC8078 which needs to be rectified at the earliest opportunity. --Dick On Jun 23, 2017 11:54, "RFC Errata System" > wrote: > >> The following errata report has been submitted for RFC8078, >> "Managing DS Records from the Parent via CDS/CDNSKEY". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5049 >> >> -------------------------------------- >> Type: Technical >> Reported by: Ond=C5=99ej Caletka >> >> Section: 4 >> >> Original Text >> ------------- >> The contents of the CDS or CDNSKEY RRset MUST contain one RR and only >> contain the exact fields as shown below. >> >> CDS 0 0 0 0 >> >> CDNSKEY 0 3 0 0 >> >> The keying material payload is represented by a single 0. This >> record is signed in the same way as regular CDS/CDNSKEY RRsets are >> signed. >> >> Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the >> DNSKEY algorithm is what signals the DELETE operation, but for >> clarity, the "0 0 0 0" notation is mandated -- this is not a >> definition of DS digest algorithm 0. The same argument applies to >> "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by >> [RFC4034], Section 2.1.2. >> >> >> Corrected Text >> -------------- >> The contents of the CDS or CDNSKEY RRset MUST contain one RR and only >> contain the exact fields as shown below. >> >> CDS 0 0 0 00 >> >> CDNSKEY 0 3 0 AA=3D=3D >> >> The keying material payload is represented by a single octet with >> the value 00. This record is signed in the same way as regular >> CDS/CDNSKEY RRsets are signed. >> >> Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the >> DNSKEY algorithm is what signals the DELETE operation, but for >> clarity, the "0 0 0 00" notation is mandated -- this is not a >> definition of DS digest algorithm 0. The same argument applies to >> "CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second field is mandated= by >> [RFC4034], Section 2.1.2. >> >> Notes >> ----- >> RFC 7344 defines both CDS and CDNSKEY record wire and presentation forma= t >> to be identical to DS and DNSKEY wire and presentation format defined in >> RFC 4034. >> >> In case of CDNSKEY record, RFC 4034 section 2.2 requires that: >> > The Public Key field MUST be represented as a Base64 encoding of the >> Public Key. >> >> As Base64 encoding encodes 6 bits into one character, one character alon= e >> can never be a valid Base64 sequence. The proper encoding of one-byte lo= ng >> sequence with binary value of 00 is AA=3D=3D. >> >> In case of CDS record, RFC 4034 section 5.3 requires that: >> > The Digest MUST be represented as a sequence of case-insensitive >> hexadecimal digits >> >> Although the value of a single 0 fulfils this requirement per se, it's >> not properly parsable by many implementations since it is expected to be >> even number of hex digits to align with octet boundaries in the wire >> format. So proper form of CDS record should contain two zeroes in place = of >> the digest. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8078 (draft-ietf-dnsop-maintain-ds-06) >> -------------------------------------- >> Title : Managing DS Records from the Parent via CDS/CDNSKE= Y >> Publication Date : March 2017 >> Author(s) : O. Gudmundsson, P. Wouters >> Category : PROPOSED STANDARD >> Source : Domain Name System Operations >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --94eb2c18d616ea5ba20552b4a947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments in line below

On 23 June 2017 at 12:37, =C3=93lafur Gu=C3=B0mu= ndsson <olafur@cloudflare.com> wrote:
The errata is correct.=


I beg to disagree.

In eac= h case,

=C2=A0 =C2=A0 =C2=A0 CDS 0 0 0 0

=C2=A0 =C2=A0 =C2=A0 CDNSKEY 0 3 0 0

the final "0&qu= ot; is a conventional token representing a zero-length key field. In neithe= r case is it an attempt to specify a single octet key value.
=
A zone file parser is expected to recognise the zero algorit= hm field and hence abstain from attempting to parse the non-existent key.
The fact that the placeholder is unparseable should be reg= arded not as an error but a useful feature designed to root out under-perfo= rming zone file parsers.

However, all of this confusion could have b= een avoided if RFC8078 had also specified the corresponding RDATA wire form= at in each case.

Although this erratum should be rejected= as it stands, it clearly does identify an issue with RFC8078 which needs t= o be rectified at the earliest opportunity.


--Dick



On Jun 23, 2017 11:54, "RFC Errata System" <= rfc-editor@r= fc-editor.org> wrote:
The following errata report has been submitted = for RFC8078,
"Managing DS Records from the Parent via CDS/CDNSKEY".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5049

--------------------------------------
Type: Technical
Reported by: Ond=C5=99ej Caletka <Ondrej.Caletka@cesnet.cz>

Section: 4

Original Text
-------------
=C2=A0 =C2=A0The contents of the CDS or CDNSKEY RRset MUST contain one RR a= nd only
=C2=A0 =C2=A0contain the exact fields as shown below.

=C2=A0 =C2=A0 =C2=A0 CDS 0 0 0 0

=C2=A0 =C2=A0 =C2=A0 CDNSKEY 0 3 0 0

=C2=A0 =C2=A0The keying material payload is represented by a single 0.=C2= =A0 This
=C2=A0 =C2=A0record is signed in the same way as regular CDS/CDNSKEY RRsets= are
=C2=A0 =C2=A0signed.

=C2=A0 =C2=A0Strictly speaking, the CDS record could be "CDS X 0 X 0&q= uot; as only the
=C2=A0 =C2=A0DNSKEY algorithm is what signals the DELETE operation, but for=
=C2=A0 =C2=A0clarity, the "0 0 0 0" notation is mandated -- this = is not a
=C2=A0 =C2=A0definition of DS digest algorithm 0.=C2=A0 The same argument a= pplies to
=C2=A0 =C2=A0"CDNSKEY 0 3 0 0"; the value 3 in the second field i= s mandated by
=C2=A0 =C2=A0[RFC4034], Section 2.1.2.


Corrected Text
--------------
=C2=A0 =C2=A0The contents of the CDS or CDNSKEY RRset MUST contain one RR a= nd only
=C2=A0 =C2=A0contain the exact fields as shown below.

=C2=A0 =C2=A0 =C2=A0 CDS 0 0 0 00

=C2=A0 =C2=A0 =C2=A0 CDNSKEY 0 3 0 AA=3D=3D

=C2=A0 =C2=A0The keying material payload is represented by a single octet w= ith
=C2=A0 =C2=A0the value 00. This record is signed in the same way as regular=
=C2=A0 =C2=A0CDS/CDNSKEY RRsets are signed.

=C2=A0 =C2=A0Strictly speaking, the CDS record could be "CDS X 0 X 00&= quot; as only the
=C2=A0 =C2=A0DNSKEY algorithm is what signals the DELETE operation, but for=
=C2=A0 =C2=A0clarity, the "0 0 0 00" notation is mandated -- this= is not a
=C2=A0 =C2=A0definition of DS digest algorithm 0.=C2=A0 The same argument a= pplies to
=C2=A0 =C2=A0"CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second = field is mandated by
=C2=A0 =C2=A0[RFC4034], Section 2.1.2.

Notes
-----
RFC 7344 defines both CDS and CDNSKEY record wire and presentation format t= o be identical to DS and DNSKEY wire and presentation format defined in RFC= 4034.

In case of CDNSKEY record, RFC 4034 section 2.2 requires that:
> The Public Key field MUST be represented as a Base64 encoding of the P= ublic Key.

As Base64 encoding encodes 6 bits into one character, one character alone c= an never be a valid Base64 sequence. The proper encoding of one-byte long s= equence with binary value of 00 is AA=3D=3D.

In case of CDS record, RFC 4034 section 5.3 requires that:
> The Digest MUST be represented as a sequence of case-insensitive hexad= ecimal digits

Although the value of a single 0 fulfils this requirement per se, it's = not properly parsable by many implementations since it is expected to be ev= en number of hex digits to align with octet boundaries in the wire format. = So proper form of CDS record should contain two zeroes in place of the dige= st.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8078 (draft-ietf-dnsop-maintain-ds-06)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Managing DS R= ecords from the Parent via CDS/CDNSKEY
Publication Date=C2=A0 =C2=A0 : March 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: O. Gudmundsson, P. Wout= ers
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Domain Name System= Operations
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--94eb2c18d616ea5ba20552b4a947-- From nobody Sat Jun 24 08:45:56 2017 Return-Path: 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 8234B126C3D for ; Sat, 24 Jun 2017 08:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz 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 sIYlAxwypzLH for ; Sat, 24 Jun 2017 08:45:52 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C4C12441E for ; Sat, 24 Jun 2017 08:45:50 -0700 (PDT) Received: from [IPv6:2a03:3b40:210::1a1e] (latte.t512.oskarcz.net [IPv6:2a03:3b40:210::1a1e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id EADD520066; Sat, 24 Jun 2017 17:45:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1498319149; bh=eiZl2CX2ehi4+Nl8wOxtesjEGOtn/7nyQjdG96Pc58E=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=a7+iUR5yO5E5LXCo48ewVN/Evn5r4pEZBtdL8n5d7moM3GYHc69sa3xx6obEQb9bz 5Tgzv28+1llbneV4dnTvIMNZuZwnlLp70hF29aMSKIbZC2utLxOT+gs4f+/WCH4JGY sehQwQLubszkNEO3XiB7T0j8TL0V+PkqGcGcOiXM= To: Dick Franks , =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= References: <20170623105434.22478B810AB@rfc-editor.org> Cc: RFC Editor , tjw.ietf@gmail.com, IETF DNSOP WG , suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson From: =?UTF-8?Q?Ond=c5=99ej_Caletka?= Message-ID: <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> Date: Sat, 24 Jun 2017 17:45:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020301030305010100060603" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 15:45:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020301030305010100060603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Dne 24.6.2017 v 15:25 Dick Franks napsal(a): > I beg to disagree. >=20 > In each case, >=20 > CDS 0 0 0 0 >=20 > CDNSKEY 0 3 0 0 >=20 > the final "0" is a conventional token representing a zero-length key > field. In neither case is it an attempt to specify a single octet key v= alue. I believe this has been discussed between 04 and 06 versions of the draft in this thread: https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE The result that made it to the RFC is that there should be indeed one byte with value of 00 in the Digest/Public key field instead of no data at all. This avoids the need of defining new format and updating all the deployed software. It's not only about parsers of the wire format but also about zone file parsers, that would need an update as the single zero is not conformant with currently defined presentation format of CDS/CDNSKEY RRs. I believe changing RRdata format just for this one purpose would add an unnecessary complexity. -- Best regards, Ond=C5=99ej Caletka --------------ms020301030305010100060603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CoEwggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwp9Jj5Aej1xPkS1GV3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYty qDGF2nnItxV1SkwVoDxFeRzOIHYNYvBRHaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+ 0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VWFf/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyim atBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0baminfLcsh6ubCdINZc+Nof2lU387NCDgg oh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAMC57iZXssncp24eaN08VlAgMBAAGj ggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcB AQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcw AoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZI hvcNAQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkF OxA/TUiuK2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBS WxITl1KHBS9YBskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsB iWU2muAoGItwbaP55EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101 S1OI6J1tUil1r7ES/svNqVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9Eow ggVwMIIEWKADAgECAhAOQPOEM/O7/KtI/tffwAnHMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMw HhcNMTcwMTAyMDAwMDAwWhcNMTgwMjAxMTIwMDAwWjB+MRMwEQYKCZImiZPyLGQBGRYDb3Jn MRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYDdGNzMQswCQYDVQQG EwJDWjEPMA0GA1UEChMGQ0VTTkVUMRwwGgYDVQQDExNPbmRyZWogQ2FsZXRrYSAzNzM4MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuVyDB1b7Pqcm93ZJ8A6J7l6gsPgpdach Mg2I5daT9osHhGUwPBsayml4ZE5mWhzForKB1hAWSrwTh5+qKyzFk/rh8fmDlXVILh0q1Z/K Wu3p3etYaPqBQK5iuQd5oV5rYfXtbCMIX/4Ne3O4cspeg3IJ+T4wQeZFbpcBCAP6MxkLSVBl u3LMftZXhz41BmiDpO+41wmAF5BQUOA11G6cAukc8La3iTr5yfydJ6VfnskBl8R3WrEkC8uX /vHvnF/Y6HeABL0ddtVGvVUYVn0Nz2D1ZnrEsce38sdNd2whSKKr6COs4a0hj3CbxcSxj04l McigkTWhZneY9DgvEMEDbwIDAQABo4IB9DCCAfAwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWL RggEpu2XcKYwHQYDVR0OBBYEFKKndMvbQc48lModjfiJrAVt7ZgMMAwGA1UdEwEB/wQCMAAw NgYDVR0RBC8wLYERY2FsZXRrYUBjZXNuZXQuY3qBGE9uZHJlai5DYWxldGthQGNlc25ldC5j ejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDQGA1Ud IAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3TAUCAwMDMIGFBgNV HR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5BZVNjaWVuY2VQ ZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFl U2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUA A4IBAQBNXO+U8KLfIAzEhfr7QGU8mSZwu3SMVnxCEhkdJvrYGTECfpz2oT4sn/CiXmRIKFrU faGwdpJaqHtYnChlQMqaFS/SzNms2XPceKOiB1QLiVSTf11sYgizVTDgIDpF8+IvH4W1mkNg pC7P8ac+9BMGERq8md28e4r5cG//U/4c2+9dqJGzRwXJvuxMk381JaYw//mZMdHkfUdFDGpN sVUcu0bDYehGpeQDOKdTic/zmd7eX3NucCmoMMsE3KGsbNdfFLmcIFRApFPBHNh9bfjrraKU MZbEBPbu/YXwENYUDqlFzJEv5Cl3xTkbrDf8vWY5hfOd0vyHUusZfKAcpAexMYIDwzCCA78C AQEwgYYwcjELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcT CUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2Ug UGVyc29uYWwgQ0EgMwIQDkDzhDPzu/yrSP7X38AJxzANBglghkgBZQMEAgEFAKCCAg0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjI0MTU0NTQ3WjAv BgkqhkiG9w0BCQQxIgQg4mA6XDEjLqg1mqYKh9ImKg785sQy8g+D+d0elFMilZ4wbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJ KwYBBAGCNxAEMYGJMIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k MRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5B IGVTY2llbmNlIFBlcnNvbmFsIENBIDMCEA5A84Qz87v8q0j+19/ACccwgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2ll bmNlIFBlcnNvbmFsIENBIDMCEA5A84Qz87v8q0j+19/ACccwDQYJKoZIhvcNAQEBBQAEggEA Og6jZ4WMAn7nNFbiJPLmfX7yx+rlcvP4vM2BMzaoTt7vlQcmiBlB1N6F8Wd1sHs94GrHhTPF CnP95ejdstEzjU+uLYC3BAufcD+03WQyGYI5bj7PhgtcepdC6VwYRd8QePcuPKMjb+ApS6Tf x88BkbXiZzgdWg3RX0/AdwsfMQPXEVlELioxt3Eq9oMnybwxFRGBZp3vR+UOExmDTRUmbgv/ CEJacN1TVTfsQuP8h6hJ1ffoQZv5Lh+6rs4amVhVb6XSTTHJRtbOW8FMYPUmbqTmebNYdntU MVczT8ERdSgNEHWkTMqvgBfgTphijUUT8H3gl6yZqwI/C3ccn4AA9wAAAAAAAA== --------------ms020301030305010100060603-- From nobody Sun Jun 25 11:19:45 2017 Return-Path: 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 EA822126CB6 for ; Sun, 25 Jun 2017 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qq9_mYyPToB6 for ; Sun, 25 Jun 2017 11:19:42 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 144A5126B71 for ; Sun, 25 Jun 2017 11:19:41 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id 95so56546389ott.3 for ; Sun, 25 Jun 2017 11:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=64KwgIR/VCuazJ4BcbnSdOm7FJv5Rf9MenPNCqnwVYg=; b=HuUGk6mVg9avjHY/pcAbOdsaMIta1RCunFX+1wlKhQCLlAZ9PmJxfsN8z5Dy+WMm6e mAnp/VXHgiSseFDeSn5FXbscUaGWEaaOMnLnh5rDpcGUJSKUAcpK/zUFx/8UY4o+JgcA 5PRzrsyiJih/rCqFj/Fz/IfejQ+g5sNp5uIIKuqGaXdFn2y4t6oNIHfcoZo231h9csXK BJP+6Ot1KMZvoLZMX2y/mnS5J0GZOUU8OrnD3g5hLskFB478NjzJGhAMfseGy8daSq3J t7aSKAkiWvTZ3YF8SnGWijAND2UU5QyAX0FZKpDiZQ3HkzUz3cZPOKKEghVWbLVnB9V+ E4WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=64KwgIR/VCuazJ4BcbnSdOm7FJv5Rf9MenPNCqnwVYg=; b=AZaq4s6xMkQF2j6zgLbN2D4SvUkBnEyZ85f1J/HroDtLdFVlJZF8kZDRxV5nIVheNT GSjvBr6AnqcWXD9wrGDw8rw2WyhqSEOGzmDk6HOHY5jZkUPFN2Lzo/weo6qOpNeVrsWc 2X8Z5NfixVvNqTedeUvd8VSZ0qJtPubuTvKRXXBqPpLhjR/5TpbIZfVN6N23BCK1FNKN uF/SScRyhmD+RZZe6ytZTOBuUt+f7E+yw5CfGIlWmBd2/MfSTYYE4ZVdPUvlJKy1/ftR eLbDLfMHjj9pL60hqJwrxAchAlbG8G1ZiL8uID3GHwoiR7d1yWiU/eKNVtcR9QWPU8fj DcHA== X-Gm-Message-State: AKS2vOw1ey0jAOuEGRjafCAumkJ+OR4BnIKZQG5nmRc1guyCFNXAKkt9 Hhq0iGDAA3s9DeiZdta63yjFXp/icg== X-Received: by 10.157.56.180 with SMTP id p49mr10633648otc.239.1498414781337; Sun, 25 Jun 2017 11:19:41 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Sun, 25 Jun 2017 11:19:00 -0700 (PDT) In-Reply-To: <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> From: Dick Franks Date: Sun, 25 Jun 2017 19:19:00 +0100 X-Google-Sender-Auth: whcS1nj543z5_QDGdmOekuqI9ek Message-ID: To: =?UTF-8?Q?Ond=C5=99ej_Caletka?= Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , tjw.ietf@gmail.com, IETF DNSOP WG , suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: multipart/alternative; boundary="001a11c10ec2c495e10552cce074" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 18:19:44 -0000 --001a11c10ec2c495e10552cce074 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 24 June 2017 at 16:45, Ond=C5=99ej Caletka w= rote: >8 The result that made it to the RFC is that there should be indeed one > byte with value of 00 in the Digest/Public key field instead of no data > at all. That does not appear to be the position at all. RFC8078 mandates a specific presentation format notation for the entire RDATA string whenever algorithm is zero, and irrespective of actual values in other fields. The RFC is conspicuously silent about the equivalent wire-format representation. This avoids the need of defining new format and updating all the > deployed software. It's not only about parsers of the wire format but > also about zone file parsers, that would need an update as the single > zero is not conformant with currently defined presentation format of > CDS/CDNSKEY RRs. > It is clear from the text of draft-ietf-dnsop-maintain-ds-04 that the notion of mandated presentation format notation was already present. Moreover, that version also carried the warning: This is a change in format from strict interpretation of [RFC7344] and may cause problems with some deployed software. Your primary argument was therefore a non-starter even before the appearance of the unparseable single zero. I believe changing RRdata format just for this one purpose would add an > unnecessary complexity. > > That train has already left the station. --001a11c10ec2c495e10552cce074 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 24 June 2017 at 16:45, Ond=C5=99ej Caletka <Ondrej.Caletka@cesnet.cz> wrote:

>8

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">The result that made it to= the RFC is that there should be indeed one
byte with value of 00 in the Digest/Public key field instead of no data
at all.

That does not appear to be the posi= tion at all.

RFC8078 mandates a specific presentation for= mat notation for the entire RDATA string whenever algorithm is zero, and ir= respective of actual values in other fields.

The RFC is c= onspicuously silent about the equivalent wire-format representation.


Th= is avoids the need of defining new format and updating all the
deployed software. It's not only about parsers of the wire format but also about zone file parsers, that would need an update as the single
zero is not conformant with currently defined presentation format of
CDS/CDNSKEY RRs.

It is clear from the t= ext of draft-ietf-dnsop-maintain-ds-04 that th= e notion of mandated presentation format notation was already presen= t. Moreover, that version also carried the warning:

=C2=A0=C2=A0=C2=A0 This is a change in format from strict interpretat= ion of
=C2=A0 =C2=A0 [RFC7344] and may cause problems with some deployed= software.

Your primary argument was therefore a n= on-starter even before the appearance of the unparseable single zero.


I believe changing RRdata format just for this one purpose would add an
unnecessary complexity.

That train has already left the station.


=
--001a11c10ec2c495e10552cce074-- From nobody Sun Jun 25 12:54:34 2017 Return-Path: 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 B7AFF126BF0 for ; Sun, 25 Jun 2017 12:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hshYsf4PF0gc for ; Sun, 25 Jun 2017 12:54:31 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 84F531241FC for ; Sun, 25 Jun 2017 12:54:31 -0700 (PDT) Received: from [169.254.111.199] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v5PJrbHT008946 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 12:53:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.111.199] From: "Paul Hoffman" To: "Dick Franks" Cc: "RFC Editor" , "IETF DNSOP WG" Date: Sun, 25 Jun 2017 12:54:15 -0700 Message-ID: <5CF5AB49-5A02-4757-962C-004C9EDFA851@vpnc.org> In-Reply-To: References: <20170623105434.22478B810AB@rfc-editor.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 19:54:33 -0000 On 24 Jun 2017, at 6:25, Dick Franks wrote: > In each case, > > CDS 0 0 0 0 > > CDNSKEY 0 3 0 0 > > the final "0" is a conventional token representing a zero-length key field. Dick, can you give examples of that conventional token use? --Paul Hoffman From nobody Sun Jun 25 15:31:11 2017 Return-Path: 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 88A831270B4 for ; Sun, 25 Jun 2017 15:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZNxEvK_sad75 for ; Sun, 25 Jun 2017 15:31:08 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 2313B1270AC for ; Sun, 25 Jun 2017 15:31:08 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id 95so58093143ott.3 for ; Sun, 25 Jun 2017 15:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hcRdsCVY9r7MTXrL7i8Zp2kFJPokB/2dRheppxwrOtc=; b=GH/k0+sw45jP/DcKG4pwOm5b81V8cTttI5JWfYD+eT7KkDpP0vO4XL9w4QILOD1e8m fYZL0Qa+l4tXnZiD+C8lmN7iIJYzdLKj9gk0gr8rQLQueerLrnz99KFJN2WI80gkxcD/ OxLdExTPu0xUxcuSyFCf/0ze4sSeDC8tNQCaBYKXjU2f5b+Fx3sEO41SElP9jXYzqD7I KuVzaCqb9CX8inX65yI6gOy476fs5AGPVJsbkMv36HjHOByRqaBNHv/k/AqemfbKPMz1 V2UCNU3dwhtkJef7FuiGsVvHmb2InWfF8qcYei/0Jd6yx23A0C5ST0KRZOMFWx69fpOn K83w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hcRdsCVY9r7MTXrL7i8Zp2kFJPokB/2dRheppxwrOtc=; b=OTtfOcfux6PePzHzOj3qk/l/Vt0FGCQl1FXRlv95d2LsvlspfXkawH7hd6atmFx1SK 0c1E4UZfZgtiy4VD19VLR/8sybYn986QFcfO3cbtZngW12PDTLTemSxc9pq7gjn09g9s woSYQlWyeq5K5U0Lg6qtVMSf5A0K8agbpuR/11rcjiJjss2pxeWhNNPp4GPPeWUZ7CU5 wCpnnXvB+P7C2dI+f9hILfWvL5amusV7UHJX7e27HgxvfIFc0lklAvn+GfWKNtLa0SVO R8+1RDNHXR8jUkyrePnn/A0aljMaT7HIcN38/n97FRnDKwCXGV6qvDGOmCvcJBsF9GVz XhrQ== X-Gm-Message-State: AKS2vOyc2YEjcWQ0DjYqYks51e8FyqjMNTRmRxsTLirUkSmKIlOrbDq4 KycZSGKIL92Rm5I4SI3xEnRUclHkXQ== X-Received: by 10.157.12.102 with SMTP id 93mr10790173otr.11.1498429867555; Sun, 25 Jun 2017 15:31:07 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Sun, 25 Jun 2017 15:30:27 -0700 (PDT) In-Reply-To: <5CF5AB49-5A02-4757-962C-004C9EDFA851@vpnc.org> References: <20170623105434.22478B810AB@rfc-editor.org> <5CF5AB49-5A02-4757-962C-004C9EDFA851@vpnc.org> From: Dick Franks Date: Sun, 25 Jun 2017 23:30:27 +0100 X-Google-Sender-Auth: ICChnpQxjTLoVr8x9SInBHH07Sw Message-ID: To: Paul Hoffman Cc: IETF DNSOP WG , RFC Editor Content-Type: multipart/alternative; boundary="94eb2c11f8a2fa02920552d06388" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 22:31:09 -0000 --94eb2c11f8a2fa02920552d06388 Content-Type: text/plain; charset="UTF-8" On 25 June 2017 at 20:54, Paul Hoffman wrote: > On 24 Jun 2017, at 6:25, Dick Franks wrote: > > > In each case, > > > > CDS 0 0 0 0 > > > > CDNSKEY 0 3 0 0 > > > > the final "0" is a conventional token representing a zero-length key > field. > > Dick, can you give examples of that conventional token use? > This example is as good as any. conventional: established by custom or agreement token: a mark, sign or distinctive feature. [Chambers 21st Century Dictionary] The token (final zero) is not in this case a self-defining term, but is given meaning, or in this case lack of meaning, by the formal agreement (RFC8078) that a zero algorithm field will completely define a DELETE CDS/CDNSKEY RR. --Dick --94eb2c11f8a2fa02920552d06388 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 25 June 2017 at 20:54, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 24 Jun 2017, at 6:25, Dick Franks wrote:

> In each case,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CDS 0 0 0 0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CDNSKEY 0 3 0 0
>
> the final "0" is a conventional token representing a zero-le= ngth key field.

Dick, can you give examples of that conventional token use?

This example is as good as any.

conventional:=C2=A0=C2=A0 established by custom or agreement

token:=C2=A0=C2=A0 a mark, sign or distinctive feature.
=C2=A0=C2=A0=C2=A0 [Chambers 21st Century Dictionary]
<= br>
The token (final zero) is not in this case a self-definin= g term, but is given meaning, or in this case lack of meaning, by the forma= l agreement (RFC8078) that a zero algorithm field will completely define a = DELETE CDS/CDNSKEY RR.


--Dick
--94eb2c11f8a2fa02920552d06388-- From nobody Mon Jun 26 01:40:06 2017 Return-Path: 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 9100312955F for ; Mon, 26 Jun 2017 01:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Y4bquPSO7at2 for ; Mon, 26 Jun 2017 01:40:02 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 8FDBD129466 for ; Mon, 26 Jun 2017 01:40:02 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5Q8dol4026246 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 08:39:51 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5Q8dn87004163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 08:39:50 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5Q8dkf9029014; Mon, 26 Jun 2017 08:39:48 GMT Received: from [192.168.178.30] (/83.160.139.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jun 2017 01:39:45 -0700 To: =?UTF-8?Q?Ond=c5=99ej_Caletka?= , Dick Franks , =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= Cc: tjw.ietf@gmail.com, IETF DNSOP WG , suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> From: Matthijs Mekking Message-ID: <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> Date: Mon, 26 Jun 2017 10:39:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 08:40:04 -0000 Hi, On 24-06-17 17:45, Ondřej Caletka wrote: > Hello, > > Dne 24.6.2017 v 15:25 Dick Franks napsal(a): >> I beg to disagree. >> >> In each case, >> >> CDS 0 0 0 0 >> >> CDNSKEY 0 3 0 0 >> >> the final "0" is a conventional token representing a zero-length key >> field. In neither case is it an attempt to specify a single octet key value. > > I believe this has been discussed between 04 and 06 versions of the > draft in this thread: > > https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE > > The result that made it to the RFC is that there should be indeed one > byte with value of 00 in the Digest/Public key field instead of no data > at all. To be precise: We actually agreed that there should be *one field with the value of 0* instead of no data at all. > This avoids the need of defining new format and updating all the > deployed software. It's not only about parsers of the wire format but > also about zone file parsers, that would need an update as the single > zero is not conformant with currently defined presentation format of > CDS/CDNSKEY RRs. I raised the specific issue because the to be RFC 8078 was going to change the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable length: In case of the DELETE operation, the Digest in presentation format was omitted. While I agree with Paul in that thread that we should use all zeros for the DELETE operation, I believe it was an oversight that the proper encodings (hexadecimal, base64) should be used. So to me this errata is valid. Best regards, Matthijs > I believe changing RRdata format just for this one purpose would add an > unnecessary complexity. > > -- > Best regards, > Ondřej Caletka > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Mon Jun 26 02:59:30 2017 Return-Path: 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 69083129A97 for ; Mon, 26 Jun 2017 02:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz 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 j0qZopBpAxvb for ; Mon, 26 Jun 2017 02:59:26 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 EE489128A32 for ; Mon, 26 Jun 2017 02:59:25 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y70so37023161vky.3 for ; Mon, 26 Jun 2017 02:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+SuJiI7cggwe84g2zcNQu8ZHsuZm6SrRKmEk+KIOZE4=; b=IsjwY9Rekq85NYovtP2IJ3p/e0eNJsT84wgg5j1MSgxRXJx7H9bZ840CbFmeMsBFry tgmZTyBsEXfQvedArBmWwHu3F9fFQWinBhqUa0GemXTP9HIrUq31pvrwCvLdsAW/mRr4 gptVmA3yC705L/WkEgmsepSzJlEdkcoyrunG4= 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=+SuJiI7cggwe84g2zcNQu8ZHsuZm6SrRKmEk+KIOZE4=; b=gz1q7VNnTtp/AxAarLU8dHHRIYjN4vx+XEsNxS3HMStluEroBiQZ0flWkCsxr1VUj6 frsQv9svlQr7hFwsQ2+3560eiUOcHxETlvRaIAGttwqtHnxjVDAz/79YhOhaS4niy+Ey GlGcMlsgpOmA6xWy9l3ZW5zhS3zopaA6i75f5/UNs4x/PZkwgSaqtdFxcXKuTeu+IzR0 4yJroYWWLzkVkgonA3GyuwUvyAz6oNX+t4MOPlR/18EyHBSpV+kiUvHzbGJqdNwJtmhI 7vaYODhh5bfNkR/onkU3bvAvxCQdymf+mp4/yAh73JNxUXt8dKSOxQ6q11pOZjl8IRTa ar/w== X-Gm-Message-State: AKS2vOzs1DBxyRyXWRDFe4MO8sU78Rl6FDhCFwiqnsTj8eg3SPU0UpV6 hmIW36Da+sQEsD52IR2S1JyX7GjVJoUu X-Received: by 10.31.36.19 with SMTP id k19mr9385781vkk.78.1498471164685; Mon, 26 Jun 2017 02:59:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.92 with HTTP; Mon, 26 Jun 2017 02:59:04 -0700 (PDT) X-Originating-IP: [94.112.122.95] In-Reply-To: <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Mon, 26 Jun 2017 11:59:04 +0200 Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Cc: =?UTF-8?Q?Ond=C5=99ej_Caletka?= , Matthijs Mekking , Dick Franks , tjw.ietf@gmail.com, IETF DNSOP WG , suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 09:59:28 -0000 I agree that the errata is correct. It is maybe suboptimal that wire format for DS/DNSKEY delete-request was not specified in the document. And I'm not sure if the authors meant that the digest/public key is zero-length or one-byte long. But luckily this can prevent some compatibility issues: Presentation format for DS/CDS just doesn't expect zero-length digest (as opposed to NSEC3PARAM which uses dash instead of the hex encoded salt if the salt is zero-length). I tried with Knot DNS and BIND - both can write DS record in presentation format with zero-length digest but cannot parse it back. (Try it yourself with "delete-cds.example.test. IN TYPE59 \# 4 00000000". I haven't trie with DNSKEY but I expect the problem will be the same.) The implementers should be careful and avoid the trouble. In this sense, I think parent zone should accept both zero-length and one-byte long digests/keys as a request to remove the DS. Jan On Mon, Jun 26, 2017 at 10:39 AM, Matthijs Mekking wrote: > Hi, > > On 24-06-17 17:45, Ond=C5=99ej Caletka wrote: >> >> Hello, >> >> Dne 24.6.2017 v 15:25 Dick Franks napsal(a): >>> >>> I beg to disagree. >>> >>> In each case, >>> >>> CDS 0 0 0 0 >>> >>> CDNSKEY 0 3 0 0 >>> >>> the final "0" is a conventional token representing a zero-length key >>> field. In neither case is it an attempt to specify a single octet key >>> value. >> >> >> I believe this has been discussed between 04 and 06 versions of the >> draft in this thread: >> >> https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE = > >> The result that made it to the RFC is that there should be indeed one >> byte with value of 00 in the Digest/Public key field instead of no data >> at all. > > > To be precise: We actually agreed that there should be *one field with th= e > value of 0* instead of no data at all. > >> This avoids the need of defining new format and updating all the >> deployed software. It's not only about parsers of the wire format but >> also about zone file parsers, that would need an update as the single >> zero is not conformant with currently defined presentation format of >> CDS/CDNSKEY RRs. > > > I raised the specific issue because the to be RFC 8078 was going to chang= e > the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable > length: In case of the DELETE operation, the Digest in presentation forma= t > was omitted. > > While I agree with Paul in that thread that we should use all zeros for t= he > DELETE operation, I believe it was an oversight that the proper encodings > (hexadecimal, base64) should be used. > > So to me this errata is valid. > > Best regards, > Matthijs > > >> I believe changing RRdata format just for this one purpose would add an >> unnecessary complexity. >> >> -- >> Best regards, >> Ond=C5=99ej Caletka >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Jun 26 04:27:10 2017 Return-Path: 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 CB8A21296CF for ; Mon, 26 Jun 2017 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 RsSUHYARS50l for ; Mon, 26 Jun 2017 04:27:06 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C53F8126CD8 for ; Mon, 26 Jun 2017 04:27:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wx6GG3kZ8z3GW; Mon, 26 Jun 2017 13:27:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1498476422; bh=ZKa96QQ2DN+qim3A9R9x41mTGVgd0uNpXfGVu+OCHUQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cj6P0NfLDDYfpuYwU/vXGimm05sZI7AoHcjc/S2SSONu5QbAd2bbguQ4MbQBD0X8q 0YxJKmpbUqxpddiWo2iUWBEbWq+x+/sYQptaO+2eOJqnFPpHj1duX7G8hUSVyAweb4 lIgF89lMGbHR9coW3bTmpvMdv2SIjp8CDUf9dWxE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id i0ihLLtprBWP; Mon, 26 Jun 2017 13:27:00 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 26 Jun 2017 13:27:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 34668F25; Mon, 26 Jun 2017 07:26:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 34668F25 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1CC5740D3592; Mon, 26 Jun 2017 07:26:59 -0400 (EDT) Date: Mon, 26 Jun 2017 07:26:58 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-2?Q?Jan_V=E8el=E1k?= cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson?= , tjw.ietf@gmail.com, Matthijs Mekking , =?ISO-8859-2?Q?Ond=F8ej_Caletka?= , IETF DNSOP WG , Dick Franks , suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor In-Reply-To: Message-ID: References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 11:27:09 -0000 On Mon, 26 Jun 2017, Jan Včelák wrote: > It is maybe suboptimal that wire format for DS/DNSKEY delete-request > was not specified in the document. The reason we did not, was that we did not mean to have anything "special" on either the presentation or the wire format, so there was no need to specify a wire format. When Mathijs noticed it was different, we added his disclaimer that the presentation format (and thus wireformat) was different. Once we added the additional zeros, we were no longer using a different format, so we removed that disclaimer again. We thought we no longer asked something non-standard. > The implementers should be careful and avoid the trouble. In this > sense, I think parent zone should accept both zero-length and one-byte > long digests/keys as a request to remove the DS. Yes that seems best. In fact, it could ignore the entire digest field content when algorithm 0 is found. And the cross this with another giant ietf-thread, that is a correct application of the Postel Principle :P Paul From nobody Mon Jun 26 04:30:09 2017 Return-Path: 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 EF9BC129AF9 for ; Mon, 26 Jun 2017 04:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jWCXNCMnu-ix for ; Mon, 26 Jun 2017 04:30:06 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 76CDC126CD8 for ; Mon, 26 Jun 2017 04:30:06 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id p66so52503304oia.0 for ; Mon, 26 Jun 2017 04:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1hf892YXXeJNNIFeeisiatWuc3pzKxqPt1Ho5vJxJ+A=; b=Gtam0OB+pxnI2GhI73D7o+CC5UYfBkvsrXkAHYv0fVOH/bq88TnBn0sVXoVc9mnRWX rzCQPkLMQlquQvSn9WcZvGFevqYeOBNPtOHUeCKeWjHePASbfYmnHaiV043jjSVlroDk 6haxmnijm8bQQmjREK15eXaSoU1oVoY04TCP+2tKukX8gQiXI8WzcxCYz+E75mz9HxUb b+SuqzMbT3SC3M6zb68YdJx4Z7OfTf8LC/nvpk61UCrU9CEXpc/3Y728UJ6nI9OzrCKi Qsr3W+a3jmW/A33LPy2FX5p8HtHwtD+txDLkYT/9mKNHzfUyKrpXbAGWpQafuJtQAWx3 VN5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1hf892YXXeJNNIFeeisiatWuc3pzKxqPt1Ho5vJxJ+A=; b=D0Xdnl/xmlz4ui0xii55OGX8OXCKy94hKN3tqBqA/nxL0ZDOMRQ1pl7/FBvhApxKus jeKAtChMoeWqRV3X1yi9JkUsK8p2gjW7AJD4d3Fk4yCPsSpFbvOjOVXyNFtQh1ubEPTc ymt2ieTy0oSra4+p5GVJOSgdXNEMTA3IkNRtotRXgeT1RZgTXOa4n0DeMyYgVb20DiSG 1zzYVC7E1noTV3Z27SWi09+uLhD3cniXW/3R8vTR5Fsdm7FJufEo8Y5Z4A8v8ZlaULwf AhWNyzBDiDpQB0hlldWnMNw93z0y6csHEpGprF0q08f2Ht3j96Dtb+bWW4IAnc3UVaq4 LkCg== X-Gm-Message-State: AKS2vOwx66p+ry3DkhrTW+DKxXUknQYQqdDx3Fw5oBHNAtgF17Zfn6aw ofHRMcOO8WhxOodsqj2bA7Z5YH2hlA== X-Received: by 10.202.188.87 with SMTP id m84mr11233651oif.166.1498476605941; Mon, 26 Jun 2017 04:30:05 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Mon, 26 Jun 2017 04:29:25 -0700 (PDT) In-Reply-To: References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> From: Dick Franks Date: Mon, 26 Jun 2017 12:29:25 +0100 X-Google-Sender-Auth: RJm2LI9NbC-RGxud47Ptu_AqLWs Message-ID: To: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , =?UTF-8?Q?Ond=C5=99ej_Caletka?= , Matthijs Mekking , tjw ietf , IETF DNSOP WG , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: multipart/alternative; boundary="001a113dd52acd2e160552db45fc" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 11:30:08 -0000 --001a113dd52acd2e160552db45fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 26 June 2017 at 10:59, Jan V=C4=8Del=C3=A1k wrote: >8 > > The implementers should be careful and avoid the trouble. In this > sense, I think parent zone should accept both zero-length and one-byte > long digests/keys as a request to remove the DS. > Exactly! The _only_ way to recognise DELETE CDS/CDNSKEY is the zero algorithm field. RFC8078 says that. All the rest is mere decoration. --001a113dd52acd2e160552db45fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 26 June 2017 at 10:59, J= an V=C4=8Del=C3=A1k <jv@fcelda.cz> wrote:

>8

The implementers should be careful and avoid the trouble. In this
sense, I think parent zone should accept both zero-length and one-byte
long digests/keys as a request to remove the DS.

Exac= tly!=C2=A0 The _only_ way to recognise DELETE CDS/CDNSKEY is the zero algor= ithm field. RFC8078 says that.=C2=A0 All the rest is mere decoration.

--001a113dd52acd2e160552db45fc-- From nobody Mon Jun 26 04:30:42 2017 Return-Path: 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 EA267129B17 for ; Mon, 26 Jun 2017 04:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xXOGzVe7Kq_i for ; Mon, 26 Jun 2017 04:30:39 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 043F1126CD8 for ; Mon, 26 Jun 2017 04:30:39 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id c189so52661534oia.2 for ; Mon, 26 Jun 2017 04:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xXHsgE9GxCsl07HI98OAbgZaMVj0+5O6T7yLUwoHlug=; b=TlCohsCL1GpBCsDU72gDhHoy0ndff+z2U9pMPaKm4LqOxizrI2m6v2IMqwCfJCzob2 a7tXbs2wdNgRJVzh6l87tO6tv5G2jxsWxHlAwvRi8iuvbyfobLF+ISp1ZP7YLJHZsZ/Z To5MOKudlIs5JFt6Pg/C6dVrfEujznWPN9CIJNp4nEK2on9/azsfFjoBcg4v8oEDzxRp 0rsa8FbPPCiReid4kpWBCdyXVOHor+QdgoHe2KoTnCInG01v68aP/ryHWkscpb9Zrnja OI0Nc/v1Hppcpac3oXY/o1O3Y0D6dJtubX5KkH37bJ7kSH8bvGfC466dGkc08NEl/8+f oDcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xXHsgE9GxCsl07HI98OAbgZaMVj0+5O6T7yLUwoHlug=; b=qi1qS3UyyuHFzC9+FAiuILpK3F/mbAEwTPpBY6SUOc7k9/9hbagaDUonY3yLseNawJ nT8dZHnhb86qFflkT1nza5bQpWxNxuyHhypzDGvrU4qDyvlMlagm8dWhZz8M6kNbIbAU cOaB/7Vyx3cvBIEV4czw+sFcrCEOP+3XZg/U2Tl79zxHELGhR9QqaJAqZcC4dseg3jCo FHqOWvRrx/WOf8fvRYvaH2nQS7cQnISJb5yzYLHlfkCGqZuPsjot6mxhif1cjfsV0TVg C3K3pKghXTS9hEXz6O1mSfy33gpGfOhEPVm4s6DPKnIiRBh4oxEktvxCHk/1y4rRhPAa YIeA== X-Gm-Message-State: AKS2vOzMb5yye9IrBl1Zso7usRP9O6SQNdKK/tSNZm16ogzxw8LJlx2X QtvFSwArYn/pZxHodLeSxgi4bNXaIQ== X-Received: by 10.202.169.79 with SMTP id s76mr7472955oie.156.1498476638373; Mon, 26 Jun 2017 04:30:38 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Mon, 26 Jun 2017 04:29:57 -0700 (PDT) In-Reply-To: <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> From: Dick Franks Date: Mon, 26 Jun 2017 12:29:57 +0100 X-Google-Sender-Auth: ubsv5hr_TjFvfqb9TH_ztXUDPYI Message-ID: To: Matthijs Mekking Cc: =?UTF-8?Q?Ond=C5=99ej_Caletka?= , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , tjw ietf , IETF DNSOP WG , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: multipart/alternative; boundary="001a113cc044bc10d00552db4777" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 11:30:41 -0000 --001a113cc044bc10d00552db4777 Content-Type: text/plain; charset="UTF-8" On 26 June 2017 at 09:39, Matthijs Mekking wrote: I raised the specific issue because the to be RFC 8078 was going to change > the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable > length: In case of the DELETE operation, the Digest in presentation format > was omitted. > CDS and CDNSKEY are both variable length. There is no length component in the RDATA itself. The length of the digest (or key) is calculated (RDLENGTH - 4) so whether there is one byte or none at all makes not a scrap of difference. So that explanation can be dismissed immediately. While I agree with Paul in that thread that we should use all zeros for the > DELETE operation, I believe it was an oversight that the proper encodings > (hexadecimal, base64) should be used. > Not just an oversight. Now it is an oversight baked into an IESG approved standards track document. So an implementer has little choice but to make CDS/CDNSKEY work in accordance with the standard as written until IESG approves something else. And when that something else arrives, users will be mightily upset if RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to cope with both versions. The only realistic way to achieve that is to determine the entire content of the DELETE CDS/CDNSKEY from the zero algorithm field. Beyond that, the content of the "mandated notation" is irrelevant because it can be left unparsed. --001a113cc044bc10d00552db4777 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 26 June 2017 at 09:39, Matthijs Mekking <= span dir=3D"ltr"><matthijs@pletterpet.nl> wrote:

I raised the specific issue because the to be RFC 8078 was going to change = the CDS and CDNSKEY RDATA format from a fixed length RDATA to a variable le= ngth: In case of the DELETE operation, the Digest in presentation format wa= s omitted.

CDS and CDNSKEY are both var= iable length. There is no length component in the RDATA itself. The length = of the digest (or key) is calculated (RDLENGTH - 4) so whether there is one= byte or none at all makes not a scrap of difference. So that explanation c= an be dismissed immediately.


While I agree with Paul in that thread that we should use all zeros for the= DELETE operation, I believe it was an oversight that the proper encodings = (hexadecimal, base64) should be used.

N= ot just an oversight. Now it is an oversight baked into an IESG approved st= andards track document.

So an implementer has little choi= ce but to make CDS/CDNSKEY work in accordance with the standard as written = until IESG approves something else.

And when that something else arr= ives, users will be mightily upset if RFC8078 CDS/CDNSKEY suddenly stops wo= rking, so the code will need to cope with both versions.=C2=A0 The only rea= listic way to achieve that is to determine the entire content of the DELETE= CDS/CDNSKEY from the zero algorithm field. Beyond that, the content of the= "mandated notation" is irrelevant because it can be left unparse= d.


--001a113cc044bc10d00552db4777-- From nobody Mon Jun 26 07:30:59 2017 Return-Path: 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 2889912EAA1 for ; Mon, 26 Jun 2017 07:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Fxo8vLesDg-9 for ; Mon, 26 Jun 2017 07:30:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3CAEF12EAAB for ; Mon, 26 Jun 2017 07:30:55 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5QEUgTf021261 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jun 2017 14:30:42 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v5QEUegl027638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jun 2017 14:30:42 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5QEUbUU020190; Mon, 26 Jun 2017 14:30:38 GMT Received: from [172.19.130.10] (/216.146.45.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jun 2017 07:30:37 -0700 To: Dick Franks Cc: =?UTF-8?Q?Ond=c5=99ej_Caletka?= , =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= , tjw ietf , IETF DNSOP WG , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> From: Matthijs Mekking Message-ID: Date: Mon, 26 Jun 2017 16:30:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:30:58 -0000 On 26-06-17 13:29, Dick Franks wrote: > > On 26 June 2017 at 09:39, Matthijs Mekking > wrote: > > I raised the specific issue because the to be RFC 8078 was going to > change the CDS and CDNSKEY RDATA format from a fixed length RDATA to > a variable length: In case of the DELETE operation, the Digest in > presentation format was omitted. > > > CDS and CDNSKEY are both variable length. There is no length component > in the RDATA itself. The length of the digest (or key) is calculated > (RDLENGTH - 4) so whether there is one byte or none at all makes not a > scrap of difference. So that explanation can be dismissed immediately. You misunderstood: Variable length in octets, but not variable in number of RDATA elements. > While I agree with Paul in that thread that we should use all zeros > for the DELETE operation, I believe it was an oversight that the > proper encodings (hexadecimal, base64) should be used. > > > Not just an oversight. Now it is an oversight baked into an IESG > approved standards track document. > > So an implementer has little choice but to make CDS/CDNSKEY work in > accordance with the standard as written until IESG approves something else. Sure, but that is why we are discussing it, not? > And when that something else arrives, users will be mightily upset if > RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to > cope with both versions. The only realistic way to achieve that is to > determine the entire content of the DELETE CDS/CDNSKEY from the zero > algorithm field. Beyond that, the content of the "mandated notation" is > irrelevant because it can be left unparsed. My first suggestion for the draft was indeed: In case the DNSSEC algorithm is 0, the Digest/Public Key MUST be ignored. But there were concerns that if someone mistyped the algorithm field the DS accidentally gets removed. So now the RFC says that the contents of the CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" notation is mandated. Best regards, Matthijs From nobody Tue Jun 27 05:29:25 2017 Return-Path: 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 0F884129AD7 for ; Tue, 27 Jun 2017 05:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wyfmQj-yQKgO for ; Tue, 27 Jun 2017 05:29:21 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 4F14B129AD4 for ; Tue, 27 Jun 2017 05:29:21 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id r67so20718034ota.1 for ; Tue, 27 Jun 2017 05:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YtcABbPZ1CtW1XW8bLf9enZxNiuEwd/xFF5KTO0y26M=; b=aCQTBXyVkog0ITz3y8HRr90W5q0gc1xwG/wKp7d79iUGEEZtaFgVoT0K/eRz+WWolL 0aw3uC7Hk05/tVp1XXfV4iir/CFW/nWgoqqq9eiUBZMsnFEcwwz1HGk3A5gsULaQYDNX PBOxmRoaxEV0pd4/K8iRjg9UmIh2OR7oGL6KhMcUNuP+Bx4IR72i4McQZQTrZqwqVaQL HEaG/lSpTUHuIzaAeHmIt4HQXX/+IqOeWzq3gmrbgs+C7XXRTlhZdJIbhEI6iivnXHW0 yDt0xPUIdc9WpaxWJToevGrInJ9kIOl3szFTHqwo6EyqMt54d/BpagZ4WiLljo1UnLG8 Q4dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YtcABbPZ1CtW1XW8bLf9enZxNiuEwd/xFF5KTO0y26M=; b=n8KLlaRrYldTTMPyL/++LSpFKF0LzU/4qAwiT+vUdQS0pkTWIpcEnM/3qrj3dSSrFp JLO8HqbeFglzfoosUOkoEzmyUWVE3UzjxIH6CZpkxdb9zzsTo3Yklw2x0Gkes6OHVjQA s92G5OAU64Jd8Auue87dPXGcJ6vcBD64Rnrs8E4727DiQ9FckyIu99xvxsSbMaeHkGi8 eH9UtT9NTHHxCbIYKGJd4AKMI0Q6pobuyXBesh21j5aJVwevhaRm/hPrUC+OYRmUlFQm fnHmd1HZy7XsJM/xMs2dPqLSLxnRv4xF5v4PyVAkql0mNHOcjh4I6rhU7eLyaH9askKv NftQ== X-Gm-Message-State: AKS2vOysG7zjpVxfURhy35YbHpQUmsW5U8Omd5qj44dylwLys2FT+WKl O3SeEkjE3SwISDTJhzBvaqLRZ3wbzA== X-Received: by 10.157.52.132 with SMTP id g4mr1203475otc.213.1498566560630; Tue, 27 Jun 2017 05:29:20 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Tue, 27 Jun 2017 05:28:40 -0700 (PDT) In-Reply-To: References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> From: Dick Franks Date: Tue, 27 Jun 2017 13:28:40 +0100 X-Google-Sender-Auth: hoAOXLEqV0WkaR0MYXncZrjmvOo Message-ID: To: Matthijs Mekking Cc: =?UTF-8?Q?Ond=C5=99ej_Caletka?= , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , tjw ietf , IETF DNSOP WG , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: multipart/alternative; boundary="001a113ef7e484cebe0552f03742" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 12:29:23 -0000 --001a113ef7e484cebe0552f03742 Content-Type: text/plain; charset="UTF-8" On 26 June 2017 at 15:30, Matthijs Mekking wrote: > > > On 26-06-17 13:29, Dick Franks wrote: > > You misunderstood: Variable length in octets, but not variable in number > of RDATA elements I did. Am I correct in thinking that you want some acknowledgement that 4 fields exist, but do not really care what the final item is? So an implementer has little choice but to make CDS/CDNSKEY work in >> accordance with the standard as written until IESG approves something else. >> > > Sure, but that is why we are discussing it, not? > That is what we should be discussing, but this erratum seems to be steering us along a road full of potholes that I certainly do not want to fall into. IMHO this is based on a misunderstanding of your "mandated notation" argument. > And when that something else arrives, users will be mightily upset if >> RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to cope >> with both versions. The only realistic way to achieve that is to determine >> the entire content of the DELETE CDS/CDNSKEY from the zero algorithm field. >> Beyond that, the content of the "mandated notation" is irrelevant because >> it can be left unparsed. >> > > My first suggestion for the draft was indeed: In case the DNSSEC algorithm > is 0, the Digest/Public Key MUST be ignored. > I would go further, and say that all fields (except algorithm) MUST be ignored > But there were concerns that if someone mistyped the algorithm field the > DS accidentally gets removed. So now the RFC says that the contents of the > CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" notation is > mandated. > The one RR requirement is not in dispute. Let us make a start with the following 3 use cases, to see if we can come to some common understanding of what we are trying to achieve. (1) CDS arrives on the wire cds.example. IN CDS \# 5 1234 00 56 78 ; silly numbers in most fields RDATA as received: 'algorithm' => 0, 'digestbin' => 'x', 'digtype' => 86, 'keytag' => 4660, Algorithm = 0, so presentation format uses "RFC8078 mandated notation": cds.example. IN CDS 0 0 0 0 (2) DELETE CDS read from zone file, transmitted to parent cds.example. IN CDS 0 0 0 0 Algorithm = 0, so this is a DELETE CDS. Check that RDATA string matches "mandated notation". Coerce all RDATA numerical fields to zero, digest empty. Transmitted CDS RR: cds.example. IN CDS \# 4 0000 00 00 (3) Normal CDS read from zone file, but with accidental 0 in algorithm field cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118 Algorithm = 0, so this is apparently a DELETE CDS. Exception raised - RDATA does not match "mandated notation" DS saved from accidental deletion:-) Obviously, similar logic applies to CDNSKEY. --Dick --001a113ef7e484cebe0552f03742 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 26 June 2017 at 15:30, Matthijs Mekking <= span dir=3D"ltr"><matthijs@pletterpet.nl> wrote:


On 26-06-17 13:29, Dick Franks wrote:
You misunderstood: Variable length in octets, but not variable in number of= RDATA elements

I did.

Am= I correct in thinking that you want some acknowledgement that 4 fields exi= st, but do not really care what the final item is?


So an implementer has little choice but to make CDS/CDNSKEY work in accorda= nce with the standard as written until IESG approves something else.

 Sure, but that is why we are discussing it, not?

That is= what we should be discussing, but this erratum seems to be steering us alo= ng a road full of potholes that I certainly do not want to fall into. IMHO = this is based on a misunderstanding of your "mandated notation" a= rgument.
=C2=A0
=C2=A0
And when that something else arrives, users will be mightily upset if RFC80= 78 CDS/CDNSKEY suddenly stops working, so the code will need to cope with b= oth versions.=C2=A0 The only realistic way to achieve that is to determine = the entire content of the DELETE CDS/CDNSKEY from the zero algorithm field.= Beyond that, the content of the "mandated notation" is irrelevan= t because it can be left unparsed.

 My first suggestion for the draft was indeed: In case the DNSSEC algorithm = is 0, the Digest/Public Key MUST be ignored.

I would go further, and say that all fields (except algorithm) MUST b= e ignored

=C2=A0
But there were concerns that if someone mistyped the algorithm field the DS= accidentally gets removed. So now the RFC says that the contents of the CD= S or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" nota= tion is mandated.

The one RR requiremen= t is not in dispute.

Let us make a start with= the following 3 use cases, to see if we can come to some common understand= ing of what we are trying to achieve.

(1)=C2=A0 CDS arriv= es on the wire

cds.example. IN CDS=C2=A0 \# 5 1234 00 56 78=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ; silly numbers in most fields

RDAT= A as received:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 '= ;algorithm' =3D> 0,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 'digestbin' =3D> 'x',
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 'digtype' =3D> 86,
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'keytag' =3D> 4660,

=
Algorithm =3D 0, so presentation format uses "RFC8078 mandated no= tation":

cds.example.=C2=A0=C2=A0=C2=A0 IN=C2=A0=C2=A0=C2=A0 CD= S=C2=A0=C2=A0=C2=A0 0 0 0 0


(2)=C2=A0 DELE= TE CDS read from zone file, transmitted to parent

cds.example.=C2=A0= =C2=A0=C2=A0 IN=C2=A0=C2=A0=C2=A0 CDS=C2=A0=C2=A0=C2=A0 0 0 0 0

Algorithm =3D 0, so this is a DELETE CDS.

Check that RDATA st= ring matches "mandated notation".

Co= erce all RDATA numerical fields to zero, digest empty.

Tr= ansmitted CDS RR:

cds.example. IN CDS=C2=A0 \# 4 0000 00 00

<= br>
(3)=C2=A0 Normal CDS read from zone file, but with accidental= 0 in algorithm field

cds.example. CDS 6485 0 1 2bb183af5f22588179a5= 3b0a98631fad1a292118

Algorithm =3D 0, so this is apparently a D= ELETE CDS.

Exception raised - RDATA does not match "= mandated notation"

DS saved from accidental deletion= :-)


Obviously, similar logic applies to CD= NSKEY.

--Dick
--001a113ef7e484cebe0552f03742-- From nobody Tue Jun 27 07:55:09 2017 Return-Path: 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 21810129B41 for ; Tue, 27 Jun 2017 07:55:08 -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 dvpnijRvWUHg for ; Tue, 27 Jun 2017 07:55:06 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 2077B129B1A for ; Tue, 27 Jun 2017 07:55:06 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 37FE624AE08; Tue, 27 Jun 2017 14:54:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 75785160048; Tue, 27 Jun 2017 14:54:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2E7F5160096; Tue, 27 Jun 2017 14:54:56 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8TS-unkozhl1; Tue, 27 Jun 2017 14:54:56 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 89C3C160048; Tue, 27 Jun 2017 14:54:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 623CB7C84E77; Wed, 28 Jun 2017 00:54:52 +1000 (AEST) To: Dick Franks Cc: Matthijs Mekking , tjw ietf , =?UTF-8?Q?Ond=C5=99ej_Caletka?= , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, IETF DNSOP WG , Olafur Gudmundsson , RFC Editor From: Mark Andrews References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> In-reply-to: Your message of "Tue, 27 Jun 2017 13:28:40 +0100." Date: Wed, 28 Jun 2017 00:54:52 +1000 Message-Id: <20170627145452.623CB7C84E77@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 14:55:08 -0000 And in reality it will be something like for CDS: if (validated && rrset_count == 1 && rdata->len >= 4 && !memcmp(rdata->data, "\0\0\0", 4)) remove_ds(); because this will all be done in wire format. Note the above ignores the hash content for the CDS if any. The problem is that we do not have a well defined wire format for this signal. "The keying material payload is represented by a single 0." The quoted sentence does not make sense. I can think of 3 interpretions of that sentence. 1. the zero is a place holder for zero length field. 2. the field is a zero byte. 3. the field can be any non zero length content but we are showing it as a zero as it is to be ignored. Remember this record has to be written out and read back in by slave servers across restarts. They MUST *all* produce the same wire representation or else the returned rrset will not validate. Mark In message , Dick Franks wr ites: > > On 26 June 2017 at 15:30, Matthijs Mekking wrote: > > > > > > > On 26-06-17 13:29, Dick Franks wrote: > > > > You misunderstood: Variable length in octets, but not variable in number > > of RDATA elements > > > I did. > > Am I correct in thinking that you want some acknowledgement that 4 fields > exist, but do not really care what the final item is? > > > So an implementer has little choice but to make CDS/CDNSKEY work in > >> accordance with the standard as written until IESG approves something else. > >> > > > > Sure, but that is why we are discussing it, not? > > > > That is what we should be discussing, but this erratum seems to be steering > us along a road full of potholes that I certainly do not want to fall into. > IMHO this is based on a misunderstanding of your "mandated notation" > argument. > > > > > And when that something else arrives, users will be mightily upset if > >> RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to cope > >> with both versions. The only realistic way to achieve that is to determine > >> the entire content of the DELETE CDS/CDNSKEY from the zero algorithm field. > >> Beyond that, the content of the "mandated notation" is irrelevant because > >> it can be left unparsed. > >> > > > > My first suggestion for the draft was indeed: In case the DNSSEC algorithm > > is 0, the Digest/Public Key MUST be ignored. > > > > I would go further, and say that all fields (except algorithm) MUST be > ignored > > > > > But there were concerns that if someone mistyped the algorithm field the > > DS accidentally gets removed. So now the RFC says that the contents of the > > CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" notation is > > mandated. > > > > The one RR requirement is not in dispute. > > Let us make a start with the following 3 use cases, to see if we can come > to some common understanding of what we are trying to achieve. > > (1) CDS arrives on the wire > > cds.example. IN CDS \# 5 1234 00 56 78 ; silly numbers in most fields > > RDATA as received: > > 'algorithm' => 0, > 'digestbin' => 'x', > 'digtype' => 86, > 'keytag' => 4660, > > Algorithm = 0, so presentation format uses "RFC8078 mandated notation": > > cds.example. IN CDS 0 0 0 0 > > > (2) DELETE CDS read from zone file, transmitted to parent > > cds.example. IN CDS 0 0 0 0 > > Algorithm = 0, so this is a DELETE CDS. > > Check that RDATA string matches "mandated notation". > > Coerce all RDATA numerical fields to zero, digest empty. > > Transmitted CDS RR: > > cds.example. IN CDS \# 4 0000 00 00 > > > (3) Normal CDS read from zone file, but with accidental 0 in algorithm > field > > cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118 > > Algorithm = 0, so this is apparently a DELETE CDS. > > Exception raised - RDATA does not match "mandated notation" > > DS saved from accidental deletion:-) > > > Obviously, similar logic applies to CDNSKEY. > > --Dick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jun 27 08:47:34 2017 Return-Path: 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 3DF0E129A9F; Tue, 27 Jun 2017 08:47:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149857845320.31027.4356523685496824571@ietfa.amsl.com> Date: Tue, 27 Jun 2017 08:47:33 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:47:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-02.txt Pages : 13 Date : 2017-06-27 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing with only recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 10:10:27 2017 Return-Path: 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 72A73129572 for ; Tue, 27 Jun 2017 10:10:26 -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, 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 (1024-bit key) header.d=fcelda.cz 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 SMuznDsG0UzO for ; Tue, 27 Jun 2017 10:10:23 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 017AE127078 for ; Tue, 27 Jun 2017 10:10:22 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id w19so1591400uac.0 for ; Tue, 27 Jun 2017 10:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5rDz/3opxZeOcxJwDk+rRU6lNr5f+V9qr2gAGWbMKYY=; b=QzeP+qpMxWeGgucODAoeFrllsq7GV+X8pNePDVmN7EDxA/t1Bt0E7fHGgOmIoRQCOd iPoF3NOAHD99WEr8IdVS/NiCBbjFE1Finfptd7JkYwUE14Tb/vRB0+5Fp/WAcLbhPwvN OLya0yzxJ1ERtl3HD/HhVpCsM8SYe9ZP8y+ig= 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=5rDz/3opxZeOcxJwDk+rRU6lNr5f+V9qr2gAGWbMKYY=; b=FwuQ8xVliTDP6gcvwOc6E/HV3r71SlxrmMPdnUO60Fc3ynlC8ycwJNAZuKA9PHuxtJ OlWdgXkZ410USiHFtB0xSVffTFW1pYEyPaLLEzBmJ291CoS4GADJtY5DVlocCo6vaDD3 3S2ChiIyp9SOQShSctXBDNuBCON1dIScPI7VLoG0JGO0PdbCmXTogX/2IRxMX035Jn3V f7/VuCaGpQmIKXwZqzfuujHAtlH23jozaJ4lWeenKVT5uwXpjKBhomWuNLGNPZmIrql2 nJrz3yvOUCpHc1kX0rocHKJp3yWtEX1Nc4y6TahkigR/T4yZEoLOUCi3nnv5FpsamrEm PEJQ== X-Gm-Message-State: AKS2vOwxqOHyb/S71xviUdLzmTaHYrtZlrrnvVOIiMvQQLxLW5yVLMM1 bu3YlGX09UciZiV+6D3L5UDZHY+n/H8omidhHgDB X-Received: by 10.176.70.201 with SMTP id t9mr3158216uab.65.1498583421548; Tue, 27 Jun 2017 10:10:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.92 with HTTP; Tue, 27 Jun 2017 10:10:01 -0700 (PDT) X-Originating-IP: [94.112.122.95] In-Reply-To: <20170627145452.623CB7C84E77@rock.dv.isc.org> References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> <20170627145452.623CB7C84E77@rock.dv.isc.org> From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Date: Tue, 27 Jun 2017 19:10:01 +0200 Message-ID: To: IETF DNSOP WG Cc: Mark Andrews , Dick Franks , tjw ietf , Matthijs Mekking , =?UTF-8?Q?Ond=C5=99ej_Caletka?= , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 17:10:26 -0000 I'm not sure if this discussion is moving forward. CDS/CDNSKEY RDATA format is the same as DS/DNSKEY RDATA format per definition in Section 3 of RFC 7344. Although DS Digest field and DNSKEY Public Key field can be zero-length on wire, the presentation format is underspecified and it practically cannot be used in this case. That is a problem in implementations where presentation format is used (e.g. in zone file). And we have already confirmed existence of this problem in some implementations in this very thread. This erratum makes a simple change that as a result gives one clear interpretation of how the DS DELETE request should look like. And it allows CDS/CDNSKEY record for the request to be specified both in wire and presentation format. There is plenty other alternative ways to express DS DELETE request. But I would prefer accepting this simple erratum rather than researching all the other options (which we should have done when revising the drafts of this document). Jan On Tue, Jun 27, 2017 at 4:54 PM, Mark Andrews wrote: > > And in reality it will be something like for CDS: > > if (validated && rrset_count == 1 && > rdata->len >= 4 && !memcmp(rdata->data, "\0\0\0", 4)) > remove_ds(); > > because this will all be done in wire format. Note the above ignores > the hash content for the CDS if any. The problem is that we do not > have a well defined wire format for this signal. > > "The keying material payload is represented by a single 0." The > quoted sentence does not make sense. I can think of 3 interpretions > of that sentence. > > 1. the zero is a place holder for zero length field. > 2. the field is a zero byte. > 3. the field can be any non zero length content but we > are showing it as a zero as it is to be ignored. > > Remember this record has to be written out and read back in by slave > servers across restarts. They MUST *all* produce the same wire > representation or else the returned rrset will not validate. > > Mark > > In message , Dick Franks wr > ites: >> >> On 26 June 2017 at 15:30, Matthijs Mekking wrote: >> >> > >> > >> > On 26-06-17 13:29, Dick Franks wrote: >> > >> > You misunderstood: Variable length in octets, but not variable in number >> > of RDATA elements >> >> >> I did. >> >> Am I correct in thinking that you want some acknowledgement that 4 fields >> exist, but do not really care what the final item is? >> >> >> So an implementer has little choice but to make CDS/CDNSKEY work in >> >> accordance with the standard as written until IESG approves something else. >> >> >> > >> > Sure, but that is why we are discussing it, not? >> > >> >> That is what we should be discussing, but this erratum seems to be steering >> us along a road full of potholes that I certainly do not want to fall into. >> IMHO this is based on a misunderstanding of your "mandated notation" >> argument. >> >> >> >> > And when that something else arrives, users will be mightily upset if >> >> RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to cope >> >> with both versions. The only realistic way to achieve that is to determine >> >> the entire content of the DELETE CDS/CDNSKEY from the zero algorithm field. >> >> Beyond that, the content of the "mandated notation" is irrelevant because >> >> it can be left unparsed. >> >> >> > >> > My first suggestion for the draft was indeed: In case the DNSSEC algorithm >> > is 0, the Digest/Public Key MUST be ignored. >> > >> >> I would go further, and say that all fields (except algorithm) MUST be >> ignored >> >> >> >> > But there were concerns that if someone mistyped the algorithm field the >> > DS accidentally gets removed. So now the RFC says that the contents of the >> > CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" notation is >> > mandated. >> > >> >> The one RR requirement is not in dispute. >> >> Let us make a start with the following 3 use cases, to see if we can come >> to some common understanding of what we are trying to achieve. >> >> (1) CDS arrives on the wire >> >> cds.example. IN CDS \# 5 1234 00 56 78 ; silly numbers in most fields >> >> RDATA as received: >> >> 'algorithm' => 0, >> 'digestbin' => 'x', >> 'digtype' => 86, >> 'keytag' => 4660, >> >> Algorithm = 0, so presentation format uses "RFC8078 mandated notation": >> >> cds.example. IN CDS 0 0 0 0 >> >> >> (2) DELETE CDS read from zone file, transmitted to parent >> >> cds.example. IN CDS 0 0 0 0 >> >> Algorithm = 0, so this is a DELETE CDS. >> >> Check that RDATA string matches "mandated notation". >> >> Coerce all RDATA numerical fields to zero, digest empty. >> >> Transmitted CDS RR: >> >> cds.example. IN CDS \# 4 0000 00 00 >> >> >> (3) Normal CDS read from zone file, but with accidental 0 in algorithm >> field >> >> cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118 >> >> Algorithm = 0, so this is apparently a DELETE CDS. >> >> Exception raised - RDATA does not match "mandated notation" >> >> DS saved from accidental deletion:-) >> >> >> Obviously, similar logic applies to CDNSKEY. >> >> --Dick > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Jun 27 10:15:57 2017 Return-Path: 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 C03A512EA97 for ; Tue, 27 Jun 2017 10:15:56 -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, 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 XpAM1hbVWzbO for ; Tue, 27 Jun 2017 10:15:54 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AF712EA7C for ; Tue, 27 Jun 2017 10:15:54 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 907033F438; Tue, 27 Jun 2017 13:15:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22866.37576.448814.454933@gro.dd.org> Date: Tue, 27 Jun 2017 13:15:52 -0400 From: Dave Lawrence To: dnsop In-Reply-To: References: Archived-At: Subject: Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 17:15:57 -0000 Thank you for the feedback, Jinmei! Now that Akamai finally posted its IPR notice we can work on moving it forward. We plan on asking for WG adoption now that -01 is up. https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ Jinmei wrote: > - I suspect it should include 'Updates: 1035 (if approved)' in the > top boilerplate. Done. 1034 too. > The recommended value of the client response timer is 1.8 seconds, > so end clients will see this amount of delay for queries for which > this technique is needed (most notably while the corresponding > authoritative servers are under a DoS attack and unreachable). I > wonder whether this is really acceptable in terms of user > experience. According to the draft this implementation has been > actually used in the field (correct?). If so, were the end users > okay with the delay? It's hard for me to address directly what "okay" is. I can only say that they got service when otherwise there would have been done. We're certainly open to discussing timer values. In fact, Warren has previously told me that he doesn't think the values are right either. We might end up with some different recommendations based on particular use-cases. At any rate, they're all "SHOULD" for people to adjust for whatever their own reasons. > Also, it's not clear to me why the TTL is set to 1 second. Since > it's actually expired, a zero TTL seems to be a more sensible choice > here (a similar feature of unbound uses a zero TTL). If there's a > specific reason to avoid 0, it would be better to explain it > explicitly. Added to document: "1 second was chosen because historically 0 second TTLs have been problematic for some implementations. It not only sidesteps those potential problems with no practical negative consequence, it would also rate limit further queries from any client that is honoring the TTL, such as a forwarding resolver." Also, as noted with the other timers, it's still a SHOULD. It doesn't seem worth it to me to add even more text cataloguing the problems that some people have encountered with 0 TTL, such as informally described in http://mark.lindsey.name/2009/03/never-use-dns-ttl-of-zero-0.html I am, however, still open to further discussion on whether there is a compelling reason to use 0 instead of 1. I realize 1035 did have a pretty explicit definition of what it though 0 *should* mean, but then went on to describe sending 0 TTL SOAs, which no one does. > - Section 4 > >> Canonical Name (CNAME) records mingled in the expired cache with >> other records at the same owner name can cause surprising results. [...] > I suspect this is quite specific to internal implementation details > of BIND, [...] it's probably better to clarify it's specific to a > particular implementation architecture. I struggled with how to incorporate this feedback, because I felt like it was already pretty clear that I was discussing BIND specifically. In the end the only change I made specifically about this was to say "The version of BIND" instead of just "BIND", because I'm not even sure whether it would be an issue in the latest versions. I also swapped the sequence of events around to match the real incident that happened (A was received first, then later CNAME, versus the original doc saying CNAME then A). If people think there is additional wording improvement still needed here, please suggest. From nobody Tue Jun 27 11:39:40 2017 Return-Path: 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 517D612EA58 for ; Tue, 27 Jun 2017 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 SNRxFn4d3Gew for ; Tue, 27 Jun 2017 11:39:36 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 4674F1292F5 for ; Tue, 27 Jun 2017 11:39:36 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id p187so24391937oif.3 for ; Tue, 27 Jun 2017 11:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JLgskIERHtI0kaISg9YkU1bcZIUg2Zc3E8g6xpXxTt4=; b=Ei9dJARjSI5EvC/18K/7SjXthiOWzoFmrjTD/jMWwuGiTtleqPl1Ek9UUlkfoy4xtS 83pnxdQGN/tKd853NaOSr9+D1IAlnov2L3kUEPAsJW/xcN66HkiJHuSlsK+01TwLgZmi 5SUdt8PynyVuZ3FPpd5XG4F0a8X4vTVTaUTxpHg6bS6QVDF+Its2h+hE6saZ6V/hyf5I nxWUceT6kNJLR6FC7x1lKX0XOuPgtT1uV1d+pSjpCfTcuoiFQ3CGWhZz0z02xn1Y/JCs wdvr87BfoZI0uGdBWE+dRjs9pCt+fRqoZsOr68oZ3ZVUd/X6ID3CB6uzWrDZ5R1nGOXR 6/zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JLgskIERHtI0kaISg9YkU1bcZIUg2Zc3E8g6xpXxTt4=; b=HE9skVR7eMj7EmxLkSLnxNN18QPj95XFmclMsUFMBtwjdly/wwry70jEq8pXLak2UT TsZdsTlhgmXx3UDDihO/Wx20Vx17HyaiE04lru32GjA7UAavzKnXSOKWNGsQSIAEyqEl IICR77nKftruUmUODilG/1gRTCbm56YlTmarYyg9SXl3yS5YFxiUy9RCM3ZhAqANoV5I bW905fjmerKu0vZWY92gModWWAfBL3qsXLqzA08/vhai3dQprWPzZ7FnJMinf6JYw4li rOgStsU49TrL8NHndhBMeVz/u1rPq5+D5OabUbaOiM2WSh57/bNI44lxLdGa7NzrHB8q r9EA== X-Gm-Message-State: AKS2vOxpOr3RhThshvGiz46ooploQHcaqCDjHS0Ark9itQMMMNLtRXRd i/C61LQKSwOeWhKoW3/0p8PqghrifQ== X-Received: by 10.202.188.87 with SMTP id m84mr4194259oif.166.1498588775693; Tue, 27 Jun 2017 11:39:35 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.182.232.163 with HTTP; Tue, 27 Jun 2017 11:38:55 -0700 (PDT) In-Reply-To: References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> <20170627145452.623CB7C84E77@rock.dv.isc.org> From: Dick Franks Date: Tue, 27 Jun 2017 19:38:55 +0100 X-Google-Sender-Auth: 0AZwg82FjuwrWV0e9vNAvbeCb4k Message-ID: To: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= Cc: IETF DNSOP WG , Mark Andrews , tjw ietf , Matthijs Mekking , =?UTF-8?Q?Ond=C5=99ej_Caletka?= , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor Content-Type: multipart/alternative; boundary="001a113dd52aa3c1070552f5631c" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 18:39:38 -0000 --001a113dd52aa3c1070552f5631c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 27 June 2017 at 18:10, Jan V=C4=8Del=C3=A1k wrote: >8 There is plenty other alternative ways to express DS DELETE request. > But I would prefer accepting this simple erratum rather than > researching all the other options (which we should have done when > revising the drafts of this document). > There is no point in moaning that things could/should have been done better= . What is needed now is methodical use-case analysis based on RFC8078 as it exists now and tested against a real implementation. The time to rewrite the RFC will come if/when we discover we are unable to live with it. We have not reached that point yet. --Dick --001a113dd52aa3c1070552f5631c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On 27 June 2017 at 18:10, Jan V=C4=8Del=C3=A1k <jv@fcelda.cz> wro= te:

>8

There is plenty other alternative ways to express DS DELETE request.
But I would prefer accepting this simple erratum rather than
researching all the other options (which we should have done when
revising the drafts of this document).

= There is no point in moaning that things could/should have been done better= .

What is needed now is methodical use-case analysis base= d on RFC8078 as it exists now and tested against a real implementation.=C2= =A0 The time to rewrite the RFC will come if/when we discover we are unable= to live with it. We have not reached that point yet.


--Dick
--001a113dd52aa3c1070552f5631c-- From nobody Tue Jun 27 17:57:16 2017 Return-Path: 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 19F12129B79; Tue, 27 Jun 2017 17:57:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149861142806.18319.17791641856394471897@ietfa.amsl.com> Date: Tue, 27 Jun 2017 17:57:08 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 00:57:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Special-Use Domain Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-06.txt Pages : 28 Date : 2017-06-27 Abstract: The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-06 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 21:21:38 2017 Return-Path: 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 664A9126B6D for ; Tue, 27 Jun 2017 21:21:36 -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, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 MTRt0YloyDeU for ; Tue, 27 Jun 2017 21:21:34 -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 D6402127867 for ; Tue, 27 Jun 2017 21:21:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 962D0349421; Wed, 28 Jun 2017 04:21:30 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 49E1D160048; Wed, 28 Jun 2017 04:21:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0BD6916004F; Wed, 28 Jun 2017 04:21:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1ftbvSS0Ld_i; Wed, 28 Jun 2017 04:21:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AEA03160048; Wed, 28 Jun 2017 04:21:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 863D87CA0CFF; Wed, 28 Jun 2017 14:21:27 +1000 (AEST) To: Dick Franks Cc: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= , IETF DNSOP WG , tjw ietf , Matthijs Mekking , =?UTF-8?Q?Ond=C5=99ej_Caletka?= , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson , RFC Editor From: Mark Andrews References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> <20170627145452.623CB7C84E77@rock.dv.isc.org> In-reply-to: Your message of "Tue, 27 Jun 2017 19:38:55 +0100." Date: Wed, 28 Jun 2017 14:21:27 +1000 Message-Id: <20170628042127.863D87CA0CFF@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 04:21:36 -0000 In message , Dick Franks writes: > On 27 June 2017 at 18:10, Jan Včelák wrote: > > >8 > > There is plenty other alternative ways to express DS DELETE request. > > But I would prefer accepting this simple erratum rather than > > researching all the other options (which we should have done when > > revising the drafts of this document). > > > > There is no point in moaning that things could/should have been done > better. > > What is needed now is methodical use-case analysis based on RFC8078 as it > exists now and tested against a real implementation. The time to rewrite > the RFC will come if/when we discover we are unable to live with it. We > have not reached that point yet. I can't go from RFC8078 to a working implementation because the existing description is not clear enough to do it. I don't think anyone can do it. With the proposed errata fix I could write code. For CDS the RRset is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00. For CDNSKEY the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00. In both cases the RRset needs to be signed and validitation needs to return that the answer is secure before it can be acteded on. Mark > --Dick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jun 28 01:01:33 2017 Return-Path: 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 4C61312EB78 for ; Wed, 28 Jun 2017 01:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 o0V2tWItsXvj for ; Wed, 28 Jun 2017 01:01:29 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 D5A8C12EB9B for ; Wed, 28 Jun 2017 01:01:28 -0700 (PDT) Received: from [IPv6:2001:981:19be:1:8963:6456:103b:9dfe] (unknown [IPv6:2001:981:19be:1:8963:6456:103b:9dfe]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4B7B1B2F3; Wed, 28 Jun 2017 10:01:26 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl To: Dick Franks Cc: =?UTF-8?Q?Ond=c5=99ej_Caletka?= , =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= , tjw ietf , IETF DNSOP WG , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, RFC Editor References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> From: Matthijs Mekking Message-ID: <8d9bac0b-102e-f40f-2f8f-21da28d24518@pletterpet.nl> Date: Wed, 28 Jun 2017 10:01:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 08:01:31 -0000 On 27-06-17 14:28, Dick Franks wrote: > > On 26 June 2017 at 15:30, Matthijs Mekking > wrote: > > > > On 26-06-17 13:29, Dick Franks wrote: > > You misunderstood: Variable length in octets, but not variable in > number of RDATA elements > > > I did. > > Am I correct in thinking that you want some acknowledgement that 4 > fields exist, but do not really care what the final item is? RFC 7344 specifies that the CDS RDATA format is the same as DS RDATA format. RFC 4034 speficies the DS RDATA format contains 4 fields. So by definition the CDS RDATA contains 4 fields. Same logic applies for DNSKEY/CDNSKEY. I suggested indeed one time that we should ignore the Digest (or Public Key in case of CDNSKEY) if Algorithm is 0, but that is unrelated to this issue. Since "0" is not valid base64, I would like to see this erratum accepted to fix the notation in RFC 8078. Best regards, Matthijs > So an implementer has little choice but to make CDS/CDNSKEY work > in accordance with the standard as written until IESG approves > something else. > > > Sure, but that is why we are discussing it, not? > > > That is what we should be discussing, but this erratum seems to be > steering us along a road full of potholes that I certainly do not want > to fall into. IMHO this is based on a misunderstanding of your "mandated > notation" argument. > > > > And when that something else arrives, users will be mightily > upset if RFC8078 CDS/CDNSKEY suddenly stops working, so the code > will need to cope with both versions. The only realistic way to > achieve that is to determine the entire content of the DELETE > CDS/CDNSKEY from the zero algorithm field. Beyond that, the > content of the "mandated notation" is irrelevant because it can > be left unparsed. > > > My first suggestion for the draft was indeed: In case the DNSSEC > algorithm is 0, the Digest/Public Key MUST be ignored. > > > I would go further, and say that all fields (except algorithm) MUST be > ignored > > > > But there were concerns that if someone mistyped the algorithm field > the DS accidentally gets removed. So now the RFC says that the > contents of the CDS or CDNSKEY RRset MUST contain one RR and the "0 > [0,3] 0 0" notation is mandated. > > > The one RR requirement is not in dispute. > > Let us make a start with the following 3 use cases, to see if we can > come to some common understanding of what we are trying to achieve. > > (1) CDS arrives on the wire > > cds.example. IN CDS \# 5 1234 00 56 78 ; silly numbers in most fields > > RDATA as received: > > 'algorithm' => 0, > 'digestbin' => 'x', > 'digtype' => 86, > 'keytag' => 4660, > > Algorithm = 0, so presentation format uses "RFC8078 mandated notation": > > cds.example. IN CDS 0 0 0 0 > (2) DELETE CDS read from zone file, transmitted to parent > > cds.example. IN CDS 0 0 0 0 > > Algorithm = 0, so this is a DELETE CDS. > > Check that RDATA string matches "mandated notation". > > Coerce all RDATA numerical fields to zero, digest empty. > > Transmitted CDS RR: > > cds.example. IN CDS \# 4 0000 00 00 > > > (3) Normal CDS read from zone file, but with accidental 0 in algorithm > field > > cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118 > > Algorithm = 0, so this is apparently a DELETE CDS. > > Exception raised - RDATA does not match "mandated notation" > > DS saved from accidental deletion:-) > > > Obviously, similar logic applies to CDNSKEY. > > --Dick From nobody Wed Jun 28 03:13:13 2017 Return-Path: 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 1E13B129462 for ; Wed, 28 Jun 2017 03:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IY-3Fn4DCPdI for ; Wed, 28 Jun 2017 03:13:10 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 3F3AD126C0F for ; Wed, 28 Jun 2017 03:13:09 -0700 (PDT) X-AuditID: c618062d-9edff70000002716-37-595396403b50 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id D1.0A.10006.04693595; Wed, 28 Jun 2017 13:42:57 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0352.000; Wed, 28 Jun 2017 06:13:07 -0400 From: Daniel Migault To: dnsop Thread-Topic: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-05.txt Thread-Index: AQHS7/NtM/PzMkhdlEOztqzFKkayf6I6DeQA Date: Wed, 28 Jun 2017 10:13:06 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C87C98@eusaamb107.ericsson.se> References: <149864318298.18209.9110331798587720209.idtracker@ietfa.amsl.com> In-Reply-To: <149864318298.18209.9110331798587720209.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXRPoK7jtOBIg/W3uC3uvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO+3fjMWnJGsmPl7MUsD4w+JLkZODgkBE4lpfX+Yuxi5OIQE jjJKbN9ygg3CWc4o8fXjUlaQKjYBI4m2Q/3sILaIgJTEs1mPWEBsYYFEic33ZzJBxJMkGpra oWqMJO6eOQwU5+BgEVCV+N7oAGLyCvhK/L5nAFIhBGR+6PsN1skp4Cex8etnNhCbUUBM4vup NWBxZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBC2ksSc19eYQcYzC2hKrN+lD9GqKDGl+yHY MbwCghInZz5hmcAoMgvJ1FkIHbOQdMxC0rGAkWUVI0dpcUFObrqRwSZGYGgfk2DT3cF4f7rn IUYBDkYlHl6TquBIIdbEsuLK3EOMEhzMSiK8BolAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwT zl+IEBJITyxJzU5NLUgtgskycXBKNTDuYMou2/eoSpjZ7+TCULXtWosunrTk0ddoO382cpG6 342Jj40m1n89cMUnrrZ3SijntrOz+86an/tuV3apj8HvUe3NeQ2byo8evu7y9UfpxKN//1VF KHEWFf0Q/jPnydM5fCZH9jN9TBNLC9p5KMLAebs11w3bpexVU+b7O3v5fZlwjd37ZMF7JZbi jERDLeai4kQAhQMj22kCAAA= Archived-At: Subject: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-05.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 10:13:12 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhIG5ldyB2ZXJzaW9uIGZvciB0aGUgRE5TU0VDIHZhbGlkYXRv cnMgcmVxdWlyZW1lbnRzLiBPdXIgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBjdXJyZW50IHZl cnNpb24gaGFzIGNvbnNpZGVyZWQgYWxsIHJlY2VpdmVkIGNvbW1lbnRzLg0KDQpXZSBhcHByZWNp YXRlIHlvdXIgY29tbWVudHMgYW5kIGZlZWQgYmFja3MuIA0KDQpZb3VycywgDQpEYW5pZWwgDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBK dW5lIDI4LCAyMDE3IDExOjQ2IEFNDQpUbzogRWR3YXJkIExld2lzIDxlZHdhcmQubGV3aXNAaWNh bm4ub3JnPjsgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT47IERh biBZb3JrIDx5b3JrQGlzb2Mub3JnPjsgeW9ya0Bpc29jLm9yZyA8eW9ya0Bpc29jLm9yZz4NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWdsdC1kbnNvcC1kbnNz ZWMtdmFsaWRhdG9yLXJlcXVpcmVtZW50cy0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbWdsdC1kbnNvcC1kbnNzZWMtdmFsaWRhdG9yLXJlcXVpcmVtZW50cy0wNS50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFuaWVsIE1pZ2F1bHQgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWdsdC1kbnNvcC1k bnNzZWMtdmFsaWRhdG9yLXJlcXVpcmVtZW50cw0KUmV2aXNpb246CTA1DQpUaXRsZToJCUROU1NF QyBWYWxpZGF0b3JzIFJlcXVpcmVtZW50cw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wNi0yNw0KR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTMNClVSTDogICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWdsdC1kbnNvcC1kbnNz ZWMtdmFsaWRhdG9yLXJlcXVpcmVtZW50cy0wNS50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZ2x0LWRuc29wLWRuc3NlYy12YWxpZGF0 b3ItcmVxdWlyZW1lbnRzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tZ2x0LWRuc29wLWRuc3NlYy12YWxpZGF0b3ItcmVxdWlyZW1lbnRzLTA1DQpI dG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1tZ2x0LWRuc29wLWRuc3NlYy12YWxpZGF0b3ItcmVxdWlyZW1lbnRzLTA1DQpEaWZmOiAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1nbHQtZG5zb3At ZG5zc2VjLXZhbGlkYXRvci1yZXF1aXJlbWVudHMtMDUNCg0KQWJzdHJhY3Q6DQogICBETlNTRUMg cHJvdmlkZXMgZGF0YSBpbnRlZ3JpdHkgYW5kIHNvdXJjZSBhdXRoZW50aWNhdGlvbiB0byBhIGJh c2ljDQogICBETlMgUlJzZXQuICBHaXZlbiBhIFJSc2V0LCBhIHB1YmxpYyBrZXkgYW5kIGEgc2ln bmF0dXJlLCBhIEROU1NFQw0KICAgdmFsaWRhdG9yIGNoZWNrcyB0aGUgc2lnbmF0dXJlLCB0aW1l IGNvbnN0cmFpbnRzLCBhbmQgb3RoZXIsIGxvY2FsLA0KICAgcG9saWNpZXMuICBJbiBjYXNlIG9m IG1pc21hdGNoIHRoZSBSUlNldCBpcyBjb25zaWRlcmVkIGlsbGVnaXRpbWF0ZQ0KICAgYW5kIGlz IHJlamVjdGVkLg0KDQogICBBY2N1cmFjeSBpbiBETlNTRUMgdmFsaWRhdGlvbiwgdGhhdCBpcywg YXZvaWRpbmcgZmFsc2UgcG9zaXRpdmVzIGFuZA0KICAgY2F0Y2hpbmcgdHJ1ZSBuZWdhdGl2ZXMs IHJlcXVpcmVzIHRoYXQgYm90aCB0aGUgc2lnbmluZyBwcm9jZXNzIGFuZA0KICAgdmFsaWRhdGlv biBwcm9jZXNzIGFkaGVyZSB0byB0aGUgcHJvdG9jb2wsIHdoaWNoIGJlZ2lucyB3aXRoIGV4dGVy bmFsDQogICBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyByZXF1aXJlbWVudHMgZm9yIGENCiAgIHZhbGlkYXRvciB0byBiZSBhYmxlIHRvIHBlcmZvcm0g YWNjdXJhdGUgdmFsaWRhdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Jun 28 04:00:36 2017 Return-Path: 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 135DE12EAEB for ; Wed, 28 Jun 2017 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz 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 F7zoESYxLwfL for ; Wed, 28 Jun 2017 04:00:32 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEECE12EA64 for ; Wed, 28 Jun 2017 04:00:31 -0700 (PDT) Received: from [IPv6:2001:718:1:6::134:196] (oskarpc.cesnet.cz [IPv6:2001:718:1:6::134:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 6FCD120066; Wed, 28 Jun 2017 13:00:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1498647629; bh=EOGPnhKEs4zxI9UyMnVfxXfcfymoC4Aous1gAUhYNHU=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=RQdjmNlBT90kdk2EHFpIMudVTCsNxlHvRSmJQtAEGxMzaduoedTRjRR165XXOy5uO 7XemP6AE3a6PeP6cBCWBxabwkCiuTNNdbiLttkn86BlD7GKfVXMODh/4fQY5i+UbAz lkMkDrtd9dkD7mHRrg/F0iOQ+pNV+hKi3HM6/LE0= To: RFC Errata System , olafur+ietf@cloudflare.com, pwouters@redhat.com, bclaise@cisco.com, warren@kumari.net, suzworldwide@gmail.com, tjw.ietf@gmail.com References: <20170623105434.22478B810AB@rfc-editor.org> Cc: dnsop@ietf.org From: =?UTF-8?Q?Ond=c5=99ej_Caletka?= Message-ID: <15f2db72-8529-6093-2bf1-5af85ee0bca4@cesnet.cz> Date: Wed, 28 Jun 2017 13:00:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170623105434.22478B810AB@rfc-editor.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010605040405050909080705" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 11:00:34 -0000 This is a cryptographically signed message in MIME format. --------------ms010605040405050909080705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I have an erratum to this reported erratum. This proposed corrected paragraph: > Strictly speaking, the CDS record could be "CDS X 0 X 00" as only th= e > DNSKEY algorithm is what signals the DELETE operation, but for > clarity, the "0 0 0 00" notation is mandated -- this is not a > definition of DS digest algorithm 0. The same argument applies to > "CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second field is mandate= d by > [RFC4034], Section 2.1.2. should actually look like this (difference is the first CDS example): > Strictly speaking, the CDS record could be "CDS X 0 X X" as only the= > DNSKEY algorithm is what signals the DELETE operation, but for > clarity, the "0 0 0 00" notation is mandated -- this is not a > definition of DS digest algorithm 0. The same argument applies to > "CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second field is mandate= d by > [RFC4034], Section 2.1.2. Otherwise, the statement "only the DNSKEY algorithm is what signals the DELETE operation" would not make any sense. -- Regards, Ond=C5=99ej Caletka --------------ms010605040405050909080705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CoEwggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwp9Jj5Aej1xPkS1GV3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYty qDGF2nnItxV1SkwVoDxFeRzOIHYNYvBRHaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+ 0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VWFf/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyim atBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0baminfLcsh6ubCdINZc+Nof2lU387NCDgg oh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAMC57iZXssncp24eaN08VlAgMBAAGj ggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcB AQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcw AoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZI hvcNAQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkF OxA/TUiuK2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBS WxITl1KHBS9YBskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsB iWU2muAoGItwbaP55EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101 S1OI6J1tUil1r7ES/svNqVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9Eow ggVwMIIEWKADAgECAhAOQPOEM/O7/KtI/tffwAnHMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMw HhcNMTcwMTAyMDAwMDAwWhcNMTgwMjAxMTIwMDAwWjB+MRMwEQYKCZImiZPyLGQBGRYDb3Jn MRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYDdGNzMQswCQYDVQQG EwJDWjEPMA0GA1UEChMGQ0VTTkVUMRwwGgYDVQQDExNPbmRyZWogQ2FsZXRrYSAzNzM4MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuVyDB1b7Pqcm93ZJ8A6J7l6gsPgpdach Mg2I5daT9osHhGUwPBsayml4ZE5mWhzForKB1hAWSrwTh5+qKyzFk/rh8fmDlXVILh0q1Z/K Wu3p3etYaPqBQK5iuQd5oV5rYfXtbCMIX/4Ne3O4cspeg3IJ+T4wQeZFbpcBCAP6MxkLSVBl u3LMftZXhz41BmiDpO+41wmAF5BQUOA11G6cAukc8La3iTr5yfydJ6VfnskBl8R3WrEkC8uX /vHvnF/Y6HeABL0ddtVGvVUYVn0Nz2D1ZnrEsce38sdNd2whSKKr6COs4a0hj3CbxcSxj04l McigkTWhZneY9DgvEMEDbwIDAQABo4IB9DCCAfAwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWL RggEpu2XcKYwHQYDVR0OBBYEFKKndMvbQc48lModjfiJrAVt7ZgMMAwGA1UdEwEB/wQCMAAw NgYDVR0RBC8wLYERY2FsZXRrYUBjZXNuZXQuY3qBGE9uZHJlai5DYWxldGthQGNlc25ldC5j ejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDQGA1Ud IAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3TAUCAwMDMIGFBgNV HR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5BZVNjaWVuY2VQ ZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFl U2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUA A4IBAQBNXO+U8KLfIAzEhfr7QGU8mSZwu3SMVnxCEhkdJvrYGTECfpz2oT4sn/CiXmRIKFrU faGwdpJaqHtYnChlQMqaFS/SzNms2XPceKOiB1QLiVSTf11sYgizVTDgIDpF8+IvH4W1mkNg pC7P8ac+9BMGERq8md28e4r5cG//U/4c2+9dqJGzRwXJvuxMk381JaYw//mZMdHkfUdFDGpN sVUcu0bDYehGpeQDOKdTic/zmd7eX3NucCmoMMsE3KGsbNdfFLmcIFRApFPBHNh9bfjrraKU MZbEBPbu/YXwENYUDqlFzJEv5Cl3xTkbrDf8vWY5hfOd0vyHUusZfKAcpAexMYIDwzCCA78C AQEwgYYwcjELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcT CUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2Ug UGVyc29uYWwgQ0EgMwIQDkDzhDPzu/yrSP7X38AJxzANBglghkgBZQMEAgEFAKCCAg0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjI4MTEwMDI2WjAv BgkqhkiG9w0BCQQxIgQgR+bHspri9lic/+s7kMviyUSBBO1qLP2+/IwzdErbzDAwbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJ KwYBBAGCNxAEMYGJMIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k MRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5B IGVTY2llbmNlIFBlcnNvbmFsIENBIDMCEA5A84Qz87v8q0j+19/ACccwgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2ll bmNlIFBlcnNvbmFsIENBIDMCEA5A84Qz87v8q0j+19/ACccwDQYJKoZIhvcNAQEBBQAEggEA nxEJoka5EJ11Z2AjnSfa+bZYYdQE81Da9EjpLnVXYiLzE/zL0yrl8IMtQyt5Dc/f8WtzqbEB r66KcU6JsUhLeYY6g271gA21KW1iomf9yuAaTeSpvLASoKAaapIWW1FPONiAarShhGswTIEY UaPFIIUvT89+PsxwAxH7Q/zsxe/GfbL0yWAqQjoT+9ZX/PLl2HFhy2JDEKZKFcd3h8y3BXhO Qoy7HtIbMZLumqxtGOSiBSHlrtLwnjutVedSOw2tk3WCBepUORw+idItXoMd+zZ2MDptJp78 oP5OrBGWjDKSrpmW9bm3/MCTQSfpwgSwJF0fL6/drqsq7jfWCaMJDgAAAAAAAA== --------------ms010605040405050909080705-- From nobody Wed Jun 28 04:27:10 2017 Return-Path: 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 5049B1293E1 for ; Wed, 28 Jun 2017 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz 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 R68MxRQ_Lwki for ; Wed, 28 Jun 2017 04:27:07 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD2912EBF9 for ; Wed, 28 Jun 2017 04:27:06 -0700 (PDT) Received: from [IPv6:2001:718:1:6::134:196] (oskarpc.cesnet.cz [IPv6:2001:718:1:6::134:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 14BA5200AD; Wed, 28 Jun 2017 13:27:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1498649224; bh=s21TuIA95uMY5kjZFSQM+Akf6WjtJhkJYGnMr0G3s24=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=f37Ze0tynFfkeVKGHlVPF3zabjDbIRf3meMkBFX/9RS7eRV8hS16xSwIlPlT7Yd/F j2rs6oXPmv3oSYUyZJhXrEtVar9jxbLJTGG9rMWVhFnukj9bDBpLymNF349SJPkXgK IqYb2DLm18788ExyN3oSGCnCuZRMQ7ZEoFtzg8Fg= To: Mark Andrews , Dick Franks References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> <20170627145452.623CB7C84E77@rock.dv.isc.org> <20170628042127.863D87CA0CFF@rock.dv.isc.org> Cc: tjw ietf , Matthijs Mekking , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= , IETF DNSOP WG , Suzanne Woolf , pwouters@redhat.com, bclaise@cisco.com, =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= , Olafur Gudmundsson , RFC Editor , =?UTF-8?B?SmFyb23DrXIgVGFsw63FmQ==?= From: =?UTF-8?Q?Ond=c5=99ej_Caletka?= Message-ID: <6e0e2e92-6c06-38cf-16d9-a78ddfbaaed6@cesnet.cz> Date: Wed, 28 Jun 2017 13:27:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170628042127.863D87CA0CFF@rock.dv.isc.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010703010307080509000101" Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 11:27:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010703010307080509000101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, >Dick Franks: >> What is needed now is methodical use-case analysis based on RFC8078 as= it >> exists now and tested against a real implementation. The time to rewr= ite >> the RFC will come if/when we discover we are unable to live with it. W= e >> have not reached that point yet. Mark Andrews: > I can't go from RFC8078 to a working implementation because the > existing description is not clear enough to do it. I don't think > anyone can do it. >=20 > With the proposed errata fix I could write code. For CDS the RRset > is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00. For CDNSKEY > the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00. I have a confirmation from the real implementation of RFC8078 in the .CZ domain registry (cc jaromir.talir) that their understanding of CDNSKEY DELETE operation is exactly the set of RDATA quoted by Mark Andrews, which translates to the presentation form CDNSKEY 0 3 0 AA=3D=3D I don't think there is a big room to interpret RFC 8078 differently, since it does not define any new presentation/wire format for CDS/CDNSKEY record. Therefore, even future versions of software that (de-)serializes RRs between wire and presentation format will have issues if there are not all fields mandated by RFC 4034 present in the rdata. -- Ond=C5=99ej Caletka --------------ms010703010307080509000101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CoEwggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwp9Jj5Aej1xPkS1GV3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYty qDGF2nnItxV1SkwVoDxFeRzOIHYNYvBRHaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+ 0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VWFf/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyim atBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0baminfLcsh6ubCdINZc+Nof2lU387NCDgg oh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAMC57iZXssncp24eaN08VlAgMBAAGj ggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcB AQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcw AoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZI hvcNAQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkF OxA/TUiuK2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBS WxITl1KHBS9YBskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsB iWU2muAoGItwbaP55EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101 S1OI6J1tUil1r7ES/svNqVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9Eow ggVwMIIEWKADAgECAhAOQPOEM/O7/KtI/tffwAnHMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMw HhcNMTcwMTAyMDAwMDAwWhcNMTgwMjAxMTIwMDAwWjB+MRMwEQYKCZImiZPyLGQBGRYDb3Jn MRYwFAYKCZImiZPyLGQBGRYGdGVyZW5hMRMwEQYKCZImiZPyLGQBGRYDdGNzMQswCQYDVQQG EwJDWjEPMA0GA1UEChMGQ0VTTkVUMRwwGgYDVQQDExNPbmRyZWogQ2FsZXRrYSAzNzM4MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuVyDB1b7Pqcm93ZJ8A6J7l6gsPgpdach Mg2I5daT9osHhGUwPBsayml4ZE5mWhzForKB1hAWSrwTh5+qKyzFk/rh8fmDlXVILh0q1Z/K Wu3p3etYaPqBQK5iuQd5oV5rYfXtbCMIX/4Ne3O4cspeg3IJ+T4wQeZFbpcBCAP6MxkLSVBl u3LMftZXhz41BmiDpO+41wmAF5BQUOA11G6cAukc8La3iTr5yfydJ6VfnskBl8R3WrEkC8uX /vHvnF/Y6HeABL0ddtVGvVUYVn0Nz2D1ZnrEsce38sdNd2whSKKr6COs4a0hj3CbxcSxj04l McigkTWhZneY9DgvEMEDbwIDAQABo4IB9DCCAfAwHwYDVR0jBBgwFoAUjJ8RLubjegSlHlWL RggEpu2XcKYwHQYDVR0OBBYEFKKndMvbQc48lModjfiJrAVt7ZgMMAwGA1UdEwEB/wQCMAAw NgYDVR0RBC8wLYERY2FsZXRrYUBjZXNuZXQuY3qBGE9uZHJlai5DYWxldGthQGNlc25ldC5j ejAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDQGA1Ud IAQtMCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3TAUCAwMDMIGFBgNV HR8EfjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5BZVNjaWVuY2VQ ZXJzb25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFl U2NpZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUA A4IBAQBNXO+U8KLfIAzEhfr7QGU8mSZwu3SMVnxCEhkdJvrYGTECfpz2oT4sn/CiXmRIKFrU faGwdpJaqHtYnChlQMqaFS/SzNms2XPceKOiB1QLiVSTf11sYgizVTDgIDpF8+IvH4W1mkNg pC7P8ac+9BMGERq8md28e4r5cG//U/4c2+9dqJGzRwXJvuxMk381JaYw//mZMdHkfUdFDGpN sVUcu0bDYehGpeQDOKdTic/zmd7eX3NucCmoMMsE3KGsbNdfFLmcIFRApFPBHNh9bfjrraKU MZbEBPbu/YXwENYUDqlFzJEv5Cl3xTkbrDf8vWY5hfOd0vyHUusZfKAcpAexMYIDwzCCA78C AQEwgYYwcjELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcT CUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2Ug UGVyc29uYWwgQ0EgMwIQDkDzhDPzu/yrSP7X38AJxzANBglghkgBZQMEAgEFAKCCAg0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNjI4MTEyNzAzWjAv BgkqhkiG9w0BCQQxIgQgLD1AsUQUEgHU9exlicYdQ48sjEE8zOgIov8UjadXNtUwbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJ KwYBBAGCNxAEMYGJMIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k MRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5B IGVTY2llbmNlIFBlcnNvbmFsIENBIDMCEA5A84Qz87v8q0j+19/ACccwgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2ll bmNlIFBlcnNvbmFsIENBIDMCEA5A84Qz87v8q0j+19/ACccwDQYJKoZIhvcNAQEBBQAEggEA k5i3Rk4cxn3dR6sfK/8B6AZDRhUHcpRzE0iK0tZRiP28KhtUCt3jPaKuNhrBGde00zTd0tB6 IU/Owu2HfNnJfi1G533L6nzlEgFC+S3tEFgAnnc13fe+ByGX+7hoOmtws7IZKI/ZaT+W+HYd 3GHxQaQ1taN8HiUBFI3EfVPUBASBfy13+9iK5qJFiXhGjIx4eplz0yDIH12foYIlqXJhfOIv uNWKlAjMEYeMcWTA8R9fbo+tlrmDl4Uxw5vgRvvrztvPs/QvtV439FeXaClILuZl49DGh7CP WURsK94KO2SSx8UQ5UDFTFfbTQn64tL2bd1Ht2HExwSPE11ZNBkjDQAAAAAAAA== --------------ms010703010307080509000101-- From nobody Wed Jun 28 13:15:02 2017 Return-Path: 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 0C50B12EAEF for ; Wed, 28 Jun 2017 13:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fFYJbA83ZKBV for ; Wed, 28 Jun 2017 13:14:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88D412EAF4 for ; Wed, 28 Jun 2017 13:14:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CF4B7300463 for ; Wed, 28 Jun 2017 16:14:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0GKxr2cNFygt for ; Wed, 28 Jun 2017 16:14:55 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BA9D430002C for ; Wed, 28 Jun 2017 16:14:55 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Jun 2017 16:14:53 -0400 References: <149861142806.18319.17791641856394471897@ietfa.amsl.com> To: IETF DNSOP WG In-Reply-To: <149861142806.18319.17791641856394471897@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 20:15:00 -0000 Please correct this typo: s/certs for such names/certificates for such names/ > On Jun 27, 2017, at 8:57 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations of the = IETF. >=20 > Title : Special-Use Domain Names Problem Statement > Authors : Ted Lemon > Ralph Droms > Warren Kumari > Filename : draft-ietf-dnsop-sutld-ps-06.txt > Pages : 28 > Date : 2017-06-27 >=20 > Abstract: > The Special-Use Domain Names IANA registry policy defined in RFC = 6761 > has been shown through experience to present unanticipated > challenges. This memo presents a list, intended to be = comprehensive, > of the problems that have been identified. In addition it reviews > the history of Domain Names and summarizes current IETF publications > and some publications from other organizations relating to Special- > Use Domain Names. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-06 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-sutld-ps-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Jun 29 06:34:52 2017 Return-Path: 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 B68A3126C25 for ; Thu, 29 Jun 2017 06:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 sMOvggV-cUCe for ; Thu, 29 Jun 2017 06:34:48 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 5C627129ADE for ; Thu, 29 Jun 2017 06:34:48 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id d78so75850470qkb.1 for ; Thu, 29 Jun 2017 06:34:48 -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=lM+BnkQhyDJYxirlNyduef/dIaYJnX953zEjfB0l378=; b=dpBDMpvshZtSDahAHJ1LpWTxSDqeso3bwTp0oMTx56m7rn9WRqSp/oONHrLZAfggdq 22JO4qF7dgeOjz/hqyB/fts22WMmTaP9OLTqY7sKuNXmI/4X62bu8DQ3uDxv4yDpLR7T EpkVTxzWf/QMsZHAp2/ngxEdFl7uFZJWqxhjtmeUG1OpPjpMlYNaL59vQavOsyrzSGX/ 0OQEgCgL04LavQDh/1USGs7J7KBLiTIlpezPQXYQfyPZCB8SGgFm0VML8bqAGPxFTwFg bEI1f01Ps0xI1/ofa6DOTVpZ48D97ljobixHYEtQpl+AjWj8eWpV/3SyRf4nRqzc49P0 fw+A== 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=lM+BnkQhyDJYxirlNyduef/dIaYJnX953zEjfB0l378=; b=HXhpXS4zs1ESckANuswLF1uUoKwmcBYrfK9nqm4Ih3bhVhxk8xnXSxAKOFcEsIs0r+ Z/99mLD/fPurz/USAyZXegsQhJRBEqZD9+gerAFkmk05p7Phc7A+MMo4YvkH4YohWxvb K9ahpPac0FDkb0PtSmC3gBkWOcc1/mL8MAmzz4nZ0COjixsCypP6h/pD87k4xTZfpsuw +V6lw/EPv3qFvhNG707md1JI+kuaBViNYH9QL4gRkZOeLA0BIZ2iA1X7Q+YE5LNAyh9Y RaYgFDHmJH9oRDuU6gBoZDhxkVb+JdgS2153rNpLp7jjmvjzTo2qp7WsTSsgbtcmHxY1 7wSQ== X-Gm-Message-State: AKS2vOwP6ei6AgcvnQ3DYSOTrfvi5bD99hUwjn4EGapS2I2d/toT/OaZ EyehmWIjO3dPug== X-Received: by 10.55.20.147 with SMTP id 19mr20839838qku.204.1498743287519; Thu, 29 Jun 2017 06:34:47 -0700 (PDT) Received: from ?IPv6:2601:18f:801:600:fd09:6098:88a2:5306? ([2601:18f:801:600:fd09:6098:88a2:5306]) by smtp.gmail.com with ESMTPSA id a6sm3325343qtc.54.2017.06.29.06.34.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 06:34:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ralph Droms In-Reply-To: Date: Thu, 29 Jun 2017 09:34:43 -0400 Cc: IETF DNSOP WG Content-Transfer-Encoding: quoted-printable Message-Id: <911E7F56-8E4B-4F7B-8CD2-062639841A8D@gmail.com> References: <149861142806.18319.17791641856394471897@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-06.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:34:51 -0000 > On Jun 28, 2017, at 4:14 PM, Russ Housley = wrote: >=20 > Please correct this typo: > s/certs for such names/certificates for such names/ The fix will appear in the next rev of the draft. Thanks, Russ. - Ralph >=20 >=20 >> On Jun 27, 2017, at 8:57 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Domain Name System Operations of the = IETF. >>=20 >> Title : Special-Use Domain Names Problem Statement >> Authors : Ted Lemon >> Ralph Droms >> Warren Kumari >> Filename : draft-ietf-dnsop-sutld-ps-06.txt >> Pages : 28 >> Date : 2017-06-27 >>=20 >> Abstract: >> The Special-Use Domain Names IANA registry policy defined in RFC = 6761 >> has been shown through experience to present unanticipated >> challenges. This memo presents a list, intended to be = comprehensive, >> of the problems that have been identified. In addition it reviews >> the history of Domain Names and summarizes current IETF publications >> and some publications from other organizations relating to Special- >> Use Domain Names. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-sutld-ps-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Jun 30 04:24:17 2017 Return-Path: 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 1D08212ECAD; Fri, 30 Jun 2017 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 wqyI59bmSpV2; Fri, 30 Jun 2017 04:24:13 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 B32DD129468; Fri, 30 Jun 2017 04:24:12 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w126so107056213wme.0; Fri, 30 Jun 2017 04:24:12 -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=U3IwIaF5X7jyHx+1W3ld6g3DkiCWNz4Iy3cy8jinCzM=; b=QzDDJriKh+6wNJfAnpYNZRNAZTHXtYW/hJYt88D7dBkmla7o9ynoKghn2KDtCl49tY cAvy4vR4JunhvKeuweHUaiW2aRCZYebFronNpVm9odLjIJ4r6Pf8mZhfVzXjq9FT63mp ri1cEGl+QItRQmfmdjr/MVv+8pJf20fskBAR87JOBtQANh+pr6Y7bIbgE3I9u4l6waxW 6pMZjKgY18nTB/qy+bPyPtgCzjtTGsyD3ifePR5Km59C0xHKtlWDNHyKe/zvP/3or0gZ MR+cTLbe120e16IQ4xiciv3RvjDECIkc7AsbQzkraGLHJecPT7oLo+vjdCdQMHMX+4jN jO9w== 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=U3IwIaF5X7jyHx+1W3ld6g3DkiCWNz4Iy3cy8jinCzM=; b=cmbYzqEHiFF4wy2qO0wNVdkRdpb4jNIdNsRdq8esKHiyGI5J0ot/PxtoWtDocVmTk4 syt8xJrvGb3qwKRj7OEOpIBnkWj7cb8nH3ApzZqTYVcM5GuuiCP6TKTT+FOGp7W2FHu1 BB6vqASvGXLyXx2cIXOM/FYhXQ8STs1EFshJNe5TRZwKdi+BoAL2vPmSKLpCNw0QIaKg L9kF02bT5jkiFPnFweAcItMd3PH27wXksRRBq5EU6O4kjcu2rd5D3hwtgeJOAbqojCgo Vj2L00fPdO2tvU0GRTLmEvVgd/UvkHBr0TOmJf7tqFDDPDJT09kwcOVUAiAH3IZA9jex 2dGw== X-Gm-Message-State: AKS2vOxEnFpLa5lJnN2kYK6L7ydTn5mpxAAqppL1D+sLlmbalEq3vUmO C779kte1nUvfK9JviahZa7OKTNJobg== X-Received: by 10.28.35.201 with SMTP id j192mr5808232wmj.103.1498821851160; Fri, 30 Jun 2017 04:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.170.152 with HTTP; Fri, 30 Jun 2017 04:24:10 -0700 (PDT) In-Reply-To: <681AC410-2F7D-449E-9521-8512EEFB8BD9@gmail.com> References: <681AC410-2F7D-449E-9521-8512EEFB8BD9@gmail.com> From: tjw ietf Date: Fri, 30 Jun 2017 13:24:10 +0200 Message-ID: To: dnsop Cc: "dnsop-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a113eab4205435405532ba805" Archived-At: Subject: Re: [DNSOP] IETF 99: Call for agenda items, and draft cutoff reminder X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 11:24:15 -0000 --001a113eab4205435405532ba805 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reminder on the deadline for submitting drafts is Monday 3 July at Midnight UTC. If you wish to have a slot and have not contacted us please drop an email to the chairs. I'm done with my NomCom commitments which have taken me away, and will be working on a draft agenda this weekend. thanks tim On Mon, Jun 19, 2017 at 11:22 PM, Suzanne Woolf wrote: > Hi all, > > IETF 99 is advancing rapidly upon us=E2=80=A6. > > DNSOP has two sessions scheduled in the preliminary agenda, Tuesday > 15:50-17:50 and Thursday 18:10-19:10. In the interests of managing that > time well, we=E2=80=99d like to hear from you ASAP if you=E2=80=99re aski= ng for agenda time. > > As always=E2=80=94 we=E2=80=99ll prioritize work that will advance WG dra= fts, and new work > that=E2=80=99s already gained some interest on the mailing list. > > Note also that the draft cutoff is in two weeks, on July 3. If you=E2=80= =99ve got > a WG draft with pending changes, or a draft you=E2=80=99d like the WG to = consider > for adoption, please have the latest and greatest version submitted by th= en. > > > thanks, > your faithful chairs > (Tim & Suzanne) > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a113eab4205435405532ba805 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reminder on the deadline for submitting drafts is Monday 3= July at Midnight UTC. =C2=A0 =C2=A0 If you wish to have a slot and have no= t contacted us please drop an email to the chairs.=C2=A0

I'm done with my NomCom commitments which have taken me away, and will= be working on a draft agenda this weekend.=C2=A0

= thanks
tim

<= br>
On Mon, Jun 19, 2017 at 11:22 PM, Suzanne Woo= lf <suzworldwide@gmail.com> wrote:
Hi all,

IETF 99 is advancing rapidly upon us=E2=80=A6.

DNSOP has two sessions scheduled in the preliminary agenda, Tuesday 15:50-1= 7:50 and Thursday 18:10-19:10. In the interests of managing that time well,= we=E2=80=99d like to hear from you ASAP if you=E2=80=99re asking for agend= a time.

As always=E2=80=94 we=E2=80=99ll prioritize work that will advance WG draft= s, and new work that=E2=80=99s already gained some interest on the mailing = list.

Note also that the draft cutoff is in two weeks, on July 3. If you=E2=80=99= ve got a WG draft with pending changes, or a draft you=E2=80=99d like the W= G to consider for adoption, please have the latest and greatest version sub= mitted by then.


thanks,
your faithful chairs
(Tim & Suzanne)

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a113eab4205435405532ba805--