referencedby link shows partial result only

[cabo]

What happened?

https://datatracker.ietf.org/doc/draft-ietf-ace-aif/referencedby/

only shows draft-ietf-ace-key-groupcomm

It should be showing:

File: draft-ietf-ace-key-groupcomm
File: draft-ietf-ace-key-groupcomm-oscore
File: draft-ietf-ace-mqtt-tls-profile
File: draft-ietf-ace-oscore-gm-admin

I haven't checked with other documents.

What browser(s) are you seeing the problem on?

Safari

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[cabo]

A few more weird results:

https://datatracker.ietf.org/doc/rfc9031/references/

includes draft-ietf-cbor-cddl but doesn't include the RFC from that, RFC 8610 (which is what is actually being referenced from 9031).

In general, I'd like a referencedby query for RFC 8949 include those that reference RFC 7049 and vice versa, except when I don't (e.g., when I specifically look for documents that reference the earlier document). And that includes the I-D stages of that document (e.g. draft-ietf-cbor-7049bis) and of the replaced document (7049, draft-bormann-cbor).

But maybe that is a feature request, and we should get the direct references right, first.

[rjsparks]

This is a consequence of trying to take references out of xml when xml is provided, combined with the current state where we we are allowing xml to be submitted that isn't fully self-contained.

When attempting to rebuild the reference relationships for draft-ietf-ace-key-groupcomm-oscore using the xml in the archive for version 14:

{'warnings': ['There were 18 references with no matching DocAlias'], 'unfound': ['i-d.ietf-ace-oscore-profile', 'cose.algorithms', 'i-d.ietf-core-groupcomm-bis', 'nist-800-56a', 'i-d.ietf-ace-key-groupcomm', 'i-d.ietf-ace-oauth-authz', 'i-d.ietf-ace-oscore-gm-admin', 'i-d.ietf-cose-cbor-encoded-cert', 'cose.key.types', 'i-d.ietf-cose-rfc8152bis-algs', 'i-d.tiloca-core-oscore-discovery', 'cose.elliptic.curves', 'i-d.ietf-cose-rfc8152bis-struct', 'i-d.ietf-ace-dtls-authorize', 'cose.header.parameters', 'i-d.ietf-core-oscore-groupcomm', 'i-d.ietf-ace-aif', 'i-d.ietf-core-coap-pubsub']}

Whereas rebuilding it using the txt in the archive produces no warnings or errors.

We have a separate issue tracking when/how to require xml draft submissions to be self-contained.

In the meantime, we should change rebuild_reference_relations to look at the xml and see if it has xinclude elements, and if so, punt to the old mechanism of parsing the text. Then we need to build a management command to run through the documents that have been submitted in xml since we started building reference relations from the xml and reparse them.

[cabo]

A few more weird results:

https://datatracker.ietf.org/doc/rfc9031/references/

includes draft-ietf-cbor-cddl but doesn't include the RFC from that, RFC 8610 (which is what is actually being referenced from 9031).

In general, I'd like a referencedby query for RFC 8949 include those that reference RFC 7049 and vice versa, except when I don't (e.g., when I specifically look for documents that reference the earlier document). And that includes the I-D stages of that document (e.g. draft-ietf-cbor-7049bis) and of the replaced document (7049, draft-bormann-cbor).

But maybe that is a feature request, and we should get the direct references right, first.

This one is not fixed, I think.

[larseggert]

I think the problem may be that references are computed at I-D submit time, but not at other times (see #5093), e.g., when an RFC is published. (When I force a recomputation of the references on the XML for 9031, 8610 is found.)

[rjsparks]

The auto-close on merge was not correct for this issue - there is a manual fix-up effort that we need to go through to straighten out the damage the issue calls out. It will look like recomputing the reference relationships at least for all documents submitted with xml, and it may be worth simply recomputing everything. But we need to test whether the changes in the recent PR are such that we get better results doing the recomputation over the xml, or if we force recomputation using the txt.

[larseggert]

I had a case recently where the text extraction was also incorrect, because it matched something outside the references section. Will see if I can remember the doc.