search

ietf-tools / datatracker

The day-to-day front-end to the IETF database for people who work on IETF standards.
https://datatracker.ietf.org
BSD 3-Clause "New" or "Revised" License
589 stars 359 forks source link

Review handling of draft-iesg state when ingesting non-IETF stream RFCs #6154

Open rjsparks opened 1 year ago

rjsparks commented 1 year ago

At RFC publication, non-IETF stream docs that had draft-iesg state (other than idexists) have their draft-iesg state set to pub.

There are 307 RFCs like this when the issue was opened, the most recent being RFC9361. In this document's case, the IESG state was moved from Dead to Published. It might have been better for the IESG to have put the draft back into the idexists IESG state instead of dead.

Should we change so that, in the future, if an RFC is published on a non-IETF stream, and the draft it came from had draft-iesg state other than idexists, we set the state to idexists? If so, do we migrate the 307 existing RFCs draft-iesg state to idexists as well (and any others that might come into existence as we are discussing this change?

cc: @larseggert, @evyncke, @wkumari

larseggert commented 1 year ago

I think I need more background here - what would be the consequence of making that change?

cabo commented 1 year ago

idexists is weird, because it no longer exists: It has been replaced by the RFC.

rjsparks commented 1 year ago

idexists is weird, because it no longer exists: It has been replaced by the RFC.

The IESG state of idexists is the euphamism for "this document has no IESG state" and exists as an explicit state so that documents can be put back into it. I think it is less confusing to say that the IESG acknowledges that the draft that led to the RFC exists than to risk misinterpretation that the IESG published the draft.

cabo commented 1 year ago

The IESG state of idexists is the euphamism for "this document has no IESG state"

OK, maybe the GUI then should say that (instead of implying that the I-D is still sitting there and maybe even needs some IESG processing).

rjsparks commented 1 year ago

what would be the consequence of making that change?

Not much for the UI, at least right now - we bury the iesg-state when we're displaying non-IETF stream documents, with the exception of RFCs where we have the IESG state block but just provide the RFC name for the state (Information type confabulation for the, um, win?): image I wonder why we show IESG state at all here?

But the real issue is for the future code and for users of the APIs that expose the states. Right now:

>>> Counter([d.get_state_slug('draft-iesg') for d in Document.objects.filter(states__slug="rfc").exclude(stream_id="ietf")])
Counter({'idexists': 2236, 'pub': 307})

The opportunity for someone to make a bad assumption when doing computation over the IESG state of non-IETF stream documents is high. It would be much lower if it was always idexists.

OK, maybe the GUI then should say that (instead of implying that the I-D is still sitting there and maybe even needs some IESG processing).

As above, at the moment we don't leak these slugs to the GUI (I think - if you've found where we do, point at it).

larseggert commented 1 year ago

I'm fine with hiding the IESG state completely here, although we might somehow want to point to the conflict-review where available. (The "Send notices to" bit should move elsewhere, since it's actually not IESG-related.

rjsparks commented 1 year ago

The conflict review is already prominent - in the top block (just above my the earlier screencapture): image

Look at https://datatracker.ietf.org/doc/rfc9361/ to see it all in context.