Subject: [dnsext] Fwd: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt

From: Joe Abley <[email-masked]>
Date: Tue, 23 Apr 2013 08:46:03 -0400

Hi all,

I incorporated the text from Michael and Donald, and added text describing the use case that triggered this work (as has been described on this list before).

Given that these RRTypes, code-points assigned, have been implemented as specified by at least one DNS server vendor, I have not considered changing the presentation or encoding (or the number of) these RRTypes; it seems counter-productive to change the spec when there is already running code. I imagine any other related specification could proceed on its own merits.

If anybody has further suggestions for improvement (of this document, not of RFC6895) please let me know.

Joe

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt
> Date: 23 April 2013 08:36:33 EDT
> To: <[email-masked]>, <[email-masked]>, <[email-masked]>
> 
> 
> A new version (-03) has been submitted for draft-jabley-dnsext-eui48-eui64-rrtypes:
> http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/
> 
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-03
> 
> IETF Secretariat.
>

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 24 Apr 2013 07:55:37 +0200

Hi Joe,

On 04/23/2013 02:46 PM, Joe Abley wrote:
> Hi all,
> 
> I incorporated the text from Michael and Donald, and added text 
> describing the use case that triggered this work (as has been 
> described on this list before).
> 
> Given that these RRTypes, code-points assigned, have been
> implemented as specified by at least one DNS server vendor, I have
> not considered changing the presentation or encoding (or the number
> of) these RRTypes; it seems counter-productive to change the spec
> when there is already running code. I imagine any other related
> specification could proceed on its own merits.

The RRtypes may be implemented, but no such code has been officially
released. Before releasing, the specification should be stable (and if
we did, we would disable it by default and mark it experimental).

Therefore, I do not see this as an argument not to make changes in the
presentation or encoding of the RRtypes. If such changes are made, we
can quite easily adapt the code.

Best regards,
  Matthijs

> 
> If anybody has further suggestions for improvement (of this
> document, not of RFC6895) please let me know.
> 
> 
> Joe
> 
> Begin forwarded message:
> 
>> From: <[email-masked]> Subject: New Version
>> Notification - draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt
>> Date: 23 April 2013 08:36:33 EDT To: <[email-masked]>, 
>> <[email-masked]>, 
>> <[email-masked]>
>> 
>> 
IETF Secretariat.
>> 
> 
> _______________________________________________ dnsext mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 24 Apr 2013 10:18:34 -0400

Hi Matthijs,

> we did, we would disable it by default and mark it experimental).

True; although I still think it's cleaner to leave the wire format alone now that there is running code, I agree that the running code is probably not actually running anywhere yet and the cost of changing the spec is therefore not high.

Several alternatives occur to me, some suggested by others here (e.g. Ohta-san), e.g.

1. A single EUI RRType that includes some number of bits to identify the type of EUI address (EUI-48 and EUI-64, currently), the remaining payload dependant on those bits.

2. A single IEEE RRType that includes perhaps a larger number of bits to accommodate other types of IEEE identifier, perhaps with an attendant registry to allow future use of the RRType to be defined in an extensible way.

3. Presentation formats that hide the details from sight, e.g. interpret example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48 address and set the address type bits implicitly, whereas example. $ttl IN EUI 88-99-aa-bb-cc-dd-ee-ff is clearly an EUI-64 address.

There is an argument that being able to publish both EUI-48 and EUI-64 addresses for the same owner name is more efficient if it can be done in a single RRSet. However, I don't see any examples of networked devices that use both EUI-48 and EUI-64 addresses simultaneously on the same interface; each address type seems to be used by different network types (e.g. EUI-48 for ethernet, EUI-64 for firewire) and I haven't seen any examples of shared use.

Given the lack of motivation to preserve RRTypes (according to the current allocation rules, don't shoot the messenger) and the lack of obvious examples of other IEEE addresses that might be useful to encode (EUI-64 is already pretty marginal) I tend to think that the spec as written has the benefit of simplicity and clarity, and complicating it has little short- or long-term benefit for implementers or users.

It's arguable I guess that the current spec is also more consistent in approach with A and AAAA, in the sense that we didn't overload a single RRType to accommodate multiple address types for IP addresses. I realise that's more an accident of history than a conscious design decision for A/AAAA (and one that some people wish was different).

I feel like a lot of mailing list bandwidth has already been expended on what is frankly a fairly small-time application, but if there's consensus here that the spec should be overhauled I can do that regardless of whether the process demands it (my impression is it doesn't; this is not a working group document and the allocation procedure doesn't actually require an RFC to be published at all).

Joe

---

From: Alex Bligh <[email-masked]>
Date: Wed, 24 Apr 2013 15:33:42 +0100

> 3. Presentation formats that hide the details from sight, e.g. interpret example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48 address and set the address type bits implicitly, whereas example. $ttl…

If you are going for economy, I would have thought the most economical would be one byte representing the length of the string, then the actual bytes in binary format (in wire format). Obviously hyphens (or colons for that matter) can be used in the presentation format.

-- 
Alex Bligh

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Apr 2013 07:42:57 -0700

This is amazing overkill. RRtypes are not a scarce resource; the WG already decided that, regardless of the fact that some people forgot it. Having different types for different lengths makes the processing code easier; combining them with some in-record logic makes it harder.

Having the WG second-guess the expert reviewer is not a good use of anyone's time.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Apr 2013 15:56:09 +0100

> Having the WG second-guess the expert reviewer is not a good use of anyone's time.

+1

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 24 Apr 2013 11:40:35 -0400

I think the currently allocated two RRTYPEs are just fine.

There are no network interfaces that I am aware of that have both 48
and 64 bit MAC addresses. While 48-bit is more commonly used in
standards, some uses of 64 could end up being very numerous, such as
802.15 sensor devices and the like.

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

On Wed, Apr 24, 2013 at 10:18 AM, Joe Abley <[email-masked]> wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Apr 2013 08:48:43 -0700

Paul,

> This is amazing overkill. RRtypes are not a scarce resource; the WG already decided that, regardless of the fact that some people forgot it. Having different types for different lengths makes the p…

Don't have a strong opinion here (to put it mildly) and haven't really been following, but:, what's the typical use case?  Naively, I would've have thought the client would wand to ask "what's the MAC" and get back the EUI, be it 48 or 64.  By using separate RR types, the client will have to know if the EUI is one size or the other or it'll need to send 2 queries.

BTW, I just tried to pull down the draft and I got:

"Content generation failed (on script line 329) with error code 1" with a 404.

The HTMLized version of the doc ends at section 6.

> Having the WG second-guess the expert reviewer is not a good use of anyone's time.

To be clear, I'm not second-guessing the expert reviewer, rather I'm second guessing Joe :)

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Wed, 24 Apr 2013 12:05:24 -0400

