--On Saturday, March 16, 2024 08:59 +1000 Benoit Claise
<benoit.claise@xxxxxxxxxx> wrote:
>
>
> On 3/16/2024 6:49 AM, Brian E Carpenter wrote:
>> On 16-Mar-24 10:17, Pete Resnick wrote:
>>> Agreed. We really need to have a bit of a general re-think
>>> on what we really want out of these rules instead of (IMO)
>>> silly point-fixes that don't really address the issue.
>>> Re-opening the queue on Sunday is completely
>>> counter-productive if the point was not to have new versions
>>> just before the f2f. (Similarly, the current proposal to
>>> remove the I-D expiry date, which I agree is anachronistic
>>> and not serving its original purpose, is another attempt at
>>> a simple point fix that does not address the original reason
>>> those dates existed.)
>>>
>>> Can we have a go at why we want these mechanisms in the
>>> first place instead of making arbitrary changes?
>>
>> As far as I recall, it was originally intended to ensure that
>> in the face-to-face meeting of each WG, people had all read
>> the same version of each I-D. As hacks to bypass the posting
>> deadline have emerged (with github PRs only being the latest
>> hack), this has become less and less effective. Maybe that
>> battle has now been lost.
>>
>> However, we should consider two other effects of the deadline:
>>
>> 1. Negative: A ridiculously large number of drafts are posted
>> within ~72 hours, as Carsten pointed out recently**. So
>> anybody who tries to track the IETF very broadly is swamped
>> three times a year.
>>
>> 2. Positive: People are deadline-driven. If we didn't have
>> the deadline two weeks before the meeting, the ridiculous
>> number of drafts would be posted... today!
Or Sunday or Monday. I think these are important
considerations, but, again, my hope, like Pete's, is that we can
look at the whole set of issues, not apply isolated patches to
individual real, potential, or imagined problems.
> Let's add a third effect.
> 3. The IETF hackathon positive effect. People start meeting on
> Sat/Sun before the IETF week, discussing the different open
> issues, ideally around code development. Some issues are
> potentially solved during the week-end, leading to new draft
> revisions being posted, as prerequisite for the WG discussion.
> If not posted as a new draft revision, the WG slide deck will
> anyway contain the hackathon findings (which has the same
> positive effect)
Sure. Whether discussions and tests occur at the hackathon or,
as Carsten suggested, there is discussion within a particular WG
-- either one or both leading to a new draft during IETF week
and/or slides that are completed and posted just before the WG
meets (or later). It seems to me that there is a tradeoff
between those sorts of things and, e.g., keeping WGs open and
transparent, inviting newcomers and those who are not paying
careful attention to its work to meaningfully participate, and
interpreting "IETF consensus" as the informed position of a
large fraction of the community. If those latter considerations
are important, then it seems to me that we need to be quite
careful about making participants in some groups --e.g., active
hackathon participants or those who are active and committed
enough to a WG to be watching and thinking about its discussion,
possibly in preference to most others, in the days leading up to
and during an IETF meeting.
I think that is related to a discussion I have had a few times
with one or two others and, AFAICT, concluded that neither of us
is going to convince the other. To state the difference more
extremely than I think either of us has, the most efficient way
for many WGs to do their work and produce a spec is to gather a
small number of like-minded people and proceed to create a
document that reflects their views, cutting off alternate views
and dissenting opinions and discouraging those who hold them
from participating. However accidentally, they may also
announce meetings, post agendas, conduct discussions and provide
meeting summaries in ways that make it difficult or impossible
for newcomers and people who are not very active participants in
the WG to follow what they are doing. From the perspective of
such a tight and efficient group, those other IETF participants
can only add noise to what would otherwise be a quiet, focused,
and efficient conversation. Consequently, that is not a problem
and may be an advantage. When publication is requested on the
documents, they go into IETF LC for two weeks. The fact that is
not nearly enough time for someone with a different perspective,
who was cut off earlier, or has bad intuitions about the work to
dig into the details and write a review that cannot be
immediately refuted by "we discussed that extensively within the
WG and..." is, again from the perspective of that group, not a
problem and may be a disadvantage.
Over time, some AD have been very good about noticing the
disconnects between WGs of that sort and the rest of the
community but then the WG participants complain about the
delays. Other ADs, who have not followed the WG's work and
processes themselves, don't have time to dig in either, and the
work slides through.
The alternative view, again stated extremely, is that WGs should
be actively trying to involve a broad range of interests in
perspectives in their work, carefully considering alternate or
dissenting views in the hope that there is something that can be
learned from some of them, and putting extra effort into
welcoming newcomers and those who are interested, have some
knowledge, but are not able to be heavily involved in the hope
of developing better specs that actually represent IETF
community consensus.
Perhaps neither extreme is completely feasible, but, as with the
more specific issues relative deadlines, it is not clear to me
that we have the balance right even after allowing for different
WGs having different styles of work ... and, coming back to
Pete's point, it is clear to me that we should stop pulling out
micro-problems and applying patches.
The IETF has changed and is changing, it is time to do a
comprehensive review, make some decisions that fully consistent
with each other, and then be open and clear about it.
john
p.s. While written after this note was partially complete,
George's and Jan-Frederik's comments are both good illustrations
of the point that making WG efforts open and transparent to
people who are not primary participants should be important to
the IETF.
