Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Mar 10, 2011 at 12:08 PM, Samuel Weiler <[e-mail]> wrote:

> Thats a process issue outside my scope :-)
>>
>
> Heh.  Indeed.  :-)
>
>
>       It might be appropriate to skip the IANA registry for the moment.
>> Resubmit the specificcation with no IANA registry
>>      ("here are the two values") and only create the registry in the RFC.
>>
>> That would only change the template, not the draft?
>>
> ...
>
>> I am trying to follow the process as I understand it here and that
>> requires the template to specify the registries the draft proposes to
>> create.
>>
>
> I'm sensitive to the "we don't want to start over from square one". I also
> want to be able to point to a firm "here's the definition of the RRTYPE"
> document.  And I'm concerned that your use of the "Expert Review" IANA
> assignment metric is underspecified in this case.
>
> I was suggesting you take the IANA registry bits out of the draft (for
> now), point to a static-list version of the draft for purposes of RRTYPE
> assignment, and later create a registry for that field (in a subsequent
> revision of the i-d, as it gets closer to publication).
>
> I suppose that's inconsistent, in some ways, with wanting a static
> specification, but it highlights my desire to nail down particular version
> of the i-d which is the definition.
>
> Two alternate ideas are below.
>
>
>  Now what may well make more sense as a process would be to have a two
>> phase scheme in which DNS RR codes are marked 'reserved' in response to the
>> expert review and the final allocation is performed when the RFC is issued.
>> This is effectively what has happened with Stuart Cheshire's Bonjour scheme.
>>
>> But that is not the process we have.
>>
>
> You can still do that: 5395 specifically recognizes that RFC can allocate
> RRTYPES (with no template), including using the RFC420 early allocation
> process.  It sounds like that might be appropriate here, since you plan to
> publish as an RFC -- skip the template and ask for an early allocation.
>
> Another idea: change the IANA assignment metric to one of the more
> thoroughly defined ones like "First Come First Served" or "RFC Required".
>  Those get you away from needing to tell the expert what to look for, though
> with First Come First Served you still should put restrictions on the tag
> field (max length 15 and only numbers and lowercase letters, consistent with
> section 3.1 of the draft).  You can easily change that assignment metric
> later.



Given the size of the tag space, I think either alternative is acceptable as
they will converge on the same effect: Anyone can define a new tag with
minimal risk of collision but it is rather unlikely that tags will be widely
supported or recognized unless they are described in an RFC somewhere.

I suggest RFC required.




>
>
>       Which brings us to the discussion on the list yesterday: the template
>> should really be citing a particular version of the
>>      spec.  It hardly seems fair to ask the expert to approve an RRTYPE
>> based on a reference to a changing document.
>>
>> I think that is unhelpful.
>>
>
> I think of it more from the "let's make sure the record is clear"
> perspective.  In two years, how will I know which version of the document is
> the one that defined this RRTYPE?
>

Well the hope would be that we replace the document with a published RFC by
then.


Now in theory the draft could change in ways that are incompatible with the
wire format proposed here, but if that happens then either there will have
to be a new RR code issued or the RFC should probably not be published.

I really want to get this nailed down much sooner because getting the wire
format settled and set in concrete is a pre-condition to discussing the
lawyer stuff in CABForum.

-- 
Website: http://hallambaker.com/