Subject: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

From: joel jaeggli <[email-masked]>
Date: Sun, 14 Apr 2013 08:55:52 -0700

I've been asked to take this document on as AD sponsored individual 
submission.

http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02

If there's anyone who has strenuous objections to that, please let me know.

joel

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Apr 2013 12:40:09 -0400

What exactly is the purpose for this document?  Specifically, please describe the concept of operations for the use of this record.

Mapping a name directly to a MAC address seems somewhat problematic and perhaps even dangerous to consistency. 

I understand storing things in the DNS system is attractive, but adapting it to store L2 data may be going a bit too far past it's designed scope,

I would object to the document absent a clear and convincing description of why it is needed and what applications will use it.  

Mike

Sent from my iPad

On Apr 14, 2013, at 11:55, joel jaeggli <[email-masked]> wrote:

> I've been asked to take this document on as AD sponsored individual submission.
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Apr 2013 11:13:05 -0700

> I would object to the document absent a clear and convincing description of why it is needed and what applications will use it.  

Is such an objection really appropriate? I don't see anything in RFC 6195 that would allow someone to demand a "clear and convincing description of why it is needed and what applications will use it" before an Internet Draft could even go to IETF Last Call, or even during IETF Last Call to prevent registration of the RRTtypes requested (which is all this Internet Draft is about).

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Apr 2013 14:17:05 -0400

Rfc6195, section 3.1.2, items 1, 4, and 5 apply.   

Sent from my iPad

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Apr 2013 11:28:09 -0700

> Rfc6195, section 3.1.2, items 1, 4, and 5 apply.   

To a request for an AD to bring the document to IETF Last Call? Where in RFC 6195 do you see that? Or did you misunderstand Joel's question?

--Paul Hoffman

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Apr 2013 15:22:08 -0400

Let's try this again.

I understood what Joel was asking.  I objected to bringing this to last call.

You asked where in RFC6195 that there was grounds to object.

I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the following:

Although the allocation template says that the code points were assigned by expert review, its unclear they followed the criteria required by 6145.  Given the lack of details, I don't see how an expert could say:

(1) that the documentation was complete enough to evaluate.

(4) that the document was complete enough to describe any other interactions with DNS - for example publishing the DNS name to IP mapping as part of a DHCP IP address assignment process for the MAC address.

and (5) that give the lack of 1 and 4, and the short shrift to "well, we could do it in the text record, but we'd rather not" that it's unclear why this is a global assignment rather than a private one.

If this makes it through in the current condition, I would suggest that I could submit a document based on the current document where EUi48 is changed to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes" with fairly minimal text changes that would ALSO make it through.  And that would be bad.

Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the 6145 mandated application and experts assignment message on the list or in the archives:

>After the applicant posts their formal application with their
>   template as specified in <http://tools.ietf.org/html/rfc6195#appendix-A>Appendix A, IANA appoints an Expert and the
>   template is posted, with an indication that it is a formal
>   application, to the [email-masked] mailing list.  No less than three
>   weeks and no more than six weeks after this posting to
>   [email-masked], the selected Expert shall post a message, explicitly
>   accepting or rejecting the application, to IANA, [email-masked], and
>   the email address provided by the applicant.  If the Expert does not
>   post such a message, the application shall be considered rejected but
>   may be resubmitted to IANA.  IANA should report non-responsive
>   Experts to the IESG.

Mike

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 14 Apr 2013 17:38:13 -0400

RFC 6195 is not in effect. draft-ietf-dnsext-rfc6195bis-05 (RFC-to-be
6895) is in effect since it was approved last year. It's been held up
by a dependency but will presumably will pop out early next week since
it looks like the dependency has cleared.

> I understood what Joel was asking.  I objected to bringing this to last

As below, if the last call is blocked it might block documentation and
review but will have no effect on the code points.

> Although the allocation template says that the code points were assigned by
> expert review, its unclear they followed the criteria required by 6145.

They are not "criteria required". They are *guidelines* and the
overall policy, from RFC-to-be-6895 is "The Designated Expert should
normally be lenient, preferring to approve most requests."

> Given the lack of details, I don't see how an expert could say:
>
> (4) that the document was complete enough to describe any other interactions
> with DNS - for example publishing the DNS name to IP mapping as part of a
> DHCP IP address assignment process for the MAC address.
>
> and (5) that give the lack of 1 and 4, and the short shrift to "well, we
> could do it in the text record, but we'd rather not" that it's unclear why
> this is a global assignment rather than a private one.

As regards the allocation of the code points, it actually does not
make any difference what you think. The application was submitted. The
assigned expert has approved. (I am not a member of the expert pool.)
The code points (108 and 109) have been allocated and are in the
public RRTYPE registry as of, probably, a couple of week ago, and
since then anyone in the world has been free to use them:
   http://www.iana.org/assignments/dns-parameters/dns-parameters.xml

> If this makes it through in the current condition, I would suggest that I
> could submit a document based on the current document where EUi48 is changed
> to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes"
> with fairly minimal text changes that would ALSO make it through.  And that
> would be bad.

It seems odd to restrict it breakfast cereal UPC codes, but having an
DNS RRTYPE for UPC code or ISBN number seems fine to me. Why would it
be bad to store such things in the DNS? It would provide a way to
securely associate such numbers with a DNS name.

> Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the
> 6145 mandated application and experts assignment message on the list or in
> the archives:

See RFC-to-be-6895. Such a message has not been required since the
approval of RFC-to-be-6895 which is the result of years of effort to
defeat narrow-minded objections and real and perceived barriers to
getting new RRtypes for ordinary data (can be handled as an Unknown RR
as described in [RFC3597]). In my opinion, there is almost never a
reason to turn down such an RRTYPE request and the rapid approval of
this request is exactly what is supposed to happen.

I would like to thank the author for taking the step of proposing
publication of his draft as an RFC, something not required. This
provides an opportunity for review and, for example, possible
inclusion of usage guidance or the like.

Experience proves that the "you can't get a number without jumping
through hoops" mindset leads to lots of overloadings of TXT and people
just grabbing a random RRTYPE number and camping on it, which I think
is a worse than, say, allocating some RRTYPE numbers for some data
which turns out to be not so useful in the DNS.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

>    template as specified in
> Appendix A,
> IANA appoints an Expert and the
>    Experts to the
> IESG.
> To a request for an AD to bring the document to IETF Last Call? Where in RFC
> 6195 do you see that? Or did you misunderstand Joel's question?
>
> --Paul Hoffman
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Apr 2013 18:45:31 -0400

>it looks like the dependency has cleared.

OK.  Sort of double secret probation.  I missed that announcement.

>normally be lenient, preferring to approve most requests."

"However, the Expert should usually reject any
   RRTYPE allocation request that meets one or more of the following
   criteria:"

is what follows the above.  I'd suggest that "SHOULD" here [my caps] sets the following items as criteria for evaluation, not guidelines.  The word "usually" muddies the water so maybe you could get by with calling them guidelines.  It's  splitting hairs in any case.

>securely associate such numbers with a DNS name.

I used "breakfast cereal UPC codes" to describe an absurd case, but one that appears would be permitted without much review using pretty much the same boiler plate as the current document.

It would be really nice if there were actually a real-world reason to have such a mapping though before doing such an assignment.  I keep hoping for some sanity in DNS use, but it seems to be getting further and further distant.

But getting back to the current case - 

