On the other hand. If the ADs have an issue they can always just rev the RFC.
> On Jul 12, 2017, at 10:54 PM, Phillip via Public <[email protected]> wrote: > > The reason I would like to avoid that is demarcation between IETF and > CABForum. Since it is Prague next week, I can ask the ADs if they have > concerns. They may not but if I was them, I would. > > > > -----Original Message----- > From: Ryan Sleevi [mailto:[email protected]] > Sent: Tuesday, July 11, 2017 1:43 PM > To: [email protected]; CA/Browser Forum Public Discussion List > <[email protected]> > Cc: Paul Hoffman <[email protected]> > Subject: Re: [cabfpub] [Ext] Fixup ballot for CAA > > Is there a reason not to simply include the errata text as an Appendix to the > BRs (thus ensuring the necessary IP protections as well), and then remove > that once/if the CAA document is updated? > > This seems clearer and with one less dependency - namely, on the CABForum > website. > > On Tue, Jul 11, 2017 at 1:30 PM, philliph--- via Public <[email protected]> > wrote: >> So to close on this, I suggest the following that I think meets the >> points raised by both Paul and myself which I think are equally valid: >> >> 1) Reference the IETF Errata in the BR text >> 2) Archive a copy of the errata on the CABForum site >> 3) In the references section of the BR, cite the IETF as the primary >> source and add a link saying ‘archived on' >> >> This is the practice in Wikipedia and it does work pretty well. I >> don’t think this creates any precedents that we might later regret. >> >> >> >> On Jul 11, 2017, at 9:26 AM, Phillip Hallam-Baker >> <[email protected]> >> wrote: >> >> >> >> On Tue, Jun 13, 2017 at 11:26 AM, Paul Hoffman via Public >> <[email protected]> wrote: >>> >>> On Jun 13, 2017, at 8:14 AM, Gervase Markham via Public >>> <[email protected]> wrote: >>>> >>>> On 13/06/17 15:33, Phillip via Public wrote: >>>>> I do not see a good argument for including the text in the BR and >>>>> a good reason not to. >>>> >>>> Well, you may not consider it a good argument, but the >>>> recommendation of ICANN's Principal Technologist is certainly _an_ >>>> argument. >>> >>> This has nothing to do with ICANN, just the IETF. Phill and I each >>> have decades of experience with the IETF processes and their evolution. >>> >>>>> One of the things that we have attempted to maintain is a >>>>> separation of concerns between CABForum and IETF so that CABForum >>>>> does not do protocol and IETF does not do policy. >>>> >>>> Quite so. CAB Forum should not try and define what the erratum says. >>>> This is merely a question of the best way to reference a stable >>>> piece of text. >>> >>> Exactly. Phill is saying that he believes that the text in an erratum >>> is stable, and I'm saying that I hope it is true but wouldn't trust >>> that. To make it clearer, you could put the text in the BR saying >>> "this text matches Erratum 5029 to RFC 6844 at the time this revision is >>> published". >>> >>> Note that Erratum 5029 has not yet been accepted by the IETF. It and >>> the other two submitted by Phill are still in the "Reported" state, >>> not "Held for Document Update". See >>> <https://www.rfc-editor.org/errata_search.php?rfc=6844&rec_status=15&; >>> presentation=table> >>> for the status. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> Public mailing list >>> [email protected] >>> https://cabforum.org/mailman/listinfo/public >> >> >> >> >> _______________________________________________ >> Public mailing list >> [email protected] >> https://cabforum.org/mailman/listinfo/public >> > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
