People were already storing MAC addresses in DNS for the reason given in the draft and perhaps others, it is just that they were doing so in a variety of proprietary ways. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx On Mon, May 20, 2013 at 12:48 PM, SM <sm@xxxxxxxxxxxx> wrote: > At 06:44 20-05-2013, The IESG wrote: >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS' >> <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2013-06-17. Exceptionally, comments may be > > > This draft is about putting MAC addresses in the DNS. The purpose is for IP > address tracking by vendors. As the RRTYPE has already been allocated it is > useful to document the format. In my humble opinion it is not a good idea > to put MAC address in the DNS. There is some text in Section 9 about why it > may not be a good idea. In Section 9: > > "These potential concerns can be mitigated through restricting access > to zones containing EUI48 or EUI64 RRs or storing such information > under a domain name whose construction requires that the querier > already know some other permanent identifier." > > The "querier already know some other permanent identifier" reminds me of > security through obscurity. I'll do some selective quoting from another > document: > > "Once the MAC-derived suffix mechanism was standardized, it > was perceived to be required and therefore became part of compliance > suites, which continue to compel implementations to support it many > years after the associated vulnerabilities have been identified." > > "A comprehensive privacy threat model was never developed (which seems > to be a recurring theme with older protocol development efforts)" > > The write-up mentions: "The intended status is standards track with the > label of propsed standard". Why is the intended status "Proposed Standard"? > > As a comment to Joe, the first line in Appendix A.2 was entertaining. :-) > > Regards, > -sm