1) If you query the DNS for both an IP and a MAC address, and you get records for both, but the records don't point to the same physical host, what should you do, and how might you detect this?

2) If you query the DNS for MAC address records and you get multiple records for the same DNS name, what does that mean?

3) If you query the DNS for an IP and MAC address and only get a MAC address record, what does that mean?

4) If you query the DNS for an IP and a MAC, and then ARP for the MAC address and get a different value than the MACs from the DNS, what does that mean?

At least in the UPC and ISBN stuff I can mostly assume they don't refer to an internet connected device.  In the specific case, because the MAC address usually has some interaction with the IP address, and someone is bound to try and come up an application (e.g something besides ARP or DHCP) that cares about both simultaneously, it would REALLY be nice if the document at least set out the thoughts for why adding this type was a good idea, and possibly how to deal with some of the above issues.

>as described in [RFC3597]). 

Umm.. I realize you wrote the draft, but I'm surprised you forgot what it said:

>IANA appoints an Expert
>   and sends the completed template to the Expert copying the applicant.
>   No more than two weeks after receiving the application the Expert
>   shall explicitly approve or reject the application, informing IANA,
>   the applicant, and the [email-masked] mailing list.

You took out the requirement to publish the application for comments, but you did not take out the requirement to publish the approval.    I may have missed it, but I didn't see such a message from the assigned expert.

>In my opinion, there is almost never a

---

From: Joe Abley <[email-masked]>
Date: Sun, 14 Apr 2013 18:56:45 -0400

Hi there,

> What exactly is the purpose for this document?  Specifically, please describe the concept of operations for the use of this record.

Regardless of whether it's required or not, there's no secret here and I believe I've mentioned the motivations more than once on this list.

Some cable internet companies of my acquaintance in Canada have been required to provide a mapping between subscriber (CPE) MAC addresses and assigned (DHCP) IPv4 addresses for customers of other ISPs who are using the cable infrastructure as a wholesale product.

Due perhaps in part to the fact that there is no defined, neat and tidy way to store a MAC address in the DNS, different cable providers do it in different ways. Some of them encode it in the owner name, some do it in free-form TXT RDATA; some encode the IP address in an in-addr.arpa fashion, some don't.

I was motivated to try and make this better for the next place this kind of uncoordinated requirement arises, since surely the wholesale internet market in Canada cannot be unique. I have heard some musings from DHCP software vendors about whether the ability to publish such a mapping using DNS UPDATE directly from the DHCP servers would be useful. That suggests to me that such vendors (who presumably are familiar with their customers) think there are people who would like to use it.

There's more to making a consistent schema for such an application than defining an RRType, but the RRType existing certainly helps point things in the right direction.

I wasn't required to declare the motivation for the registration when I sent in the form, and the expert review (as I understand it) wasn't conducted on the basis of whether this was a useful idea, but on the basis of whether this was something that couldn't use an existing RRType, and had a stable specification.

I can assure you that these registrations are not of zero value, even if you don't seem them as something you would use.

Joe

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Apr 2013 20:33:10 -0400

>I can assure you that these registrations are not of zero value, even if you don't seem them as something you would use.

I don't think this is of zero value, and I think it's probably more useful than not to have a consistent way of representing EUI stuff in the DNS. 

BUT - this has some potential to interact badly with DNS to IP(4/6) mappings for the same name.  Although this is a straight data RR, it's semantics mean that an EUI RR directly represents an L2 capable device.  That places it much closer to A and AAAA records and suggests that some guidance on how to reconcile names that have both IP content and EUI content is desirable.  

It also suggests that there may need to be some text in the security section describing privacy issues where the DNS name points to both the mac and the ip  E.g. the mac is permanent, unique, and provides additional ways to identify specific users and relate identity to content.  For example, a web server may do an inverse lookup on the IP address, gets an innocuous cable provider DNS name, uses that to look up the EUI and adds that information to its back end database for tracking purposes.  Since that mac address never changes, the individual can be tracked even across DHCP updates, moving from one provider to another, etc.

As I said in a private message to Paul Hoffman, I mostly don't care about random RR assignments, but I think this one needs a bit more thought and explanatory text.

Mike

---

From: Joe Abley <[email-masked]>
Date: Sun, 14 Apr 2013 20:41:45 -0400

Hi again,

> I don't think this is of zero value, and I think it's probably more useful than not to have a consistent way of representing EUI stuff in the DNS. 

Thanks!

> BUT - this has some potential to interact badly with DNS to IP(4/6) mappings for the same name.  Although this is a straight data RR, it's semantics mean that an EUI RR directly represents an L2 ca…

Since clients need to specify that they want an EUI48 or EUI64 RR in order to receive an answer (or ask ANY, which these days mainly means they want someone else to receive the answer) I don't see any conflicts with existing cases of name resolution. Can you explain?

> It also suggests that there may need to be some text in the security section describing privacy issues where the DNS name points to both the mac and the ip  E.g. the mac is permanent, unique, and p…

With respect to privacy issues, the use case I described involves cable plant/CMTS operators publishing data for use by their wholesale customers. In Canada at least there is ample provision for privacy and protection of both cable operators and ISPs for disclosure of data relating to customers. I'm not sure such a wide-ranging discussion really belongs in a brief protocol specification, though. Sounds more like fodder for industry regulators and privacy commissioners.

> As I said in a private message to Paul Hoffman, I mostly don't care about random RR assignments, but I think this one needs a bit more thought and explanatory text.

I still don't see it myself, but if you feel strongly and wanted to write up guidance for people using this particular RRType I'd be happy to review it from the perspective of the use case I described.

Joe

---

From: list reader DNSEXT <[email-masked]>
Date: Mon, 15 Apr 2013 08:53:53 +0200

Hi,

I think there's an error in section 4.1 where it should say EUI64 but
actually says EUI48.

and +1 for the privacy concerned

Regards

ian maddison

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Apr 2013 07:53:46 -0400

> I think there's an error in section 4.1 where it should say EUI64 but

I think you're right. Thanks for that! I will make changes.

> and +1 for the privacy concerned

Can you explain further? I don't understand those concerns.

This document provides a specification for a structured way of storing particular data in the DNS. It's not data that can't be stored today using more general RRTypes like TXT. It doesn't advocate publication of anything. What are the privacy concerns?

If there are concerns that people should take time to understand the privacy implications of publishing subscriber data in the DNS, then that seems entirely valid. But this is not a draft about publishing subscriber data in the DNS, it's a draft about implementing specific RRTypes.

If there is useful information for the IETF to publish about privacy considerations in the DNS, I don't understand why that should be specific to these particular RRTypes. Are similar privacy concerns not also applicable to the DNS in general?

I've seen people distribute password hashes and user identities in the DNS before, as a back-end to tacacs servers deployed to authenticate dial-up users. (OK, this is going back a bit.) Surely if there is advice to be given about the publication of subscriber data in the DNS we would want to talk about the general approach, and not specific RRTypes.

Would we caution people about storing MAC addresses in an EUI48 RR, but not bother to caution other people about storing the same data in TXT records?

etc, etc.

Joe

---

From: "Dickson, Brian" <[email-masked]>
Date: Mon, 15 Apr 2013 15:51:35 +0000

Michael StJohns wrote:
> 1) If you query the DNS for both an IP and a MAC address, and you get
>records for both, but the records don't point to the same physical host,
>what should you do, and how might you detect this?
>
> 2) If you query the DNS for MAC address records and you get multiple
>records for the same DNS name, what does that mean?
>
> 4) If you query the DNS for an IP and a MAC, and then ARP for the MAC
>address and get a different value than the MACs from the DNS, what does
>that mean?

