From nobody Mon Jun 26 05:31:52 2023 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1AC151070 for ; Mon, 26 Jun 2023 05:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwVfOtMi7kNt for ; Mon, 26 Jun 2023 05:31:48 -0700 (PDT) Received: from smtpbg153.qq.com (smtpbg153.qq.com [13.245.218.24]) (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 1E17AC14CE38 for ; Mon, 26 Jun 2023 05:31:45 -0700 (PDT) X-QQ-mid: bizesmtp71t1687782697t4coednq Received: from smtpclient.apple ( [113.105.127.26]) by bizesmtp.qq.com (ESMTP) with SMTP id 0 for ; Mon, 26 Jun 2023 20:31:37 +0800 (CST) X-QQ-SSF: 01400000000000Z0Z000000A0000000 X-QQ-FEAT: uWtt+4oZiA+jIVLi5+rpLvCql8fnXqoDsahRr78aUumEIhxlxUwvxzDuHT6Jn ORpMnCZC3Td+tb4B98qxMBaPI7Ih7u86jhuQ7OsOmxwguKiuH3TPjhdRixltlvex/dBc/r8 VzKUC9F4f2K3SHtiSEV+Y2qvKO1qqBqs0FhsJEHbGQapYa8NqBEy7zs8qxadpOtIVo6eIxz VHG/Y2eRIeS9KtNCH71NiGZblbB+JIo7b2wB877jysOd/iUy/lgwjarR8QWBwvlXN38tLES /fqjTfDADSeIkM82li+xGdS8VW1p9Jy31tFKvbMTOgGDIF9Q7etR3kbKOjUN3V9VM2PF+dR 9izYUfkbOHvPEOuAK5GTOWWv8Ifq2dvTfajCZTVKfZnldj1oqezQuPT7V+JDQ== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 72870669061864776 From: Di Ma Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Message-Id: Date: Mon, 26 Jun 2023 20:31:26 +0800 To: SIDR Operations WG X-Mailer: Apple Mail (2.3731.600.7) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybglogicsvrgz:qybglogicsvrgz6a-1 Archived-At: Subject: [Sidrops] DNS-RR for RPKI Publication Point Operation Practice X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2023 12:31:51 -0000 Hi, folks, I am thinking about a way of improving the interaction between the RPKI = Publication Point and the RPKI Relying Party.=20 A couple of days ago, I just realized the DNS had been playing a = significant role in RPKI operation efficiency when my RP system took = remarkable time to get access to some RPKI Publication Points due to DNS = query delay. Since DNS resolution of the IP address of publication point = is inevitable before an RP starts interacting with the very publication = point, I cannot help but think of the discussions we had in this mailing = list about RP synchronization in bandwidth constrained environments. =20 As far as I developed and maintained RP systems, I think it would be = better for an RP to know about what the publication point operation = practice relating to its interaction with RPs such as download speed = limit, frequency restriction, compression protocol and so on. Why not = consider unitizing DNS to meet this end? =20 We might make an RP query a special sub-domain of publication point=E2=80=99= s name to get those information of publication point operation practice = (ppop) in the meanwhile when it enquires as to the A/AAAA record, the = TXT DNS-RR of _ppop.[publication point name] for instance, without = making any change to current rrdp. This could be optional for both = repository managers and RPs. =20 If this WG group think this is good idea then we can work together to go = into the detail of key-value design of DNS TXT RR for this extension.=20 Comments? :-) Di=