[cabfpub] FW: [Technical Errata Reported] RFC6844 (5029)

[Ryan Sleevi]

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 <philliph at comodo.com> 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:sleevi at google.com]
> *Sent:* Tuesday, June 6, 2017 10:41 AM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Phillip <philliph at comodo.com>
> *Subject:* Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029)
>
>
>
>
>
>
>
> On Tue, Jun 6, 2017 at 10:35 AM, Phillip via Public <public at cabforum.org>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170606/97619fcf/attachment.html>