Hi Randy, On 2013-05-21, at 11:23, Randy Bush <[email protected]> wrote:
> i have read the draft. if published, i would prefer it as a proposed > standard as it does specify protocol data objects. Noted, thanks. It does seem that the main objection to the standards track for this document is that I accidentally erred on the side of running code before the document was last-called. This does seem like a poor reason to move the document to informational, but since my primary goal with this has always been to provide a specification (and since the specification is trivial) it's not especially clear to me why a fight for the standards track would have more than semantic benefits. > < where you goin' with that gun in your hand? > Going to kill my old lady. Not really. > i am not at all sanguine about the issues raised in the in sec cons. i > accept that NTRE038D may have asked that these be in the dns, but seems > to me that it is ill advised and some other means to meet their actual > needs might be found. e.g. what's the matter with logs? I agree it was a strange implementation decision, almost as though more neutral, technical common sense might have been helpful in the process, an unusual situation for a regulator to find themselves in, no doubt. But at this point, it is what it is. The distaste of many here notwithstanding, the DNS is widely used today as a convenient distributed database for the storage of non-public data. I've had feedback from others who say that they are doing similar things with TXT records, and who welcomed the availability of a specific type, so regardless of the merits of NTRE038D the idea seems to have more general applicability. The text in the Security Considerations section was a response to concerns raised on the dnsext list that someone might look at the RRType spec and conclude that publishing subscriber (or other privacy-busting) link-layer addresses in the public namespace was something that was desirable or necessary. I don't personally see that as a great concern (I don't think operators are sufficiently naive) but the warning that subsequently appeared in section 8 did not seem inappropriate. > nits you are welcome to ignore. > > 1 - intro - do we have a standard way to refer to the dns specs as tuned > in 42 subsequent rfcs since 1035? No, as Andrew mentioned. > 3.2 and 4.2 the presentation format specs might be simpler if the > examples in 5 were moved there Good idea. > 6 - the example use case is as much or more a motivation as an example It was certainly the motivation for the draft; the ugly and varied RR schemas used made me reach for grep to find the sensible way to store MAC-48 addresses in the DNS; there wasn't one. In a brief moment of spring-cleaning fervour I decided to try and make things better for the next person who has to parse this kind of stuff. I could just as well have made that section title "Motivation for Bothering" but "Example Use Case" seemed like a better fit for the context I imagined future readers might have. Joe