All of the above suffer from "pronoun trouble".

Who is "you", in each case above?

While DNS can be queried by humans, its main raison d'être is use by
machines.

So, what is doing the query/queries?

And presumably, it is doing so because of some standard for using DNS for
the relevant info.

And, the behavior would, I would expect, be defined by that
protocol/application, including how to handle the above cases.

Your questions might be turned around, and ask the question:
- what protocol would be doing queries for both (A or AAAA) and (EUI-48 or
EUI-64)?
- what protocol would be doing queries for just (EUI-48 or EUI-64)?

And each question's answer might quite reasonably differ, based on the
application/protocol doing the queries.

Examples for IP+MAC might include:
- DHCP servers
- IPS/IDS/Firewall systems
- enhanced ACLs on servers
- anything doing static ARP
- anything doing reverse-arp

Similarly, what kinds of things might be involved in setting EUI-48/EUI-64
records?
- dynamic update related to wifi (authenticated registration)
- layer 2 protection schemes (especially for IPv6 vs ND/RA/etc)
- zeroconf (multicast DNS), and perhaps mdnsext

I'd humbly suggest that the variety of potential use cases already meets
the "need" you have articulated.

Having defined RRTypes is an enable for all of the above.

Brian

---

From: joel jaeggli <[email-masked]>
Date: Sun, 14 Apr 2013 12:09:08 -0700

On 4/14/13 9:40 AM, Michael StJohns wrote:
> What exactly is the purpose for  this document?  Specifically, please
 > describe the concept of operations for the use of this record.

The rational described on this list a month ago was as follows:

-------- Original Message --------
Subject:     [dnsext] Fwd: New Version Notification for 
draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt
Date:     Tue, 19 Mar 2013 10:33:04 -0400
From:     Joe Abley <[email-masked]>
To:     [email-masked] Group <[email-masked]>

Hi all,

During a conversation about an attempt to stuff IP and subscriber MAC 
addresses into the DNS (something that is happening operationally in 
Canada, related to wholesale cable internet service) I noticed that 
there is currently no clean way to represent ethernet MAC addresses. 
People are either using TXT records, or encoding MAC addresses into PTR 
RDATA, and it's all a bit messy.

Assuming that this is not the last time that someone will find a reason 
to encode layer-2 addresses in the DNS, I thought it worthwhile to 
define a cleaner option.

The draft referenced below defines two new RRTypes, EUI48 (for EUI-48 
addresses, which is what prompted this line of thinking) and EUI64 (for 
EUI-64 addresses, since it seems silly to accommodate one without the 
other).

The wire format is pretty trivial (network byte order, simple octet 
string), the RRTypes chosen are unremarkable (not sure what else you'd 
call an EUI-48 address RRType than EUI48) and the presentation format 
should be familiar. The examples given use the ethernet address of the 
wireless adapter on my laptop and its EUI-64 mapping, for lack of any 
documentation OUI that I could find. The IEEE references are consistent 
with the references for EUI-64 in IPv6, e.g. in RFC 4291. The expert 
review template for the RRType application is included as an appendix.

In the event that this proposal doesn't meet with projectile heartburn, 
I would hope that this could be adopted, discussed, refined and 
last-called before the demise of dnsext. Alternatively, assuming again 
that the expert review raises no concerns and code points are assigned, 
it could proceed as an individual-track submission.

Comments welcome.

Joe

>
 > Mapping a name directly to a MAC address seems somewhat problematic
 > and perhaps even dangerous to consistency.
 >
 > I understand storing things in the DNS system is attractive, but
 > adapting it to store L2 data may be going a bit too far past it's
 > designed scope,

The scope in which such a mapping is useful is clearly fairly limited, I 
imagine there are provisioning/subscriber managment systems that would 
adopt such a representation, but  I imagine the author has a more 
specifc example.

> I would object to the document  absent a clear and convincing
 > description of why it is needed and what applications will use it.
 >
 > Mike
 >
 > Sent from my iPad
 >
>>
 >> joel _______________________________________________ dnsext mailing
 >> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
 >

---

From: Doug Barton <[email-masked]>
Date: Mon, 15 Apr 2013 09:10:59 -0700

> I was motivated to try and make this better for the next place this kind of uncoordinated requirement arises, since surely the wholesale internet market in Canada cannot be unique. I have heard som…

Personally I would like to see a more well-defined use case for this 
before RRtypes are actually assigned. It's not at all clear why the 
right answer isn't a common definition of how to do this in a TXT 
record. Not everything needs (or should have) it's own RRtype.

It's also not clear why IANA has already assigned code points for this 
(as described in your text).

Doug

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Apr 2013 12:18:14 -0400

On 2013-04-15, at 12:10, Doug Barton <[email-masked]> wrote:

> It's not at all clear why the right answer isn't a common definition of how to do this in a TXT record. Not everything needs (or should have) it's own RRtype.

I think this is madness.

By this logic we didn't need to bother defining AAAA records, since there's no reason why they can't live in TXT records. Ditto DNSKEY, and everything, really. Why even have RRTypes, if we can just ship free-form text around?

> It's also not clear why IANA has already assigned code points for this (as described in your text).

Because the expert review passed, and IANA was following the required procedure, I think.

Joe

---

From: Jim Reid <[email-masked]>
Date: Mon, 15 Apr 2013 17:38:55 +0100

>> It's not at all clear why the right answer isn't a common definition of how to do this in a TXT record. Not everything needs (or should have) it's own RRtype.

+100.

> By this logic we didn't need to bother defining AAAA records, since there's no reason why they can't live in TXT records. Ditto DNSKEY, and everything, really. Why even have RRTypes, if we can just…

Indeed.

The "just make everything a TXT record" mindset is nuts. How is an application making a QTYPE=TXT query expected to make sense of possibly zillions of TXT records in the response, filtering the wheat from the chaff? What's the operational impact of that? Going further down that path probably means having to subtype TXT records while RR type codes go unassigned. Sheer madness.

> Because the expert review passed, and IANA was following the required procedure, I think.

In other words, we're done. The type codes have been assigned. That ship has already sailed.

An RFC documenting these RRTypes and how they're used is to be welcomed. After all that draft didn't *have* to be written. Further discussion on this thread should be about improving that document. For instance by contributing text to explain the potential for unwelcome interactions with A/AAAA/PTR mappings for the same name that Mike mentioned the other day.

The question of "why not do this in a TXT record?" has already been satisfactorily answered and IMO is no longer up for debate.

---

From: Doug Barton <[email-masked]>
Date: Mon, 15 Apr 2013 09:42:34 -0700

> By this logic we didn't need to bother defining AAAA records, since there's no reason why they can't live in TXT records. Ditto DNSKEY, and everything, really. Why even have RRTypes, if we can just…

Don't be absurd. You're smart enough to know the difference between 
something that is widely or near-universally deployed, and something 
that is a special case for a limited number of environments; and the 
relative value of exhausting a scarce resource for each.

Or is your argument that everyone who applies should get an RR code 
point, until they're all gone?

FWIW, we did something similar when I was at Yahoo!, and I know from 
experience that TXT works just fine for this purpose. As I said in my 
first message, I am not opposed to assigning RRtypes for this per se, 
but I don't think that the use case is well enough documented to justify 
it yet.

