Subject: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 8 October 2019 at 1:00 Eastern

From: Russ Housley <[email-masked]>
Date: Thu, 3 Oct 2019 14:09:48 -0400

Tools Call Agenda -- 8 October 2019 at 1:00 Eastern

JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m440dd848726339c03e605b9956e38bac
Meeting number (access code): 640 103 570
Meeting password: tools

JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada) 
1-650-479-3208 Call-in toll number (US/Canada)
Meeting number (access code): 640 103 570
Meeting password: tools

1. Datatracker Projects
   - Expected Datatracker Releases -- Robert and Henrik
     -- https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/PLAN
   - Implementation of [email-masked] -- Robert
   - Meeting Application Improvements by IOLA -- Robert
   - Datatracker maintenance by DashCare -- Robert
   - IRSG balloting -- Robert
   - Deployment of Python3 datatracker -- Robert
     -- Impacts on related applications

2. Community & Other Projects
   - WWW search to provide additional pointers -- Greg
     -- Give pointers to datatracker and mailarchive
   - Host third-party subresources on mailarchive -- Ryan

3. RFC Services Projects
   - RPC use of new RFC format tools -- Heather and Henrik
   - Deploying in-line errata on rfc-editor.org? -- Alice
   - Security Review of RPC Tools -- Robert and Heather

4. Server Infrastructure
   - Expected Website Releases -- Robert
   - IESG discussions of DMARC -- Henrik and Alexey
     -- When do we expect the next release of OpenARC? Ever?

5. YANG Catalog
   - Putting yangcatalog.org in a Docker container -- Robert

6. Parking Lot
   - Search over www, datatracker, and mailarchive
   - Transition Datatracker to Django2
   - Transition Website to Django2

7. AOB

---

From: Robert Sparks <[email-masked]>
Date: Fri, 4 Oct 2019 10:37:40 -0500

Some notes for the call.

>       -- https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/PLAN

The priorities in the plan have been tuned. Please look and see that 
they still meet expectations.

>     - Implementation of [email-masked] -- Robert

Most of the work for this (other than creating the new list) is in the 
datatracker.

We plan to have this as a release ready to deploy on Oct 18.

>     - Meeting Application Improvements by IOLA -- Robert
IOLA began work this week. They are significantly off their originally 
expected start date. I think it is still reasonable for them to finish 
this project this year.
>     - Datatracker maintenance by DashCare -- Robert
The improvements to the review tool project continues to go well. The 
recent 6.104.0 release contained much of this work, and the next several 
will continue to include improvements.
>     - IRSG balloting -- Robert
On track for completion before IETF106.
>     - Deployment of Python3 datatracker -- Robert

We are going to have to separate and containerize trac, which isn't 
likely to become python3 enabled until sometime next year.

We are currently planning to deploy the conversion to python 3 when the 
main ietf server is upgraded.

>       -- Impacts on related applications
The mailarchive app will need to deploy on python 3 at the same time as 
the datatracker.
>       -- Give pointers to datatracker and mailarchive
This is on my queue to implement.
>     - Security Review of RPC Tools -- Robert and Heather
We are in the period where we are gathering proposals. The deadline is 
14Oct. We have received a few clarifying questions and have answers 
ready for the 7Oct question response deadline.
>     - Expected Website Releases -- Robert

I released a significant to the website behavior today (affecting blog 
page performance). It should be in production before we get to Tuesday's 
meeting.

See <https://github.com/ietf-tools/wagtail_website/releases>.

There will be several releases in the next couple of weeks that change 
database internals without changing the public's view of the website. 
The names of fields that editors use will be improved.

After that, the major work items are to

* Remove the current datatracker integration attempt

* Migrate to Django 2 so that we can move to more recent wagtail releases

* Investigate reimplementation of the Area and Topic templates

We'll be making smaller improvements with regular releases from now on.

We're discovering that the CSS framework used by the current system is 
undocumented, and hard to work with. We are beginning to discuss a 
project to rebase the site on Bootstrap4 while maintaining the look and 
feel of the site.

>     - Putting yangcatalog.org in a Docker container -- Robert
As noted in the last meeting, this is prioritized behind major 
functionality issues in the yangcatalog project, but it is getting 
cycles. I am currently to the point where most of the containers come up 
the way they should in my development environment , but the confd and 
api_recovery containers are not reaching the expected steady run-state. 
I am keeping pressure on this, but I don't expect that we'll switch 
production to the containerized version in the near future. Certainly 
not before IETF106.
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Greg Wood <[email-masked]>
Date: Sat, 5 Oct 2019 10:56:45 +0000

Hi Russ,

Could analytics implementation be added under item 2?

Thanks,

-Greg

> On Oct 3, 2019, at 2:09 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Oct 2019 10:49:57 -0500

On 10/4/19 10:37 AM, Robert Sparks wrote:
> recent 6.104.0 release contained much of this work, and the next 
> several will continue to include improvements.
> We are currently planning to deploy the conversion to python 3 when 
> the main ietf server is upgraded.
>
> The mailarchive app will need to deploy on python 3 at the same time 
> as the datatracker.
>>
> page performance). It should be in production before we get to 
> Tuesday's meeting.
>
> project to rebase the site on Bootstrap4 while maintaining the look 
> and feel of the site.
>
> cycles. I am currently to the point where most of the containers come 
> up the way they should in my development environment , but the confd 
> and api_recovery containers are not reaching the expected steady 
> run-state. I am keeping pressure on this, but I don't expect that 
> we'll switch production to the containerized version in the near 
> future. Certainly not before IETF106.
>>
>> 6. Parking Lot
I think we should talk briefly about the state of supporting markdown 
for minutes/agendas (and eventually other documents), and how we should 
prioritize improving it.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 8 Oct 2019 10:11:54 -0400

Hi Robert,

> On Oct 4, 2019, at 11:37 AM, Robert Sparks <[email-masked]> wrote:
> 
> Some notes for the call.
> 
> The priorities in the plan have been tuned. Please look and see that they still meet expectations.

The 5th item down says:

"Review and change the draft submission and handling code to deal with UTF-8 instead of ascii before upload of utf-8 drafts should be permitted.”

How is this working now given that we started allowing utf-8 drafts months ago?

Thanks,
Alissa

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 8 Oct 2019 16:40:02 +0200

Hi Alissa,

On 2019-10-08 16:11, Alissa Cooper wrote:
> "Review and change the draft submission and handling code to deal
> with UTF-8 instead of ascii before upload of utf-8 drafts should be
> permitted.”
> 

The status has been changing gradually over the last few months.  The
first step was to change idnits to not issue errors for non-ASCII contents,
only warnings.  The next step was when we started accepting and converting
V3 XML uploads, which provides an improved ability to use non-ASCII.

However, all parts of the code is still not fully able to deal with non-ASCII:
If V3 XML is not used for upload, but just a text-format draft is submitted,
the code that extracts author data from text has problems if it's given
non-ASCII author names.  This will not change with the transition to Python 3;
we will either have to go back and refine the complex code that tries to
figure out author names and addresses from text-only uploads, or (less work
and better results) change the approach to requiring XML in order to support
non-ASCII author names.

The parts of the item you point at which refers to open() in general has
been accomplished with the rewrite that gave Python3 compatibility.

Regards,

	Henrik