Subject: Re: [Tools-discuss] slow tools reaction

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 16 Sep 2021 12:32:10 +0000

[ moving to tools-discuss ]

Hi Ben,

Thanks for pointing out the decommissioning. Sorry for not noticing the announcement before, and apparently there are quite some people like me 😊

Anyway, I use the diff/idnit/spell/xml2rfc and draft submission tools at tools.ietf.org and they've been slow recently. After learning that tools.ietf.org is replaced by the datatracker, I went to datatracker.ietf.org. There the only links related to the tools that I use are "Draft Submission" under the "Documents" tab, and "IETF Tools" at the lower right bottom.

However, "IETF Tools" simply points to "tools.ietf.org", and "Draft Submission" link in "tools.ietf.org" is the same as "Draft Submission" under the "Documents" tab (all point to https://datatracker.ietf.org/submit/).

So I am still a bit lost - appreciate if someone could share a link to the announcement that I missed.

Thanks.
Jeffrey

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Sent: Thursday, September 16, 2021 12:14 AM
To: Donald Eastlake <[email-masked]>
Cc: [email-masked]; Mankamana Mishra (mankamis) <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Subject: Re: slow tools reaction

[External Email. Be cautious of content]

I assume that everyone is referring to sites hosted under tools.ietf.org,
the old server that is slated for decommisioning.
I have seen slowness as well, but it does not really concern me much
because everything I regularly use is actually on the datatracker, and the
slowness only comes about because links (e.g., from google) have not
updated to point to datatracker directly instead of tools.

Also, tools-discuss is probably a better list at which to discuss any
issues.

-Ben

On Wed, Sep 15, 2021 at 10:13:55PM -0400, Donald Eastlake wrote:
> Me too...
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [email-masked]
>
> On Wed, Sep 15, 2021 at 8:42 PM Mankamana Mishra (mankamis)
> <mankamis=[email-masked]> wrote:
> >
> > Yes , it’s been slow for me too .
> >
> > Mankamana
> > ________________________________
> > From: WGChairs <[email-masked]> on behalf of Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> > Sent: Wednesday, September 15, 2021 5:33:32 PM
> > To: [email-masked] <[email-masked]>
> > Subject: slow tools reaction
> >
> > Hi,
> >
> > Is it just me or have you also noticed that IETF tools have been quite slow recently?
> >
> > Thanks.
> > Jeffrey
> >
> > Juniper Business Use Only
> >
>

Juniper Business Use Only

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 Sep 2021 09:29:40 -0500

Jeffrey -

> Anyway, I use the diff/idnit/spell/xml2rfc and draft submission tools at tools.ietf.org and they've been slow recently. After learning that tools.ietf.org is replaced by the datatracker, I went to…

rfcdiff is at www.ietf.org/tools/rfcdiff (this is where you will land if 
you use the diff features from the History tab any draft.

idnits is at www.ietf.org/tools/idnits (also where you land if you click 
the [! Nits] button on the main datatracker page for any draft.)

(Yes, both rfcdiff and idnits have an odd behavior of temporarily 
redirecting to www6, and serving an older skin, but that will be 
addressed soon.)

This is the first request I've seen to provide something like the spell 
service - we will look at adding something like that.

We are actively working on a re-implementations of the bibxml and online 
xml2rfc conversion services, and are very much aware of the slowness and 
occasional incorrect behavior of the current xml2rfc.tools.ietf.org.

We are also building a replacement for the current tools.ietf.org front 
page.

RjS

> So I am still a bit lost - appreciate if someone could share a link to the announcement that I missed.

https://mailarchive.ietf.org/arch/msg/tools-discuss/oYrAxb3KayPzZ4SNB1DVZTDPPNo/ 
(which was copied to [email-masked], and forwarded to [email-masked].

As all things seem to be in the IETF, it is taking slightly longer than 
expected, but we are on track for turning down the current 
tools.ietf.org by the end of the year.

As I ask in that note, if there are things you rely on at tools.ietf.org 
that are not yet available somewhere else, send a note to this list.

(The remaining things other than the services at xml2rfc.tools.ietf.org 
that are already identified and waiting to be addressed are pdf-ized 
versions of drafts, dailydose, and a small handful of things that used 
metadata from tools that are being adjusted to use metadata from the 
datatracker).

RjS

> ___________________________________________________________
> 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: "Martin Thomson" <[email-masked]>
Date: Fri, 17 Sep 2021 09:54:23 +1000

Thanks for the links Robert, but a small query.

> you use the diff features from the History tab any draft.

Is http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=... a final location and the replacement for https://tools.ietf.org/rfcdiff?url1=... ?

I ask only because the pyht thing might be something you want to remove (see https://www.w3.org/Provider/Style/URI.html and "What to leave out").

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 Sep 2021 21:40:54 -0500

Um, wow?

No - where did you find the link that exposed the pyht - did I send 
that? I'm surprised it works, and is an unintended consequence of the 
webserver configuration.

It should simply be http://www.ietf.org/rfcdiff/?url1=

at least at the moment - I think we should probably put things like 
rfcdiff, idnits, idspell, or such somewhere that's not buried in 
www.ietf.org, but perhaps that's another conversation.

The phyt bit is an implementation detail that may change, and shouldn't 
be visible. Please let me know offline what led you to it.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 Sep 2021 21:44:23 -0500

Ah - I see at least one place where it leaks (in the instructions at the 
bottom of the default form - I will be sure that is addressed. Thanks 
for calling attention to it - if you see it anywhere else, please let me 
know.

RjS

On 9/16/21 9:40 PM, Robert Sparks wrote:
> The phyt bit is an implementation detail that may change, and 
> shouldn't be visible. Please let me know offline what led you to it.
>
> RjS
>
>> Is http://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=... a final location 
>> and the replacement for https://tools.ietf.org/rfcdiff?url1=... ?
>>
>> I ask only because the pyht thing might be something you want to 
>> remove (see https://www.w3.org/Provider/Style/URI.html and "What to 
>> leave out").
>>
>> List info (including how to Unsubscribe): 
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> List info (including how to Unsubscribe): 
> https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 20 Sep 2021 11:32:00 +1000

Thanks Robert,

(Changing the subject as we are now way off the original subject.)

Is there a resource that refers to the latest text rendering of a draft regardless of version?  

The only unversioned links I'm aware of point to the latest HTMLized version of a draft and its metadata page.  I'm in the process of converting the links I generate to use this version of rfcdiff and some of the links I used to provide I find are now broken.

For example, this is a link that used to be useful.  Note the absence of a -06 in url1:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures.txt&url2=https://httpwg.github.io/http-extensions/draft-ietf-httpbis-message-signatures.txt

I can now fix the first part of that, but url1 remains a problem.

(Maybe the fact that no one has complained about these links being broken is a sign that maybe there isn't enough use of this feature to continue supporting it, but I thought that I would at least try.)

---

From: Robert Sparks <[email-masked]>
Date: Mon, 20 Sep 2021 10:21:30 -0500

> Is there a resource that refers to the latest text rendering of a draft regardless of version?

No, there is not a good single resource for this, but I am in the 
process of making one.

See the thread at 
<https://mailarchive.ietf.org/arch/browse/tools-discuss/?q=Getting%20the%20%22current%22%20version%20of%20things>

You are, I think, stating a preference for {versionlessname}.{extension} 
(and inferring format from extension) in whatever URL plan we end up 
with in the long run vs {versionlessname}/{format}?

Similarly, {versionlessname}-{version}.{extension} vs 
{versionlessname}/{version}/{format}

As a brief diversion, while thinking about this, consider the foot-wound 
we carry around that is heuristic extraction of version given a string 
that looks like aaaaaa-nn.txt.

Things like this 
<https://datatracker.ietf.org/doc/draft-ietf-16ng-ip-over-ethernet-over-802-dot-16> 
make for code that has to guess at what a request for 
"draft-ietf-16-ng-ip-over-ethernet-over-802-dot-16.txt" means. We 
heuristically solve this by looking for -802-dot version 16 first and if 
we don't find it, we look for -802-dot-16 version latest. There's a 
chance for harmful masking of a name here - fortunately we haven't seen 
it exercised in practice.

And then consider what horror we inflicted on ourselves with names like 
review-ietf-taps-interface-13-artart-early-sparks-2021-09-17-00 and 
charter-ietf-quic-02-06.

RjS

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 21 Sep 2021 09:03:00 +1000

> with in the long run vs {versionlessname}/{format}?

I don't have any firm opinions about the structure of the URL.  However you decide to encode things, it will work out.

(You could also use content negotiation, but that means telling rfcdiff to set Accept headers in a particular way.)

> that looks like aaaaaa-nn.txt.

Yeah, that is a problem.  I think that you might solve this one of a few ways:

1. Do a deterministic search, either specific first (treat the -nn as a version number to start with and seek that file, if that turns up nothing, then look for aaaaaa-nn-xx.txt) or the other way around.  There should only ever be two for documents.

2. Make separate URLs for versioned and unversioned content:  doc.ietf.org/latest/name/txt (or whatever) vs doc.ietf.org/draft/name-nn/txt (or whatever).

3. Make separate URLs for specific first and specific second searches.  (Add the search order as a URI parameter.)

There are so many ways to cut this.  I think that it's best to give you freedom to decide as I have no firm requirements that might help narrow things down.  I could offer opinions, but those are probably not helpful as they might differ from others'.

> review-ietf-taps-interface-13-artart-early-sparks-2021-09-17-00 and 

Yes, that is bad.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 21 Sep 2021 09:28:47 +0200

I can access this resource:

> https://datatracker.ietf.org/doc/charter-ietf-iotops/01/

and as that is the current charter it also is accessible via:

> https://datatracker.ietf.org/doc/charter-ietf-iotops/

So there is some kind of versioning in the DT URL already, I think?

---

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Sep 2021 09:23:40 -0500

> So there is some kind of versioning in the DT URL already, I think?

Yes, but it is a partial implementation - you can't easily ask, right 
now, for _just_ the plain text (without the metadata), the pdf, or for 
v3 docs the html generated by xml2rfc without the version. Being able to 
ask for that first thing (just the plain text) is really needed for 
things like rfcdiff.

>> I don't have any firm opinions about the structure of the URL. 
>> However you decide to encode things, it will work out.
>>
>> (You could also use content negotiation, but that means telling 
>> rfcdiff to set Accept headers in a particular way.)
>>
>> 1. Do a deterministic search, either specific first (treat the -nn as 
>> a version number to start with and seek that file, if that turns up 
>> nothing, then look for aaaaaa-nn-xx.txt) or the other way around.  
>> There should only ever be two for documents.
>>
>> 2. Make separate URLs for versioned and unversioned content: 
>> doc.ietf.org/latest/name/txt (or whatever) vs 
>> doc.ietf.org/draft/name-nn/txt (or whatever).
>>
>> 3. Make separate URLs for specific first and specific second 
>> searches.  (Add the search order as a URI parameter.)
>>
>> There are so many ways to cut this.  I think that it's best to give 
>> you freedom to decide as I have no firm requirements that might help 
>> narrow things down.  I could offer opinions, but those are probably 
>> not helpful as they might differ from others'.
>>