Subject: [TOOLS-DEVELOPMENT] Tools Team Report -- 29 April 2019

From: Russ Housley <[email-masked]>
Date: Mon, 29 Apr 2019 13:32:20 -0400

Tools Team Report -- 29 April 2019

1. Datatracker Projects
   - The plan was recently updated.
     -- https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/PLAN
     -- Bids for Meeting Application Improvements were received and
        evaluated, and then the Interim LLC Executive Director
        negotiated a contract.  Work will begin shortly.
     -- An RFP for IRSG balloting was just released.  Proposals are
        due on 16 May 2019, and we expect work to begin in June.   
     -- One thing to highlight is the increased the priority of the
        transition from Python 2 to Python 3.  This increased priority
        is because Python 2 is being officially deprecated, and it 
        will not receive maintenance starting January 2020.

2. Community & Other Projects
   - The Secretariat deployed the latest website deliverable from
     Torchbox.   This uncovered a mess with redirects between Wagtail
     and Apache.  Glen Barney from the Secretariat IT staff will begin
     a significant clean up effort today; it should finish tomorrow.
     
3. RFC Services Projects
   - Support for the v3 schema was enabled for I-D submission during
     IETF 104.  The IESG needs to make a policy decision about when I-Ds
     in this new format can be submitted to the IESG for publication on
     the IETF stream.
   - The RFC Production Center is testing the tools related to the new
     format.
   - The Tools Team is working on a Statement of Work for the security
     review of tools used by the RFC Production Center.  The tools used
     for the new format will be reviewed since the ones related to the
     old format are about to be put in mothballs.
   - Bids for tools for rendering errata in a more useful way were
     received last week, and they are being evaluated right now.  We
     expect a contract to be negotiated in May 2019, and then work to
     begin the same month.

4. Server Infrastructure
   - The custom DMARC-handling software was deployed for all mail lists
     in June 2018, but there is a desire to move away from the custom
     software to ARC.  The ARC software cannot be configured to handle
     just a few of our mail lists.  Requirements were provided to the
     ARC developers, but so far, they have not offered a release date.
     Alexey continues to try to get a response from the ARC developers,
     but so far we are only getting silence.  This has not changed in
     many months; maybe we will be using our custom code forever.

5. YANG Catalog
   - Operation of the yangcatalog.org was to transferred to the IETF
     Secretariat.  A few significant things to highlight:
     -- A YANG Catalog support contractor is under contract.
     -- The yangcatalog.org service is running on different hardware
        than ietf.org.  It will be "in the cloud."  This will allow the
        Tools Team to determine whether this is a useful management
        model for other IETF-related services.
   - The registration for yangcatalog.com has been transferred to the
     IETF Trust.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Apr 2019 20:09:40 +0200

On 29.04.2019 19:32, Russ Housley wrote:
> ...
 > ...

Sorry for being pedantic, but we currently have *three* different things
that can be called v3:

- the format defined in RFC 7991
- the format defined in RFC 7991bis (abandoned for now)
- what happens to be accepted by xml2rfc (which has implementation
notes, but no proper specification)

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Apr 2019 14:27:24 -0400

> On Apr 29, 2019, at 2:09 PM, Julian Reschke <[email-masked]> wrote:
> 

Julian:

Authors can currently use the implementation of xml2rfc to submit an I-D.  The question is at what point will the IESG be comfortable with that format for an approved I-D.  I assume that significant discussion between the RFC Editor and the IESG will be needed to answer that question.  And, if there are actions that need to be taken before that point, tehy need to be identified so we can find the resources to make them happen.

Russ

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Apr 2019 21:29:42 +0200

> Authors can currently use the implementation of xml2rfc to submit an I-D.  The question is at what point will the IESG be comfortable with that format for an approved I-D.  I assume that significan…

At some point, we need updated versions of RFC 7991 (and related docs)
that actually describe precisely what the RFC format *is*. To get there,
we should review what's different right now, discuss that, and decide
how to resolve the differences. In some cases, it will likely mean to
agree on the proposed change implemented in xml2rfc (and properly
document it); but in some other cases I'd expect more discussion.

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Apr 2019 15:58:04 -0400

> On Apr 29, 2019, at 3:29 PM, Julian Reschke <[email-masked]> wrote:
> 

Yes, I agree, but I do not believe that the tools team has the lead on that discussion.  Once the discussion comes to a close, if any changes are needed to xml2rfc, then the ball comes back to the tools team.

Russ