https://www.ietf.org/proceedings/98/minutes/minutes-98-lamps-01.txt
HUM: Consensus in the room to suggest this for a future LAMPS WG charter. Nobody immediately volunteered to write or review documents. I volunteered to write documents before the meeting. I don’t recall there being an actual call given that the ADs told us it was future work. My proposal is to amend the BR to read “RFC 6844 as amended by Errata 5029”. We can then revisit it when IETF comes up with something. Nygren’s proposal changed the situation. It is a better way to address the problem now we understand it. I am basing my proposal on IETF process as implemented rather than what it says in the spec. Running code and all that. This is not a LAMPS work item right now because CAA was a PKIX spec and PKIX is closed. From: Ryan Sleevi [mailto:[email protected]] Sent: Tuesday, June 6, 2017 11:01 AM To: Phillip <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029) I believe you may have misunderstood my question. That said, it would be very useful if you could point to such a public message from the ADs. As an IETF veteran, I'm sure you understand this process, but for the sake of the members less engaged in such SDOs, there's two aspects here: 1) Agreement within the IETF that a) The errata fixes a known deficiency or b) The errata represents a significant enough change to be held for a subsequent document update (which would replace the current CAA draft). 2) Creating a subsequent document update b generally happens if something would be a 'breaking' change - resulting in observable differences - while a generally happens if the text, as written, was not implementable or correct. With respect to the Area Directors (ADs), #1 is not blocked on 'finishing the existing LAMPS work first'. Errata gets discussed and confirmed - after all, that's the purpose of maintaining the standards. #2 is blocked on making sure that there are authors willing to edit the specification and make timely and considerate edits, and that there are sufficient participants (of which, as a reminder, anyone can participate) that agree that the document needs update and are willing to contribute to reviewing and correcting it. So while #2 - the production of a new CAA document - may be stalling due to a lack of an editor willing to make the timely edits, or a lack of participation in the IETF (since, as it stands, it's mostly been 4-5 people discussing it), that wouldn't block #1 - the confirmation and discussion of the errata, consensus that it's technically correct and accurate, and worthy of considering. My question remains that it's unclear that you're asking for, Phillip, so I'm hoping you could try to rephrase your question. What would you like the Forum to do? There are several possible ways to read your message: 1) Review the Errata and, within the IETF, express support for adopting it as technically correct (and implementable). 2) Commit to reviewing an updated draft (that you will presumably edit) within the IETF, to express support for progressing on a new I-D that would UPDATE the existing CAA RFCs 3) Support a ballot that requires that Errata 5029 be considered 'as if' #2 had happened, without actually going through the community-driven, consensus-based process that the IETF provides There's probably more readings, but I'm hoping you can clarify your intent. On Tue, Jun 6, 2017 at 10:52 AM, Phillip <[email protected] <mailto:[email protected]> > wrote: It is really very difficult to see how we can do anything in IETF when the ADs are telling us we have to finish the existing LAMPS work first. From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ] Sent: Tuesday, June 6, 2017 10:41 AM To: CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Cc: Phillip <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029) On Tue, Jun 6, 2017 at 10:35 AM, Phillip via Public <[email protected] <mailto:[email protected]> > wrote: This is the update for the CAA errata as approved by Jacob. Please review in case there is another cut n' paste screw up and we can go to a ballot. Do I have a seconder? Could you clarify what you're asking for? You mention a ballot and seconder, but this is just the technical correction. That is, are you looking for folks to review and say "Yes, this addresses the issues" - or are you interpreting it as "Yes, this addresses the issues, and the CABF should make this normatively required" ? For the second half, wouldn't it be more appropriate to endorse support in the IETF to such errata is Accepted/Verified/Held for Document update before going to a CABF ballot?
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
