Subject: [TOOLS-DEVELOPMENT] Tools Team Report -- 11 September 2018

From: Russ Housley <[email-masked]>
Date: Tue, 11 Sep 2018 14:45:49 -0400

Tools Team Report -- 11 September 2018

1. Datatracker Projects
   - The merge plan was recently updated.
     -- See http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
     -- Highlight that the transition to Python3 and Postgress will
        be tackled in 2019.
   - GDPR Compliance -- The email for people to give consent for
     information in the datatracker did not go out July 2018 as planned.
     Deletion of email addresses had many more edge cases than expected,
     so more time was needed to write the code.  Next week, the consent
     requestes will go out to a list of over 15,000 email addresses Of
     course, most of them are very old, so they will bounce.  The email
     will include a link to their datatracker account page.  Alissa will
     send a message to the community to avoid surprises.
   - Management of "extra" IETF meeting sessions -- this task is being
     combined with the update to the meeting scheduling tool that is
     in the budget for 2019.

2. Community & Other Projects
   - The Tools Team is working to discontinue MonArch email archives.
     This will allow all of the mail-related tools to work from one
     copy of the archives in maildir format.  However, the community
     clearly still likes the speed offered by MonArch.  Yesterday an
     update to mailarchive.ietf.org was deployed, and it is much faster.
     The update makes much greater use of static pages and it uses
     ElasticSearch, which is much more efficient than the previous
     index approach.  Robert Sparks will renew the discussion with
     the community discontinuing the MonArch email archives next week.

3. RFC Services Projects
   - RFC Format contracts are on schedule:
     -- IDnits
     -- Publication Formatter
     -- Text Submission
     -- RFClint
     -- SVGcheck
     -- XMLdiff
   - IDnits, Publication Formatter, and Text Submission are on
     schedule, and they will be completed this year.
   - RFClint, SVGcheck, and XMLdiff are in final acceptance test by
     the RFC Series Editor and the RFC Production Center.  Bugs are
     being resolved promptly.

4. Server Infrastructure
   - The custom DMARC-handling software was deployed for all mail lists
     in June.  We received very positive feedback from the community.
   - There is a desire to move away from the custom software to ARC, but
     the ARC software cannot be configured to handle just a few of our
     mail lists.  Henrik is providing requirements to the ARC developers 
     for the needed configuration capability.  So far, they have not
     offered a release date with the new capability.
   - There are three updates to www.ietf.org underway with Torchbox.
     First, upgrade the version of Wagtail from 1.12.1 to 2.2.2.
     Second, change the home page display based on feedback received
     from the IETF community, which includes adding email archive search
     to the page.  Third, add an RSS feed for the IETF Blog.  All three
     updates are expected to be complete by the end of October.

5. Other Business
   - The web pages for the Tools Team were updated.
     -- https://www.ietf.org/about/grpups/tools
     -- https://datatracker.ietf.org/group/tools/about/
   - The IESG needs to decide when to change IDnits to allow I-Ds with
     non-ascii characters in places other than names to be posted.  We
     have a request to allow posting.
     -- See https://trac.tools.ietf.org/tools/ietfdb/ticket/2574
   - The IMAP server code that is provided by ISODE does not handle
     changed usernames well.  When a person changed their username, the
     IMAP server noticed the change, but all saved IMAP state was lost.
     Changing the username back recovered the state.  Alexey has written
     a fix that will be released soon.

6. Parking Lot
   - Prepare the RFC Production Center code for publication.
     -- Maybe this can get some attention when the six RFC Format tools
        are posted in an open source repository.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Sep 2018 18:03:12 +0200

On 9/11/2018 8:45 PM, Russ Housley wrote:
> ...
> ...

Out of curiosity - we have over 50 issues open on the specs, and so far 
there hasn't been a lot of progress getting them discussed and resolved. 
Don't we need to fix these spec issues before any of the deliverables 
can be considered "complete"?

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Wed, 19 Sep 2018 11:12:10 -0500

No - the development SoWs are scoped to implement the RFCs that are 
published to the extent they are implementable.

Only some of the changes needed because of the issues discovered with 
the RFCs will be reflected in the initial deliverables - primarily those 
that would otherwise leave us with tools that wouldn't work at all.

After we have agreement on what we want to do about the rest of the 
specification issues (or as each becomes stable enough to act on), we'll 
approach changing the tools through maintenance or a new development 
effort, depending on scope. (I'm expecting them to all be maintenance 
level).

RjS

On 9/19/18 11:03 AM, Julian Reschke wrote:
> Out of curiosity - we have over 50 issues open on the specs, and so 
> far there hasn't been a lot of progress getting them discussed and 
> resolved. Don't we need to fix these spec issues before any of the 
> deliverables can be considered "complete"?
>
> Best regards, Julian
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Sep 2018 18:21:52 +0200

> that would otherwise leave us with tools that wouldn't work at all.

Well, some of he bug categories are:

1) missing features

2) features that should work differently (such as anchor numbering, 
deprecation of v2 elements that over-complicate things...)

3) simplifications

and probably more...

My fear is that by shipping code for controversial stuff we'll 
essentially paint us into a corner - it's hard to get rid of features 
once they have been used in the wild.

Do we have a strategy for making incompatible changes to the v3 vocabulary?

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Wed, 19 Sep 2018 12:49:59 -0500

On 9/19/18 11:21 AM, Julian Reschke wrote:
>> the RFCs will be reflected in the initial deliverables - primarily 
>> those that would otherwise leave us with tools that wouldn't work at 
>> all.
>> ...
>
Thanks for thinking these through.
> once they have been used in the wild.
Yes, but...
> Do we have a strategy for making incompatible changes to the v3 
It's a position with some obvious rough edges, but I'm not sure we need 
one other than "just do it", as long as we address these the documents 
and make the changes in the tools before we publish an RFC in the v3 
format. Those folks brave enough to be working on drafts using the v3 
format in the meantime would need to change their drafts if an 
incompatible change occurred.

If something causes things to drag out such that we have an archival 
artifact and then need to change the version, we'd need to do something 
differently.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Sep 2018 20:24:37 +0200

> incompatible change occurred.

But that essentially means were just getting to a "beta" stage, not some 
kind of stable release. Would be better to be clear about that.

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Sep 2018 15:37:12 -0400

Julian:
>> It's a position with some obvious rough edges, but I'm not sure we need one other than "just do it", as long as we address these the documents and make the changes in the tools before we publish an RFC in the v3 format. Those folks brave enough to be working on drafts using the v3 format in the meantime would need to change their drafts if an incompatible change occurred.
>> ...
> 
> But that essentially means were just getting to a "beta" stage, not some kind of stable release. Would be better to be clear about that.

My perspective is that the code will implement the existing RFCs.  Once bis documents are available, we can make an assessment of the code changes that are needed.  We also want the lessons learned from doing to code to impact the bis documents.

Russ