[cabfpub] Ballot 195 - CAA Fixup is in the DISCUSSION period (ends April 10)

[philliph at comodo.com]

The rules for IETF errata depend on the nature of the change.

Changes to the language that do not affect the technical details may be accepted or rejected. Changes to the technical content are either rejected or ‘held for document update’, that is publication of a new RFC.

This is a change in the technical content so it can’t be accepted as a correction. Discussion in the LAMPS WG indicated that the consensus was to replace the search algorithm completely with one that uses prefixes. Which is obviously going to take some time. Certainly much longer than the BR will take effect.

Hence the need to do the update this way.


When CAA was proposed, the DNS people were insisting that people should define new DNS resource records rather than using prefixed TXT records, hence the need to define CAA as a new record. That position has now collapsed (hooray!). The technical limitation that made this a problem was that a DNS zone is only allowed to contain a CNAME if there are no other records (except DNSSEC). Which is a stupid rule but one that some of the infrastructure enforces (it appears). So the proposal is to use a prefixed record for CAA thus eliding the need to deal with CNAME completely.


> On Apr 10, 2017, at 12:39 PM, Gervase Markham <gerv at mozilla.org> wrote:
> 
> On 10/04/17 17:27, Phillip Hallam-Baker via Public wrote:
>> As I proposed earlier, can we amend this so that instead of saying:
>> 
>> "CAs MUST process the issue, issuewild, and iodef property tags as
>> specified in RFC 6844, although they are not required to act on the
>> contents of the iodef property tag."
>> 
>> We say
>> 
>> "CAs MUST process the issue, issuewild, and iodef property tags as
>> specified in RFC 6844 as updated by errata 4992, although they are not
>> required to act on the contents of the iodef property tag."
> 
> Can you explain how IETF errata work? Surely it must be the case that
> unadorned references to RFC 6844 actually mean "RFC 6844 as updated by
> any errata"? Otherwise, every reference would have to be updated every
> time there was an erratum, which rather defeats the point of an erratum
> process (as opposed to issueing a whole new, fixed RFC).
> 
> Gerv

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170410/45ad13a1/attachment-0003.html>