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

[Donald Eastlake <[e-mail]>]

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.

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."

> 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.

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

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

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

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

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> After the applicant posts
> their formal application with their
>    template as specified in
> Appendix A,
> IANA appoints an Expert and the
>    template is posted, with an indication that it is a formal
>    application, to the [e-mail] mailing list.  No
> less than three
>    weeks and no more than six weeks after this posting to
>    [e-mail], the selected Expert shall post a message,
> explicitly
>    accepting or rejecting the application, to IANA,
> [e-mail], and
>    the email address provided by the applicant.  If the
> Expert does not
>    post such a message, the application shall be considered
> rejected but
>    may be resubmitted to IANA.  IANA should report
> non-responsive
>    Experts to the
> IESG.
>
>
>
>
> Mike
>
>
>
> At 02:28 PM 4/14/2013, Paul Hoffman wrote:
>
> On Apr 14, 2013, at 11:17 AM, Michael StJohns <[e-mail]> wrote:
>
>> Rfc6195, section 3.1.2, items 1, 4, and 5 apply.
>
> To a request for an AD to bring the document to IETF Last Call? Where in RFC
> 6195 do you see that? Or did you misunderstand Joel's question?
>
> --Paul Hoffman
>
>
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>