RE: RFC 8252 [Process and reviews]

["Rob Wilton \(rwilton\)" <rwilton=40cisco.com@xxxxxxxxxxxxxx>]

Hi Keith,

 

 

 

From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Keith Moore
Sent: 11 July 2023 16:10
To: ietf@xxxxxxxx
Subject: Re: RFC 8252 [Process and reviews]

 

On 7/10/23 13:14, Rob Wilton (rwilton) wrote:

I think that it is also somewhat hard for ADs in other areas to override (i.e., put a blocking DISCUSS) for a security issue on a document coming out of the SEC area.  I.e., it would have been clear that the experts in the area (i.e., the two SEC ADs) were okay with this being published.  I can’t speak for the SEC ADs at the time, but my general experience whilst I have been on the IESG is that the SEC ADs have always been quite strict on what they will (or will not) accept from a security perspective.

I would like to encourage everyone on IESG to vote DISCUSS on any issue from any area that they have a concern about.  That's what DISCUSSes are for.   I understand that there is sometimes a sense of pressure on ADs to "go along with" WG activities from certain areas.  But cross-area review is essential and IETF itself is not well-structured to facilitate it.  This unfortunately leaves ADs in other areas as the only people outside those areas who read the documents before approval.  And sometimes one area's agenda is not always best for the Internet as a whole.

[Rob Wilton (rwilton)]
Generally, in the current IESG, we do.  Sometimes ADs ballot a “discuss DISCUSS”, i.e., perhaps something that are not an expert on, and hence don’t specifically know that it is wrong, but they want to specifically flag an issue for further discussion – i.e., preventing a document from being approved without some level of discussion having occurred.  Often such discussion happens, concerns are alleviated, and the DISCUSS position is cleared (to Yes or No Objection), and the document progresses.

But my key point is that if the conversation happened, and the security ADs both indicated that they regarded this issue as having been considered (by the WG and themselves), and were happy with the outcome, then I personally wouldn’t feel particularly comfortable continuing to hold a blocking discuss position (to prevent publication of the RFC) for an architecture issue which is really under the jurisdiction of another area.  I.e., even if a discussion had happened, then it is still plausible that the IESG would collectively reach the same outcome, i.e., it is okay for the document to be published.

Sometimes, at least for the current IESG, ADs move to ballot Abstain in this scenario – i.e., they don’t really support the document being published (i.e., they have objections that probably cannot really be addressed by minor changes to the text), but neither will they stand in the way of the document being published.

I will also reiterate a point that I made previously – getting more reviews at IETF LC would be nice, but it is currently hard and those reviews come late in the process causing conflict if they are very significant comments.  Hence, I’m still convinced that it is the BOFs and WG charters that are a more effective way of controlling what a WG is allowed to work on, and to put constraints on what the solution must or must not do.  I.e., if documents reach the IESG that are not in the scope of the WG charter, then it is quite likely that an AD will put a DISCUSS on the document and may delay clearing the DISCUSS until the charter has been updated (allowing an IETF review of the charter changes) to bring the work in scope.  Charters don’t change that frequently, and hence if a participant has  limited time to spend on cross area review, then that may be a good place to focus their time and energy.

Regards,
Rob

 

Keith