> Because the expert review passed, and IANA was following the required procedure, I think.

Fair enough. I'm not as familiar with the fine points of the procedure 
as I used to be. :)

Doug

---

From: "Dickson, Brian" <[email-masked]>
Date: Mon, 15 Apr 2013 16:52:48 +0000

On 4/15/13 12:38 PM, "Jim Reid" <[email-masked]> wrote:
>
>The question of "why not do this in a TXT record?" has already been
>satisfactorily answered and IMO is no longer up for debate.
>

+ 2^16 :-)

Anyone still suggesting use of TXT, please read RFC 5507
(http://tools.ietf.org/html/rfc5507), which answers this in a canonical
fashion.

Brian

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 15 Apr 2013 09:57:04 -0700

On Apr 15, 2013, at 9:42 AM, Doug Barton <[email-masked]> wrote:
> Don't be absurd. You're smart enough to know the difference between something that is widely or near-universally deployed, and something that is a special case for a limited number of environments; and the relative value of exhausting a scarce resource for each.
> 
> Or is your argument that everyone who applies should get an RR code point, until they're all gone?
> 
> FWIW, we did something similar when I was at Yahoo!, and I know from experience that TXT works just fine for this purpose. As I said in my first message, I am not opposed to assigning RRtypes for this per se, but I don't think that the use case is well enough documented to justify it yet.

I rather find the opposite:  I don't see why this is NOT a good use of DNS.  DNS is, first and foremost, about tying names to network address information.  This is simply one common piece of addressing information that does not already have a type assigned.

So the real question is "is it broad enough"?  Yes, since just about every L2 network technology has a 48B or 64B fixed address size.

And its not like we need to worry about RR space exhaustion, we are only using what, .5% of the space for allocating new RR types?

---

From: Doug Barton <[email-masked]>
Date: Mon, 15 Apr 2013 10:10:04 -0700

>> satisfactorily answered and IMO is no longer up for debate.

Been there, done that, got the t-shirt. For things that are going to be 
generally useful I have no argument with assigning an RRtype (as I've 
said many times now).

But the mere fact that something is in an RFC doesn't mean that I have 
to agree with it carte blanche, does it? Not to mention that 5707 is 
Informational, so by definition non-canonical. :)

Doug

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Apr 2013 13:20:55 -0400

On 2013-04-15, at 12:42, Doug Barton <[email-masked]> wrote:

> Don't be absurd. You're smart enough to know the difference between something that is widely or near-universally deployed,

... like ethernet...

> and something that is a special case for a limited number of environments

... like DNSSEC or IPv6 when AAAA and DNSKEY were assigned, or, even arguably, now?

> ; and the relative value of exhausting a scarce resource for each.
> 

I certainly don't think we should be turning down RRType applications on the grounds that one day we might possibly run out of code points. By that logic, we'd never assign any at all.

Fortunately, the question at hand is not whether you think assignment is a good idea (code points have already been assigned) or whether this is something you would ever use (feel free not to). The question is whether the document provides reasonable documentation that could facilitate implementation and interop. Do you have any opinions on that?

> FWIW, we did something similar when I was at Yahoo!, and I know from experience that TXT works just fine for this purpose.

I had no idea Yahoo! was involved with implementing CRTC policy decades before it was enacted, that's certainly impressive.

> As I said in my first message, I am not opposed to assigning RRtypes for this per se, but I don't think that the use case is well enough documented to justify it yet.

Noted, but your opinion (or anybody else's) on these assignments is not actually relevant here.

Joe

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Apr 2013 18:11:42 -0400

>Can you explain further? I don't understand those concerns.

Suggested paragraphs for the security section.

[ PRIVACY: 
There may be privacy concerns with publishing EUI RRs.  EUI64 and EUI48 represent unique identifiers for network connected equipment.  As such, their inclusion within the DNS may result in privacy issues in the form of unique trackable identities.  Unlike the IP addresses and DNS names for network devices which can and do change over time, the EUI information will almost always uniquely identify a device (or more specifically, a network interface).  As an example of this, consider a wireless provider that publishes EUI information for its subscribers.  An entity that wants to relate web queries, for example, to a specific customer need only do a reverse query from the IP address to a DNS name, and then a forward query for the EUI information.  The tracking entity may relate all queries to specific unique identities regardless of changes in IP addresses and DNS names resulting in a possible loss of privacy for the subscriber. 

Transitive Trust:

DNSSEC allows the binding of a name to one or more RR's.  It is possible to use DNSSEC to bind both A/AAAA records and EUI64/48 records to the same name.  This should probably not be consider as a secure binding between an IP address and an EUI64/48 address.  {Not sure where this should go - this gets perilously close to secure ARP and placing this in the hands of the domain owner rather than the hands of the network owner is probably a "bad thing" }

Paragraph for the main body:

[
EUI64 and EUI48 addresses represent another way of referencing a network connected host past IP addresses and DNS names.  Any system which deploys EUI64 and EUI48 RR's should consider how to maintain consistency between the various systems which may be involved in such mapping.  Specifically, DNS, DHCP, and ARP.   Any application that desires to make use of EUI64 and EUI48 RR's for any other use beyond simple data storage should consider how to resolve at least the following possible inconsistencies in data in the DNS and local network information:

1)  A mismatch for the same name where the device referenced by the A and AAAA records do not represent the same device as those referenced by the EUI64 and EUI48 RRs.  (E.g. the ARP response for a local IP address does not yield one of the values in an EUI64 or EUI48 RR).

2) A query for a specific name which returns multiple EUI64 and EUI48 records. 

3) A query for a specific name which returns only EUI64 and EUI48 records and does not return either of A or AAAA records.

---

From: Joe Abley <[email-masked]>
Date: Tue, 16 Apr 2013 09:04:25 -0400

Hi Michael,

> There may be privacy concerns with publishing EUI RRs.  EUI64 and EUI48 represent unique identifiers for network connected equipment.  As such, their inclusion within the DNS may result in privacy…

I think this presumes too much about how the EUI48/EUI64 records might be used.

In the use case that triggered this walk in the woods, MAC addresses of cable modems are published in zones available for query and AXFR by wholesale customers of the cable company (i.e. ISPs) but are not generally available to the DNS-querying public. They're protected by ACLs. They're also published in in-addr.arpa-style zones (but not under in-addr.arpa), and hence references to forward and reverse queries don't really mean much.

How about something more general, like:

"EUI48 and EUI64 addresses are intended to represent unique identifiers for network-connected equipment. Publishing those identifiers in the DNS might present privacy concerns, e.g. by providing an indirect mapping between an IPv4 or IPv6 address and a specific end-user device. Operators are encouraged to consider the privacy implications of publishing EUI48 or EUI64 addresses in the DNS before doing so."

> DNSSEC allows the binding of a name to one or more RR's.  It is possible to use DNSSEC to bind both A/AAAA records and EUI64/48 records to the same name.  This should probably not be consider as a…

I'm not entirely sure what problems you are anticipating, here. Can you elaborate?

> 3) A query for a specific name which returns only EUI64 and EUI48 records and does not return either of A or AAAA records.

Again, I think you're anticipating a use-case that you haven't described, here. While mention of the general potential for privacy violation seems defensible, I don't understand the rationale for singling out one use-case for examination and dedicating text to it.

Surely particular use-cases of EUI48/64 RRs that include potential problems worth highlighting need to be documented separately, and this text belongs in those documents.

