Re: [dnsext] Last Call: <draft-ietf-dnsext-rfc2671bis-edns0-09.txt> (Extension Mechanisms for DNS (EDNS(0))) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Wednesday, October 03, 2012 10:43 +0200 João Damas
<joao@xxxxxxxxxx> 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,
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.

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.

(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).

best,
    john




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]