Re: [dnsext] WGLC: RFC6195bis IANA guidance

[Donald Eastlake <[e-mail]>]

Hi,

On Tue, Jul 3, 2012 at 10:45 AM, Paul Hoffman <[e-mail]> wrote:
> On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote:
>
>>>>   RRTYPE assignments need to say something about the rdata format
>>>>   no longer being subject to change.  Its not for reserving a code
>>>>   point as it will be coded into implementations.
>>
>> DANE thought that they had a code point that they could change the
>> internal structure about at will by going through the allocation
>> process.  They needed to be disavowed of this notion.  This should
>> not happen again.
>
> Mark's sneering is one way to look at it. Another is that, with an RRtype in a mature draft that labelled as TBD, implementers will just pick one and then eventually squat on it, screwing up both the registry and implementations.
>
> Standards-track protocols can be changed all the way through IESG review. Those changes could in fact change the internal structure of the data covered in an RRtype. This leaves exactly two choices:
>
> - Force Internet-Drafts to keep their RRtype as TBD all the way until the IESG passes the Internet-Draft to the RFC Editor

But then the IESG can pull a draft back for the RFC Editor queue and
change it. Or, after it issues as an RFC, they can cause it to be
obsoleted by a revised RFC. Barring another Kobe revolution or the
like, the locus of power in the IETF is the IESG. Anyone who believes
some IANA Considerations in an RFC for an IETF parameter are more
powerful than the IESG is a fooling themselves. However,
notwithstanding that, the IANA Considerations should be something
reasonable that has WG consensus.

> - Allow WGs and document authors to request RRtype assignment earlier in the process and know that there might be a change based on technical review of the document

To avoid squatting and the like and consistent with the idea of making
it generally easier to get an RRTYPE code point, I think this is the
way to go.

There is already provision in the application template to indicate
whether you are submitted for a new RRTYPE or the modification of an
existing RRTYPE. I think about the best we can do is to add some
language like:

"An RRTYPE Allocation Template, indicating that it is for the
modification of an RRTYPE, MUST be submitted when any material change
is made to an existing RRTYPE specification. This includes any changes
that occur in the processing of an internet-draft after initial RRTYPE
allocation and before RFC publication."

> Pick one.

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

> --Paul Hoffman