On 3 Oct 2012, at 14:10, John C Klensin wrote:
--On Wednesday, October 03, 2012 10:43 +0200 João Damas
<joao(_at_)bondis(_dot_)org> wrote:
I believe you are saying the same things when you are both
saying that for this to work there may be more than one way to
do it but all options require completely new functionality in
implementations (either by implementing support for new labels
types or by implementing new fall back behavior). The
conclusion is still the same.
Hmm. I'm not completely sure who "you" was intended to include,
Yourself and Olafur
but my conclusion from the above is that there is no substantial
justification for eliminating, at this time, a capability that
might prove better on balance when and if new capabilities are
considered and tradeoffs evaluated.
To summarize my perspective on this as of now:
(1) No one is making a case for retaining binary labels
(2) The case has not been made, at least in the document, for
eliminating label types. An argument that there are other ways
to do a particular type of label is not persuasive unless there
is a comprehensive and written analysis of what other labels
might be considered and what the tradeoffs among approaches
would be. And an argument that almost any significant added
functionality would be very slow and costly to deploy may be an
argument for not approving such functionality, but it is not an
argument for eliminating one, but not all, of the underlying
capabilities.
fair enough. The groups consensus over the last years and after the experience
with binary labels has been that new label types are basically undeployable
because they require a complete renewal of all deployed resolvers.
On the other hand the use of EDNS extension mechanisms can be incrementally
deployed (e.g. see some of DNSSEC features that leverage EDNS)
IMO, this discussion has turned up two ways in which the case
for eliminating the possibility of additional label types could
be made:
(2.1) Demonstrating that simply having the capability defined
and available in principle is somehow harmful.
People here can correct me, as my memory is fuzzy, but binary labels did cause
harm to several deployed implementations. Don't know if this is just case in
favour of natural selection.
(2.2) The WG has consensus on a bright line that defines the
nature of proposals that would require going to DNSng rather
than EDNSx-type extensions to the current model, has concluded
that any extensions or alterations to the label definition of
1034/1035 would require crossing that line, and is prepared to
document that line and get IETF consensus on it (either as part
of this document or one normatively referenced from it).
Pretty much, that is my understanding. It is quite possible that this has been
a position reached over many iterations of discussions and is not actually
documented anywhere.
Joao