Hi Marc, Yes, I think DNS-SD is likely the best solution for Application <-> BPA discovery.
Rick > -----Original Message----- > From: Marc Blanchet [mailto:marc.blanc...@viagenie.ca] > Sent: 26 June 2024 20:09 > To: Rick Taylor > Cc: Scott Johnson; Erik Kline; dnsop; Scott Burleigh; DTN WG > Subject: Re: [DNSOP] [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle > Protocol RFC9171 > > > > > Le 26 juin 2024 à 20:11, Rick Taylor <r...@tropicalstormsoftware.com> a > écrit : > > > > Hi Scott, > > > > Thanks for the updated doc. I've been thinking through what I understand > > is > your use-case, and I wonder whether new RRTYPEs is really the right way to go. > As I see it, the less one has to update the DNS infrastructure of the > Internet the > better, so would this alternative mechanism work for you?: > > > > The IETF creates a subdomain of `ipn.arpa.` under which all ipn FQNNs in > text format (reversed) may be registered, much like public IP addresses under > `inet.arpa.`, e.g. ipn:1.2.x would be registered as `2.1.ipn.arpa.`. This > would > allow any DNS capable host to resolve an ipn FQNN to DNS name. > > > > Under this DNS name, one could have one or more regular SRV records of the > form "_service._protocol.name", e.g. "_tcpcl._tcp.spacelypackets.com." that > would allow an entity to discover that TCPCL is available, and of course > "spacelypackets.com." (more correctly the target of the SRV record) can be > resolved quite normally via an A or AAAA record to your BPA's IP address. > > I like that better. No new RR. But I think DNS-SD is also very useful. > > Marc. > > > > > Of course one can sprinkle PTR and CNAME records throughout to add > indirection and delegate authority, perhaps to ipn Allocators. Also the > "ipn.arpa." registration can be skipped altogether, and instead DNS-SD or > DHCP/RA options can be used to discover the corresponding SRV record > entries without requiring global registration. > > > > This has the following advantages as I see it: > > 1. An ipn EID is now mapped to a Name that can be asserted using regular > DNS-name based certificate services. > > 2. Existing DNS software does not need to be updated. I can configure my > ancient BSD box with BIND to do this now. > > 3. We don't need yet another binary encoding of ipn EIDs, it's just text. > > > > However, I may have misunderstood your use-case, so this might not be > viable alternative. > > > > Thoughts? > > > > Rick > > > > P.S. I'm sure Brian Sipos has a more flexible solution using his EID > > Patterns > under the `ipn.arpa` TLD, but I don't want to muddy the waters by trying to > introduce it now > > > > > >> -----Original Message----- > >> From: Scott Johnson [mailto:sc...@spacelypackets.com] > >> Sent: 26 June 2024 06:19 > >> To: Rick Taylor > >> Cc: Erik Kline; dnsop; sburleig...@gmail.com; d...@ietf.org > >> Subject: Re: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle > >> Protocol RFC9171 > >> > >> Hi All, > >> > >> A new version of this draft (06) has been posted here: > >> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > >> > >> This includes edits from Scott Burleigh, as well as edits based on the > >> feedback from Brian and Rick, but for the references to specs for existing > >> CLAs in use in the wild. > >> > >> Happy to hear any further comments. > >> > >> Thanks, > >> ScottJ > >> > >> > >> On Wed, 26 Jun 2024, Scott Johnson wrote: > >> > >>> Hi Rick, > >>> > >>> On Tue, 25 Jun 2024, Rick Taylor wrote: > >>> > >>>> Hi Scott, > >>>> > >>>> Thanks for publishing this doc, it looks really interesting. > >>> > >>> You are welcome. Thanks for taking the time to review. > >>> > >>>> > >>>> One thing I am unclear about is what is the purpose of having a DNS > >>>> record mapping a dtn or ipn Node ID to an IP address. > >>> > >>> That is not exactly what is happening. I am mapping an IPN node number > >>> to > >>> domain name. That domain name may or may not have IPv4 or IPv6 > >>> addresses also mapped to it, but that is irrelevant. > >>> > >>>> Is it so that 'routing' lookups can be performed at BPAs when a next > >>>> hop for a particular EID is not known locally? > >>> > >>> That is an interesting concept perhaps worth exploring further, but no, > >>> that was not my intention. > >>> > >>>> It would be great to have the rationale described in the document. > >>> > >>> Sure, but the whole thing might be out of scope for DTN WG; it addresses > >>> application layer (outside the BPA) considerations. > >>> > >>> Consider that what BP excels at in robustness and extensibility, it > >>> lacks in standardized applications. One barrier to BP native > >>> application authoring which has been identified is lack of an API. This > >>> is being explored in multiple directions, including userspace and kernel > >>> API implementations. It is highly useful, when operating over the > >>> underlying Internet, for an application to be able to collect all > >>> necessary connectivity data via DNS query. > >>> > >>> A web browser, for example, does a DNS lookup before making a http > >>> request. At a minimum, this means Node Number and available CLA(s) in > >>> addition to IP address when making a BP connection. If BPSEC is > >>> deployed, additional RRTYPES, such as a security context identifier > >>> (CTX?) and public key (BSEC?) records might be appropriate to negotiate > >>> such a connection, but they are out of scope for this draft. > >>> > >>> If the application then transmits that information via an API to the > >>> BPA, the BPA can take action in the contact graph to perfect the > >>> connection. This draft, and the RRTYPEs it describes, enable a preferred > >>> component of an API structure to encourage application development. > >>> > >>>> > >>>> I'm also a wondering if there out to be references to the relevant > >>>> specifications for the CLA's in the RRTPE values: e.g. BSSP-v6 and > >>>> STCP-v4? > >>> > >>> Sure, that would be great. I am not aware of specification documents > >>> for many of these, and for IPND (which I know is not a CLA, but provides > >>> a useful discrete automated Node Number and CLA signaling system) > there > >>> is only the expired draft I posted last year. What I do have for all of > >>> them is running code. I will dig about a bit for (perhaps archival) > >>> spec documents on the other listed CLAs. > >>> > >>> Thanks, > >>> Scott > >>> > >>>> > >>>> Cheers, > >>>> Rick > >>>> > >>>>> -----Original Message----- > >>>>> From: Scott Johnson [mailto:sc...@spacelypackets.com] > >>>>> Sent: 25 June 2024 10:57 > >>>>> To: Erik Kline > >>>>> Cc: dnsop; sburleig...@gmail.com; d...@ietf.org > >>>>> Subject: [dtn] Re: [DNSOP] Re: IPN and CLA RRTYPEs to support Bundle > >>>>> Protocol RFC9171 > >>>>> > >>>>> 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 > >>>>>> <sc...@spacelypackets.com> > >>>>>> wrote: > >>>>>> Hi Mark, > >>>>>> > >>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 25 Jun 2024, at 16:36, Scott Johnson > >>>>>> <sc...@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 > >>>>>> <sc...@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...@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 <sc...@spacelypackets.com> > >>>>>>>>>>> Sent: Monday, June 24, 2024 8:26 PM > >>>>>>>>>>> To: Mark Andrews <ma...@isc.org>; > >>>>>> sburleig...@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 > >>>>>> <sc...@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 > >>>>>> <sc...@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-le...@ietf.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Mark Andrews, ISC > >>>>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>>>>>>>>>>>>> PHONE: +61 2 9871 4742 INTERNET: > >>>>>> ma...@isc.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> DNSOP mailing list -- dnsop@ietf.org To > >>>>>> unsubscribe send an email to > >>>>>>>>>>>>>> dnsop-le...@ietf.org > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Mark Andrews, ISC > >>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>>>>>>>>>>> PHONE: +61 2 9871 4742 INTERNET: > >>>>>> ma...@isc.org > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> DNSOP mailing list -- dnsop@ietf.org > >>>>>>>>>>> To unsubscribe send an email to dnsop-le...@ietf.org > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Mark Andrews, ISC > >>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>>>>>>>> PHONE: +61 2 9871 4742 INTERNET: > >>>>>> ma...@isc.org > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> DNSOP mailing list -- dnsop@ietf.org > >>>>>>>>> To unsubscribe send an email to dnsop-le...@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Mark Andrews, ISC > >>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia > >>>>>>> PHONE: +61 2 9871 4742 INTERNET: > >>>>>> ma...@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-le...@ietf.org > >>>>>> > >>>>>> > >>>>>> > >>> > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
