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

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

-------- Original Message --------
Subject: 	draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored 
individual sumission...
Date: 	Sun, 14 Apr 2013 08:55:52 -0700
From: 	joel jaeggli <[email-masked]>
To: 	[email-masked], [email-masked]
CC: 	[email-masked]

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: 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
 >
 > On Apr 14, 2013, at 11:55, joel jaeggli <[email-masked]> wrote:
 >
>>
 >> joel _______________________________________________ dnsext mailing
 >> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
 >

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Apr 2013 13:14:05 -0400

I have no problem with this in spirit.  But I always wonder why the presentation formats, as in section 3.2 and 4.2, have MUST concerning how the record is "written."  I've never considered the presentation format to be subject to a standard...I realize that's just my opinion, but the on-the-wire format is what is subject to interoperability concerns.

The document can have the MUSTs but I'd prefer SHOULDs.  It's right that there's only one way these addresses ever get written, so the MUST seems logical, OTOH, it just seems over the top to demand it be written one way or another.  I certainly understand it is INTENDED to be written as documented, but is it a sin if I implement something else?  (How would an alternate form hinder interoperability.)

Apparently I am a little cranky today.

On Apr 14, 2013, at 12:08, joel jaeggli wrote:

> Subject: 	draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

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

Hi Ed,

> I have no problem with this in spirit.  But I always wonder why the presentation formats, as in section 3.2 and 4.2, have MUST concerning how the record is "written."  I've never considered the pre…

I think that's valid.

My thinking when I wrote the draft is that there are two areas where interop is important: (a) on the wire, where incompatibility would simply break everything, and (b) in the canonical zone file format, where incompatibility would annoy operators (who might have to generate two different zones to be served by two different nameservers, for example).

The first draft specified MUSTs with aa:bb:cc:dd:ee style notation, since that's what I see most often on network gear and in Unix. I was subsequently shown an IEEE document that included aa-bb-cc-dd-ee as a canonical representation, so I changed it.

> The document can have the MUSTs but I'd prefer SHOULDs.  It's right that there's only one way these addresses ever get written, so the MUST seems logical, OTOH, it just seems over the top to demand…

I think a SHOULD is too weak though. I spend a lot of time parsing the output from tools that decode DNS messages, and if different tools used different presentation formats for the same wire data it would make my life hard.

I could specify that both formats were permitted on input (parse zone file) or output (generate zone file). I certainly agree that the canonical IEEE format is not the most common, at least with the systems I most frequently use.

> Apparently I am a little cranky today.

One too many Beijing hamburgers.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Apr 2013 11:00:54 -0700

> I have no problem with this in spirit.  But I always wonder why the presentation formats, as in section 3.2 and 4.2, have MUST concerning how the record is "written."  I've never considered the pre…

This has come up before, and there are indeed interoperability issues with presentation formats. Developers will use examples they find in the RFC and on the Internet to create encoders and parsers. If there is an agreed-to presentation format, the likelihood of wire interoperability goes way up.

> The document can have the MUSTs but I'd prefer SHOULDs.  

A "SHOULD" is a "MUST except for these reasons". What would the reasons be for using a different presentation format?

> It's right that there's only one way these addresses ever get written, so the MUST seems logical, OTOH, it just seems over the top to demand it be written one way or another.  I certainly understand it is INTENDED to be written as documented, but is it a sin if I implement something else?  (How would an alternate form hinder interoperability.)
> 

...and haven't re-read RFC 2119 in a while. There is no mention of "sin".

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Apr 2013 14:08:21 -0400

> I think a SHOULD is too weak though. I spend a lot of time parsing the output from tools that decode DNS messages, and if different tools used different presentation formats for the same wire data…

But are the log writers subject to the rules and regulations in an RFC?  Sigh.  Anyway, I get this way when I try to read an RFC as a specification document.

> One too many Beijing hamburgers.

It's shameful enough to have to admit to ordering a hamburger in Beijing, still the punishment was far more than deserved.

---

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

On 2013-04-15, at 14:08, Edward Lewis <[email-masked]> wrote:

> But are the log writers subject to the rules and regulations in an RFC?

