Reference to RFC7525

[mnot]

Comment by @fpalombini

Obsolete informational reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325). Please update.

[jricher]

It looks like an error in the tooling - we only reference BCP195 and not the RFC directly. The BCP has been updated at the RFC Editor site https://www.rfc-editor.org/info/bcp195 but that updated information does not appear in datatracker https://datatracker.ietf.org/doc/bcp195/bibtex/ and https://datatracker.ietf.org/doc/bcp195/ (which forwards to RFC 7525), which still has the old reference. I don't know if this is a cache issue or something else failing.

Would it be better to point directly to RFC 9325 or will the pointers from BCP 195 be updated?

[reschke]

Re-running kramdown (maybe with a fresh cache) should fix this.

[martinthomson]

For reference KRAMDOWN_REFCACHE_REFETCH=t make should ensure that references will be updated.

[jricher]

@martinthomson When running the tool locally, I get this error for that BCP, this might be the source of the problem:

.refcache/reference.BCP.0195.xml: fetching from https://xml2rfc-tools-ietf-org.lucaspardue.com/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml
*** 404  while fetching https://xml2rfc-tools-ietf-org.lucaspardue.com/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml

[martinthomson]

Ah, that's the problem. Let's drop this line from the Makefile.

@LPardue might also appreciate the notice about this; his cache was very useful, but it might have rotted and damaged something as it crumbled.

[LPardue]

Thanks for the heads up, sorry if I broke something.

In the meantime since I set that cache up, the tools team has made a lot of infra changes and made more use of a CDN. I wonder if the true origin is now doing a decent job of caching on its own.

[martinthomson]

No need to apologise. We all knew what the cost of taking this dependency was. At the time, the performance benefit was very hard to ignore, which justified taking the risk. We can run a few builds without it and see whether the situation has improved at all. (We might not get a perfect comparison if the 404 results in a different performance profile, but a big regression should be noticeable.)

[LPardue]

I don't really understand the root cause here. If we take my cache out of the mix I think the URL is https://xml2rfc.tools.ietf.org/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml

curl -v https://xml2rfc.tools.ietf.org/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml
*   Trying 50.223.129.194:443...
* Connected to xml2rfc.tools.ietf.org (50.223.129.194) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.tools.ietf.org
*  start date: Oct  1 17:03:27 2022 GMT
*  expire date: Nov  2 17:03:27 2023 GMT
*  subjectAltName: host "xml2rfc.tools.ietf.org" matched cert's "*.tools.ietf.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=Starfield Technologies, Inc.; OU=http://certs.starfieldtech.com/repository/; CN=Starfield Secure Certificate Authority - G2
*  SSL certificate verify ok.
> GET /public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml HTTP/1.1
> Host: xml2rfc.tools.ietf.org
> User-Agent: curl/7.74.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Date: Fri, 20 Jan 2023 03:20:10 GMT
< Server: Apache
< Location: https://bib.ietf.org/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml
< Content-Length: 286
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://bib.ietf.org/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml">here</a>.</p>
</body></html>
* Connection #0 to host xml2rfc.tools.ietf.org left intact

and if you follow that redirect

curl -v https://bib.ietf.org/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml
*   Trying 50.223.129.196:443...
* Connected to bib.ietf.org (50.223.129.196) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.ietf.org
*  start date: Jun 12 15:34:50 2022 GMT
*  expire date: Jul 14 15:34:50 2023 GMT
*  subjectAltName: host "bib.ietf.org" matched cert's "*.ietf.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=Starfield Technologies, Inc.; OU=http://certs.starfieldtech.com/repository/; CN=Starfield Secure Certificate Authority - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5627ba3512c0)
> GET /public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml HTTP/2
> Host: bib.ietf.org
> user-agent: curl/7.74.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 404 
< server: nginx/1.21.5
< date: Fri, 20 Jan 2023 03:21:29 GMT
< content-type: text/html; charset=utf-8
< content-length: 3284
< x-frame-options: DENY
< vary: Cookie, Origin
< x-content-type-options: nosniff
< referrer-policy: same-origin
< cross-origin-opener-policy: same-origin
< 

<!DOCTYPE html>
<html
  lang="en"
  class=""

    data-matomo-url="analytics.ietf.org"

      data-matomo-site-id="8"

>
  <head>
    <title>
  IETF BibXML
  —
  Not found (404)
</title>

....

[LPardue]

https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml works https://bib.ietf.org/public/rfc/bibxml-rfcsubseries/reference.BCP.0195.xml works https://bib.ietf.org/public/rfc/bibxml-rfcsubseries-new/reference.BCP.0195.xml fails (404)

someone more clued in can figure that out?

[martinthomson]

Invoking @rjsparks and @cabo for this one.

FWIW, "https://bib.ietf.org/get-one/export/?doctype=IETF&docid=BCP%20195&format=bibxml" works too (that's what the UI on bib.ietf.org produces).

kramdown-rfc uses "https://bib.ietf.org/public/rfc/bibxml-rfcsubseries/reference.BCP.0195.xml" by default. I don't see where the "-new" would have come from. (I'm looking at the latest code; it's possible there were changes.)

[cabo]

I generally circumvent the unstable bibxml info for STD and BCP by simply saying:

normative:
  STD66: RFC3986

(Or, if I want a mnemonic name in the document plus some indirection:

  STD66:
    -: uri
    =: RFC3986

)

But this does not work for BCP195, which is multi-document. I haven't tried multi-document BCP/STD references recently. I note that the RFCs in there now at least have anchors, so section references into the individual documents should work.

If there is any need to ever deviate from the default URI kramdown-rfc uses for RFC and I-D references, this is a bug, and I'd like to know about that.

[cabo]

https://mailarchive.ietf.org/arch/msg/xml2rfc/Dj9zM4ZGuonS236NQ0sR7Rr0ai0

[rjsparks]

Since there was the question: rfcsubseries-new was a re-implementation that Tony was working on before we started the current bibxml project. it was exposed, but never meant to be used other than as an experiment at xml2rfc.tools.ietf.org so there aren't redirects for it (IIRC). What's coming out of bib.ietf.org is intended to carry forward what Tony was working towards.

[jricher]

This seems to have been fixed in the tool chain by the time we generated draft -16:

   [BCP195]   Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
              1.1", BCP 195, RFC 8996, March 2021.

              Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, November 2022.

              <https://www.rfc-editor.org/info/bcp195>

Closing this issue as resolved, and hopefully the underlying tools keep it resolved. :)