On 3 Oct 2012, at 14:10, John C Klensin wrote: > > > --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, 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