I'll say again that the allocation of code-points to EUI48/EUI64 RRs doesn't enable any of these use-cases -- they're all possible today, e.g. using TXT RRs or by encoding MAC addresses into owner names (as some of the cable companies I mentioned have done). All this specification does is to provide an opportunity for the encoding and canonical zone syntax to be more efficient and consistent, respectively.

Joe

---

From: Chip Marshall <[email-masked]>
Date: Tue, 16 Apr 2013 11:01:54 -0400

On 2013-04-15, Michael StJohns <[email-masked]> sent:
> 1) A mismatch for the same name where the device referenced by
> the A and AAAA records do not represent the same device as
> those referenced by the EUI64 and EUI48 RRs. (E.g. the ARP
> response for a local IP address does not yield one of the
> values in an EUI64 or EUI48 RR).

This seems unnecessary to me. Is there anything currently implying
that A and AAAA records at the same node refer to the same
physical machine? If no, is there any reason to expect that the
A/AAAA and EUI records refer to the same machine?

-- 
Chip Marshall <[email-masked]>
http://2bithacker.net/

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Apr 2013 15:56:39 -0400

>A/AAAA and EUI records refer to the same machine?

IPv4 and v6 addresses are known to move around.  I believe there is sufficient documentation to describe what happens if you get the A and AAAA records not referring to the same physical machine (but they generally do refer to the same logical machine - not always, but usually).  What the above says is that there isn't documentation for the interaction between A, AAAA and EUI records and there probably needs to be.

The EUI records are unique identifiers.  My assumption - without any text saying otherwise - is that if I get records with both IP addresses and EUI values that the intent of the domain operator was to convey a relationship between the two.

The current document is silent on this intent.  It should not be.

If this record were just point to random strings of data (e.g. UUIDs for example) that don't have a network related identity, I wouldn't care.  But it is EUI48 and 64 addresses that really do have a related network ID.  It would be nice if we told applications how to deal with cognitive dissonance of this form.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Apr 2013 16:15:35 -0400

>"EUI48 and EUI64 addresses are intended to represent unique identifiers for network-connected equipment. Publishing those identifiers in the DNS might present privacy concerns, e.g. by providing an…

Until I explained the use case I was concerned about, you mostly didn't think there was a problem.  I don't have any problems with the text you propose, but I question whether or not a later reader will get the point or believe there is even an issue.

>I'm not entirely sure what problems you are anticipating, here. Can you elaborate?

Sorry.

DNSSEC signs a binding between DNS name and A record.
DNSSEC signs a binding between DNS name and an EUI record.

Application assumes that because there is an Name->A and Name->EUI signed binding, then it can assume a cryptographic binding between the A record (or rather the IP address) and the EUI record (or rather the MAC address).   That's probably a bad assumption given that you're not requiring this and should probably be stated in the security section.

This particular item came up because someone mentioned that it would be useful to have a signature over the DNS/EUI pairing.

>I'll say again that the allocation of code-points to EUI48/EUI64 RRs doesn't enable any of these use-cases -- they're all possible today, e.g. using TXT RRs or by encoding MAC addresses into owner n…

Mostly a TXT record doesn't provide you with globally actionable data and I wouldn't be too worried (or even be able to detect) mismatches between TXT and A records.  But you chose to put EUI data in the DNS - you need to think about what that might mean in the future past your simple "throw data in the DNS" application.  The fact that the EUI data represents a network connected device in a directly addressable fashion is what makes this more complex than you've considered.

I *don't* know what the future uses may be, but I do know that if I start caring about EUI data, I probably want to consider how to deal with mismatches or interactions with A/AAAA data and the EUI data. 

Consider a draft by Don Eastlake way back in '97 or so dealing with Autonomous System records.  It didn't go forward as an RFC, but it did - in its text - consider how the AS data related to other data in the DNS.  It went so far to say that A records probably shouldn't go in the same node as AS records.  It considered how that record (representing some data that was network actionable) would interact with other records in the DNS.

I think you need something like this, or you need to describe a much more constrained usage model than you already have.

Later, Mike

---

From: Philipp Kern <[email-masked]>
Date: Tue, 16 Apr 2013 23:16:43 +0200

Michael,

am Tue, Apr 16, 2013 at 04:15:35PM -0400 hast du folgendes geschrieben:
> Application assumes that because there is an Name->A and Name->EUI signed
> binding, then it can assume a cryptographic binding between the A record (or
> rather the IP address) and the EUI record (or rather the MAC address).
> That's probably a bad assumption given that you're not requiring this and
> should probably be stated in the security section.

why should Name->A and Name->EUI imply A<->EUI given that you're querying
forward DNS? I don't see how that should be true.

I don't think you'd argue the same for {A, MX} or {A, TXT}. One thing where
something like this might be relevant is {A, SSHFP}. But I don't think
anybody uses DNS->A and DNS->SSHFP together to signify A<->SSHFP, as the
matching is on the name. (Obviously in this case it's likely true, but
if you'd connect directly to the address you wouldn't get the SSHFP
information from anywhere.)

> This particular item came up because someone mentioned that it would be
> useful to have a signature over the DNS/EUI pairing.

A records are another data domain and independent. You can still sign the
DNS/EUI mapping.

Kind regards
Philipp Kern

---

From: SM <[email-masked]>
Date: Wed, 17 Apr 2013 11:01:33 -0700

Hi Doug,
At 10:10 15-04-2013, Doug Barton wrote:
>But the mere fact that something is in an RFC doesn't mean that I 
>have to agree with it carte blanche, does it? Not to mention that 
>5707 is Informational, so by definition non-canonical. :)

It's RFC 5507.  It's an IAB document.  That doesn't mean that it is 
has special status.

Regards,
-sm

---

From: Doug Barton <[email-masked]>
Date: Wed, 17 Apr 2013 11:44:36 -0700

On 04/17/2013 11:01 AM, SM wrote:
> It's RFC 5507.

Yeah, sorry ... if you hadn't snipped so much of my message you would 
have seen that was clear from context in spite of my typo.

> It's an IAB document.  That doesn't mean that it is has
> special status.

so why mention it? :)

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 17 Apr 2013 15:05:32 -0400

I suppose it depends on what you mean by "special" but I believe that
informational RFCs issued by the IAB constitute at least a mild form
of architectural guidance. To quote from the abstract of 5507: "...
This document lists different mechanisms to extend the DNS, and
concludes that the use of a new DNS Resource Record Type is the best
solution."

Thanks,
Donald

On Wed, Apr 17, 2013 at 2:01 PM, SM <[email-masked]> wrote:
>> But the mere fact that something is in an RFC doesn't mean that I have to
>> agree with it carte blanche, does it? Not to mention that 5707 is
> It's RFC 5507.  It's an IAB document.  That doesn't mean that it is has
> special status.
>
> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Wed, 17 Apr 2013 12:24:03 -0700

Hi Doug,
At 11:44 17-04-2013, Doug Barton wrote:
>Yeah, sorry ... if you hadn't snipped so much of my message you 
>would have seen that was clear from context in spite of my typo.

I saw the correct link.  I looked up the (typo) RFC and wondered how 
it was related to DNS.

>so why mention it? :)

It's because I will be reading that RFC in future and I may use if I 
comment about the draft.

Regards,
-sm

---

From: Doug Barton <[email-masked]>
Date: Wed, 17 Apr 2013 21:42:24 -0700

