On 29/Feb/12 02:54, ned+ietf@xxxxxxxxxxxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf