Hi, Thanks for the comments. More inline.
On Mon, Mar 07, 2016 at 04:50:21PM +0100, Shane Kerr wrote: > I generally consider CLASS to be 2 bytes in every RR that we'll never > get back. :( Well, yes, but I guess I'm trying to take the first step on deprecating the whole thing in an effort at least to tidy everything else up. > Section 2.1 "Class data is in the wrong part of a resource record" says > that you can't have a server for class IE at the same time as EG, > right? (At least as the protocol is currently defined.) That's not the > same as saying that if you have IE then EG is impossible, right? The problem as I see it is that, while STD 13 suggests that in principle these are parallel name spaces, there's no way actually to ensure that; and if they really are, then the chances are excellent that the same server _would_ end up serving both classes (since NS is class-independent). I guess that isn't clear in the text, so I'll try again. They're certainly not mutually exclusive in terms of definition, no. > I think there may also be a missing "Section 2.4", which is "most > software only supports IN with some special-casing for CH", and perhaps > "adding a new class is likely to break loads of stuff", and also "how > do I specify 'class' when I type in google.com?" On the "most software" claim, I fear I haven't done the survey and don't even know how to start. That's why you only see the discussion of some people hard-wiring IN. That part I know happens, because I've seen it. I suspect that adding a new class would actually break nothing except the new class: I predict that virtually nobody would be able to use it sucessfully. The point about most user applications assuming IN is a good one; I'll add it. (I am struggling to imagine the user interface that allowed a user to do something like this. It strikes me, actually, that the URL/URI definition might not even consider class. If that's true, then it's yet another argument. I'll check. Thanks for the suggestion.) > In the end, I'd suggest not including Section 4 "define new RRTYPEs for > all classes" and instead make Section 3 stronger and declare classes as > only CH for special cases, IN for everything else, and I guess don't > break on HS because MIT? Are you arguing that this draft should be stronger, and recommend closing the registry? That's how I started out, and I shied away because it seemed like work for little benefit. But I could restore that text :) It'd be a bigger deal, though, because it would then need to update the DNS registry IANA considerations document. Thanks very much, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
