Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Randy,

On 2013-05-21, at 11:23, Randy Bush <randy@xxxxxxx> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]