On 04/15/2013 10:20 AM, Joe Abley wrote:
>>>> It's not at all clear why the right answer isn't a common
>>>> definition of how to do this in a TXT record. Not everything
>>>> needs (or should have) it's own RRtype.
>>>
>>> I think this is madness.
>>>
>>> By this logic we didn't need to bother defining AAAA records,
>>> since there's no reason why they can't live in TXT records. Ditto
>>> DNSKEY, and everything, really. Why even have RRTypes, if we can
>>> just ship free-form text around?
>>
>> something that is widely or near-universally deployed,
>
> ... like ethernet...

And every ethernet port is going to have one of your new records in DNS?

C'mon Joe, argue for your positions merits, sure. But please stop using 
these ad absurdum claims, it doesn't add anything to the discourse.

> ... like DNSSEC or IPv6 when AAAA and DNSKEY were assigned, or, even

Each of your examples above were planned for wide deployment, and the 
use cases were obvious from the beginning. It's still not clear to me 
how wide spread the use case is for these records, but apparently that 
doesn't matter since the ship has sailed. That's not hurting anything, 
as was pointed out the potential space is huge, and we're only using a 
tiny fraction of it. Just like IPv4. Oh, wait ...  :)

> I certainly don't think we should be turning down RRType applications
> on the grounds that one day we might possibly run out of code points.
> By that logic, we'd never assign any at all.

Again, ad absurdum. My point was that there should be _some_ criteria 
applied regarding how "popular" (to use a crass and loaded term) a new 
record is likely to be. Or, I could be wrong ... and my concern is 
totally misplaced. Either way I find it fascinating that people are not 
willing to even consider the question.

> Fortunately, the question at hand is not whether you think assignment
> is a good idea (code points have already been assigned) or whether
> this is something you would ever use (feel free not to). The question
> is whether the document provides reasonable documentation that could
> facilitate implementation and interop. Do you have any opinions on
> that?

Dunno, I still haven't gotten past how silly I think the idea is. :) 
Meanwhile, there are plenty of people who have made observations about 
the utility of your draft, I'm sure it will get whipped into shape with 
or without me.

>> FWIW, we did something similar when I was at Yahoo!, and I know
>> from experience that TXT works just fine for this purpose.
>
> I had no idea Yahoo! was involved with implementing CRTC policy
> decades before it was enacted, that's certainly impressive.

Well now you're just being an ass. I think my meaning was clear, if 
you're interested in hearing about our use case I'm happy to share, if 
you're not, that's fine too.

>> As I said in my first message, I am not opposed to assigning
>> RRtypes for this per se, but I don't think that the use case is
>> well enough documented to justify it yet.
>

Thanks for making your perspective clear. :)

Doug

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Apr 2013 10:17:59 +0100

On 15 Apr 2013, at 18:10, Doug Barton <[email-masked]> wrote:

> But the mere fact that something is in an RFC doesn't mean that I have to agree with it carte blanche, does it?

Doug, you're being silly and not contributing anything useful or constructive to the discussion. Please stop.

Whether you like some RFC or not is your choice. Nobody else cares or needs to care about your RFC preferences. Just like the world doesn't need to do that for mine.

You've said on this thread that you consider the draft does not justify the assignment of type codes. But not why you think that. No, don't bother: the time where that opinion may have counted or was even worth listening to has long passed. The expert reviewers have decided the idea is sound and justify the type code assignments which IANA has duly done. Their opinion is the one which matters here. They've spoken. We're done. This thread should have stopped long ago.

In an earlier posting you asked "is your argument that everyone who applies should get an RR code point, until they're all gone?". Well the short answer to that is yes. Read RFC6195. The expert reviewers can and should be trusted to block frivolous or badly thought out type code assignment requests. That's why they're expert reviewers. If they screw up or somehow lose the confidence of the WG, they get replaced.

The point of the lightweight type code assignment mechanism is to avoid futile angels on pinheads debates in this list.

PS At current assigment rates, the Internet will run out of RR type codes a few thousand years from now. If this rate changes dramatically, I'm reasonably certain a viable solution will be available in good time: say a 128 bit QTYPE2 field in EDNS8 queries.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Apr 2013 09:27:25 -0400

Dear colleagues,

No hat.

> point, until they're all gone?

The WG already came to consensus on the answer to that question.  It
was, roughly, "Yes."  The guidelines for this are well-specified, and
therefore arguments to the effect that a particular use case is not
good enough for a typecode assignment have no force.

Moreover, I think this is a good thing.  There are a lot of people
around the DNS community who seem to think we have a responsibility to
be the protocol cops.  I am not one of them.  I think that it should
be cheap and easy to get a typecode assignment at least until we start
to see evidence that the number space is getting used up unsustainably
quickly.  

Best,

A 

-- 
Andrew Sullivan
[email-masked]

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 18 Apr 2013 09:46:59 -0400

> Because the expert review passed, and IANA was following the required procedure, I think.

[reviewing the discussion from a process perspective -- what is the root 
cause of the controversy?]

It appears that the bar for RR type allocation is lower than for an 
informational RFC.

To which extent should the IESG lower the bar for a specific I-D on the 
ground that it acquired an RR type?

Incidentally:

Process-wise, we could be in front of a "submarine RFC" case: IANA (or 
the expert?) would have followed the RFC6895 procedures before it was 
published.

It bugs me that the IANA allocation process uses a mailing list a) not 
listed in the IANA web pages, and b) (I guess) subject to the IETF IPR 
disclosure policy by virtue of being run under the ietf.org domain.

I am not particularly expert in those details, but somehow I care that
1) stakeholders are created equal, but some are more equal than others 
(e.g. those aware in advance of the submarine RFC), and
2) who controls the process controls the outcome.

Regards,

- Thierry Moreau

---

From: Joe Abley <[email-masked]>
Date: Thu, 18 Apr 2013 10:16:04 -0400

On 2013-04-18, at 09:46, Thierry Moreau <[email-masked]> wrote:

> [reviewing the discussion from a process perspective -- what is the root cause of the controversy?]
> 
> It appears that the bar for RR type allocation is lower than for an informational RFC.

The RRType application registry's bar is "expert review". The bar for publication of an informational RFC depends on what stream you follow, whether it's a working group document, etc. It's not clear to me that one bar is obviously lower; they're just different.

> To which extent should the IESG lower the bar for a specific I-D on the ground that it acquired an RR type?

I'm not sure that it should (nor that anybody has suggested it should, or would).

> Incidentally:
> 
> Process-wise, we could be in front of a "submarine RFC" case: IANA (or the expert?) would have followed the RFC6895 procedures before it was published.

As I understand it, the directions in draft-ietf-dnsext-rfc6195bis-05 were followed by the IANA once that document was approved by the IESG. It looks like that happened in December last year. The document emerged from the RFC editor queue as RFC6895 two days ago.

It doesn't seem unreasonable that "IESG approval" is the trigger here, rather than "RFC published".

> It bugs me that the IANA allocation process uses a mailing list a) not listed in the IANA web pages, and b) (I guess) subject to the IETF IPR disclosure policy by virtue of being run under the ietf.org domain.

I'm not sure what mailing list you're talking about. Applications for RRTYPE code point assignments are sent to [email-masked], which seems to forward to a ticket system at the IANA.

> 1) stakeholders are created equal, but some are more equal than others (e.g. those aware in advance of the submarine RFC), and

