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

[Marc Blanchet <[e-mail]>]

> 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]