Subject: [xml2rfc] whose on first

From: Randy Bush <[email-masked]>
Date: Fri, 19 Feb 2021 14:13:48 -0800

now that henrik too has been driven off, are there folk still fixing
issues, such as bibxml?  or do we keep rolling our own?

      <reference anchor='I-D.spaghetti-sidrops-rpki-rsc'>
	<front>
	  <title>RPKI Signed Checklists</title>
	  <author initials='J' surname='Snijders' fullname='Job Snijders'>
	    <organization>Fastly</organization>
	  </author>
          <date month='February' year='2021' />
        </front>
	<seriesInfo name='Internet-Draft' value='draft-spaghetti-sidrops-rpki-rsc-02' />
	<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-spaghetti-sidrops-rpki-rsc-02.txt' />
      </reference>

randy

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Feb 2021 23:29:11 +0100

On 2021-02-19, at 23:13, Randy Bush <[email-masked]> wrote:
> 
> are there folk still fixing

I don’t understand the current situation any more than you, but Henrik did leave us this gem:

$ curl https://datatracker.ietf.org/doc/bibxml3/draft-spaghetti-sidrops-rpki-rsc/xml

<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.spaghetti-sidrops-rpki-rsc">
   <front>
      <title>RPKI Signed Checklists</title>
      <author fullname="Job Snijders">
	 <organization>Fastly</organization>
      </author>
      <date month="February" day="11" year="2021" />
      <abstract>
	 <t>   This document defines a Cryptographic Message Syntax (CMS) profile
   for a general purpose listing of checksums (a &#39;checklist&#39;), for use
   with the Resource Public Key Infrastructure (RPKI).  The objective is
   to allow an attestation, in the form of a listing of one or more
   checksums of arbitrary digital objects (files), to be signed &quot;with
   resources&quot;, and for validation to provide a means to confirm a
   specific Internet Resource Holder produced the signed checklist.  The
   profile is intended to provide for the signing of a checksum listing
   with an arbitrary set of Internet Number Resources.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-spaghetti-sidrops-rpki-rsc-02" />
   <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-spaghetti-sidrops-rpki-rsc-02.txt" />
</reference>

(The value of /reference/format/@target in this is, er, suboptimal; Martin Thomson has pointed out [1] that you can delete the whole <format target=…> thing and xml2rfc will insert something sensible instead, which you can further control via xml2rfc options.  kramdown-rfc environment variable for that: KRAMDOWN_NO_TARGETS)

Grüße, Carsten

[1]: https://github.com/cabo/kramdown-rfc2629/pulls?q=is%3Apr+is%3Aclosed

---

From: "Randy Bush" <[email-masked]>
Date: Fri, 19 Feb 2021 14:32:13 -0800

hi carsten,

my rsync does not get it

ryuu.rg.net:/Users/randy> ls refs/id/bibxml3/*spaghetti*
refs/id/bibxml3/reference.I-D.draft-spaghetti-sidrops-rpki-manifest-validation-00.xml
refs/id/bibxml3/reference.I-D.draft-spaghetti-sidrops-rpki-manifest-validation-01.xml
refs/id/bibxml3/reference.I-D.draft-spaghetti-sidrops-rpki-vrp-yang-00.xml
refs/id/bibxml3/reference.I-D.spaghetti-sidrops-rpki-manifest-validation.xml
refs/id/bibxml3/reference.I-D.spaghetti-sidrops-rpki-vrp-yang.xml

randy

---
[email-masked]
`gpg --locate-external-keys --auto-key-locate wkd [email-masked]`
signatures are back, thanks to dmarc header mangling

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Feb 2021 23:36:08 +0100

> my rsync does not get it

I don’t think we can rsync bibxml from the datatracker yet.
Might be interesting to pull something together that does the equivalent over HTTP so one can then rsync from that…  But the datatracker is not very fast, so this might overload it.

Grüße, Carsten

---

From: "Randy Bush" <[email-masked]>
Date: Fri, 19 Feb 2021 14:39:08 -0800

> Might be interesting to pull something together that does the 
> equivalent over HTTP so one can then rsync from that…  But the 
> datatracker is not very fast, so this might overload it.

this is my nightly rsync

```
#!/bin/sh
RSY="/usr/bin/rsync -vaHx --delete"
$RSY rfc-editor.org::rfcs-text-only $HOME/rfcs
$RSY ietf.org::internet-drafts $HOME/ids
# old + new, though i really want only old
$RSY rsync.tools.ietf.org::tools.id $HOME/ids.old
# for xml2rfc
$RSY xml2rfc.tools.ietf.org::xml2rfc.bibxml/bibxml $HOME/refs/rfc
$RSY xml2rfc.tools.ietf.org::xml2rfc.bibxml/bibxml3 $HOME/refs/id
```

i am quite open to improving it

randy

---
[email-masked]
`gpg --locate-external-keys --auto-key-locate wkd [email-masked]`
signatures are back thanks to dmarc header mangling

---

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Feb 2021 17:18:48 -0600

I'm in the process of putting together a statement of work to 
reimplement the generation of the various pools of bibxml. (Tony and 
Henrik are providing input).

This isn't abandoned.

Henrik and Tony are also still trying to straighten out the issues with 
the existing service.

RjS

On 2/19/21 4:39 PM, Randy Bush wrote:
> |#!/bin/sh RSY="/usr/bin/rsync -vaHx --delete" $RSY 
> rfc-editor.org::rfcs-text-only $HOME/rfcs $RSY 
> ietf.org::internet-drafts $HOME/ids # old + new, though i really want 
> only old $RSY rsync.tools.ietf.org::tools.id $HOME/ids.old # for 
> xml2rfc $RSY xml2rfc.tools.ietf.org::xml2rfc.bibxml/bibxml 
> $HOME/refs/rfc $RSY xml2rfc.tools.ietf.org::xml2rfc.bibxml/bibxml3 
> $HOME/refs/id |
>
> ------------------------------------------------------------------------
>
> [email-masked] <mailto:[email-masked]>
> |gpg --locate-external-keys --auto-key-locate wkd [email-masked]|
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Julian Reschke <[email-masked]>
Date: Sat, 20 Feb 2021 07:01:52 +0100

Am 19.02.2021 um 23:29 schrieb Carsten Bormann:
> ...

Note that the <format> element was deprecated in RFC 7991 for good
reasons: it had no proper docs, and was inconsistently used. If there's
a use case for it, it should be written down properly, and then the
element could be resurrected.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 20 Feb 2021 08:08:53 +0100

> element could be resurrected.

Interesting.  
I know of only one usage, and that is quite well established:  Providing multiple link targets that differ in their format.
Well, it sometimes was used for single links with the intention to give the format of the one target provided.

I find a lot of examples of the single link use in the RFC repository, the most recent one in RFC 8979 from this month.
RFC 8795 has one with
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-teas-te-topo-and-tunnel-modeling-06.txt"/>
          <format type="PDF" target="http://www.ietf.org/internet-drafts/draft-ietf-teas-te-topo-and-tunnel-modeling-06.pdf"/>

What was the usage inconsistent with that?

(I would understand an argument that we don’t know how to render it in general, or that it has an attribute named “octets” :eyeroll:, but not that it was inconsistently used.  Obviously, RFC 7749/7991 was the opportunity to write it down less poorly.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Sat, 20 Feb 2021 08:24:48 +0100

> (I would understand an argument that we don’t know how to render it in general, or that it has an attribute named “octets” :eyeroll:, but not that it was inconsistently used.  Obviously, RFC 7749/7…

1) It's (AFAIR) not covered by the style guide.

2) RFC 7749 says in
<https://greenbytes.de/tech/webdav/rfc7749.html#element.format>:

> 2.18. <format>
>
> Provides a link to an additional format variant for a reference.
>
> Note that these additional links are neither used in published RFCs nor supported by all tools. If the goal is to provide a single URI for a reference, the "target" attribute on <reference> can be used instead.
>
> This element appears as a child element of <reference> (Section 2.30).
>
> Content model: this element does not have any contents.

I believe back then it was rendered in HTML but not in text, or the
other way around.

3) If you look at the output formats for 8979 and 8795 you see that the
links indeed are not rendered (I checked text and HTML). I'll also note
that the Internet Draft references point to tools.ietf.org, which likely
is in conflict with the RFC Style Guide.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 20 Feb 2021 08:26:55 +0100

Am 20.02.2021 um 08:24 schrieb Julian Reschke:
>> Note that these additional links are neither used in published RFCs
>> nor supported by all tools. If the goal is to provide a single URI for
>> a reference, the "target" attribute on <reference> can be used instead.
>>

4) That the <format> element appears in the canonical RFC appears to be
in conflict with
<https://greenbytes.de/tech/webdav/rfc7998.html#rfc.section.5.6.6>.

Best regards, Julian

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Feb 2021 10:40:56 -0800

> Note that the <format> element was deprecated in RFC 7991

i nuked it yesterday under advice from, i think, carsten, tyvm

but i am just a protocol wonk and would really like all this cruft
hidden from me in a nice file in my rsunk dirs

    <?rfc include="reference.I-D.spaghetti-sidrops-rpki-rsc"?>

but it's broken and i have to deal with this cruft.  i respect that this
may be fun for you rfc production process wonks, but have mercy on us
poor geeks just trying to get a draft out. :)

[ btw, major thanks and props to you folk hanging in there despite the
  fools who think senior folk are fungible ]

randy

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Sat, 20 Feb 2021 20:42:56 +0000

On 2/19/2021, 5:31 PM, "rfc-interest on behalf of Randy Bush" <[email-masked] on behalf of [email-masked]> wrote:

My privileges on the machine where bibxml is hosted were also cut off, so I have not been able to debug or fix what is going on there.

I identified one permission issue last week, but can't fix that.
I know WHERE to look for other issues, but don't have the permissions.

Sigh

	Tony

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Feb 2021 12:54:00 -0800

> My privileges on the machine where bibxml is hosted were also cut off,
> so I have not been able to debug or fix what is going on there.

effing brilliant.  as an old friend once told me

    When there is rot somewhere in the middle of the organization, that
    part can be sawed off and regrown.  When it is at the top, it
    descends.  A middle manager may be able to block it for a while; but
    eventually they break and the rot keeps descending.
      -- paraphrased from Tom DeMarco

if senior software engineers of the quality of the tools crew are
actually fungible, then why can $dayjob not fill two open reqs?

randy

---
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 23 Feb 2021 08:59:30 +1300

> On 21/02/2021, at 9:54 AM, Randy Bush <[email-masked]> wrote:
> 

Just so that we are clear, the machine that Tony has lost privileges on is under the sole control of Henrik and privileges were lost because it died irreparably.  The service has since been moved to another machine controlled exclusively by Henrik and so all decisions regarding privileges are made by him.

Jay

> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Feb 2021 13:27:31 -0800

> Just so that we are clear, the machine that Tony has lost privileges
> on is under the sole control of Henrik and privileges were lost
> because it died irreparably.  The service has since been moved to
> another machine controlled exclusively by Henrik and so all decisions
> regarding privileges are made by him.

i can unhappily report that i have become aware of this.  and more of
the sad chain of events leading us here than i might like to be.  and
yes, of course henrik had his role to play.  and he comes from the
passive aggressive swedish culture to which i am somewhat allergic.

as the list of departing senior professionals continues to grow, all
from similar causes, it just might not be entirely their fault.

best wishes on the senior software engineers are fungible experiment.

randy

---
[email-masked]