> Don't have a strong opinion here (to put it mildly) and haven't really been following, but:, what's the typical use case?  Naively, I would've have thought the client would wand to ask "what's the…

No idea what a typical use case would be. The use case that led to the thinking that led to the draft is described in -03.

> The HTMLized version of the doc ends at section 6.

For me, too. The text version is complete:

http://tools.ietf.org/id/draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt

> To be clear, I'm not second-guessing the expert reviewer, rather I'm second guessing Joe :)

Fair enough, too :-)

Joe

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 25 Apr 2013 08:06:32 +0200

Hi Joe,

On 04/24/2013 04:18 PM, Joe Abley wrote:
>>> implemented as specified by at least one DNS server vendor, I
>>> have not considered changing the presentation or encoding (or
>>> the number of) these RRTypes; it seems counter-productive to
>>> change the spec when there is already running code. I imagine
>>> any other related specification could proceed on its own
>>> merits.
>> 
>> The RRtypes may be implemented, but no such code has been
>> officially released. Before releasing, the specification should
>> be stable (and if we did, we would disable it by default and mark
>> it experimental).
> 
> True; although I still think it's cleaner to leave the wire format
> alone now that there is running code, I agree that the running code
> is probably not actually running anywhere yet and the cost of
> changing the spec is therefore not high.

It may be cleaner, true, but if there is a good proposal to change the
wire format or presentation format it should not be the reason to turn
such a change down.

> 1. A single EUI RRType that includes some number of bits to
> identify the type of EUI address (EUI-48 and EUI-64, currently),
> the remaining payload dependant on those bits.
> 
> 2. A single IEEE RRType that includes perhaps a larger number of
> bits to accommodate other types of IEEE identifier, perhaps with an
> attendant registry to allow future use of the RRType to be defined
> in an extensible way.
> 
> 3. Presentation formats that hide the details from sight, e.g.
> interpret example. $ttl IN EUI 7c-d1-c3-e8-10-2f as an EUI-48
> address and set the address type bits implicitly, whereas example.
> $ttl IN EUI 88-99-aa-bb-cc-dd-ee-ff is clearly an EUI-64 address.
> 
> There is an argument that being able to publish both EUI-48 and
> EUI-64 addresses for the same owner name is more efficient if it
> can be done in a single RRSet. However, I don't see any examples of
> networked devices that use both EUI-48 and EUI-64 addresses
> simultaneously on the same interface; each address type seems to be
> used by different network types (e.g. EUI-48 for ethernet, EUI-64
> for firewire) and I haven't seen any examples of shared use.
> 
> Given the lack of motivation to preserve RRTypes (according to the
> current allocation rules, don't shoot the messenger) and the lack
> of obvious examples of other IEEE addresses that might be useful to
> encode (EUI-64 is already pretty marginal) I tend to think that the
> spec as written has the benefit of simplicity and clarity, and
> complicating it has little short- or long-term benefit for
> implementers or users.
> 
> It's arguable I guess that the current spec is also more consistent
> in approach with A and AAAA, in the sense that we didn't overload a
> single RRType to accommodate multiple address types for IP
> addresses. I realise that's more an accident of history than a
> conscious design decision for A/AAAA (and one that some people wish
> was different).
> 
> I feel like a lot of mailing list bandwidth has already been
> expended on what is frankly a fairly small-time application, but if
> there's consensus here that the spec should be overhauled I can do
> that regardless of whether the process demands it (my impression is
> it doesn't; this is not a working group document and the allocation
> procedure doesn't actually require an RFC to be published at all).

I agree and I hope you realize that my previous mail was not
discussing the RRtype allocation. I was merely arguing your argument
for not changing the wire and presentation format. I also don't
propose any changes to the format (although I do have some ideas about
that), but suppose if someone did, imho your "running code" argument
should not be a valid reason to deny such a change.

Best regards,
  Matthijs