Well, I was talking about zone files and resource records (e.g. things you load into knot/nsd/bind9, things you receive back from kdig/dig), not log files.

In my experience people who write logging code in nameservers are subject to nobody, least of all their users. That's probably harsh. But fair.

> Sigh.  Anyway, I get this way when I try to read an RFC as a specification document.

Try reading this specification document as an RFC :-)

Joe

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Apr 2013 14:54:01 -0400

> Well, I was talking about zone files and resource records (e.g. things you load into knot/nsd/bind9, things you receive back from kdig/dig), not log files.

It's just more code. ;)

> Try reading this specification document as an RFC :-)

Or I could have another hamburger.

Really, it's no big deal.  (The presentation format that is, digesting poorly cooked ground beef is a big deal.)

Ahh - here we go with food on an IETF list.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Apr 2013 15:42:23 +1000

In message <[email-masked]>, Edward Lewis writes:
> I have no problem with this in spirit.  But I always wonder why the 
> presentation formats, as in section 3.2 and 4.2, have MUST concerning how 
> the record is "written."  I've never considered the presentation format 
> to be subject to a standard...I realize that's just my opinion, but the 
> on-the-wire format is what is subject to interoperability concerns.

It's a MUST because master file format is a interchange standard.

RFC 1034

The standard format of master files allows them to be exchanged between
hosts (via FTP, mail, or some other mechanism); this facility is useful
when an organization wants a domain, but doesn't want to support a name
server.  The organization can maintain the master files locally using a
text editor, transfer them to a foreign host which runs a name server,
and then arrange with the system administrator of the name server to get
the files loaded.

Mark
 
> The document can have the MUSTs but I'd prefer SHOULDs.  It's right that 
> there's only one way these addresses ever get written, so the MUST seems 
> logical, OTOH, it just seems over the top to demand it be written one way 
> or another.  I certainly understand it is INTENDED to be written as 
> documented, but is it a sin if I implement something else?  (How would an 
> alternate form hinder interoperability.)
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Apr 2013 16:24:46 +1000

In message <[email-masked]>, Paul Hoffman writes:
> > presentation formats, as in section 3.2 and 4.2, have MUST concer
> > ning how the record is "written."  I've never considered the presentation 
> > format to be subject to a standard...I realize that's just my
> > opinion, but the on-the-wire format is what is subject to 
> > interoperability concerns.
> 
> This has come up before, and there are indeed interoperability issues 
> with presentation formats. Developers will use examples they find
> in the RFC and on the Internet to create encoders and parsers. If there 
> is an agreed-to presentation format, the likelihood of wire in
> teroperability goes way up.

Web site developers not reading the RFCs has lead to problems
entering perfectly valid DS records.

> A "SHOULD" is a "MUST except for these reasons". What would the reasons 
> be for using a different presentation format?
> 
> > It's right that there's only one way these addresses ever get written, 
> > so the MUST seems logical, OTOH, it just seems over the top to
> > demand it be written one way or another.  I certainly understand it is 
> > INTENDED to be written as documented, but is it a sin if I implement
> > something else?  (How would an alternate form hinder  interoperability.)

I looked at accepting something else when implementing EUI48 and
EUI64 in named then thought about the "named accepts it so it must
be right" crowd.  If you want more liberal formats they need to
be documented and the LCD is a MUST the rest are MAYs or SHOULDs.

---

From: Richard Lamb <[email-masked]>
Date: Wed, 17 Apr 2013 12:22:17 -0700

FWIW I don't see any problem with having RRtypes for MAC addresses in the DNS.  I am not an old DNS salt like many on this list, but seems there are many other RRtypes out there that have less interest.  I see the reference to the IEEE "Guidelines for use of a ...EUI-48" but for the sake of equal billing to this "other lookup table" it might be nice to add a reference/link to the IEEE Registration authority for OUIs, e.g.,  http://standards.ieee.org/develop/regauth/oui/public.html , in your references section.

-Rick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: Monday, April 15, 2013 10:42 PM
To: Edward Lewis
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

