On Mon, Oct 21, 2024 at 3:24 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> On Mon, Oct 21, 2024 at 10:46 AM Salz, Rich > <rsalz=40akamai....@dmarc.ietf.org> wrote: > > > > > If the FATT process still has anonymous reviewers, IMO it is > > > still broken. > > > > I had a personal conflict so could only attend the last few minutes of > the meeting but I just watched the video. > > > > I strongly agree with Stephen's opinion quoted above. This particular > issue has been raised MANY times by several participants, both on the > mailing list and in our meetings. There has been no direct response from > the chairs. Why not have a consensus call? > > > > So what is the new process? Surprisingly, it seems little has changed > from the first proposal. Instead of a TLS Chair interacting with the FATT, > there is a Liaison picked by the FATT to interface between the overall FATT > team and the TLS WG and Chairs. Likely to rotate with each document > presented to them. > > > > At 9:30, Sean said they tried to have a middle ground between "complete > radical openness" to "actually getting someone to respond." In reasons to > CPatton's question why there is a need for anonymous reviews, Sean said > that it's not truly anonymous since the FATT membership is known. Also that > most people do not want to know the minutia of IETF processes. (Presumably > that is a comment on FATT membership, not WG membership.) Deirdre says that > all participants through the Liaison will be known but that she says it's > clear they (FATT) do not want to have the discussion in public to disagree > amongst themselves. It gets "gross and grotty" if it's all on a public list. > > > > At WGLC the FATT conclusion, as relayed by the Liaison, will be reported > as part of the Shepherd writeup. The Shepherd write must explain why the > analysis (really an assessment that a security analysis is needed) is being > ignored by the WG if that happens. That also concerns me and feels like > putting a thumb on the scale: "your Chair-picked group of experts says > analysis is needed and you didn't do it." > > > > I think with two fairly small changes, this could be brought into line > with historic IETF processes and philosophy: treat the FATT as a design > team -- one design team per document, if needed -- and drop the shepherd > writeup part. > > I think that's more ramming the new wine into the old wineskins. With > design teams we're usually dealing with a complex mess of inputs that > need a document to come together to crystalize the choices and > ultimately result in an *input* into the usual consensus based WG > process. And as someone working on a document and participating in WGs > WG input can be very difficult to assess, and make use of at times, so > you end up making some decisions just because someone has to > sometimes. But actually contentious issues do get thrashed out. > > RFC 2418 specifically says the output of the design team is subject to > WG consensus. That's not true of the FATT right now: it goes > separately into Shepard Report, comes after WGLC, etc. Doesn't seem to > me that it's within what was contemplated there. And what FATT is > assessing is not a narrow technical thing but a tradeoff between doing > a lot of specialized work, and being comfortable with the introduced > risks. > [Joe] The output of the FATT is input to the working group consensus process. The intent to include information about the FATT review into the shepherd writeup is to inform the IESG that review has taken place similar to other reviews that have taken place on the document. I don't understand how this is out of the ordinary. A large portion of the shepherd writeup is about the consensus process and the reviews that were input to that process. > > Furthermore, as I understand the rational for FATT it's that people > don't feel comfortable participating in the WG. That's a shame, and we > should also try to fix it. I understand we need an interim measure > here, but formal analysis is not the only place where would have this > problem. > > Sincerely, > Watson > > > > > > > _______________________________________________ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
