Hi Toerless, On Wed, Mar 11, 2020 at 04:17:44PM +0100, Toerless Eckert wrote: > Thanks, Michael > > Brian, > > At IETF106 i thought if Bens review would remove all discuss, we would have > finished IESG review, but that is not the case because two of the > IESG members that had approved ACP draft have since left office, so > their votes do not count. I did report that at ANIMA WG @IETF106. > > At IETF106 we had both the ACP report from me of -21, as well as Ben's > presentation on the main issue he saw, the encoding of the ACP > domain information field in the certificate. > > While i had hoped that the in-person discuss about that issue would > resolve that discuss because we did explain all the argments for it, > his discuss of -21 on 12/30/2019 did i think not change his position,
I had also hoped that, though it did at least give me a better understanding of the situation and the interplay amongst the various pieces. > instead it also mentioned IPsec experts supporting that view, but > without a technical explanation why, or who all those experts where. I think it's more of a matter for PKIX experts (e.g., LAMPS WG) than IPsec, since it relates to X.509 certificate contents. I've asked Russ Housley to take a closer look and produce some comments, and have a todo item to get another expert or two to opine. > In January, i worked on -22 to answer to Bens review of -21. which i > published 02/03/2020. For the encoding issue i rewrote the bullet > points justifying the choice of encoding, primarily pointing to the > fact that rfc822 names are nowadays quite common identifiers in a > lot of e.g.: web systems, in addition to all the benefits of avoiding > new or extensions to certificate parsing libraries and the like. > > Through IETF106 and writeup of -22 i even think more this > is a pragmatic, prudent and logical choice, and i couldn't find > anything in the cert related RFCs i read that seemed to contradict this for > me. I'll also mention again that there are procedures in place that can allow a document to proceed even with a "holdout" Discuss position such as mine: per https://www.ietf.org/standards/process/iesg-ballots/ the sponsoring AD can request the "Single Discuss" procedure be used, or ask the chair to invoke the "Alternate" ballot procedure. > In February, Ben had told me, that -22 resolves his other points, > except that that he continues on his position re. the encoding. > But there was also security profile work improved in -22. I'm very happy to see those improvements and the exchanges with the IPSECME WG; thank you again for driving that! -Ben > Shortly after IETF 106, Eric Vyncke took over as sponsoring AD for > ACP. He provided a review with 72 comments in january to the authors. > After i finished -22, i worked on these 72 points through february and posted > -23/24 last week. > > In addition, during february, i also started to reach out to IPsec > mailing list to further discuss details of the proposed enhancements > to the IPsec profile. I ran out of time last week, and plan to > finalize those fixes quickly (together with the WG fix sugestions i > received for -24). > > In addition, i will also reach out directly to the IPsec experts > i know and ask for the rfc822name encoding. I did that already > last year, but never received replies. > > Eric told me, he wants to put ACP back onto the IESG agenda for April, > and this would result in a new IETF review. > > Thats all i know. > > Cheers > Toerless > > On Wed, Mar 11, 2020 at 09:57:56AM -0400, Michael Richardson wrote: > > > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > > Could those on the hook for the ACP and BRSKI drafts, which have been > > > very seriously delayed, update the WG with the plan for getting them > > > approved? It seems to me that there has been endless nitpicking, of > > the > > > kind that is appropriate for full Standard status, but very surprising > > > for Proposed Standard where there is no expectation of perfection. > > > > I don't know what kind of plan I can relate: It seems to be above my pay > > grade. > > > > For BRSKI, since IETF106, all DISCUSSes, except Ben Kaduk's desire to have > > the examples redone have been cleared. I had originally tagged redoing that > > for AUTH48 time, since all IANA allocations would be done by then. > > All allocations have been done at this point, and in January I redid the > > examples in the non-normative Appendix with the right OIDs. Ben found some > > errors (one repeated certificate), and so I generated the examples again. > > > > I then asked Jim Schaad and Max Pritikin (a BRSKI co-author, who has been > > redirected on other important Cisco work), to validate. Max reviewed, and > > this resulted in an additional clarifiying sentence committed to the github. > > (I thought I posted it on Monday, I don't seem to have. I will do that now. > > > > Warren Kumari has taken over as the sponsoring AD. > > > > > Can we expect these drafts to be approved in the next one or two > > weeks, > > > for example? If not then, when? > > > > I know that ACP has gone through a similar set of DISCUSSes, and I think > > that > > they are mostly all done. > > I don't see an update from Ben. > > > > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/ > > says that most have No Objections, rather than Yes. Three YES are needed to > > override a DISCUSS. > > I guess this document has been in front of the IESG since 2018 when Terry > > was > > an AD! > > > > I think that the WG participants need to actively engage the DISCUSSes and > > the choices that the WG has made. > > > > -- > > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > -- > --- > t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