In message <[email-masked]>, Edward Lewis writes:
> presentation formats, as in section 3.2 and 4.2, have MUST concerning 
> how the record is "written."  I've never considered the presentation 
> format to be subject to a standard...I realize that's just my opinion, 
> but the on-the-wire format is what is subject to interoperability concerns.

RFC 1034

The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server.  The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded.

Mark
 
> The document can have the MUSTs but I'd prefer SHOULDs.  It's right 
> that there's only one way these addresses ever get written, so the 
> MUST seems logical, OTOH, it just seems over the top to demand it be 
> written one way or another.  I certainly understand it is INTENDED to 
> be written as documented, but is it a sin if I implement something 
> else?  (How would an alternate form hinder interoperability.)
> 
> > If there's anyone who has strenuous objections to that, please let 
> > me
> know.
> > 
> > joel
> > 
> > 
> > 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=
> -
> Edward Lewis

---

From: Erik Kline <[email-masked]>
Date: Thu, 18 Apr 2013 12:31:11 +0900

I too am not a long-standing dnsop participant, but this draft raised a
question for me.  Does the class have any relevance anymore, really?

To be clear, I have no substantive comment on this document.  But when I
read "The EUI{48,64} RR is class-independent" I thought, that's a
bit...weird.  It seemed to me that if there were, for example, an IEEE
class then this would be perfectly suitable.  But I guess that the RR
number-space is effectively flat?  Do people even contemplate new classes
anymore?

Apologies for my naivete.

PS: If there are clarifying statements being added it might be worth
stating (the obvious) that EUI64 != Modified EUI64 as used by IPv6 SLAAC
(so don't go flipping bits unnecessarily).

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Apr 2013 00:14:55 -0400 (EDT)

On Thu, 18 Apr 2013, Erik Kline wrote:

>  But I guess that the RR number-space is effectively flat?  Do people even contemplate new classes anymore?

I think most people believe new classes would lead to implementation chaos[*]

Paul
[*] sorry :)

---

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

On 18 Apr 2013, at 04:31, Erik Kline <[email-masked]> wrote:

> Do people even contemplate new classes anymore?

Yes. A now dead Swiss(?) academic got paid by the ITU to promote this idea 4-5 years ago after he presented it at WSIS and IGF. The concept was to "increase competition" in the DNS name space. Which would have the not entirely accidental side effect of breaking USG/ICANN hegemony on Internet governance.

His web sites and projects are no longer active, so I don't have current URLs for his papers and slideware. google found this though:
	http://www.itu.int/wsis/implementation/2009/forum/geneva/Pdfs/WSISForum09-InfraClasses-V0%201%20(2).pdf

Be sure to have lots of padding beneath your chin to soften the impact when your jaw drops if you read this.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 18 Apr 2013 11:17:18 +0200

On Thu, Apr 18, 2013 at 10:10:53AM +0100,
 Jim Reid <[email-masked]> wrote 
 a message of 15 lines which said:

> Yes. A now dead Swiss(?)

He was French. An analysis (in french) of his work is here:

http://www.bortzmeyer.org/net4d.html

---

From: tsg <[email-masked]>
Date: Thu, 18 Apr 2013 05:16:38 -0700

There is no reason USE RULES on the addresses resolved cannot be 
published (except perhaps that certain parties in this group doesnt want 
that to happen for some reason).

For instance - one could publish a OPT-OUT Statement for Mailing Use 
Rules, something that is critically needed in dealing with SPAM...

That said it makes sense to extend DNS into other areas to make it less 
necessary at the application context to rely on its shared OS context 
(allows a more appliance like operation). In fact ultimately there is no 
reason DNS is not functionally a policy and infrastructure information 
lookup and publishing tool.

Oh yeah - except a bunch of purists want to make sure it never evolves 
into something that they didnt create... This is the same crap I run 
into all the time with the US6370629 patent now that McNeil and I have 
our control back.

So look - YES while this specific brief isnt maybe the best expansion - 
the idea has merit that there is a need for a DIGITAL CONTENT 
INFRASTRUCTURE LOOKUP PRACTICE for policy publication and DNS is 
probably the best place possible to layer that functionality INTO (not 
on top of).

Todd