[dnsext] draft-levine-dnsextlang-02 interop w/ rfc3597[bis]

[Alfred Hönes <[e-mail]>]

Hi,

I spent a few thoughts on operational considerations and
interoperability with implementations that wouldn't support
your proposal of a RRtype description language (btw: the AAA
folks call such decription for RADIUS attributes a "dictionary").

If an implementation of your I-D has to import zone data
in presentation format produced by a system that "only" supports
RFC 3597 (or the stalled 'bis' version), I think a conformant
receiving system SHOULD automatically recognize RFC 3597
"Unknown RR Format" even for RRtypes for which it has been configured
with a description of the RRtype-specific presentation format.
(The source system could be another DNS implementation or a
provisioning system.)

So far, so fine.

But what happens if the implementation supporting Ext'lang and
having been configured with the friendly format for a specific
"Unknown RRtype" (as listed in RFC 3597) has operational needs
to _export_ data to a non-upgraded recipient system, in a specific
operational environment?

Maybe the extension language could be amended by a (per-RRtype)
indicator that, on data _export_, the RFC 3597 format needs to be
used, and/or implement some (global) trigger to cause this behavior
for a particular operation for the tagged RRtypes, or for _all_
RFC 3597 Unknown RRtypes.
This fine-grained interop-configuration would help to accommodate
interaction with systems that (hard-coded) support the specific
presentation format for _some_ "Unknown RRtypes" in the best
human-friendly manner possible in a specific operational setting.

Note that the RRtype descriptions would be needed anyway for
communications (at least import from) upgraded systems, so just
leaving out some descriptions would be counter-productive.
Such additional tags in the language would thus make the gradual
deployment of Ext'lang within an operational domain much more
easier and hence might further actual acceptance, implementation,
and deployment of the proposal.

(For instance, a provisioning system could be upgraded to accept
human-friendly presentation format for Unknown RRtypes, but might
still have the need to produce RFC 3597 format to be fed to the
authoritative servers or other operational support systems until
these also support the Ext'lang.)


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext