> > This technique has been in use for years by implementations > > using TXT records because we've been unable to get the DHCID > > RR approved. > > OK so why are you proposing a new protocol rather than writing a > description of the protocols that are already in use? > > Correctly prefixed TXT records work just as well as new RRs and are > completely compatible with the deployed infrastructure. If you attempt > to cut new DNS RRs you will hit the problem that your proposal is now > dependent on deployment of a new infrastructure which has no deployment > strategy. Not this old chestnut again. > Lets get back to the idea that a standard is a description of running > code. The DNS group has become a bottleneck for deployment of a lot of > technology. This should not be acceptable. There is a fundamental > extensibility flaw in DNS, new RRs must be understood by the sender, > receiver and intermediate infrastructure. Incorrect. Only the DHCP elements need to understand this. For everything else it should be treated as a opaque blob. The intent of RFC 1034/1035 was for new RRs to be treated as opaque blobs. You don't need RDLEN if you don't expect to treat unknown as opaque blobs. This was clear to me when I first read those RFC's back in the early 90's. RFC2535 (March 1999) made it absolutely clear that unknown RR's were to be treated as opaque blobs. It is now 6 years later and you are saying we should be worrying about implementations that were clearly broken on the first day they deployed. > The DNSEXT group appears to believe that their objectives should be to > create as much of an incentive to upgrade to DNSSEC capable > infrastructure as possible and that the way to do this is to gate all > proposed uses of the DNS on cutting a new RR. Hogwash. > This is not a good strategy, DNSSEC is a double ended adoption problem, > the problem is not that the promise of DNSSEC is insufficient incentive > for deployment, the problem is that early adopter deployment of DNSSEC > has negligible incentive. This has absolutely nothing to do with the deployment of DNSSEC. > The Pareto optimal solution here is for the IAB to specify a method of > introducing new features that use the DNS that is entirely compatible > with deployed DNS infrastructure. These in turn create new dependencies > on the DNS that create a near term demand for DNSSEC and an early > adopter incentive. The DNSSEC people get an early adopter market for > their proposal, people looking to extend the DNS can do so without > committing error 33. > For example one of the discussions in DKIM is on what to do with the > ESTG vehicle set up for early development. The idea that most people > seem to think is a good one is to turn it into a branding vehicle > similar to WiFi. So that just as people advertise that their product is > WiFi compatible to mean 'yes it really works' there would be an ESTG > brand that a registrar could use to say 'yes I do provide the services > necessary to support DKIM signed email'. This then leads naturally to > the question of levels of support, a level 1 registrar might do the bare > minimum necessary to support DKIM (allow the relevant records to be > defined), the requirements for level 2 might well include support for > DNSSEC (at least I would argue that they should require DNSSEC support). > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf