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

[Michael StJohns <[e-mail]>]

At 05:38 PM 4/14/2013, Donald Eastlake wrote:
>RFC 6195 is not in effect. draft-ietf-dnsext-rfc6195bis-05 (RFC-to-be
>6895) is in effect since it was approved last year. It's been held up
>by a dependency but will presumably will pop out early next week since
>it looks like the dependency has cleared.


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


>On Sun, Apr 14, 2013 at 3:22 PM, Michael StJohns <[e-mail]> wrote:
>> Let's try this again.
>>
>> I understood what Joel was asking.  I objected to bringing this to last
>> call.
>
>As below, if the last call is blocked it might block documentation and
>review but will have no effect on the code points.
>
>> You asked where in RFC6195 that there was grounds to object.
>>
>> I pointed out section 3.1.2, items 1, 4 and 5 apply as short hand for the
>> following:
>>
>> Although the allocation template says that the code points were assigned by
>> expert review, its unclear they followed the criteria required by 6145.
>
>They are not "criteria required". They are *guidelines* and the
>overall policy, from RFC-to-be-6895 is "The Designated Expert should
>normally be lenient, preferring to approve most requests."


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

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






>> Given the lack of details, I don't see how an expert could say:
>>
>> (1) that the documentation was complete enough to evaluate.
>>
>> (4) that the document was complete enough to describe any other interactions
>> with DNS - for example publishing the DNS name to IP mapping as part of a
>> DHCP IP address assignment process for the MAC address.
>>
>> and (5) that give the lack of 1 and 4, and the short shrift to "well, we
>> could do it in the text record, but we'd rather not" that it's unclear why
>> this is a global assignment rather than a private one.
>
>As regards the allocation of the code points, it actually does not
>make any difference what you think. The application was submitted. The
>assigned expert has approved. (I am not a member of the expert pool.)
>The code points (108 and 109) have been allocated and are in the
>public RRTYPE registry as of, probably, a couple of week ago, and
>since then anyone in the world has been free to use them:
>   http://www.iana.org/assignments/dns-parameters/dns-parameters.xml
>
>> If this makes it through in the current condition, I would suggest that I
>> could submit a document based on the current document where EUi48 is changed
>> to "breakfast cereal UPC codes" and EUI64 is changed to "Book ISBN codes"
>> with fairly minimal text changes that would ALSO make it through.  And that
>> would be bad.
>
>It seems odd to restrict it breakfast cereal UPC codes, but having an
>DNS RRTYPE for UPC code or ISBN number seems fine to me. Why would it
>be bad to store such things in the DNS? It would provide a way to
>securely associate such numbers with a DNS name.

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

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

But getting back to the current case - 

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

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

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

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



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




>> Hmm.. I went back to the DNSEXT mailing list and I can't seem to find the
>> 6145 mandated application and experts assignment message on the list or in
>> the archives:
>
>See RFC-to-be-6895. Such a message has not been required since the
>approval of RFC-to-be-6895 which is the result of years of effort to
>defeat narrow-minded objections and real and perceived barriers to
>getting new RRtypes for ordinary data (can be handled as an Unknown RR
>as described in [RFC3597]). 


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


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


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

>In my opinion, there is almost never a
>reason to turn down such an RRTYPE request and the rapid approval of
>this request is exactly what is supposed to happen.
>
>I would like to thank the author for taking the step of proposing
>publication of his draft as an RFC, something not required. This
>provides an opportunity for review and, for example, possible
>inclusion of usage guidance or the like.
>
>Experience proves that the "you can't get a number without jumping
>through hoops" mindset leads to lots of overloadings of TXT and people
>just grabbing a random RRTYPE number and camping on it, which I think
>is a worse than, say, allocating some RRTYPE numbers for some data
>which turns out to be not so useful in the DNS.
>
>Thanks,
>Donald
>=============================
> Donald E. Eastlake 3rd   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]