[DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Tue, 25 June 2024 14:30 UTC
Return-Path: <Brian.Sipos@jhuapl.edu>
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 2EE94C14CF15; Tue, 25 Jun 2024 07:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
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 poMq0bTEECEg; Tue, 25 Jun 2024 07:30:00 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8E331C14F726; Tue, 25 Jun 2024 07:30:00 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.17.1.19/8.17.1.19) with ESMTP id 45PCT24G030946; Tue, 25 Jun 2024 10:29:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=cc : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=JHUAPLDec2018; bh=Pp92x54j2w1c02ozodFAy8elAEdYiu8cBy7OtqH45H4=; b=rymiMF1Jq4Q0ITJTFbVZgSwnJ4+yPoD9mm8YltTOHnVyggZJvNzSTi8i/lgAsV8YZeiq ZtU81Qi3xw5Os78env3/gCut7TmP46m98Ag6Z9rLOmEXQBE+njFD6ORQtLeiC6HLFvw5 KuAK5LAjt8aYc2oAi+RjMn41SNrq8yW4JoRg5NazDOUJz/0p+3Wpln3aoBu6EDizGy3y OHsAngkMEOr7LAwwO866d+XVxsnv725UiUDoj+xrCG8rT/b2C3D3JD8zUX3tI3ebZOTF kQ6x2rQ0mHQU8qEpXZM6/MBFSQqX67wdxXiTuKY57O+TLGGWuQNl69lIqEFKnVwRLhDB sg==
Received: from aplex22.dom1.jhuapl.edu (aplex22.dom1.jhuapl.edu [10.114.162.7]) by aplegw02.jhuapl.edu (PPS) with ESMTPS id 3ywtu183mm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jun 2024 10:29:58 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX22.dom1.jhuapl.edu (10.114.162.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 25 Jun 2024 10:29:58 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2]) by APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2%5]) with mapi id 15.02.1544.011; Tue, 25 Jun 2024 10:29:58 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: Scott Johnson <scott@spacelypackets.com>, Erik Kline <ek.ietf@gmail.com>
Thread-Topic: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Thread-Index: AQHaxuZaF41VprY5dEOLEZkaHPklv7HYghQg
Date: Tue, 25 Jun 2024 14:29:58 +0000
Message-ID: <126832862de047c389651d7e4f39eb04@jhuapl.edu>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <44BBD57B-752B-47FA-B5A5-D4F37BE60E9A@isc.org> <b3f42856-9460-2fa2-1088-185fda441f51@spacelypackets.com> <F2BD591F-8512-4E3E-ABA2-3DF3F34372CB@isc.org> <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>
In-Reply-To: <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.19]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_010D_01DAC6EA.9FC5D3C0"
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX22.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX22.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-25_09,2024-06-25_01,2024-05-17_01
Message-ID-Hash: 5575J5JRPD6YD4K7V22YEVHWWGGKVD4D
X-Message-ID-Hash: 5575J5JRPD6YD4K7V22YEVHWWGGKVD4D
X-MailFrom: Brian.Sipos@jhuapl.edu
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: 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: [EXT] [dtn] 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/g0yLq0SYU2S8Ub-7Je9xosxb_Xw>
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>
Scott, I see two major issues with your current proposal. The first is that a CLA is more than just a specific transport, it is also a profile and likely a whole protocol above that transport. For example, there are multiple versions of "TCPCL" which behave differently and have different capabilities. So just saying "I support TCP-over-IPv6" falls short of indicating what a node is actually capable of and whether or not I can expect to successfully make contact and transfer bundles with that peer. The second is that I think it's actually more appropriate to use DNS Service Discovery (DNS-SD) as a mechanism to register CLAs over DNS. I have drafted a profile of this in [1] which does not even require any new code point allocations; the existing DNS-SD and service name registries [2] already have what is needed for a node to register listening CLAs as services. The DNS-SD also works for both unicast and multicast DNS. In the specific profile of [1] there is a requirement that only BP routers register themselves, but that is more of a convenience than a strict necessity. One possible extension to the DNS-SD profile is to define a service parameter ("bpnodeid" or similar) which would allow exposing the node's administrative EID in the DNS-SD registration. This opens the door to some security considerations about authenticating ownership of that EID, but it is a possible mechanism on a closed and trusted network. Another possibility is to use existing CERT RR [3] to store certificates asserting ownership of one or more EIDs, which are already defined as a PKIX profile in RFC 9174 [4]. My main concern with just having a bare EID (or part of an EID in this case, just the IPN node number) in DNS is that there is no way to assign a chain of trust to some authority of BP node naming. Thanks for consideration of this feedback, Brian S. [1] https://www.ietf.org/archive/id/draft-sipos-dtn-edge-zeroconf-01.html#section-3 [2] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml [3] https://www.rfc-editor.org/rfc/rfc4398.html [4] https://www.rfc-editor.org/rfc/rfc9174.html#section-4.4.2 > -----Original Message----- > From: Scott Johnson <scott@spacelypackets.com> > Sent: Tuesday, June 25, 2024 5:57 AM > To: Erik Kline <ek.ietf@gmail.com> > Cc: dnsop <dnsop@ietf.org>; sburleig.sb@gmail.com; dtn@ietf.org > Subject: [EXT] [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle > Protocol RFC9171 > > APL external email warning: Verify sender forwardingalgorithm@ietf.org before > clicking links or attachments > > Hi Erik, > > Cross posted to DTN list for any such discussion, if they so desire. > The draft in question is here: > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > Thanks, > ScottJ > > On Tue, 25 Jun 2024, Erik Kline wrote: > > > Speaking as the responsible AD for DTN, I think the DTN working group > > should probably have a discussion about what it wants to do (if > > anything) vis. DNS RRs. > > > > On Tue, Jun 25, 2024 at 08:27 Scott Johnson <scott@spacelypackets.com> > > wrote: > > Hi Mark, > > > > On Tue, 25 Jun 2024, Mark Andrews wrote: > > > > > > > > > > >> On 25 Jun 2024, at 16:36, Scott Johnson > > <scott@spacelypackets.com> wrote: > > >> > > >> Hi Mark, > > >> > > >> Noted and changed. Good stuff, thanks. Updated draft > > (04) at datatracker using that verbiage: > > >> > > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > >> > > >> Is it appropriate to add an acknowledgments section or > > co-authors at this point? > > > > > > I’m not fussed either way. > > > > (05) of the draft adds a "Contributors" section. > > > > > > > >> As well, should I be asking for WG adoption (DNSOP or > > DTN WG), or as an Informational document, is Individual > > submission sufficient? > > > > > > I’ll leave that for the chairs to answer. > > > > Ack. Thank you so much for your time and attention to this > > document. > > > > ScottJ > > > > > > > >> Thanks, > > >> ScottJ > > >> > > >> > > >> On Tue, 25 Jun 2024, Mark Andrews wrote: > > >> > > >>> Made the IPN description more specific. > > >>> > > >>> > > >>> Wire format > > encoding shall > > >>> be an unsigned 64-bit integer in network order. > > Presentation format, for these > > >>> resource records are either a 64 bit unsigned decimal > > integer, or two 32 bit > > >>> unsigned decimal integers delimited by a period with > > the most significant 32 bits > > >>> first and least significant 32 bits last. Values are > > not to be zero padded. > > >>> > > >>>> On 25 Jun 2024, at 15:22, Scott Johnson > > <scott@spacelypackets.com> wrote: > > >>>> > > >>>> Hi Scott, > > >>>> > > >>>> Wire format of 64 bit unsigned integer it is for IPN. > > >>>> Updated draft (03) incorporating all changes posted > > at: > > >>>> > > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > >>>> > > >>>> Let me know if you see anything else, Mark, and > > thanks! > > >>>> > > >>>> > > >>>> ScottJ > > >>>> > > >>>> > > >>>> On Mon, 24 Jun 2024, sburleig.sb@gmail.com wrote: > > >>>> > > >>>>> I've lost lock on the ipn-scheme RFC, but my own > > assessment is that always sending a single 64-bit unsigned > > integer would be fine. The application receiving the > > resource can figure out whether or not it wants to condense > > the value by representing it as two 32-bit integers in > > ASCII with leading zeroes suppressed and a period between > > the two. Internally it's always going to be a > > 64-bitunsigned integer, from which a 32-bit "allocator" > > number can be obtained by simply shifting 32 bits to the > > right; if the result is zero then we're looking at an > > old-style IPN node number. > > >>>>> > > >>>>> Scott > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Scott Johnson <scott@spacelypackets.com> > > >>>>> Sent: Monday, June 24, 2024 8:26 PM > > >>>>> To: Mark Andrews <marka@isc.org>; > > sburleig.sb@gmail.com > > >>>>> Cc: dnsop <dnsop@ietf.org> > > >>>>> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support > > Bundle Protocol RFC9171 > > >>>>> > > >>>>> Hi Mark, > > >>>>> > > >>>>> > > >>>>> On Tue, 25 Jun 2024, Mark Andrews wrote: > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>>> On 25 Jun 2024, at 10:32, Scott Johnson > > <scott@spacelypackets.com> wrote: > > >>>>>>> > > >>>>>>> Hi Mark, > > >>>>>>> > > >>>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote: > > >>>>>>> > > >>>>>>>> An obvious correction “LTP--v6” -> “LTP-v6” > > >>>>>>> > > >>>>>>> Aha! Good eye. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> For IPN why isn’t the wire format two network 64 > > bit integers? That is 16 bytes. Also 2^64-1 is 20 > > characters so 2 64-bit numbers separated by “." is 41 > > characters. It’s not clear where then 21 comes from. > > >>>>>>> > > >>>>>>> EID is the basic unit of IPN naming, which is > > indeed two 64 bit integers separated by a ".". We are > > seeking to represent only the node-nbr component of an EID, > > as the service-nbr component is loosely analagous to a UDP > > or TCP port, for which there is one publicly defined > > service in the registry, and a collection of space agencies > > who lay claim to another chunk of them: > > >>>>>>> > > https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service- > num > > >>>>>>> bers As such, there is no gain in including the > > second 64-bit > > >>>>>>> integer, representing service-nbr in the DNS > > records, and indeed, a loss of utility on the application > > level. > > >>>>>>> > > >>>>>>> The node-nbr component is presently, under RFC7116, > > a 64 bit unsigned integer. There is a draft from the DTN > > WG currently making it's way through the IESG which will > > amend the IPN naming scheme. Perhaps I should add it to > > normative references? > > >>>>>>> > > https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ > > >>>>>>> > > >>>>>>> In effect it splits the node-nbr component into > > two-32 bit integers; Allocator Identifier and Node Number > > in the "Three-Element Scheme-Specific Encoding" of Section > > 6.1.2 over the above. Section 6.1.1 describes the > > "Two-Element Scheme-Specific Encoding" method which retains > > the use of a single 64-bit integer. Thus, a single 64 bit > > integer (20 characters) or two 32-bit integers (10 > > characters each) delimited by a "." > > >>>>>>> makes 21 characters maximum. This preserves > > forwards compatibility with the proposed amended scheme, > > and does no harm if the scheme fails to achieve > > standardization. > > >>>>>> > > >>>>>> Or just 8 bytes on the wire with both possible input > > formats described. > > >>>>>> Machines using the records will just be converting > > ASCII values to a > > >>>>>> 64 bit integer. We may as well transmit it as > > that. Input validation > > >>>>>> will need to do the conversion anyway to ensure both > > fields will fit > > >>>>>> into 32 bits in the “.” separated case and 64 bits > > in the single value case. > > >>>>>> Length along is not sufficient to prevent undetected > > overflows. The > > >>>>>> only thing you need to determine is which format is > > the initial > > >>>>>> canonical presentation format. That can be changed > > with a later > > >>>>>> update if needed. > > >>>>> > > >>>>> I am tagging in Scott Burleigh, co-author of RFC9171 > > on this point for clarification. > > >>>>> Section 4.2.5.1.2 of same indicates: > > >>>>> > > >>>>> "Encoding considerations: > > >>>>> For transmission as a BP endpoint ID, the > > scheme-specific part of a URI of the ipn scheme SHALL be > > represented as a CBOR array comprising two items. The first > > item of this array SHALL be the EID's node number (a number > > that identifies the node) represented as a CBOR unsigned > > integer. > > >>>>> The second item of this array SHALL be the EID's > > service number (a number that identifies some application > > service) represented as a CBOR unsigned integer. For all > > other purposes, URIs of the ipn scheme are encoded > > exclusively in US-ASCII characters." > > >>>>> > > >>>>> Having already established that we are transmitting > > the node-nbr component only, and not a full EID, I am not > > sure we are restricted to using only US-ASCII. ScottB, > > your opinion? CBOR might also be an option, but that would > > place a higher burden upon implementers, I think. Integer > > notation for wire format is fine by me. > > >>>>> > > >>>>>> > > >>>>>>>> Limit CLA characters to Letter Digit Hyphen rather > > than the full ASCII range. > > >>>>>>> > > >>>>>>> It is possible for a node to support multiple CLAs > > on the same IP > > >>>>>>> address and node number. Will this change allow > > multiple, comma > > >>>>>>> delimited values to be expressed in the CLA > > record? If so, can you > > >>>>>>> point me to an example so I can get the verbiage of > > the draft right? > > >>>>>>> If not, what do you recommend (in addition to my > > defining that in the > > >>>>>>> draft)? I like the idea of limiting the usable > > characters. > > >>>>>> > > >>>>>> Personally I would just use a TXT record wire format > > with the > > >>>>>> additional constraint that the values are restricted > > to Letter, Digits > > >>>>>> and interior Hyphens. The input format matches the > > TXT record with > > >>>>>> the above character value constraints. The > > canonical presentation > > >>>>>> form is space separated, unquoted, unescaped ASCII. > > This allow for > > >>>>>> long records to be split over multiple lines. > > Descriptive comments in the zone file. > > >>>>>> This take one extra octet over using comma separated > > values. > > >>>>> > > >>>>> Sold to the man from ISC :) This part works great; > > thank you! Updated draft pushed to datatracker at > > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > >>>>> > > >>>>> Thanks, > > >>>>> Scott > > >>>>> > > >>>>> > > >>>>>> > > >>>>>> e.g. > > >>>>>> > > >>>>>> example inputs > > >>>>>> > > >>>>>> @ CLA ( TCP-V4 ; TCP over IPv4 > > >>>>>> TCP-V6 ) ; TCP over IPv6 > > >>>>>> > > >>>>>> @ CLA “TCP-V4” TCP-V6 > > >>>>>> > > >>>>>> Wire > > >>>>>> > > >>>>>> 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ > > ‘6’ > > >>>>>> > > >>>>>> Canonical presentation > > >>>>>> > > >>>>>> @ CLA TCP-V4 TCP-V6 > > >>>>>> > > >>>>>> > > >>>>>>> Thanks, > > >>>>>>> Scott > > >>>>>>> > > >>>>>>>> > > >>>>>>>> Mark > > >>>>>>>> > > >>>>>>>>> On 25 Jun 2024, at 08:19, Scott Johnson > > <scott@spacelypackets.com> wrote: > > >>>>>>>>> > > >>>>>>>>> Hi All, > > >>>>>>>>> > > >>>>>>>>> After reading the recent discussion about WALLET, > > I am hesitant to jump into the fray here, but this plainly > > is the correct group to help me get my logic and syntax > > right, so here goes: > > >>>>>>>>> > > >>>>>>>>> I submitted requests to IANA for IPN and CLA > > RRTYPEs, these representing the missing datasets necessary > > to make a BP overlay network connection from data found by > > DNS queries. > > >>>>>>>>> > > >>>>>>>>> For those not familiar, BP is a store and forward > > mechanism generally used in high latency situations where > > there does not exist constant end-to-end connectivity. It > > was designed for deep space networking, however has network > > segments and application uses which overlay the terrestrial > > Internet. There will arise similar use cases on the Moon > > (in the reasonably near future) and Mars whereby low > > latency, constant connectivity exists, thereby making use > > of DNS in these situations viable. > > >>>>>>>>> > > >>>>>>>>> My Expert Reviewer asked for an i-d, to clarify > > the requests, and that said i-d be sent to this list for > > review. > > >>>>>>>>> > > >>>>>>>>> Please find the approptiate draft here: > > >>>>>>>>> > > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > >>>>>>>>> > > >>>>>>>>> Relevant IANA requests: > > >>>>>>>>> > > https://tools.iana.org/public-view/viewticket/1364843 > > >>>>>>>>> > > https://tools.iana.org/public-view/viewticket/1364844 > > >>>>>>>>> > > >>>>>>>>> I have the BP community also reviewing this, but > > they are generally in agreement as to use. > > >>>>>>>>> > > >>>>>>>>> Thanks, > > >>>>>>>>> Scott M. Johnson > > >>>>>>>>> Spacely Packets, LLC > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> DNSOP mailing list -- dnsop@ietf.org To > > unsubscribe send an email > > >>>>>>>>> to dnsop-leave@ietf.org > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> 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 To > > unsubscribe send an email to > > >>>>>>>> dnsop-leave@ietf.org > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> 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 > > >>>>> To unsubscribe send an email to dnsop-leave@ietf.org > > >>> > > >>> > > >>> -- > > >>> 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 > > >>> To unsubscribe send an email to dnsop-leave@ietf.org > > > > > > > > > -- > > > 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 > > > To unsubscribe send an email to > > dnsop- > leave@ietf.org_______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-leave@ietf.org > > > > > >
- [DNSOP] IPN and CLA RRTYPEs to support Bundle Pro… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… sburleig.sb
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Mark Andrews
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Erik Kline
- [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: [EXT] Re: Re: IPN and CLA R… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Adam Wiethuechter
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYP… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Marc Blanchet
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYP… Sipos, Brian J.
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Mark Andrews
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Paul Vixie
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … sburleig.sb
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Sauli Kiviranta
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Joe Abley
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Alberto Montilla (SPATIAM)
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Mark Andrews
- [DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and… Jorge Amodio
- [DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and… Rick Taylor
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Rick Taylor
- [DNSOP] Re: [EXT] [dtn] Re: RE: Re: IPN and CLA R… Sipos, Brian J.
- [DNSOP] Re: [EXT] [dtn] Re: RE: Re: IPN and CLA R… Scott Johnson
- [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRT… Scott Johnson
- [DNSOP] Re: [EXT] [dtn] Re: Re: IPN and CLA RRTYP… Marc Blanchet
- [DNSOP] Re: [dtn] Re: Re: Re: Re: Re: Re: IPN and… Scott Johnson
- [DNSOP] Re: [dtn] Re: [EXT] Re: RE: Re: IPN and C… Sauli Kiviranta
- [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to … Rick Taylor