datatracker
datatracker copied to clipboard
Updating a subseries when one of its RFCs has been obsoleted
Description
BCP 219 originally contained RFC 8499. It was updated when RFC 9499, which obsoleted RFC 8499, was published. The BCP information is correct on rfc-editor.org (BCP 219 contains only RFC 9499) [1], and in rfc-index.xml [2], but is incorrect on datatracker, which says BCP 219 contains both RFC 8499 and RFC 9499 [3].
[1] https://www.rfc-editor.org/info/bcp219 [2] https://www.rfc-editor.org/rfc-index.xml [3] https://datatracker.ietf.org/doc/bcp219/
Code of Conduct
- [X] I agree to follow the IETF's Code of Conduct
From a small sample of BCPs that are of RFCs that were obsoleted, I suspect this is a one-off error in the Datatracker.
rfc-index.xml
has the BCP constituents right in the BCP section, but not in the RFC section.
<rfc-entry>
<doc-id>RFC8499</doc-id>
<title>DNS Terminology</title>
...
<is-also>
<doc-id>BCP0219</doc-id>
</is-also>
<current-status>BEST CURRENT PRACTICE</current-status>
<publication-status>BEST CURRENT PRACTICE</publication-status>
...
My process error on the RPC side - Upon 8499 being obsoleted by 9499, I should have removed the BCP number from the record for RFC 8499. Have done so today, and updated rfc-index.xml, so expect that bcp219 in datatracker will be accurate accordingly at some point.
For background, this is how obsoleted BCPs are handled in general (e.g., BCP 195 no longer contains RFC 7525, as shown accurately on https://datatracker.ietf.org/doc/bcp195/).
I see the update in rfc-index.xml
but it looks like the change was not picked up by the datatracker. The rfc_editor_index_update_task
ran on the full index on 2024-03-31, so it should have seen this.
Guessing we need to teach it how to remove RFCs from subseries? (It may have done this previously, but seems a likely corner case that may have been overlooked in the recent rework of the modeling.)
Confirmed - in the code here, the update task adds but does not remove contains
relationships between docs.
The also
variable at that point contains a list of subseries docs that were pulled from the (bcp|fyi|std)-entry
data in the XML, so I don't think the inconsistency in the rfc-entry
data was responsible. As far as I saw, that is ignored by the current implementation.
I posted too quickly - the code right below what I quoted is meant to do the removal. Not sure why it's not working, but take my diagnosis with a grain of salt.