Subject: [Tools-discuss] Reference to NIST document

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Jun 2021 18:32:32 +0300

Hi,

We have a reference to a NIST SP (special publication) in a draft, and xml2rfc complains that we’re not using the canned reference.

But in trying to locate the appropriate reference, I’m getting more and more confused.

When I look up the list of bibxml databases in https://xml2rfc.tools.ietf.org/, there’s a “Miscellaneous” section with two links. One is broken, and one (bibxml2) seems to be outdated. In any case it barely contains any NIST documents.

There’s also a wonderful extensive list here [1] but all the XML links are broken ☹

Specifically, I’m fighting with NIST SP 800-56a (either in general, or revision 3 of the standard).

Oh, there is a “working” list [2], but when I try using “NIST.SP.800-56Ar2”, I get a broken reference (this one appears to be a kramdown bug, trying to fetch from bibxml2 instead of bibxml-nist, so it’s not just me getting confused…).

Thanks,

            Yaron

[1] https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist-new/

[2] https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist/

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Jun 2021 17:59:13 +0200

Hi Yaron,

Please see [1] for context.

The NIST reference collections are really dusty at this point.
Kramdown-rfc does not do shopping around, so a NIST.* reference triggers lookup in bibxml2.

I’m lazy and usually use DOIs for NIST references.

Putting...

informative:
   NIST.SP.800-56a: DOI.10.6028/NIST.SP.800-56a

...in the YAML header gives me:

   [NIST.SP.800-56a]
              "Recommendation for pair-wise key establishment schemes
              using discrete logarithm cryptography", National Institute
              of Standards and Technology report,
              DOI 10.6028/nist.sp.800-56a, 2006,
              <https://doi.org/10.6028/nist.sp.800-56a>.

Good enough?

Grüße, Carsten

[1]: https://github.com/cabo/kramdown-rfc2629/wiki/Pitfalls#reference-anchors

> On 2021-06-19, at 17:32, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi,
>  
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Jun 2021 18:09:46 +0200

> On 2021-06-19, at 17:59, Carsten Bormann <[email-masked]> wrote:
> 

… or, since you asked about 10.6028/NIST.SP.800-56Ar2 …

informative:
   NIST.SP.800-56Ar2: DOI.10.6028/NIST.SP.800-56Ar2

➔
   [NIST.SP.800-56Ar2]
              Barker, E., Chen, L., Roginsky, A., and M. Smid,
              "Recommendation for Pair-Wise Key Establishment Schemes
              Using Discrete Logarithm Cryptography", National Institute
              of Standards and Technology report,
              DOI 10.6028/nist.sp.800-56ar2, May 2013,
              <https://doi.org/10.6028/nist.sp.800-56ar2>.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Jun 2021 18:40:05 +0200

… and if you really want to use the undocumented and slightly broken bibxml-nist-new, for now please run these two commands once (in your draft directory):

wget https://xml2rfc.tools.ietf.org/public/rfc/bibxml-nist-new/reference.NIST.SP.800-56Ar3.xml
sed -i.bak 1d reference.NIST.SP.800-56Ar3.xml

(get a local copy of the .xml and remove the xml declaration), and add...

--- informative

{::include reference.NIST.SP.800-56Ar3.xml}

... before your

--- back

I don’t want to automate anything like this until, later this year, the bibxml services have been renovated.

Grüße, Carsten

> On 2021-06-19, at 18:09, Carsten Bormann <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 15:44:24 -0400

> NIST.SP.800-56a: DOI.10.6028/NIST.SP.800-56a

Is "NIST." an kramdown thing?
I recognize the DOI as being an alias, but I didn't know I could put a / in there.
Is anything special done with a DOI?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 15:47:21 -0400

Yaron Sheffer <[email-masked]> wrote:
    > When I look up the list of bibxml databases in
    > https://xml2rfc.tools.ietf.org/, there’s a “Miscellaneous” section with
    > two links. One is broken, and one (bibxml2) seems to be outdated. In
    > any case it barely contains any NIST documents.

My understanding is that everything there is dusty, and will get renovated.

Since we mostly just *add* to these things, with rare updates/fixes, I wonder
if this isn't something that git{hub} wouldn't be good at?  I.e. if you find
yourself needing something else, you should add it to a copy you keep
locally,  and send a pull request.

This solves much of the stability and airplane problem if one has it locally.
(I've often rsync'ed it)

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Jun 2021 21:49:16 +0200

> On 2021-06-19, at 21:44, Michael Richardson <[email-masked]> wrote:
> 
> 

Kramdown-rfc recognizes NIST.* labels and tries to look them up in bibxml2.

However, the syntax above uses a DOI reference and then renames that, so the above magic is not applied.

> I recognize the DOI as being an alias, but I didn't know I could put a / in there.

Both / and _ should work; since the point of the rename is to get to choose an anchor of one’s liking (and so it doesn’t matter that “/“ cannot be in an anchor), I just copied the / from the original DOI.

> Is anything special done with a DOI?

If it looks like DOI.*, it will be looked up for you from doi.org, so you don’t need to supply your own reference.  doi.org info can be a bit sketchy, though, so better check, and use kramdown-rfc’s doilit tool plus some hand editing if you don’t like the result.

https://github.com/cabo/kramdown-rfc2629/wiki/Pitfalls#reference-anchors

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Jun 2021 21:54:43 +0200

On 2021-06-19, at 21:47, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

This year, we all hope…

> if this isn't something that git{hub} wouldn't be good at?  

It turns out that git is actually good at updates/fixes, too :-)

> I.e. if you find

Exactly.

The idea is so great Mark Nottingham has started something…
https://www.specref.org

> This solves much of the stability and airplane problem if one has it locally.

A git pull is so much easier than getting an rsync right!
(And git also doesn’t resend data that hasn’t changed — some rfc editor info gets new file dates for each RFC every day even without content changes, which can be very time consuming even with rsync.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 17:36:23 -0400

> If it looks like DOI.*, it will be looked up for you from doi.org, so
    > you don’t need to supply your own reference.  doi.org info can be a bit
    > sketchy, though, so better check, and use kramdown-rfc’s doilit tool
    > plus some hand editing if you don’t like the result.

    > https://github.com/cabo/kramdown-rfc2629/wiki/Pitfalls#reference-anchors

Given that DOIs seem to be on the rise, this is a really useful thing, and I
think it deserves some more awareness :-)

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 20 Jun 2021 00:37:49 +0300

I'm glad to hear life will be better later in 2021. In the meantime, DOI FTW!

	Yaron

On 6/19/21, 22:54, "Carsten Bormann" <[email-masked]> wrote:

    This year, we all hope…

    Exactly.

    Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 17:41:31 -0400

> The idea is so great Mark Nottingham has started something…

oh, that's very nice.
It seems like the IETF should renovate to use that tool.
Still needs IEEE, ITU, ANSI, content, but that might not be hard to fix.

    mcr> This solves much of the stability and airplane problem if one has it locally.
    mcr> (I've often rsync'ed it)

    > (And git also doesn’t resend data that hasn’t changed — some rfc editor
    > info gets new file dates for each RFC every day even without content
    > changes, which can be very time consuming even with rsync.)

Also, I can maintain a local patch on something that I find is wrong, and
then keep rebasing until it gets accepted.  (or I give up)

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2021 18:17:22 -0400

It appears that Michael Richardson  <[email-masked]> said:
>-=-=-=-=-=-

Here is the RFP:

https://www.ietf.org/media/documents/BibXML_Service_RFP.pdf

Looks like they should be selecting the contractor shortly.

R's,
John

---

From: Jay Daley <[email-masked]>
Date: Mon, 21 Jun 2021 22:04:48 +1200

Double reply below. 

> On 20/06/2021, at 10:17 AM, John Levine <[email-masked]> wrote:
> 
> Here is the RFP:
> 

Yes we are on track for announcing a contractor soon. 

> On 20/06/2021, at 9:41 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

We have to do it ourselves because BibXML is ‘proprietary’ to the IETF. i.e. while we publish it as an open standard, albeit not a standalone one, nobody else uses it. 

The intent of the RFP is to provide access to our references and those of select other organisations in four ways (basically what we already have but rewritten and modernised):
- web api
- interactive web form, single citation
- interactive web form, full datasets for those that can be statically generated
- rsync, for those sets that can be statically generated 

This makes it easy for a site such as specref.org to pull our files and republish.  They don’t need permission but we will help to make it happen. 

In addition to specref.org you might also be interested in ISO 690 and relaton.org. 

Jay

-- 
Jay Daley
IETF Executive Director