Hi Randy,
On 2013-05-21, at 11:23, Randy Bush <randy(_at_)psg(_dot_)com> 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