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

From: Alfred Hönes <[email-masked]>
Date: Tue, 27 Mar 2012 22:17:58 +0200 (MESZ)

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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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

---

From: "John R. Levine" <[email-masked]>
Date: 28 Mar 2012 11:19:23 +0200

> to _export_ data to a non-upgraded recipient system, in a specific

It uses AXFR or something similar.  This is not a new problem, since there 
are plenty of DNS servers that use RFC 1034 master file format and haven't 
been upgraded to handle recently defined RR types.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Wed, 28 Mar 2012 17:51:21 +0100

> to _export_ data to a non-upgraded recipient system, in a specific

My immediate reaction was to say this is a matter for the configuration of
these systems, but then the question is where this configuration should
live and what form it should take.

I have been working on this proposal from the point of view of making
RR editors extensible, which brings up some related issues: whether RRs of
a particular type are human-editable or whether they should normally be
hidden. This mainly applies to DNSSEC records, so the question is whether
this should be hardcoded or supported by a generic mechanism. (There's a
similar question about name compression, for which John has specified a
generic mechanism but which can also be hardcoded according to the rules
in RFC 3597.) The generic mechanism would basically be per-RRtype
qualifiers (c.f. John's per-RDATA-field qualifiers) which could also be
used to say what format to use in master file exports.

Alternatively John's "AXFR or something similar" covers RFC 3597 generic
format master files - you can use the generic format for all records if
you want.

Another question this raises is whether the /etc/rrtypes file should be a
representation of the IANA RR type registry (like /etc/services and
/etc/protocols) or whether it is more system-specific. I have a
half-finished proposal for attaching descriptive text to RDATA fields for
user interfaces, which implies there will at least be per-language
versions, so perhaps it should be thought of as a per-package
configuration file rather than a fairly static part of the OS.

Any opinions on this vague rambling are welcome :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Northwesterly 5 to 7. Moderate or rough. Rain or
showers. Moderate or good, occasionally poor at first.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext