I understand what is being attempted here and I am a big fan of JSON. But I don't see the value in representing DNS information in an alternative syntax.
If we are going to change the discovery interface I would want to go a step up in abstraction and present the type of interface the application layer needs. An application is not interested in the details of DNS, it just wants to connect to a particular service at a particular named site. Using SRV service names and DNS names is what the application needs. This is the approach I take in omnibroker: https://datatracker.ietf.org/doc/draft-hallambaker-omnibroker/ Here the discovery protocol is a meta-discovery protocol taking information from multiple sources. On Wed, Oct 15, 2014 at 9:58 PM, Brian Dickson < brian.peter.dick...@gmail.com> wrote: > Hi, > This is the second of the pair of drafts submitted together for > consideration. > (See the first post for the full description.) > Brian Dickson > ---------- Forwarded message ---------- > From: <internet-dra...@ietf.org> > Date: Wed, Oct 15, 2014 at 6:11 PM > Subject: New Version Notification for > draft-dickson-dnsop-spartacus-system-00.txt > To: Brian Dickson <brian.peter.dick...@gmail.com> > > > > A new version of I-D, draft-dickson-dnsop-spartacus-system-00.txt > has been successfully submitted by Brian Dickson and posted to the > IETF repository. > > Name: draft-dickson-dnsop-spartacus-system > Revision: 00 > Title: System to transport DNS over HTTP using JSON > Document date: 2014-10-15 > Group: Individual Submission > Pages: 34 > URL: > http://www.ietf.org/internet-drafts/draft-dickson-dnsop-spartacus-system-00.txt > Status: > https://datatracker.ietf.org/doc/draft-dickson-dnsop-spartacus-system/ > Htmlized: > http://tools.ietf.org/html/draft-dickson-dnsop-spartacus-system-00 > > > Abstract: > This is the SPARTACUS DNS gateway system. It is designed to > facilitate the transport of DNS messages opaquely, across problematic > sections of the Internet. It uses JSON encoding, and HTTP(S) as the > protocol for transport. > > The main criteria of SPARTACUS is that it preserve DNS messages > verbatim, and that only properly formatted DNS messages are passed. > > There are two modes (so far) defined: DNS forwarder (dns clients > point to a local gateway, which forwards to a remote gateway for > sending to a DNS resolver); and transparent proxy (DNS packets are > intercepted, passed to a local gateway, which sends them to the > remote gateway, with original destination IP address etc. encoded, > and used by the remote gateway as the destination). > > DNS messages are NAT-friendly, so changes to IP or UDP headers do not > impact them. Thus, SPARTACUS does not interfere with TSIG, SIG(0), > or Eastlake Cookies. > > This document describes the system, the components, and behavior, > with examples. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop