Subject: Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Mon, 20 May 2013 10:18:21 -0400

--On Monday, May 20, 2013 06:44 -0700 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from an individual submitter
> to consider the following document:
> - 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
>   <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> as Proposed
> Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [email-masked] mailing lists by
> 2013-06-17. Exceptionally, comments may be sent to
> [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it is
large, wouldn't it be better to have a single RRtype for
IEEE-based EUIs with a flag or other indicator in the DATA field
as to whether a 48 bit or 64 bit identifier was present?

In addition to saving an RRTYPE slot, my recollection of the
uses of EUI-64 is that an application trying to look up an EUI
may not, in the general case, know whether the device and its
EUI are of the 48 or 64 bit persuasions.  If that is correct, a
single RRTYPE and a length/type indicator in the DATA would
avoid a two-stage lookup and/or unnecessary use of QTYPE=ANY.
The same one RRTYPE model would, with even a modicum of good
design, make transition easier when the IEEE goes interplanetary
or interstellar and discovers a need for EUI-128 (or some other
length > 64).

If there really are significant advantages to having two
separate RRTYPEs that override the considerations above, it
seems to me that the reasoning for doing so should at least be
briefly explained in the document.

    john

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 May 2013 07:53:29 -0700

> as to whether a 48 bit or 64 bit identifier was present?
the basis for assignment of rr-types is expert review. Whether the draft 
advances or not the rr-types have been assigned.

http://tools.ietf.org/html/rfc6895#section-3.1.1

http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-3

---

From: SM <[email-masked]>
Date: Mon, 20 May 2013 09:48:33 -0700

At 06:44 20-05-2013, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>   <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-06-17. Exceptionally, comments may be

This draft is about putting MAC addresses in the DNS.  The purpose is 
for IP address tracking by vendors.  As the RRTYPE has already been 
allocated it is useful to document the format.  In my humble opinion 
it is not a good idea to put MAC address in the DNS.  There is some 
text in Section 9 about why it may not be a good idea.  In Section 9:

   "These potential concerns can be mitigated through restricting access
    to zones containing EUI48 or EUI64 RRs or storing such information
    under a domain name whose construction requires that the querier
    already know some other permanent identifier."

The "querier already know some other permanent identifier" reminds me 
of security through obscurity.  I'll do some selective quoting from 
another document:

   "Once the MAC-derived suffix mechanism was standardized, it
    was perceived to be required and therefore became part of compliance
    suites, which continue to compel implementations to support it many
    years after the associated vulnerabilities have been identified."

   "A comprehensive privacy threat model was never developed (which seems
    to be a recurring theme with older protocol development efforts)"

The write-up mentions: "The intended status is standards track with 
the label of propsed standard".  Why is the intended status "Proposed 
Standard"?

As a comment to Joe, the first line in Appendix A.2 was entertaining. :-)

Regards,
-sm

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 May 2013 15:10:46 -0400

People were already storing MAC addresses in DNS for the reason given
in the draft and perhaps others, it is just that they were doing so in
a variety of proprietary ways.

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

On Mon, May 20, 2013 at 12:48 PM, SM <[email-masked]> wrote:
> This draft is about putting MAC addresses in the DNS.  The purpose is for IP
> address tracking by vendors.  As the RRTYPE has already been allocated it is
> useful to document the format.  In my humble opinion it is not a good idea
> to put MAC address in the DNS.  There is some text in Section 9 about why it
> may not be a good idea.  In Section 9:
>
> The "querier already know some other permanent identifier" reminds me of
> security through obscurity.  I'll do some selective quoting from another
> document:
>
> The write-up mentions: "The intended status is standards track with the
> label of propsed standard".  Why is the intended status "Proposed Standard"?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 May 2013 08:08:25 +1200

>    Publication of EUI-48 or EUI-64 addresses in the global DNS may
>    result in privacy issues in the form of unique trackable identities.

This might also result in such MAC addresses being spoofed, thereby allowing
some sort of direct attack. So it isn't just a privacy concern.

...
>    These potential concerns can be mitigated through restricting access
>    already know some other permanent identifier.

This "can be" seems too weak. Shouldn't we have a MUST here? Also, I doubt
that the second option (a shared secret) is sufficient.

Regards
   Brian Carpenter

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 May 2013 18:01:24 -0400

--On Tuesday, May 21, 2013 08:08 +1200 Brian E Carpenter
<[email-masked]> wrote:

>>    These potential concerns can be mitigated through
>>    restricting access to zones containing EUI48 or EUI64 RRs
>>    or storing such information under a domain name whose
>>    construction requires that the querier already know some
>>    other permanent identifier.
> 
> This "can be" seems too weak. Shouldn't we have a MUST here?
> Also, I doubt that the second option (a shared secret) is
> sufficient.

I'd guess that, in the actual use cases, a MUST would be ignored
and am consequently would be reasonably happy with the existing
text even if it said less, thereby reducing the sensation of
hand waving.

A shared secret or other mechanism for obscuring a name might be
sufficient if the privacy requirement was to prevent casual data
mining and resulting attacks.  What is, or is not, sufficient
really depends on the risk analysis and assessment of how
serious a failure might be, an analysis that is missing from the
document.  That said, if serious protection were needed,
wouldn't it make sense to incorporate some provision for data
encryption in the RRTYPE itself rather than trying to use an
obscured domain name?  I wouldn't really propose that.  Instead,
I think the bottom line is closer to "if some data really need
to be secure and private, the public DNS is probably not the
right place to put them".

Comparing this to my earlier comments, I think an IETF Proposed
Standard really needs to discuss and resolve these issues and
that Brian's question is important in that context.  If hand
waving is appropriate, it should say why.  If an obscured
identifier is sufficient, it should explain why that is the case
or the circumstances under which it is the case.    The same
problems could be solved with an Informational document by
clearly describing the RRTYPE and then, if this sort of
information is needed at all, making it clear that it represents
the authors' opinion and how they expect their RRTYPE to be used
rather than, e.g., IETF consensus.

   john

---

From: Rob Austein <[email-masked]>
Date: Mon, 20 May 2013 19:49:11 -0400

> as to whether a 48 bit or 64 bit identifier was present?

Short answer: Probably not, but it depends on the application.

Longer answer: See RFC 5507.

---

From: SM <[email-masked]>
Date: Mon, 20 May 2013 16:41:25 -0700

Hi Donald,
>a variety of proprietary ways.

Thanks for the explanation.  I'll make a general comment.

 From what I understand the use case is about Canadian ISPs using 
AXFR to (privately) transfer information about IP addresses, EUI-48 
and EUI-64 addresses.  A MAC address is usually tied to a device 
[1][2].  I understand the interoperability argument.  That is 
addressed by the code point allocation.

I personally do not think that it is a good idea to encourage [3] 
storing MAC addresses in the (public) DNS even though people might 
already be doing that.  It has become difficult to reconcile what a 
proposed standard is about.  I prefer that it does not "mean just 
what I choose it to mean - neither more nor less".

Regards,
-sm

1. 
http://www.canlii.org/eliisa/highlight.do?language=en&searchTitle=British+Columbia&path=/en/bc/bcca/doc/2005/2005bcca334/2005bcca334.html
2. http://www.priv.gc.ca/media/sp-d/2011/sp-d_20110125_pk_e.asp
3. I could not find an appropriate word.

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 May 2013 21:06:53 -0400

--On Monday, May 20, 2013 19:49 -0400 Rob Austein
<[email-masked]> wrote:

>> but, given that the RR space is not unlimited even though it
>> is large, wouldn't it be better to have a single RRtype for
>> IEEE-based EUIs with a flag or other indicator in the DATA
>> field as to whether a 48 bit or 64 bit identifier was present?
> 

Rob,

I've reread 5507 and did so again before writing my second note
today.  I don't see that it helps.

I haven't heard anyone proposing use of TXT (or any existing
RRTYPE) instead, so that is presumably a non-issue.

The discussion in 3.1 clearly applies to relatively complex
schemes like NAPTR, but it is not clear that it has anything to
do with this case.  In particular, if I correctly understand the
IEEE's allocation scheme for longer identifiers (and I may not)
than a given device gets only one -- this is not analogous to a
dual-stack IPv4/IPv6 arrangement -- and an application gets back
whatever it gets back (whether the query is addressed to the
DNS, read off a label on the device and entered manually, or
something else).  If so, then one RRTYPE with the appropriate
identifier in the data is the right answer.   

If not... if, for example, different types of applications will
look for only one type-length of identifier and will either find
it or give up (not try falling back to the other because that
would make no sense), then the use of two RRTYPEs is entirely
reasonable.  But, if that is the case and this is going to be
standards track, I expect to see an explanation in the document.
That explanation could be as simple as a statement to that
effect and an example or two of the types of applications that
would use each identifier and/or a reference to IEEE materials
that describe the circumstances under which one example or the
other is used.

I'm not opposed to having two separate RRTYPEs -- I just want to
see the rationale.  And what passes for use cases in the draft
appears to me to be  completely silent on that issue.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 May 2013 13:42:24 +1200

> appears to me to be  completely silent on that issue.

Especially since there is an IEEE-defined method for representing
a 48-bit address in the 64-bit format. Now you mention it, why can't
that be used in all cases?

    Brian

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 May 2013 21:53:50 -0400

Hi,

> identifier in the data is the right answer.

If you are getting an address to connect with a device on an Ethernet
link, you just have to know what the right address size is. After
whatever start of frame mark there is, it is just DA-SA and using the
wrong size MAC addresses isn't going to work.

Thanks,
Donald

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 May 2013 00:48:47 -0400

--On Tuesday, May 21, 2013 13:42 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
>> I'm not opposed to having two separate RRTYPEs -- I just want
>> to see the rationale.  And what passes for use cases in the
>> draft appears to me to be  completely silent on that issue.
> 
> Especially since there is an IEEE-defined method for
> representing a 48-bit address in the 64-bit format. Now you
> mention it, why can't that be used in all cases?

I think that just proves the point I was trying to make while
stumbling around in ignorance.  No need at all for two RRTYPEs
or even for an indicator in the data other than IEEE's own
methods.  Or do I misunderstand your comment?

   john

---

From: Rob Austein <[email-masked]>
Date: Tue, 21 May 2013 01:03:59 -0400

> today.  I don't see that it helps.

I was mostly referring to the discussion in section 3.1.

> reasonable.

The usual criteria are:

- Does the entire set of records need to be retrieved as an atomic
  unit (eg, to avoid internal consistency problems)?  If so, it should
  be a single RRset, thus a single new type.

- If there's no internal consistency requirement, might an application
  reasonably want to retrieve only one flavor of data (eg, 48-bit EUIs
  in this case)?  If so, multiple RRsets make more sense, thus
  multiple new types.

- Is the total size of an RRset likely to be large if all cases are
  lumped into a single type?  If so, multiple new types might be
  better, because large RRsets are a problem (amplification attacks,
  message truncation, DNSSEC verification failure due to truncation,
  etcetera ad nausium).

If none of the above apply, it's mostly a matter of taste.  My own
bias is against sub-typing, both because we've been burned before by
misguided (albeit well-intentioned) use of sub-typing and also
because, other things being equal, I prefer the simplest RDATA
structure that will get the job done (parsing code for this stuff is
often written in low-level languages which make stupid coding mistakes
all too easy, so, other things being equal, I prefer to reduce the
number of gratuitous opportunities for code exploits).

But if there really is no reason to expect that an application
retrieving EUIs have any sane need to say it only wants the 48-bit
ones or whatever, then a single RR type may be appropriate.  I don't
understand the intended uses well enough to have an informed opinion.

> But, if that is the case and this is going to be standards track, I
> expect to see an explanation in the document.  That explanation
> could be as simple as a statement to that effect and an example or
> two of the types of applications that would use each identifier
> and/or a reference to IEEE materials that describe the circumstances
> under which one example or the other is used.
> 

Fair enough.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 May 2013 23:38:41 -0700

> that be used in all cases?
two observations

If you have an iab range the eui label would get inserted in the middle 
of the IAB base value iirc. that sounds sort of appauling to read/decode.

Second it's not just a representation it's an encapsulation (you could 
if you so choose use a mac-48 on an eui-64 supporting link layer 
legitimately using the encapsulation).  I'm sure some ugly bridge device 
that I want nothing to do with will do that some time in the future, it 
does therefore seem slightly desirable to render them as they are rather 
than in some canonical form that is both.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 09:36:30 -0400

> that the second option (a shared secret) is sufficient.
And yet, multifaced DNS is also a bad idea, and probably not the sort of 
thing that IETF should encourage with a MUST.

Publishing EUI-XX addresses in the DNS is a bad idea.

I get the impression that we're bending over backwards to try to create 
new security risks with this document, and people are trying to justify 
it by citing freedom to innovate.      IMO, that's not the kind of 
"innovation" that IETF should be endorsing.

Keith

---

From: Joe Abley <[email-masked]>
Date: Tue, 21 May 2013 10:04:10 -0400

> Publishing EUI-XX addresses in the DNS is a bad idea.

With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call.

There has been very little review of the actual specification in this thread to date.

RRType assignments are made based on expert review, not IETF consensus, document published, or any other criteria. In this case, the RRTypes have been assigned and are known to have three independent implementations. I'm not sure how the Internet benefits from not publishing a specification in a sensible place (and the RFC series is surely the most sensible place). *I* think it's a good idea for this specification to be published as an RFC.

The topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential. This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that.

> I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate.      IMO, that's not the kind of "innovation" that IETF should be endorsing.

I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 10:18:41 -0400

> With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the…

The criteria for Proposed Standard are quite a bit higher than that.   
See RFC 2026 section 4.1.1.

> TThe topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential.

Assignment of the RR types (though IMO unfortunate) is a separate 
issue.    Granting Proposed Standard status would essentially be an 
endorsement of this practice by IETF.

> This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that.
>

Perhaps Informational or Experimental would be a better label for this 
document, then.

Keith

---

From: Joe Abley <[email-masked]>
Date: Tue, 21 May 2013 10:30:41 -0400

On 2013-05-21, at 10:18, Keith Moore <[email-masked]> wrote:

> Perhaps Informational or Experimental would be a better label for this document, then.

Informational was my original plan; I was persuaded by Some People that the standards track was more appropriate. As I mentioned, my objective is simply to publish the specification.

If the community is more comfortable with the publication objective being met with informational rather than standards track, I'm fine with that.

Joe

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 May 2013 11:06:52 -0400

--On Tuesday, May 21, 2013 10:04 -0400 Joe Abley
<[email-masked]> wrote:

> RRType assignments are made based on expert review, not IETF
> consensus, document published, or any other criteria. In this
> case, the RRTypes have been assigned and are known to have
> three independent implementations. I'm not sure how the
> Internet benefits from not publishing a specification in a
> sensible place (and the RFC series is surely the most sensible
> place). *I* think it's a good idea for this specification to
> be published as an RFC.

Joe, as the person with the dubious distinction of having
started this thread when the Last Call was announced, I'm not
questioning the desirability of good documentation of any
RRTYPE, nor do I doubt the fact that these were properly
assigned and are deployed.  I also agree with you that questions
about the expert review process belong elsewhere (and I don't
know that I'd want to change it in any formal way).

Had you written this document as a "this is how it is -- this is
to tell the community about what is deployed" informational one
that described the RRTYPEs and asked that it be published as
Informational, I wouldn't have been likely to raise any
objections.  Had the Security Considerations section or privacy
discussion described the risks, possibly explained how they
might be mitigated, but basically said "if those are a big
enough problem for you, don't use this facility", that wouldn't
have been a problem for me: I can't speak for Keith, but you
might have not heard from him either.

But the document has been Last Called as an Proposed Standard,
not that type of informational document.  That, at least to me,
makes both discussions of your design decisions and the relevant
security and privacy mechanisms entirely appropriate because
Proposed Standard requires IETF consensus approval of the whole
package, quite independently of your ability to register a new
RRTYPE (or two or three).   All I'm asking for is that, if you
want this as a Proposed Standard you carefully and convincingly
describe your design rationale.  I want that both because it
seems generally appropriate in this case and because, if someone
comes along and wants to register the EUI64-with-embedding or
EUI-with-48-64-switch RRTYPEs and there is pushback because
EUI48 and EUI64 are already registered, I think it is important
that pushback be based on documented and well-reasoned design
choices, not an appeal to the supposed authority of the IETF.  

You wrote a bit later:

> Informational was my original plan; I was persuaded by Some
> People that the standards track was more appropriate. As I
> mentioned, my objective is simply to publish the specification.

It might be that no one could know before this discussion
started but, at least in retrospect, those Some People may have
steered you in the wrong direction if your goal and theirs was
to get something published without putting various design
decisions into the spotlight.  To say what Keith may be saying
in different language, there is lots of stuff floating around
the Internet of which the IETF might not approve.  Publishing
Informational RFCs containing descriptions of them so they can
be understood is still a good thing.  If someone wants to follow
those RFCs with "considered harmful or at least disgusting"
commentary and try to get it published, that is a separate
issue.  But asking for Proposed Standard is a rather different
matter because it requires an IETF consensus assertion that the
criteria of RFC 2026 have been satisfied.   

If you don't think that level of scrutiny is appropriate for
this situation, ask that the document be pulled from Last Call,
review it to make it as descriptive and declarative as possible
rather than even implicitly normative (I'd have to reread, but I
think it is at least close on that criterion), and then resubmit
it as an individual or independent submission for Informational
publication.

> I have no real idea where you get that impression. The goal of
> this document is to document the use of RRTypes that have
> already been assigned, to provide a more structured option for
> encoding data that is already published in the DNS using
> non-interoperable and clumsy encoding schemes. Nothing more.

Ok.  That, to me, is a perfect recipe for an Informational
document.  It may, separately, be a call for a much more
aggressive denunciation and deprecation of overloaded and
trickily-encoded TXT RRs than RFC 5507 provides, maybe as a BCP
rather than IAB-Informational but that is also a separate issue
and problem.

best,
   john

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 May 2013 22:23:03 +0700

joe,

i have read the draft.  if published, i would prefer it as a proposed
standard as it does specify protocol data objects.

< where you goin' with that gun in your hand? >
i am not at all sanguine about the issues raised in the in sec cons.  i
accept that NTRE038D may have asked that these be in the dns, but seems
to me that it is ill advised and some other means to meet their actual
needs might be found.  e.g. what's the matter with logs?

nits you are welcome to ignore.

1 - intro - do we have a standard way to refer to the dns specs as tuned
    	    in 42 subsequent rfcs since 1035?

3.2 and 4.2 the presentation format specs might be simpler if the
    	    examples in 5 were moved there

6 - the example use case is as much or more a motivation as an example

randy

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 May 2013 11:40:24 -0400

Not related to the draft as such (whose publication, incidentally, I
support):

>     	    in 42 subsequent rfcs since 1035?

Alas, no.  Some time ago, DNSEXT was re-vivified in an effort to write
a "protocol profile" that would have been a nice roll-up document to
do this.  But there was no energy to get the work done and the drafts
languished for months without any changes.  It still seems a
worthwhile project, but there is no evidence that we have a population
interested enough to do the work.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Tue, 21 May 2013 08:46:45 -0700

On 5/21/13 8:06 AM, John C Klensin wrote:
>
>    All I'm asking for is that, if you
> EUI48 and EUI64 are already registered,
It seems like we're still re-arguing the assignment of the rr-types. It 
doesn't seem like future assignments are likely to have anymore pushback 
than present.

With respect to the question of proposed standard. What changes if the 
requested status is informational?

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 11:50:29 -0400

> requested status is informational?

I think just get rid of the normative language - SHOULDs, MUSTs, etc.

Given that the RR types have already been assigned, documenting them 
seems entirely appropriate.

Keith

---

From: Joe Abley <[email-masked]>
Date: Tue, 21 May 2013 11:52:46 -0400

On 2013-05-21, at 11:50, Keith Moore <[email-masked]> wrote:

>> With respect to the question of proposed standard. What changes if the requested status is informational?
> 

From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability.

I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document?

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 11:56:13 -0400

> I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document?

2119 language is intended to describe requirements of standards-track 
documents.    Informational documents cannot impose requirements.

Keith

---

From: Joe Abley <[email-masked]>
Date: Tue, 21 May 2013 11:57:28 -0400

On 2013-05-21, at 11:56, Keith Moore <[email-masked]> wrote:

> 2119 language is intended to describe requirements of standards-track documents.    Informational documents cannot impose requirements.

Then I think we've just identified a reason why this document should be on the standards track.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 12:02:23 -0400

> Then I think we've just identified a reason why this document should be on the standards track.
Actually I think that what we need is a BCP that says that DNS is not 
intended, not designed, and SHOULD NOT be used for dissemination of any 
information that is not deemed acceptable for widespread public 
distribution.   Neither the DNS protocol nor DNS implementations are 
designed to meet the security requirements of such applications, and DNS 
is too widely deployed to change that.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 May 2013 12:08:10 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> 2119 language is intended to describe requirements of
    Keith> standards-track documents.  Informational documents cannot
    Keith> impose requirements.

i think using 2119 language in informational documents is often
appropriate and there are certainly plenty of examples of informational
documents that use 2119 language.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 May 2013 09:08:31 -0700

On May 21, 2013, at 8:56 AM, Keith Moore <[email-masked]> wrote:

> 2119 language is intended to describe requirements of standards-track documents.    

Can you support that statement with a reference to an RFC or an IESG statement that supports it?

> Informational documents cannot impose requirements.

Same request.

I don't find either statement supported by RFC 2119 or 2026, or any updates to the latter, but I may have missed it.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Tue, 21 May 2013 12:08:41 -0400

On 2013-05-21, at 12:02, Keith Moore <[email-masked]> wrote:

> Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution.   Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that.

I'd be quite happy to work on such a document if there were others keen to contribute, review, etc, but I don't see it as anything specific to the specifications under discussion here.

What am I missing?

How is EUI48 more dangerous to the world than (say) TXT or NSAP?

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 12:23:44 -0400

The scope of RFC 2119 is clearly standards-track documents.  Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document.

Sent from my iPhone

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 May 2013 09:30:58 -0700

On May 21, 2013, at 9:23 AM, Keith Moore <[email-masked]> wrote:

> The scope of RFC 2119 is clearly standards-track documents.  

I'll take that as a "no". The "scope" is mentioned exactly once, in the abstract but not in the body of the document. 

> Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document.

I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG. The fact that there none of the updates to RFC 2026 even mention this suggests that there was not IETF consensus to the opinion.

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 May 2013 12:51:32 -0400

--On Tuesday, May 21, 2013 08:46 -0700 joel jaeggli
<[email-masked]> wrote:

>> want this as a Proposed Standard you carefully and
>> convincingly describe your design rationale.  I want that
>> both because it seems generally appropriate in this case and
>> because, if someone comes along and wants to register the
>> EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and
>> there is pushback because EUI48 and EUI64 are already
>> registered,

> It seems like we're still re-arguing the assignment of the
> rr-types.

I, at least, am not.

> It doesn't seem like future assignments are likely
> to have anymore pushback than present.

Unless you are going to join the group that says it is perfectly
ok to have multiple IETF standards-track documents that specify
conflicting ways to do almost the same thing, it seems to me
that pushback against other ways to handle EUI data is inherent
in the standards track designation.  The last time the IETF had
the argument about conflicting standards, I think there was
rough consensus that it was generally a bad idea even if some of
us thought that exceptions might occasionally be desirable.

> With respect to the question of proposed standard. What
> changes if the requested status is informational?

I don't agree with Keith that the removal of the keywords
specified in 2119 is either necessary or sufficient (nor with
the generalization that such language should never appear in
Informational documents).  Like Sam, I think that such language
may sometimes be entirely appropriate to an
informational/descriptive document although I also believe that
it should be used with care.

Since I don't have such an easy solution, answering your
question would require a paragraph-by-paragraph review of the
document, not the more overview-level reading I gave it before
participating in this thread.  Having made that proposal, I feel
obligated to do that reading --essentially an editing pass-- but
only if 

(i) you and Joe are inclined to process the document as
	Informational if the edit is satisfactory  and
	
(ii) it is understood that those edits will almost
	certainly not resolve the security and privacy concerns
	that have been raised, notably by Keith and Brian if the
	simple change to Informational does not do so.

Note that (i) is not a request for a promise or decision, only a
good-faith willingness to move in that direction.   

If I am going to do this, I'd prefer to make a pass and then
sort out residual editorial details off list with Joe and anyone
else who is significantly interested rather than trying to do
editing on this list.  If that seems reasonable and appropriate,
I can commit to getting this done within the next week, maybe
sooner, but not today.

   best,
    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 May 2013 13:32:54 -0400

(Changing Subject lines -- this is about a set of general
principles that might affect this document, not about the
document)

--On Tuesday, May 21, 2013 22:23 +0700 Randy Bush
<[email-masked]> wrote:

> joe,
> 
> i have read the draft.  if published, i would prefer it as a
> proposed standard as it does specify protocol data objects.

I would generally have that preference too.  But it seems to me
that the combination of

	-- RRTYPEs (and a bunch of other protocol data objects
	associated with different protocols) are allocated on
	expert review
		
	-- The fact that those protocol data objects have
	already been allocated is used to preempt IETF
	consideration of issues that normally go into Standards
	Track documents, including the criteria for Proposed
	Standards in 2026.

is fundamentally bad news for reasons that have little to do
with this document or RRTYPEs specifically.  If the combination
is allowed, it provides an attack vector on the standards
process itself because someone can get a parameter approved on
the basis of ability to fill out a template and then insist that
the IETF approve and standardize it simply because it is
registered and in use.    That would turn allocation of
parameters by expert review (and some related issues connected
to "deployed therefore it is ok" -- watch for another note) into
a rather large back door for standardization that could bypass
the 2026 and other less formal criteria, the IETF's
historically-strong position on change control, and so on.

These are not new issues and we have historically dealt with
them in a number of ways that don't require moving away from
liberal allocation policies and toward "the IETF is in charge of
the Internet and has to approve everything".  For example, we
have decided that media types don't have to be standardized
although certain types of names do.  People then get to choose
between easy and quick registration and standardization, but
don't get to use the first to leverage the second.  One could
argue that the pre-IETF (and very early) division between
"system" and "user" port numbers reflects the same sort of
distinction between a high standard for justification and
documentation and much lower ones.

It is possible (although I'm not convinced) that this discussion
should suggest some tuning of the allocation model for RRTYPEs.
Probably that model is ok and we just need to figure out clearer
ways to say "if you want standards track, don't get an
allocation first and try to use that as justification because
you will get a real Last Call anyway and everyone will end up a
little irritated".   Or something else may be appropriate.  But
it seems to me that, as soon as one wants to say "all protocol
parameters or other data values should be standardized" then
allocation models based on expert review are inappropriate.  For
the RRTYPE case, that issue should, IMO, have been pushed with
the relevant WG when the decision to allow expert review was
made (and, again, IMO, that cure would be worse than the disease
because it would indirectly drive more folks toward overloading
of TXT and other existing types).

best,
    john

> i am not at all sanguine about the issues raised in the in sec
> cons.  i accept that NTRE038D may have asked that these be in
> the dns, but seems to me that it is ill advised and some other
> means to meet their actual needs might be found.  e.g. what's
> the matter with logs?

---

From: joel jaeggli <[email-masked]>
Date: Tue, 21 May 2013 10:35:41 -0700

On 5/21/13 9:02 AM, Keith Moore wrote:
>>> 2119 language is intended to describe requirements of 
>>> standards-track documents.    Informational documents cannot impose 
>>> requirements.
> intended, not designed, and SHOULD NOT be used for dissemination of 
> any information that is not deemed acceptable for widespread public 
> distribution.
The basically rules out every internal split  horizon use of DNS in 
existence.

scope matters for this application just as it does for any zone you 
shouldn't be exposing to the outside world.
>    Neither the DNS protocol nor DNS implementations are designed to 
> meet the security requirements of such applications, and DNS is too 
> widely deployed to change that.
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 13:40:55 -0400

> The basically rules out every internal split  horizon use of DNS in 

Indeed.  Things have gotten way too far out of hand.  Again, DNS was not 
engineered for this purpose, and the hacks that people have employed 
like split-horizon DNS do not and cannot fix the underlying problems.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 14:53:40 -0400

On 05/21/2013 12:30 PM, Paul Hoffman wrote:
> I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG.
My recollection is that other ADs were the ones who insisted that 2119 
language not be used for Informational documents.   I was more concerned 
about other things, but I could see their point.

If the document is going to be published as Informational, rewording the 
document to remove 2119 language is my recommendation.  But it's not 
something I feel like making a huge fuss over.

If the document is still being considered as Proposed Standard, 2119 
language would be appropriate.   But I believe that this RRtype is 
fundamentally inappropriate for the standards track.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2013 15:08:22 -0400

Without responding in detail to John's note, I'll say that I agree 
substantially with the notion that the fact that someone manages to get 
a protocol name or number registered, should not be any kind of 
justification for standardization of a document that describes use of 
that name or number.

(For that matter, just because a document describes "protocol data 
objects" is also not a justification for standardization of that document.)

More generally, IETF standardization should not be a rubber stamp.   And 
to the extent that people have that notion, we would do well to 
discourage it.

Keith

---

From: Joe Abley <[email-masked]>
Date: Tue, 21 May 2013 15:24:42 -0400

On 2013-05-21, at 15:08, Keith Moore <[email-masked]> wrote:

> Without responding in detail to John's note, I'll say that I agree substantially with the notion that the fact that someone manages to get a protocol name or number registered, should not be any kind of justification for standardization of a document that describes use of that name or number.

If such a justification was inferred in my document, the problem is presumably my unclear language because no such justification was intended.

(I am very happy for my document to be re-pointed at informational, incidentally, for which wheels are in motion. I will likely leave the normative language in, in the interests of improved interop, and see how far I get.)

Code-points in the RRType registry are assigned by expert review (not simply by "filling out a template" as someone suggested earlier). If the suggestion is that the standards track is not available for any work that involves a code point that was assigned early, then I wonder what process is imagined for any future DNS work which aims at the standards track.

Joe

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 May 2013 12:27:05 -0700

> to the extent that people have that notion, we would do well to

John has raised some excellent points. I tried to raise similar concerns 
on dnsext, albeit much more clumsily, and was told "the code points are 
already assigned, so go away."

There needs to be a happy medium, where getting new RRtypes assigned is 
not as difficult as it used to be, but some thought is given to whether 
or not the proposed solution is the best one, or even a good idea at 
all. It's a hard problem to solve, and I don't claim to know the right 
answer.

Doug

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 21 May 2013 15:42:16 -0400

> historically-strong position on change control, and so on.

John, 
There are basically 3 different kinds of DNS RRtypes, 
	- types that affect the behavior of the DNS protocol and are cached by resolvers, 
	- types that have DATA and are cached by resolvers 
	- meta Types that may affect processing but are not cached. 

DNSEXT in its wisdom has deemed the second group to be "harmless" as far as
DNS is concerned and getting code to store data in DNS is a good thing, thus it is easy to get 
it. Getting code for the other classes requires IETF standards action. 

Documents that describe the DATA types use are encouraged to be published as 
Informational or some other stable reference. 

> documentation and much lower ones.
As I explained DNS RRtype allocation has this separation. 

> of TXT and other existing types).

If the expert thinks an application crosses from DATA space to Control space 
he is expected to reject the application and ask for clarification. 

So far nothing has shown up that crosses this boundary, so there is no problem. 
I will go as far as saying why should there be higher bar for getting a DNS RRTYPE than MIME media type ? 

	Olafur

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 May 2013 03:34:44 +0700

> to the extent that people have that notion, we would do well to 

please leave me off the cc:s of your deep discussions of process and who
has the prerogative to do what.

i am merely reviewing the draft for content, not drm and ietf sausage.

randy

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 May 2013 16:51:05 -0400

--On Tuesday, May 21, 2013 15:42 -0400 Olafur Gudmundsson
<[email-masked]> wrote:

> DNSEXT in its wisdom has deemed the second group to be
> "harmless" as far as DNS is concerned and getting code to
> store data in DNS is a good thing, thus it is easy to get  it.
> Getting code for the other classes requires IETF standards
> action. 

Seems perfectly reasonable

> Documents that describe the DATA types use are encouraged to
> be published as  Informational or some other stable reference. 

Reasonable too.  My problem here, which I hope was clear from
the note from which you quoted, is that a request/document in
the second category was proposed for Standards Track and then
that comments that would be entirely appropriate for a Last Call
on a Standards Track document were essentially rejected on the
grounds that they would require changes to already-registered
RRTYPEs.

>> liberal allocation policies and toward "the IETF is in charge
>> of the Internet and has to approve everything".  For example,
>> we have decided that media types don't have to be standardized

But the request for publication in the Standards Track violates
it.

>> It is possible (although I'm not convinced) that this
>> discussion should suggest some tuning of the allocation model
>> for RRTYPEs. Probably that model is ok and we just need to
>> figure out clearer ways to say "if you want standards track,
>> don't get an allocation first and try to use that as
>> justification because you will get a real Last Call anyway
>> and everyone will end up a little irritated".   Or something
>> else may be appropriate.  But it seems to me that, as soon as
>> one wants to say "all protocol parameters or other data
>> values should be standardized" then allocation models based
>> on expert review are inappropriate.  For the RRTYPE case,
>> that issue should, IMO, have been pushed with the relevant WG
>> when the decision to allow expert review was made (and,
>> again, IMO, that cure would be worse than the disease because
>> it would indirectly drive more folks toward overloading of
>> TXT and other existing types).
> 
> If the expert thinks an application crosses from DATA space to
> Control space  he is expected to reject the application and
> ask for clarification. 

We are agreed that isn't an issue here.

> So far nothing has shown up that crosses this boundary, so
> there is no problem.  I will go as far as saying why should
> there be higher bar for getting a DNS RRTYPE than MIME media
> type ? 

With the understanding that I don't think it has anything to do
with this situation, one could justify a different (and maybe
higher) bar in two ways.  First, the media type names are
structured so that, a few historical exceptions aside, one can
tell what category they are in by looking at the names.  To get
that effect with RRTYPEs, one would have to take the categories
you spell out about and create (as a silly example) type names
starting in "1" for the first category, "2" for the second, and
so on, or otherwise lexically distinguish the second category
from the other two.  Second, the potential code space for media
types may be a tad larger than the potential RRTYPE code space.
But, again, I think the question is irrelevant here -- I've not
advocating changing the allocation rules, only keeping the
relationship between already-allocated RRTYPEs and the Standards
Track into the categories you have described above.

--On Tuesday, May 21, 2013 15:24 -0400 Joe Abley
<[email-masked]> wrote:

> Code-points in the RRType registry are assigned by expert
> review (not simply by "filling out a template" as someone
> suggested earlier). 

I was the one who said "filling out a template"  and that
reflects a bad attitude toward many expert reviews.  That
attitude and what underlies it has nothing to do with this
situation.

> If the suggestion is that the standards
> track is not available for any work that involves a code point
> that was assigned early, then I wonder what process is
> imagined for any future DNS work which aims at the standards
> track.

Presumably the same mechanism that has now been used for other
registrations that are normally expert review (or less) but that
interact with standards-track work:  one develops a
specification normally, puts it through the standards track, and
only then asks IANA to register the relevant parameters (and
either asks or directs the expert to sign off).  If the existing
RRTYPE registration rules prohibit that, I would suggest they
are badly broken but I can't imagine how they could be written
to specify such a prohibition.  

One could argue that all of our "expert review" procedures
should say "expert review except where the standards track is
used for other reasons" but the application of good sense says
that the expert should either consider the IETF Standards Track
review adequate and sign off or should be screaming loudly about
the deficiencies during Last Call.

Once more, the only important thing I'm objecting to here is
registering the RRTYPEs using the expert method, then asking for
Standards Track publication, then responding to Last Call
comments by saying something equivalent to "you don't get to
discuss that because these types are already registered".    I
think one can either say "standards track is not needed, publish
the description of the types as Informational" or that there is
an obligation on whomever is proposing standards track to figure
out how to make the review process work properly and without the
existing registrations being considered as a constraint.   I
don't think that is very complex or unreasonable.  YMMD.
 
    john

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 May 2013 15:35:31 +0900

> I think just get rid of the normative language - SHOULDs, MUSTs, etc.

that is orthogonal to info/ps

next unnecessary rathole, please

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 May 2013 15:42:55 +0900

joe,

i spent time actually reading the document and commenting on it, one was
a substantive comment, at least to me.

any chance you could pull yourself away from the exemplary
anti-productive nitpicking maelstrom for a few minutes and respond?

thanks.

randy

---

From: Joe Abley <[email-masked]>
Date: Wed, 22 May 2013 08:31:07 -0400

Hi Randy,

> standard as it does specify protocol data objects.

Noted, thanks.

It does seem that the main objection to the standards track for this document is that I accidentally erred on the side of running code before the document was last-called. This does seem like a poor reason to move the document to informational, but since my primary goal with this has always been to provide a specification (and since the specification is trivial) it's not especially clear to me why a fight for the standards track would have more than semantic benefits.

> < where you goin' with that gun in your hand? >

Going to kill my old lady. Not really.

> needs might be found.  e.g. what's the matter with logs?

I agree it was a strange implementation decision, almost as though more neutral, technical common sense might have been helpful in the process, an unusual situation for a regulator to find themselves in, no doubt. But at this point, it is what it is.

The distaste of many here notwithstanding, the DNS is widely used today as a convenient distributed database for the storage of non-public data. I've had feedback from others who say that they are doing similar things with TXT records, and who welcomed the availability of a specific type, so regardless of the merits of NTRE038D the idea seems to have more general applicability.

The text in the Security Considerations section was a response to concerns raised on the dnsext list that someone might look at the RRType spec and conclude that publishing subscriber (or other privacy-busting) link-layer addresses in the public namespace was something that was desirable or necessary. I don't personally see that as a great concern (I don't think operators are sufficiently naive) but the warning that subsequently appeared in section 8 did not seem inappropriate.

>    	    in 42 subsequent rfcs since 1035?

No, as Andrew mentioned.

>    	    examples in 5 were moved there

Good idea.

> 6 - the example use case is as much or more a motivation as an example

It was certainly the motivation for the draft; the ugly and varied RR schemas used made me reach for grep to find the sensible way to store MAC-48 addresses in the DNS; there wasn't one. In a brief moment of spring-cleaning fervour I decided to try and make things better for the next person who has to parse this kind of stuff.

I could just as well have made that section title "Motivation for Bothering" but "Example Use Case" seemed like a better fit for the context I imagined future readers might have.

Joe

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 May 2013 22:03:54 -0400 (EDT)

> From: John C Klensin <[email-masked]>
> 
> My problem here, which I hope was clear from

This seems to be the only truly controversial point, and it is very
important.  The IETF does not promote something to a standard just
because someone (or even lots of people) are already doing it.

It is, however, perfectly acceptable to document it, and even to
document that some other group has anointed it as a standard within
*their* practice.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 May 2013 22:03:24 -0400 (EDT)

> From: Keith Moore <[email-masked]>
> 
> > With respect, *my* question as the author of this document is
> > simply whether the specification provided is unambiguous and
> > sufficient. It was my understanding that this was the question
> > before the community in this last call.
> 

Coming into this from the outside, the issues are interesting.

I originally thought RRTYPEs are scarce, since all the ones I was
aware of are less than 256.  But it turns out that RRTYPEs are 16 bit
integers, and we've only consumed about 110 of them in ~25 years; we
have about 15,000 years' supply of them.  So they can be handed out
rather generously.

There actually is a standard for allocating RRTYPEs, which is RFC 6195
(section 3.1).  RRTYPEs are to be handed out rather freely.

OTOH, the standards for Proposed Standard are stricter.

In regard to the question of whether to use one RRTYPE or two, it
seems that the question is whether, in practice, it is common to want
to query for both EUI-48 and EUI-64 for the same domain name at the
same time.

In regard to *how* to subtype a single RRTYPE, the resource records
themselves contain a "DATA length" field (RDLENGTH, see RFC 1035
section 3.2.1), so if we used only one RRTYPE, the RDLENGTH field
would differentiate EUI-48 from EUI-64.

There are 768 RFCs that have INFORMATIONAL status and contain the word
"MUST" -- and that is over 10% of the total number of RFCs published
to date.  So it looks like RFC 2119 terminology is commonly used in
informational RFCs.  Personally, it seems like a good idea.  If you
want to notify the world of a privately-developed protocol, you want
to be able to say MUST and SHOULD; labeling it as INFORMATIONAL makes
clear that the IETF hasn't endorsed the protocol.

Dale

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 22 May 2013 22:44:10 -0400

> (section 3.1).  RRTYPEs are to be handed out rather freely.

Obsoleted by RFC 6895 but not too much change.

Thanks,
Donald

---

From: joel jaeggli <[email-masked]>
Date: Mon, 27 May 2013 08:40:58 -0700

>    <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> as Proposed Standard

I would direct the attention of the commentors to draft 04

http://www.ietf.org/internet-drafts/draft-jabley-dnsext-eui48-eui64-rrtypes-04.txt

Which addresses concerns expressed in IETF last call over the intended 
status.

It also incorporates edits proposed by John Klensin in his review.

Notes: from the author:

  - changed intended status to informational

  - incorporation of John's suggestions in the Terminology section, to indicate that we're using 2119 keywords even though this is not a standards track document

  - added a couple of sentences to the security considerations sections to underscore the fact that this document specifies optional mechanisms that people might well not use if privacy considerations dictate otherwise

> sent to [email-masked] instead. In either case, please retain the
> Abstract
>     48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
>     Unique Identifiers (EUI-64) are address formats specified by the IEEE
>     for use in various layer-2 networks, e.g. ethernet.
>
>     This document defines two new DNS resource record types, EUI48 and
>     EUI64, for encoding ethernet addresses in the DNS.
>

>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-jabley-dnsext-eui48-eui64-rrtypes/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 May 2013 08:54:21 +0900

while i appreciate joe's listening to my other comments on the draft, i
still strongly object to publication of this draft as an rfc for the
reasons made very clear in the sec cons.  please read the summary
section of rfc 2804.

randy

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 28 May 2013 00:09:36 -0400

> reasons made very clear in the sec cons.  please read the summary

While the RFC should not be materially misleading, I don't think there
is a requirement for Informational RFCs to guarantee any particular
level or security or privacy.

RFC 2804 is about the security of communications content, not the
security of statically stored address information. I'm not denying the
applicability of some security considerations, I'm just saying that
RFC 2804 doesn't seem to me to be particularly applicable. In any
case, the final part of the summary section of RFC 2804 calls for the
publication of specifications that might affect security.

Thanks,
Donald

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 May 2013 15:42:37 +0900

> level or security or privacy.

that the draft now tries to slide by as info does not change that it
specified protocol elements and how they are to be used.  and the draft
makes very clear that this is juristiction specific and a serious
privacy problem.

> RFC 2804 is about

i am very well aware what 2804 contains

> RFC 2804 doesn't seem to me to be particularly applicable.

i disagree.  i believe the first two bullets in section one are very
applicable to joe's draft.

   - The IETF, an international standards body, believes itself to be
     the wrong forum for designing protocol or equipment features that
     address needs arising from the laws of individual countries,
     because these laws vary widely across the areas that IETF standards
     are deployed in.  Bodies whose scope of authority correspond to a
     single regime of jurisdiction are more appropriate for this task.

   - The IETF sets standards for communications that pass across
     networks that may be owned, operated and maintained by people from
     numerous jurisdictions with numerous requirements for privacy.  In
     light of these potentially divergent requirements, the IETF
     believes that the operation of the Internet and the needs of its
     users are best served by making sure the security properties of
     connections across the Internet are as well known as possible.  At
     the present stage of our ignorance this means making them as free
     from security loopholes as possible.

randy

---

From: SM <[email-masked]>
Date: Tue, 28 May 2013 00:30:24 -0700

Hi Donald,
>level or security or privacy.

Yes.  In my opinion a best effort is preferable or else the Security 
Considerations section in RFCs is useless.

In theory the IETF does not publish RFCs to suit the regulations of 
one country (see use-case in 
draft-jabley-dnsext-eui48-eui64-rrtypes-04).  In practice, the IETF 
has published a RFC to suit the requirements (it was a voluntary 
measure instead of a formal requirement) of one country.

draft-jabley-dnsext-eui48-eui64-rrtypes-04 is an odd case.  My guess 
is that the requirements were set because of a problem of 
monopoly.  I have not looked into whether the transfer of data 
violates the expectations of the user.  I understand that the draft 
is about standardizing [1] a data format and not the transfer of 
data.  Section 8 of the draft says everything correctly except that 
it doesn't provide adequate security guidance.

I believe that Joe tried to do the "right thing".  I am not 
comfortable objecting to publication as I don't know the "path 
forward".  I personally would not support publication.  That can 
easily be overcome and I won't do anything about it.

Regards,
-sm

1. I did read Section 2 carefully.

---

From: Joe Abley <[email-masked]>
Date: Tue, 28 May 2013 06:12:08 -0400

On 2013-05-28, at 3:38, SM <[email-masked]> wrote:

> In theory the IETF does not publish RFCs to suit the regulations of one country (see use-case in draft-jabley-dnsext-eui48-eui64-rrtypes-04).  In practice, the IETF has published a RFC to suit the requirements (it was a voluntary measure instead of a formal requirement) of one country.

Note that there's no suggestion that these RRTypes are required by the
CRTC. The example given was for a situation where Interop would have
been beneficial (so that cable resellers have an obvious, stable and
supported way of encoding this kind of information.

> draft-jabley-dnsext-eui48-eui64-rrtypes-04 is an odd case.  My guess is that the requirements were set because of a problem of monopoly.

The opposite actually: cable operators are required to provide access
to subscribers on behalf of third parties in order to promote
competition. There are multiple such cable providers and multiple such
resellers.

(TekSavvy is one such reseller of multiple cable companies' access networks.)

> I have not looked into whether the transfer of data violates the expectations of the user.

The CRTC's decisions are public, and one might hope they would show
their working. The Canadian courts have been pretty protective of user
privacy in general, I would say.

> I understand that the draft is about standardizing [1] a data format and not the transfer of data.  Section 8 of the draft says everything correctly except that it doesn't provide adequate security guidance.

Feel free to point out the gaps, and/or to suggest text.

> I believe that Joe tried to do the "right thing".  I am not comfortable objecting to publication as I don't know the "path forward".  I personally would not support publication.  That can easily be overcome and I won't do anything about it.

Thanks for the thoughtful review.

Joe

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 May 2013 07:56:40 -0400

--On Tuesday, May 28, 2013 15:42 +0900 Randy Bush
<[email-masked]> wrote:

>... 
>> While the RFC should not be materially misleading, I don't
>> think there is a requirement for Informational RFCs to
>> guarantee any particular level or security or privacy.
> 
> that the draft now tries to slide by as info does not change
> that it specified protocol elements and how they are to be
> used.  and the draft makes very clear that this is
> juristiction specific and a serious privacy problem.

Hmm.   I'm not happy with several aspects of the content of the
draft, including the privacy issue.  I'm also not happy with it
as an apparent example of "if one has a piece of information
that needs to be accessible sometimes, put it in the DNS whether
the characteristics of the DNS are a good match for the
information and retrieval requirements or not".   For those
reasons, and because of the principles expressed in RFC2804, I
believe it was completely unacceptable as a Standards Track
document.

Perhaps these RRTYPEs should never have been created and
registered.  If so, the balance between community review and
maximizing the number of things that are registered (and the
resulting avoidance of conflicts) is wrong for RRTYPEs.  That
would imply a need to revisit the registration policy, but it
wouldn't change the status of these two RRTYPEs.

But it seems to me that none of that is at issue at this stage.  

What is at issue, IMO, is whether the Internet is better off
having a couple of RRTYPEs around with no documentation or
having them documented.  Put differently, are these RRTYPEs
sufficiently reprehensible that we would hope to make them
non-interoperable in practice by not telling people how to make
them work.  I believe that would be a bad plan and would violate
principles far more basic than the 2804 ones -- the IETF should
not be setting itself up as the arbiter of what can be deployed
on the Internet if only because we would certainly fail.

If people find these RRTYPEs (or the document) reprehensible,
then let me suggest that they generate an I-D in Applicability
Statement form that identifies them as "Not Recommended" and
generally obscene and to do so and show sufficient consensus
quickly enough to convince the IESG to force a normative
reference to it into this document so they can be published
together.

I also don't see "slide by as info" in this.  Like you, I
opposed making this standards track and saw serious issues with
2804 in that context.  Tuning aside, only two changes have been
made to the document between -03 and -04 and both are intended
to make it clear that the _description_ of these RRTYPEs does
not constitute a recommendation to use them and that, if one has
serious security concerns that outweigh other considerations,
one should not use them (or put EUI-* information into the DNS
in any other way).   That makes the document about as close to
being information about how these RRTYPEs work without
recommending their use as I can figure out how to get it (others
can probably do better, but apparently haven't stepped forward
with text).  It also contains a pretty strong caution about
their use.  I think that is appropriate too.  It stops short of
saying "not recommended" because the latter would imply
standards track (and Joe might not agree).

> i disagree.  i believe the first two bullets in section one
> are very applicable to joe's draft.
 
>    - The IETF, an international standards body, believes
> itself to be      the wrong forum for designing protocol or
>...

In authorizing the publication of an Informational document that
describes how something works for the information of the
community, the IETF is not acting as an "international standards
body" even though it is being consistent with its goal of making
the Internet better by providing documentation that facilitates
interoperability.  The idea of providing registrations for
non-standardized objects has the same goal.  If we were willing
to register only those objects that met our standards-track
criteria, then we would encourage both code point squatting
(seen in many other cases) or kludges that overload existing
code points (as we have seen with TXT RRs) and damaging
interoperability in both cases.  I don't see the issues in
simply documenting things as different and we certainly have a
long tradition of encouraging the RFC Editor to publish that
type of documentation.

best,
   john

---

From: Randy Bush <[email-masked]>
Date: Tue, 28 May 2013 20:58:41 +0900

> having them documented.

there are two solutions to this

randy

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 May 2013 11:17:27 -0400

> there are two solutions to this

Probably more than two if your comment indicates that you agree
that having registered RRTYPEs documented is, on balance, better
than not having them documented:

(1) We can continue along the path of Informational RFC
publication in the IETF Stream

(2) Joe could have submitted the document to the ISE and
requested Informational RFC publication in the Independent
stream.

(3) Joe could post the definitional document on a web site
somewhere that could provide a stable reference and then ask
IANA to incorporate that reference, presumably in URL form,
rather than the name of an I-D in the registry.  If this is a
Canadian initiative, perhaps the Canadian government would like
to provide that location and reference but, clearly, there are
other alternatives.

Did you have something else in mind?

I think the advantage of the first over the other two is that it
promotes a level of review in the community that, a least IMO,
had improved the document and, if we need revisit how RRTYPEs
are allocated, to provide a concrete basis for that discussion.
Once an RFC is published, the broader community is unlikely to
be able to tell the difference between the first and second
although, if we think the second would be better, it suggests
another option for the longer term:

(4) Create an IANA Stream for the RFC Editor through which we
can publish documents that describe protocol parameters that are
registered through lightweight methods and assure stable
references for them, with no approval beyond that required to
accomplish the registration.  If such a stream retained the
requirement to post as an I-D (and conformance to the IETF's IPR
rules), there would still be as much or more opportunity for
community pre-publication review and feedback to the author and
expert reviewers than the independent stream affords.  I have no
idea whether that would be a good idea or not and it would
certainly be too long-term to affect this document, but it is
possible.

Of course, (5), we could retroactively change the registration
procedure and retroactively deprecate these types.  That might
avoid the need to write the Applicability Statement I-D that I
mentioned but, if my reading of trends in the IESG is correct, I
have my doubts.

What, actually, would you propose other than continuing to
complain about the RRTYPEs themselves and what they are intended
to support (which, in case it hasn't been clear, I largely agree
with you about).

best,
    john

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 May 2013 00:18:40 +0900

> Did you have something else in mind?

remove the rrtypes from the registry

---

From: joel jaeggli <[email-masked]>
Date: Tue, 28 May 2013 08:52:25 -0700

> remove the rrtypes from the registry
Unless you're proposing that we change the operation of the registry 
that seems a bit out of scope.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 May 2013 12:08:03 -0400

> remove the rrtypes from the registry

While it's good to see that the Internet Exemplary Taste-enForcers are
alive and well, I would have an extremely strong objection to that
approach.  The DNS Extensions Working Group published an IANA
Considerations document that was explicitly designed to permit
registrations, and this is an example of that procedure working.  If
people had objections to that permissiveness, they didn't express them
when the then-to-be-RFC6895 was last called.  We have shipping
implementations of DNS software that are using those code points.

Removing the types from the registry does absolutely nothing for
interoperation, doesn't actually help any of the privacy concerns that
are being raised, doesn't solve anyone's problem, and sets up the
registry as a crypto-normative repository -- a state of affairs that
several people objected to when we tried to do this explicitly (I
still bear the scars from that lashing).

I am tired of the self-appointed Internet Cops attempting to regulate
the taste of people wanting to use the DNS.  If people don't like the
allocation policy for DNS RRTYPEs, then they are free to spin up a new
DNSTASTE WG and get the policy changed.  I will attend the BoF and
blow raspberries.  But I look forward to the bright future in which
the DNS contains only TXT records, which we retrieve via port 80 or
(if lucky) port 443.

A

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Tue, 28 May 2013 09:41:01 -0700

Hi Joe,
>supported way of encoding this kind of information.

Ok.

>competition. There are multiple such cable providers and multiple such

Yes.

>(TekSavvy is one such reseller of multiple cable companies' access networks.)

Ok.

>Feel free to point out the gaps, and/or to suggest text.

I'll give it a try.  I suggest talking to the Area Director to see 
what's workable.

I would drop Section 6 of the draft as I no longer need a use case to 
get an RRTYPE assignment.  There is a typo for "RRTPES" in Section 
7.  I would start Section 9 with "There are privacy concerns ...".  I 
would replace the third paragraph with:

   The user should be provided with a disclosure statement that clearly
   mentions:

   - How the EUI addresses published in DNS will be used and protected

   - What privacy policies are applicable

   The disclosure statement is to enable the user to make an informed decision
   about whether the disclosure of the information is acceptable considering
   local laws and customs.

I would rename Section 9 as "Privacy Considerations".  I don't know 
what to put in the new Security Considerations section.  Maybe 
"Publishing EUI addresses in DNS lowers the security of the Internet".

Regards,
-sm

---

From: joel jaeggli <[email-masked]>
Date: Tue, 28 May 2013 10:35:10 -0700

On 5/28/13 9:41 AM, SM wrote:
> get an RRTYPE assignment.  There is a typo for "RRTPES" in Section 7.  
> I would start Section 9 with "There are privacy concerns ...".  I 
For some background. The usecase facilitates discussion and 
justification of the draft. It is not about justifying the RRtype (which 
was assigned under the rules of that registry).

It's in there because the sponsoring AD requested it after feedback 
during the dnsext dicussion.

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 May 2013 08:44:08 +0900

> approach.

jck was trying to enumerate alternatives.  he omitted one.  i am not a
particular advocate of any of them, including the above.

but i think the draft in question has very serious privacy issues, and
would like to focus on that, not characterization of the messengers.

randy

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 May 2013 12:25:39 -0400

> would like to focus on that, not characterization of the messengers.

The discussion in the security considerations of the -04 draft appears
to me to acknowledge there are potential privacy issues, and suggests
how to avoid them.  What more would you ask?

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 May 2013 12:36:37 -0400

--On Wednesday, May 29, 2013 12:25 -0400 Andrew Sullivan
<[email-masked]> wrote:

>> but i think the draft in question has very serious privacy
>> issues, and would like to focus on that, not characterization
>> of the messengers.
> 
> The discussion in the security considerations of the -04 draft
> appears to me to acknowledge there are potential privacy
> issues, and suggests how to avoid them.  What more would you
> ask?

At the risk of saying that differently and partially channeling
Joe, would you care to propose specific text?  The sentences
added in -04 are partially mine. If I had been able to figure
out what else to say that would be stronger, constructive, and
not stray into Applicability Statement territory, I would have,
so I'm out of ideas and it is possible that Joe is too.

    john

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2013 16:53:27 +0000

On May 29, 2013, at 12:36 PM, John C Klensin <[email-masked]> wrote:
> If I had been able to figure

Even if you don't have an applicability statement, I don't think it's inappropriate to talk about the context in which the documented protocol is intended to be useful, nor to talk about contexts in which it wouldn't be appropriate.   The document currently is far too restrained in this regard, IMHO.   I would add some text to the introduction, like this:

The DNS Resource Records described in this document have significant privacy implications (see section 8).   They were developed with the intention to use them in [scenario a] or [scenario b] and are likely not to be appropriate in other scenarios.   In particular, they are unlikely to be appropriate for use in DNS zones hosted on globally-reachable servers that will answer any query without any access control mechanism.

I realize this looks a lot like an applicability statement, but the problem with putting an applicability statement in an Informational document is that informational documents are never applicable in the sense of being the standard the IETF recommends to use in a specific case.   As long as you stay away from _recommending_ the use of this specification, I think it's okay to say where its use was envisioned.   Although of course if it was envisioned to be used on the public internet, that wouldn't help.

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 May 2013 12:34:51 -0700

Hi Ted,

> The DNS Resource Records described in this document have significant privacy implications (see section 8).   They were developed with the intention to use them in [scenario a] or [scenario b] and a…

I don't have an objection to adding text along those lines, and I
understand your reasoning.

Would this address the concerns of others who find the draft alarming?

Joe

---

From: SM <[email-masked]>
Date: Wed, 29 May 2013 14:51:51 -0700

Hi Ted,
At 09:53 29-05-2013, Ted Lemon wrote:
>too restrained in this regard, IMHO.   I would add some text to the 
>introduction, like this:
>
>The DNS Resource Records described in this document have significant 
>privacy implications (see section 8).   They were developed with the 
>intention to use them in [scenario a] or [scenario b] and are likely 
>not to be appropriate in other scenarios.   In particular, they are 
>unlikely to be appropriate for use in DNS zones hosted on 
>globally-reachable servers that will answer any query without any 
>access control mechanism.

Here's what I would be told:  Scenario a and Scenario b do not have 
privacy implications as they have been reviewed by a respected 
organization in Canada.  I would also be told that there is an Office 
of the Privacy Commissioner of Canada which is diligent [1].  I will 
also be told that all this has been reviewed diligently by highly 
respected people in the Internet Engineering Task Force.

I still do not plan to raise any objection on the draft.

Regards,
-sm

1. Out of context quote: "One issue being contended with by several 
data protection authorities was whether or not Media Access Control 
("MAC") addresses (manufacturer-assigned codes that allow devices to 
speak to one another), either alone or in combination with other 
information, constitute personal information.  The OPC did not have 
to address this question since it found, as a matter of fact, clear 
examples of personal information collected among the payload data, 
including complete e-mails, user names and passwords, and even 
medical conditions of specified individuals.  However, as in the case 
of IP addresses, the question of whether or not MAC addresses 
constitute personal information is highly contextual and must be 
considered in conjunction with what other information is also 
available to different users in different circumstances.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2013 22:21:46 +0000

On May 29, 2013, at 5:51 PM, SM <[email-masked]> wrote:
> Here's what I would be told:  Scenario a and Scenario b do not have privacy implications as they have been reviewed by a respected organization in Canada.  I would also be told that there is an Office of the Privacy Commissioner of Canada which is diligent [1].  I will also be told that all this has been reviewed diligently by highly respected people in the Internet Engineering Task Force.

I didn't say that I support the draft; just what I think could be done to somewhat mitigate its scope.   My personal (non-hat) feeling about the draft is that if there is something good that will result from documenting these RRtypes, then the draft is worth doing, but if there is no good outcome other than "we documented it," then the document shouldn't be published.   I haven't been following the discussion closely enough to know what good outcome is anticipated as a result of publishing this document.

I hope the responsible AD for this document will not count me as participating in the consensus on this document; it was not my intention in making the suggestion I made to indicate that I favor publishing the document.   Based on the extent to which I _have_ followed the discussion, my position on the document could best be characterized as "trepidatious semi-neutrality, leaning towards opposition."

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2013 22:50:53 +0000

> I hope the responsible AD for this document will not count me as participating in the consensus on this document; it was not my intention in making the suggestion I made to indicate that I favor pu…

Okay, I felt a bit embarrassed about having said this, so I went back and reviewed the justification for bringing this forth as an IETF document.   The stated reason for publishing the document as an IETF document is that there is a regulatory requirement in Canada to implement something like this.   I think that's really thin, and I as an IETF participant, hat off, I oppose the publication of this document.

I think Joe did the right thing in registering the RRtype, and I think Joe should by all means publish this on his personal web site so that people who need to implement this because of the weird requirements of various regulatory bodies can be satisfied in a clean way.   However, I think putting this forward as an IETF consensus document, or as an IETF document at all, does convey the wrong message.

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 May 2013 18:34:30 -0700

Hi Ted,

On 2013-05-29, at 15:50, Ted Lemon <[email-masked]> wrote:

> Okay, I felt a bit embarrassed about having said this, so I went back and reviewed the justification for bringing this forth as an IETF document.   The stated reason for publishing the document as an IETF document is that there is a regulatory requirement in Canada to implement something like this.

No, that's not right (and really, if that's how you read the document at hand then clearly I need to re-write it). Let's review.

The original motivation for requesting code-point assignments for new RRTypes which would facilitate a clean encoding of EUI-48 and EUI-64 addresses in the DNS resulted from my distaste for the evident lack of consistency in approach taken in response to the CRTC's general requirement that cable operators publish this kind of data in the DNS, for internal, authenticated access by resellers of their access networks in Canada.

It's not at all certain or even likely that the CRTC-mandated systems will ever use these RRTypes. That ship has surely sailed. The reason for requesting the code-points was to make future such situations less messy, and more likely to result in DNS schemas (if that's a phrase) that were consistent and parseable.

Code-points were assigned following the documented process, which relies upon expert review. To support that review, I wrote a specification for their use as an I-D (intended status: experimental). Note that by specification I mean a technical description of the encoding and protocol considerations associated with EUI48 and EUI64, and not any kind of applicability statement or guidance for how the RRTypes should be used.

I've had feedback from a small number of people who are already in the habit of publishing MAC addresses in the DNS as part of (as I understand it) inventory management and internal troubleshooting. I take no position here on whether that's a good idea, but I conclude that publishing such data in the DNS happens today, regardless of the availability of the EUI48 or EUI64 RRTypes.

The new RRTypes have since been implemented in the code base of BIND9, NSD, Knot DNS and PowerDNS based on that specification.

After some discussion in dnsext, directly with individual contributors and with Joel as Ops Area AD, the draft was revised. Text was added, including the general use case for storage of this data in the DNS mandated by the CRTC (requested by Joel). The intended status was changed to standards track, since I was told that made sense.

After last-call discussions on this list the intended status was changed to informational, and more textual changes were made.

The stated reason for publishing this draft in the RFC series (I'm stating it now!) is that the RFC series is the most obvious place for anybody to look for a specification about the implementation of these RRTypes. That's it.

So, in summary:

1. There is, I would suggest, a stable specification.

2. Code points are assigned.

3. There are multiple implementations.

4. There are multiple use-cases, and multiple examples of these data types being published in the DNS today (note, I am not suggesting that widespread use is likely or sensible.)

5. It would be useful (I would assert) that the specification can actually be found by people in the future who care about it.

In my mind, this suggests publication of the spec in the RFC series, where it can join other specifications for the encoding of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and ILNP addresses. I may have missed some.

Joe

---

From: SM <[email-masked]>
Date: Thu, 30 May 2013 01:10:35 -0700

At 15:21 29-05-2013, Ted Lemon wrote:
>I didn't say that I support the draft; just what I think could be 
>done to somewhat mitigate its scope.   My personal (non-hat) feeling 
>about the draft is that if there is

I did not read those messages as meaning that you support the draft 
or that there was anything negative.

At 18:34 29-05-2013, Joe Abley wrote:
>The original motivation for requesting code-point assignments for 
>new RRTypes which would facilitate a clean encoding of EUI-48 and 
>EUI-64 addresses in the DNS resulted from my distaste for the 
>evident lack of consistency in approach taken in response to the 
>CRTC's general requirement that cable operators publish this kind of 
>data in the DNS, for internal, authenticated access by resellers of 
>their access networks in Canada.
>
>It's not at all certain or even likely that the CRTC-mandated 
>systems will ever use these RRTypes. That ship has surely sailed. 
>The reason for requesting the code-points was to make future such 
>situations less messy, and more likely to result in DNS schemas (if 
>that's a phrase) that were consistent and parseable.
>
>Code-points were assigned following the documented process, which 
>relies upon expert review. To support that review, I wrote a 
>specification for their use as an I-D (intended status: 
>experimental). Note that by specification I mean a technical 
>description of the encoding and protocol considerations associated 
>with EUI48 and EUI64, and not any kind of applicability statement or 
>guidance for how the RRTypes should be used.
>
>I've had feedback from a small number of people who are already in 
>the habit of publishing MAC addresses in the DNS as part of (as I 
>understand it) inventory management and internal troubleshooting. I 
>take no position here on whether that's a good idea, but I conclude 
>that publishing such data in the DNS happens today, regardless of 
>the availability of the EUI48 or EUI64 RRTypes.
>
>The new RRTypes have since been implemented in the code base of 
>BIND9, NSD, Knot DNS and PowerDNS based on that specification.
>
>After some discussion in dnsext, directly with individual 
>contributors and with Joel as Ops Area AD, the draft was revised. 
>Text was added, including the general use case for storage of this 
>data in the DNS mandated by the CRTC (requested by Joel). The 
>intended status was changed to standards track, since I was told 
>that made sense.
>
>After last-call discussions on this list the intended status was 
>changed to informational, and more textual changes were made.
>
>The stated reason for publishing this draft in the RFC series (I'm 
>stating it now!) is that the RFC series is the most obvious place 
>for anybody to look for a specification about the implementation of 
>these RRTypes. That's it.

The above is what I understood.

>4. There are multiple use-cases, and multiple examples of these data 
>types being published in the DNS today (note, I am not suggesting 
>that widespread use is likely or sensible.)
>
>5. It would be useful (I would assert) that the specification can 
>actually be found by people in the future who care about it.
>
>In my mind, this suggests publication of the spec in the RFC series, 
>where it can join other specifications for the encoding of IPv4, 
>IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and ILNP addresses. 
>I may have missed some.

There was once a case of a specification which had seven 
implementations and the publication path hit the IETF heavy tail.  In 
the current case publication has been requested in the IETF 
Stream.  There are some differences between the IETF Stream and other 
Streams (in my opinion).

On a different thread and obviously in a different context John 
Klensin mentioned that:

   "For example, if we agree on a relaxed registration procedure
    for some protocol parameters, it is not reasonable to later
    turn around and ask that that those parameters be standardized,
    unchanged, because they are already registered (and maybe
    deployed).  For standardization, the IETF generally needs not
    only change control but an opportunity to comment on and affect
    the actual design and specification of whatever is being
    standardized."

RFC 6895 was reviewed by the IETF community.  RFC 6195 was reviewed 
by the IETF community.  I won't claim that I did not read them or 
that I did not have the time to review and comment about the proposals.

How does privacy fit into all this?  Well, that's what the IAB has 
been talking about.

The following objection was posted to the mailing list:

   "- The IETF, an international standards body, believes itself to be

      from security loopholes as possible."

The text I suggested was based on my reading of the above.

Regards,
-sm

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 May 2013 09:09:58 -0400

>>>>> "Joe" == Joe Abley <[email-masked]> writes:
    >> Okay, I felt a bit embarrassed about having said this, so I went
    >> back and reviewed the justification for bringing this forth as an
    >> IETF document.   The stated reason for publishing the document as
    >> an IETF document is that there is a regulatory requirement in
    >> Canada to implement something like this. 

    Joe> No, that's not right (and really, if that's how you read the
    Joe> document at hand then clearly I need to re-write it). Let's
    Joe> review. 

    Joe> The original motivation for requesting code-point assignments
    Joe> for new RRTypes which would facilitate a clean encoding of
    Joe> EUI-48 and EUI-64 addresses in the DNS resulted from my
    Joe> distaste for the evident lack of consistency in approach taken
    Joe> in response to the CRTC's general requirement that cable
    Joe> operators publish this kind of data in the DNS, for internal,
    Joe> authenticated access by resellers of their access networks in
    Joe> Canada. 

okay, fair enough.
Given that the CRTC mandated them, why wasn't the IETF involved earlier?
The regulator really should have reached out to the IETF here.  I'll be
the first to swear at my government for continuing to have ISO think
here.

This seems like a place for the IAB to respond to this regulator, and
in this case, point towards your document and ask why there isn't
someone from the regulator speaking for this.

    Joe> It's not at all certain or even likely that the CRTC-mandated
    Joe> systems will ever use these RRTypes. That ship has surely
    Joe> sailed. The reason for requesting the code-points was to make
    Joe> future such situations less messy, and more likely to result in
    Joe> DNS schemas (if that's a phrase) that were consistent and
    Joe> parseable. 

Then that's even more a reason for the IAB to send the CRTC a letter.
Maybe it's time for a Canadian liason (but then every country will want
one...?), or maybe it is time for a "regulatory liason" to be
created... I dunno.

    Joe> I've had feedback from a small number of people who are already
    Joe> in the habit of publishing MAC addresses in the DNS as part of
    Joe> (as I understand it) inventory management and internal
    Joe> troubleshooting. I take no position here on whether that's a
    Joe> good idea, but I conclude that publishing such data in the DNS
    Joe> happens today, regardless of the availability of the EUI48 or
    Joe> EUI64 RRTypes. 

Did they like the scheme?

    Joe> In my mind, this suggests publication of the spec in the RFC
    Joe> series, where it can join other specifications for the encoding
    Joe> of IPv4, IPv6, NSAP, E.164, X.25, ISDN, ATM, NIMROD, HIP, and
    Joe> ILNP addresses. I may have missed some. 

I agree.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works