IETF Logo Mail Archive

[DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

Joe Abley <jabley@strandkip.nl> Thu, 27 June 2024 11:16 UTC

Return-Path: <jabley@strandkip.nl>
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 3444DC14F703 for <dnsop@ietfa.amsl.com>; Thu, 27 Jun 2024 04:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
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 7vSqt_3LoSe6 for <dnsop@ietfa.amsl.com>; Thu, 27 Jun 2024 04:16:04 -0700 (PDT)
Received: from st43p00im-ztfb10073301.me.com (st43p00im-ztfb10073301.me.com [17.58.63.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DFAC14F6E2 for <dnsop@ietf.org>; Thu, 27 Jun 2024 04:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; t=1719486963; bh=hVReVdbKe3vWXuVap7uFKkuISNeI883UrSAN8E3GInQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=dbKGPkY7GrsRM/sz4x3aYvpxfn8dZxR9Ra7EYkLclatJTZVLxWam4uS2CspzAnHaa gfQO+o0kujOQRcBGBI47ucSZHVJmZ2d+D77ChNTUqqLqnVoFm5GH3dXEHYh1qCrSdc ik9m8T7QDrSlqd4R1a+WqLJFtMDkMHcrelJGintk7H6+5N/C1IyUdDluhM0l8sdBoh U97YWKtcLv+WYkQ9s97XiWPsZcpUR29cVX++LzQQuy5mfn461qf5g2Q9vVTnCSUb2r pufbPZe1Hyg6PA6NaEIKBzG1pcNjh6VXpwjGgNfMac17gC/4mC4z04/M7izxHzdaQl GlHhbQXrxMjvQ==
Received: from smtpclient.apple (st43p00im-dlb-asmtp-mailmevip.me.com [17.42.251.41]) by st43p00im-ztfb10073301.me.com (Postfix) with ESMTPSA id 39A5D8005CD; Thu, 27 Jun 2024 11:15:59 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9802737395E2@tss-server1.home.tropicalstormsoftware.com>
Date: Thu, 27 Jun 2024 13:15:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AEBB4F7-9724-4828-8C16-F8B9AB562DEF@strandkip.nl>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <16835c41-0e6c-bde4-d197-847928171e55@spacelypackets.com> <047a01dac6b8$43d70ca0$cb8525e0$@gmail.com> <57ca71b8-aa29-8a07-5154-e6b9c44bc64a@spacelypackets.com> <AC5B89B2-DD53-4A36-9B87-4136EC288851@isc.org> <2dec1732-841e-dd38-85a8-3263b1c59885@spacelypackets.com> <C363E260-22EA-43E9-97B6-D7A403C205ED@isc.org> <98976a58-b976-e82c-4b12-76edce92e691@spacelypackets.com> <CAMGpriUVcoJu1CWWLapwREN2NaHJFnVkGUpF45TJotm7uyAxyg@mail.gmail.com> <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273735D06@tss-server1.home.tropicalstormsoftware.com> <b3ee82da-ae38-5781-77eb-bab292d5c113@spacelypackets.com> <cca98f92-27ee-d372-b419-81c63777033b@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com> <0910E1D8-C678-498C-BAB5-AC3AA4C75750@isc.org> <e364da36-00e3-7c14-30b0-34f20b244f0a@redbarn.org> <6ff67491-30cf-cdc0-5e19-c1122465386c@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F9802737395E2@tss-server1.home.tropicalstormsoftware.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>
X-Mailer: Apple Mail (2.3774.600.62)
X-Proofpoint-GUID: CCo07sdyIuh0cWqkgDYPrmEDDQqpzpoB
X-Proofpoint-ORIG-GUID: CCo07sdyIuh0cWqkgDYPrmEDDQqpzpoB
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-27_06,2024-06-27_02,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 mlxlogscore=520 adultscore=0 malwarescore=0 suspectscore=0 bulkscore=0 clxscore=1030 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2406270085
Message-ID-Hash: 5ZWEHF2R4LGP6VGLEBPWABX6NLWAVSFD
X-Message-ID-Hash: 5ZWEHF2R4LGP6VGLEBPWABX6NLWAVSFD
X-MailFrom: jabley@strandkip.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Scott Johnson <scott@spacelypackets.com>, Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Fx2aSqRo2IMpdNLKOxgzS11FS5c>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Rick,

On Jun 27, 2024, at 10:46, Rick Taylor <rick@tropicalstormsoftware.com> wrote:

> <chair hat on>
> 
> I absolutely sympathise with your need to "grab an RRTYPE and make progress", but there is a process choice to be made here:   
> 
> * Do DNSOPS want the RRTYPE registrations to integrate with the wider work of the DTN working group?  In which case discussion like this must continue, and the document should be adopted by the WG.
> * Or is everyone happy to register the RRTYPEs as "ScottJ and colleagues need some unique RRTYPEs for the solution they're working on - no alignment  with the wider work of the DTN WG implied"?  I would propose calling the RRTYPE NODEID not IPN to make this clear, and not have the reference specification be an IETF document.

Speaking only as a recent reader of BCP 42 / RFC 6895, section 3.1 contains the guidance you are looking for. Consensus from the dnsop working group is not required, although as you have seen opinions are freely available. Specifications in the form of IETF documents are also not required to reserve a codepoint.


Joe

v2.40.3 | Report a Bug | By Email | System Status