On 29/Feb/12 02:54, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
All that said, a suggestion: Patrik published a pretty good list of
most of the issues that arise when attempting to deploy new
RRTYPEs. Some of those, like the lack of GUI pulldowns in some
hosting provider web interfaces, are clearly beyond the IETF's
purview to address. But others, like the formatting issues in zone
master files that arise when a new RRTYPE is defined, are things we
can address. (And no, external scripts to do the format conversion
are not a sufficient solution to this problem.)
Why? I realize there's lots of wisdom in those words, but I can
hardly catch sight of it. LIFO, why are RR2txt/txt2RR not sufficient
for formatting master zones? And why cannot those same scripts be
invoked by a provider's web form?
For responses and zone transfers, Patrik distinguished between "core"
and "edge" deployments. I heard about NotImp responses and mirroring
difficulties. What is the current status?
So might I suggest that instead of arguing about the operational
realities of deploying new RRTYPEs - which appears to be turning
into yet another retelling of the parable about the blind men and
the elephant - we instead turn our attention to activities that
would actually address parts of the problem.
The phrase "rough consensus and running code" must be meant to be in
that order, because consensus makes the difference between /runnable/
and /running/ code. Indeed, that parable often ends with "Then the
king/president explained to the blind men...", so we'd have to replace
that part with something that we can believe in, anyway.
In particular, John Levine has already written a draft that
attempts to address the formatting issues by defining a simple
format extension language. That might be a good place to start.
(I've already sent him my review comments in private email.)
I agree it's a clever spec, and I believe it's not overly hard to code
a couple of generic RR2txt/txt2RR scripts that use such symbolic
descriptions. However, if we want to tackle some protocols, we had
better add an alternative stanza syntax for "tag=value" kinds of
record, and/or provide for type-specific external utilities.
But shouldn't we reach consensus on a migration strategy before we
discuss the tactics? RFC 6195 says a new RR type should not be
allocated in case:
5. An excessive number of RRTYPE values is being requested when the
purpose could be met with a smaller number or with Private Use
values.
That criterion apparently matches requesting a new type and at the
same time reusing TXT. RFC 5507 elucidates good principles and
reasons why adding a new RR type is a better solution than reusing
TXT, but it doesn't say that doing both solutions at the same time
results in a parody of those principles.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf