Resource Records for EUI-48 and EUI-64 Addresses in the DNS
draft-jabley-dnsext-eui48-eui64-rrtypes-07

[Ballot comment]

I'm abstaining because I think this is standardising a very
dubious practice that is not really needed except (it
seems) for compliance with a really silly regulation in one
country. But I agree with Ted that the IETF seems to have
rough consensus to publish this, which is a pity IMO.

- Where is there a definition of a private DNS namespace?
If that is not defined, how can an implementer or
deployment know whether or not its ok to publish these
records in their DNS? I *think* I know that is meant, but
not very precisely and absent such a definition isn't there
a real danger that the (weak) privacy mitigation suggested
will be mythical? (If a good definition exists, all that'd
be needed is a reference, and I'm not saying that I think
that has to be an RFC, just good and easily accessible.)

- abstract and intro: I think you should s/where/if/ in:
"This document specifies an interoperable encoding of these
address types for use in private DNS namespaces, where the
privacy concerns can be constrained and mitigated." The
current text suggests that all you need is a "private DNS
namespace" and you're done, which is not the case.

- Section 5: It was my impression that the IETF LC
demonstrated a consensus that the Canadian regulation was
crappy. I think to properly reflect the quite rough
consensus this should say something about that here, so
that its clear that these RRs are not what the IETF would
do, were it to design a solution for this use-case.

- Section 8: was any consideration given to putting
ciphertext forms of these values into RRs? Surely that'd be
a better mitigation than depending on access control for
DNS queries? For example, in the cited use-case the EUI
value could be encrypted with a public-key before being
placed into the DNS. (Yes, that's also a crappy solution,
but perhaps less crappy than this.)

[Ballot comment]
As I've said in the past, I think this is a bad idea, because it encourages the use of private identifiers in the DNS, which I expect will result in leakage despite the document's admonition against publishing these records in public zones.  But the IETF appears to disagree, at least according to the results of the IETF last call, so I will just abstain rather than arguing about it further.

[Ballot comment]
In s9 (from secdir reviewer):

Can we replace the term "Global bit" with a term more consistant with RFC5342 or RFC4291?

RFC 5342 calls this bit the "Local bit" and the "Local/Global
bit".  RFC4291 calls this the "universal/local" bit.  The IEEE
802 standard talks about "universal" and "local" without actually
naming the bit, but lots of online documentation
says "universal/local" and "U/L".

The privacy concern arises not just from the uniqueness of the
EUI but from the fact that it is a more permanent identifier than
the IP address associated with the subscriber (as the next
paragraph notes).  So maybe in the first paragraph:

r/in the form of unique trackable/in the form of unique, permanent trackable
identities

likewise maybe:

r/typically change over time/provide a unique permanent identifier

[Ballot comment]
I happen to agree with what Martin says in his "Abstain", but I'm tipping to "No Objection" because the specification documents existing RR assignments (EUI48 and EUI64 are already in http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4), describes the privacy considerations of including this information in the public DNS, and recommends that "EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS".

[Ballot comment]
I do not see that any type of hardware identifier should be stored in the DNS at all. I also find the use case odd, though I do understand that there is a regulatory requirement to implement this. However, I do not want to block this draft and I'm balloting abstain for that reason.

IESG/Authors/WG Chairs:

IANA has reviewed draft-jabley-dnsext-eui48-eui64-rrtypes-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Resource Record (RR) TYPEs registry in the Domain Name System (DNS) Parameters page located at

www.iana.org/assignments/dns-parameters

two new resource record types, which have already been the subject of early assignment, will be made permanent as follows:

Type: EUI48
Value: 108
Meaning: An EUI-48 address
Reference: [ RFC-to-be ]
Template:
Registration Date: [ TBD-at-registration ]

Type: EUI64
Value: 109
Meaning: An EUI-64 address
Reference: [ RFC-to-be ]
Template:
Registration Date: [ TBD-at-registration ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm which actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Informational RFC


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'
  as Informational RFC

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@ietf.org mailing lists by 2013-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
  Unique Identifiers (EUI-64) are address formats specified by the IEEE
  for use in various layer-2 networks, e.g.  Ethernet.

  This document describes two new DNS resource record types, EUI48 and
  EUI64, for encoding Ethernet addresses in the DNS.

  This document describes potentially severe privacy implications
  resulting from indiscriminate publication of link-layer addresses in
  the DNS.  This document recommends that EUI-48 or EUI-64 addresses
  SHOULD NOT be published in the public DNS.  This document specifies
  an interoperable encoding of these address types for use in private
  DNS namespaces, where the privacy concerns can be constrained and
  mitigated.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/


No IPR declarations have been submitted directly on this I-D.

IESG/Authors/WG Chairs:

IANA has reviewed draft-jabley-dnsext-eui48-eui64-rrtypes-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Resource Record (RR) TYPEs registry in the Domain Name System (DNS) Parameters page located at

www.iana.org/assignments/dns-parameters

two new resource record types, which have already been the subject of early assignment, will be made permanent as follows:

Type: EUI48
Value: 108
Meaning: An EUI-48 address
Reference: [ RFC-to-be ]
Template:
Registration Date: [ TBD-at-registration ]

Type: EUI64
Value: 109
Meaning: An EUI-64 address
Reference: [ RFC-to-be ]
Template:
Registration Date: [ TBD-at-registration ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard


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'
  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@ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
  Unique Identifiers (EUI-64) are address formats specified by the IEEE
  for use in various layer-2 networks, e.g. ethernet.

  This document defines two new DNS resource record types, EUI48 and
  EUI64, for encoding ethernet addresses in the DNS.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/


No IPR declarations have been submitted directly on this I-D.

Note added 'Joe requested that I look at ad sponsoring this and it looks like a candidate for that path.

Expert review of the request for code-point assignment has completed, and code-points have been assigned.
'