I had no particular awareness of the process when I applied for code points for EUI48 and EUI64 -- I just found the relevant registry at www.iana.org and clicked the link above the table. That took me to draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I followed them.

> 2) who controls the process controls the outcome.

My experience with this application was that the process was efficient, easy to find and easy to understand.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 18 Apr 2013 13:55:41 -0400

Hi Thierry,

Calling anything but April 1st RFCs a "submarine RFC" is pretty silly.
(April 1st RFCs really do appear with no warning.)

They are all internet-drafts first and publicly available there even
before they are listed in the RFC Edtior's queue for, usually, a
couple of months, while going through the editing process. And, in the
case of a WG document like rfc6195bis, there is notice and discussion
in the working group, the IETF Last Call, the IESG process tracked in
the datatracker, etc.

The IESG has the standards setting and BCP approval authority in the
IETF. It has always been the case that, unless perhaps there is some
special provision in the document, drafts take effect on the final
approval by the IESG, that is, at the time they are transferred to the
RFC Editor, not when the RFC issues.

RFC Editor's queue is here, which is linked off the RFC Editor home page:
http://www.rfc-editor.org/queue2.html
RFC publication can be held up for a variety of reasons. The oldest
document currently in the queue was placed there 2012-02-21, almost 14
months ago.

Thanks,
Donald

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 18 Apr 2013 14:41:28 -0400

> (April 1st RFCs really do appear with no warning.)

I stand corrected on this one, with the following nuance: while IETF 
processes are eminently transparent and public, they remain obscure and 
complex, at least at the detailed level, for anyone not directly involved.

I stand corrected because IANA web pages indeed refers to the I-D once 
approved and until the RFC is published (but still, once the RFC is 
published, the date of I-D approval disappears from the IANA web pages 
... so a hindsight understanding of IANA motivation for a protocol 
assignment between I-D approval and RFC publication is harder).

> RFC Editor, not when the RFC issues.

I never figured out how to train myself about BCP. I got bored of IETF 
process before I could. So what about others not directly involved?

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Apr 2013 11:47:31 -0700

On 4/18/13 11:41 AM, Thierry Moreau wrote:
> processes are eminently transparent and public, they remain obscure 
> and complex, at least at the detailed level, for anyone not directly 
> involved.
>
Were this AD sponsored, which in fact it isn't  yet the responsible AD 
would be looking for reviewers, and at a minimum it would be subject to 
an IETF last call.

the ISG processing rules say:

AD Sponsored documents to Standards Track require review in the IETF, 
IETF Last Call, and IESG approval. AD Sponsored documents to 
Experimental/Informational require some form of review in the IETF and 
IESG approval. While RFC 2026 does not require the latter type of 
documents to go through an IETF Last Call, this statement suggests that 
it is always performed. It is needed to ensure adequate review and 
transparency in a situation where the pending publication of the 
document may not be known by any Working Group or the IETF community at 
large.
>>> The RRType application registry's bar is "expert review". The bar 
>>> for publication of an informational RFC depends on what stream you 
>>> follow, whether it's a working group document, etc. It's not clear 
>>> to me that one bar is obviously lower; they're just different.
>>>
>>>> Process-wise, we could be in front of a "submarine RFC" case: IANA 
>>>> (or the expert?) would have followed the RFC6895 procedures before 
>>>> it was published.
>>> As I understand it, the directions in 
>>> draft-ietf-dnsext-rfc6195bis-05 were followed by the IANA once that 
>>> document was approved by the IESG. It looks like that happened in 
>>> December last year. The document emerged from the RFC editor queue 
>>> as RFC6895 two days ago.
>>>
>>>> It bugs me that the IANA allocation process uses a mailing list a) 
>>>> not listed in the IANA web pages, and b) (I guess) subject to the 
>>>> IETF IPR disclosure policy by virtue of being run under the 
>>>> ietf.org domain.
>>> I'm not sure what mailing list you're talking about. Applications 
>>> for RRTYPE code point assignments are sent to 
>>> [email-masked], which seems to forward to a ticket 
>>> system at the IANA.
>>>
>>>> 1) stakeholders are created equal, but some are more equal than 
>>>> others (e.g. those aware in advance of the submarine RFC), and
>>> I had no particular awareness of the process when I applied for code 
>>> points for EUI48 and EUI64 -- I just found the relevant registry at 
>>> www.iana.org and clicked the link above the table. That took me to 
>>> draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I 
>>> followed them.
>>>
>>> My experience with this application was that the process was 
>>> efficient, easy to find and easy to understand.
>>>
>>>
>>> Joe

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Apr 2013 16:01:48 +0900

Maybe, most of you are uninterested in technical content of
the draft.

But, the proposal not using just an EUI type (depends on RDLENGTH),
but EUI48 and EUI64 types is inefficient w.r.t. RR type space
and the number of queries to get EUI information of a node.

						Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 Apr 2013 10:04:47 -0400

Ohta-san,

> and the number of queries to get EUI information of a node.

It sounds like your counter-proposal would have been to specify a single RRType with an additional field in the RDATA to distinguish between EUI48 and EUI64, e.g. without drawing the bitfields, something that might have a presentation format like

  owner1.example. 86400 IN EUI 48 7c-d1-c3-e8-10-2f

I think that's a perfectly valid idea. However, two code points have already been assigned for each of EUI48 and EUI64 at this point, and at least one vendor has implemented them according to the currently-circulating specification. I think we can consider both assigned code points to be polluted at this point, and hence revising the spec to make use of a single RRType would (a) not actually preserve a code point in the RRTypes registry, and (b) would present interop problems against current implementations if one of the assigned code-points was re-used. In effect, to implement your suggestion would require a third code-point.

Joe

---

From: "Dickson, Brian" <[email-masked]>
Date: Fri, 19 Apr 2013 15:22:03 +0000

On 4/19/13 10:04 AM, "Joe Abley" <[email-masked]> wrote:

>In effect, to implement your suggestion would require a third code-point.

Which would lead to:

http://xkcd.com/927/

:-)

Brian

---

From: SM <[email-masked]>
Date: Fri, 19 Apr 2013 14:36:06 -0700

Hi Donald,
>concludes that the use of a new DNS Resource Record Type is the best

I sometimes read some of the (informational) RFCs issued by the IAB 
as guidance.  I won't tell anyone that the RFC is more important than 
another RFC (what I meant by "special").  It helps (me) to have some 
mild form of architectural guidance as a way to avoid solving issues 
which have already been solved previously.

Regards,
-sm

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 22 Apr 2013 17:14:29 +0900

(2013/04/19 23:04), Joe Abley wrote:

> It sounds like your counter-proposal would have been to specify
> a single RRType with an additional field in the RDATA to
> distinguish between EUI48 and EUI64, e.g. without drawing
> the bitfields, something that might have a presentation format like
> 
> I think that's a perfectly valid idea. However, two code points
> have already been assigned for each of EUI48 and EUI64 at
> this point,

>> and the number of queries to get EUI information of a node.

is still a problem, the third code point must be allocated. But,
it is not my mistake.

> and at least one vendor has implemented them according to the
> currently-circulating specification.

That were a valid argument if "some vendor has implemented it
with TXT" were a valid argument against EUI48 and EUI64.

> I think we can consider both assigned code points to be
> polluted at this point, and hence revising the spec to
> make use of a single RRType would (a) not actually
> preserve a code point in the RRTypes registry, and (b)
> would present interop problems against current
> implementations if one of the assigned code-points was
> re-used. In effect, to implement your suggestion would
> require a third code-point.

