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

[Rick Taylor <[e-mail]>]

Hi Marc,

Yes, I think DNS-SD is likely the best solution for Application <-> BPA discovery.

Rick

> -----Original Message-----
> From: Marc Blanchet [mailto:[e-mail]]
> 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 <[e-mail]> 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:[e-mail]]
> >> Sent: 26 June 2024 06:19
> >> To: Rick Taylor
> >> Cc: Erik Kline; dnsop; [e-mail]; [e-mail]
> >> 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:[e-mail]]
> >>>>> Sent: 25 June 2024 10:57
> >>>>> To: Erik Kline
> >>>>> Cc: dnsop; [e-mail]; [e-mail]
> >>>>> 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
> >>>>>> <[e-mail]>
> >>>>>> wrote:
> >>>>>>      Hi Mark,
> >>>>>>
> >>>>>>      On Tue, 25 Jun 2024, Mark Andrews wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 25 Jun 2024, at 16:36, Scott Johnson
> >>>>>>      <[e-mail]> 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
> >>>>>>      <[e-mail]> 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, [e-mail] 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 <[e-mail]>
> >>>>>>>>>>> Sent: Monday, June 24, 2024 8:26 PM
> >>>>>>>>>>> To: Mark Andrews <[e-mail]>;
> >>>>>>      [e-mail]
> >>>>>>>>>>> Cc: dnsop <[e-mail]>
> >>>>>>>>>>> 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
> >>>>>>      <[e-mail]> 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
> >>>>>>      <[e-mail]> 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 -- [e-mail] To
> >>>>>>      unsubscribe send an email
> >>>>>>>>>>>>>>> to [e-mail]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Mark Andrews, ISC
> >>>>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>>>>>>>>> PHONE: [phone]              INTERNET:
> >>>>>>      [e-mail]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>> DNSOP mailing list -- [e-mail] To
> >>>>>>      unsubscribe send an email to
> >>>>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Mark Andrews, ISC
> >>>>>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>>>>>>> PHONE: [phone]              INTERNET:
> >>>>>>      [e-mail]
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> DNSOP mailing list -- [e-mail]
> >>>>>>>>>>> To unsubscribe send an email to [e-mail]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Mark Andrews, ISC
> >>>>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>>>> PHONE: [phone]              INTERNET:
> >>>>>>      [e-mail]
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> DNSOP mailing list -- [e-mail]
> >>>>>>>>> To unsubscribe send an email to [e-mail]
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Mark Andrews, ISC
> >>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>>>>> PHONE: [phone]              INTERNET:
> >>>>>>      [e-mail]
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> DNSOP mailing list -- [e-mail]
> >>>>>>> To unsubscribe send an email to
> >>>>>>      dnsop-
> >>>>> [e-mail]_______________________________________________
> >>>>>>      DNSOP mailing list -- [e-mail]
> >>>>>>      To unsubscribe send an email to [e-mail]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> > _______________________________________________
> > DNSOP mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]