Yes, of course.

If you insist on the current draft, I can write a draft and
request the third code point, can't I?

					Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Mon, 22 Apr 2013 06:40:28 -0400

> request the third code point, can't I?

Yes, of course. Since there are already code-points assigned for the publication of EUI48/EUI64 addresses in the DNS now, though, it seems possible that such a request would be denied though, on that basis.

Joe

---

From: Doug Barton <[email-masked]>
Date: Mon, 22 Apr 2013 11:02:04 -0700

> Yes, of course. Since there are already code-points assigned for the publication of EUI48/EUI64 addresses in the DNS now, though, it seems possible that such a request would be denied though, on th…

Um, wait. I thought code points should be free, and easy to obtain. 
What's the harm in having a different way to represent similar data? If 
down the road someone comes up with a fourth option that is clearly 
vastly superior to either of your proposals, should they also be denied?

Doug

---

From: Joe Abley <[email-masked]>
Date: Mon, 22 Apr 2013 14:22:56 -0400

On 2013-04-22, at 14:02, Doug Barton <[email-masked]> wrote:

> Um, wait. I thought code points should be free, and easy to obtain. What's the harm in having a different way to represent similar data? If down the road someone comes up with a fourth option that is clearly vastly superior to either of your proposals, should they also be denied?

I guess that's down to the expert review. I thought there was some explicit text in 6195 or 6895 that touched on this, but in fact what I was remembering was question F in the allocation template (e.g. see 6895 appendix A).

   F. What existing RRTYPE or RRTYPEs come closest to filling that need
      and why are they unsatisfactory?

Quite possibly I was reading more into that question than was intended.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Apr 2013 14:28:55 -0400

No hat.

On Mon, Apr 22, 2013 at 11:02:04AM -0700, Doug Barton wrote:

> What's the harm in having a different way to represent similar data?

Nobody needs to show harm here, because the guidance to experts in RFC
6895 (found in section 3.1.2, specifically number 4) says the expert
shouldn't approve requests "when the purpose could be met with a
smaller number of values or with Private Use values."

If there are people who would like the procedures for RRTYPE
assignment to change, I encourage them to submit
draft-doe-wannabe-dns-cops-00 or whatever it should be called.  But it
seems to me that arguing about the goodness of the allocation
procedure that is actually in operation is not a great use of
participants' time.  Note that the WG is not taking up any more
documents, so a new IANA procedure for DNS RRTYPE code assignment
would have to go through another route.  Perhaps an AD sponsorship.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Doug Barton <[email-masked]>
Date: Mon, 22 Apr 2013 12:01:57 -0700

> smaller number of values or with Private Use values."

Sure, so my theoretical case would be approved (assuming the new type 
actually is superior).

> assignment to change

Not my purpose at all ... clearly my previous understanding was 
incorrect, and I was met with "it should be easy to allocate a new 
type." Now someone else is proposing a new type, and the same folks are 
saying "no, you shouldn't get your new type." I'm confused.

Doug

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 22 Apr 2013 15:31:53 -0400

I'm not against all additions of text to this draft. Here is my
suggested text, partly based on Michael StJohn's suggestions:

Possible main body text:

The specification of the new RRTYPEs in this document has no effect on
the address resolution behavior of any previously existing network
processes or protocols. Proposals or specifications to modify or
augment address resolution processes or protocols by making use of
these RRTPES should specify how any address conflicts or multiple EUI
RR occurrences or the like are handled.

Possible Security Considerations text:

There may be privacy concerns with publishing EUI RRs in the global
DNS. EUI addresses with the Global bit zero [RFC5342] are supposed to
represent unique identifiers for network connected equipment
notwithstanding many observed cases of duplication due to
manufacturing errors, unauthorized use of OUIs, and address spoofing
through configuration of network interfaces. Inclusion of EUI RRs in
the global DNS may result in privacy issues in the form of unique
trackable identities. IP addresses and DNS names for network devices
typically change over time but EUIs normally provide a unique identity
for a network device. As an example of this, consider a wireless
provider that publishes EUI information for its subscribers in the
global DNS under the same name as their IP host name. An entity that
wants to relate web queries, for example, to a specific customer
might, if that customer is using a globally routable IP address, be
able to do a reverse query from the IP address to a DNS name, and then
a forward query for the EUI information. If possible, this would
enable a tracking entity to relate queries to specific identity
regardless of changes in IP addresses and DNS names resulting in a
loss of privacy for the subscriber. These potential concerns can be
mitigated through restricting access to zones containing EUI RRs
and/or storage of such information under a domain name whose
construction requires that the querier already know some other
permanent identifier.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 22 Apr 2013 15:38:44 -0400

On Mon, Apr 22, 2013 at 2:02 PM, Doug Barton <[email-masked]> wrote:
>> Yes, of course. Since there are already code-points assigned for the
>> publication of EUI48/EUI64 addresses in the DNS now, though, it seems
>> possible that such a request would be denied though, on that basis.
>
> Um, wait. I thought code points should be free, and easy to obtain. What's
> the harm in having a different way to represent similar data? If down the
> road someone comes up with a fourth option that is clearly vastly superior
> to either of your proposals, should they also be denied?

The policy is not first come, first served. It is lenient, not free.
It is an Expert judgement call.

Having multiple ways of representing the same data doesn't hurt much
if they are used for different purposes. If they are used for the same
purpose and some might be using one and some the other, it multiplies
the number of queries since you should check for all of them.

But of course, if there is a *vastly superior* way, then one could
hope that everyone would eventually switch to the new way. So in that
case it might make sense to have a new way to represent the same data
for the same purpose and accept a transient increase in queries.

Thanks,
Donald

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Apr 2013 15:40:52 -0400

Works for me.  Thanks - Mike

Sent from my iPad

---

From: Doug Barton <[email-masked]>
Date: Mon, 22 Apr 2013 12:52:16 -0700

> the number of queries since you should check for all of them.

Sure, I agree with that of course. I also had in mind the "same data, 
but different (or dissimilar) purposes."

> for the same purpose and accept a transient increase in queries.

Your explanation makes sense, thanks for helping me understand.

Doug

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 23 Apr 2013 08:23:49 +0900

> What's the harm in having a different way to represent similar data?

That is not a problem as my draft will obsolete clearly inefficient
way with EUI48/EUI64 and EUI48/EUI64 specification is not published
as an RFC yet.

> with TXT" were a valid argument against EUI48 and EUI64.

that there are informal ways to represent some data does not
block to have a formal way to do so, even though someone has
implemented the informal ways.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 23 Apr 2013 08:32:36 +0900

> smaller number of values or with Private Use values."

Don't quote the RFC wrongly.

The text in the RFC is:

   4. An excessive number of RRTYPE values is being requested when the
      purpose could be met with a smaller number of values or with
      Private Use values.

Do you mean 1 is an excessive number?

If so, as 2 is clearly more excessive than 1, the original request
with EUI48/EUI64 should have been denied as the purpose can be met
with a smaller number of value.

						Masataka Ohta

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 22 Apr 2013 21:35:53 -0400

> way with EUI48/EUI64 and EUI48/EUI64 specification is not published
<no-hat> 
Ohta'san makes a good point, the currently allocated points are not in use 
thus they can be reassigned at later point i.e. after we all stop caring about DNS. 

Lets just live with the "wasted" code points.

	Olafur