Subject:	Notes from the format developers and doc authors meeting @ IETF 101
Date:	Wed, 21 Mar 2018 16:48:40 +0000
From:	Heather Flanagan <rse@rfc-editor.org>
To:	Paul Hoffman <paul.hoffman@icann.org>, julian.reschke@gmx.de, henrik@levkowetz.com, n.brownlee@auckland.ac.nz, Jim Schaad <ietf@augustcellars.com>, rjsparks@nostrum.com, housley@vigilsec.com, sginoza@amsl.com

Subject:

Notes from the format developers and doc authors meeting @ IETF 101

Date:

Wed, 21 Mar 2018 16:48:40 +0000

From:

To:

Paul Hoffman <paul.hoffman@icann.org>, julian.reschke@gmx.de, henrik@levkowetz.com, n.brownlee@auckland.ac.nz, Jim Schaad <ietf@augustcellars.com>, rjsparks@nostrum.com, housley@vigilsec.com, sginoza@amsl.com

Some pre-discussion for the call tomorrow...

<= /div>I note this on the agenda:

On Mon, Apr 9, 2018 at 10:= 35 AM, Russ Housley <housley@vig= ilsec.com> wrote:
> Here is the updated agenda for tomorrow.= =C2=A0 It includes the additional item requested by Henrik.
> 4. Serv= er Infrastructure
> =C2=A0 =C2=A0- IESG discussions of DMARC -- Henri= k and Alexey
> =C2=A0 =C2=A0 =C2=A0-- Mail list system is too fragile= .=C2=A0 What can be done?

A search here:=C2=A0 https://mailarchive.ietf.org/arch/search/?email_list=3Dtool= s-development&q=3Dfragile

Yields 12 messages, wit= h only 3 salient results.=C2=A0 The word "fragile" appeared in 20= 11...

Tools call - 14 Dec 2011
> 5.=C2=A0 NomCom To= ols
> TH: HL was last to touch them for NomCom11. Has proposals that = are still in work. =C2=A0
> RH: tools are fairly fragile?

and in 2014...

Tools call - 11 Dec 2014
> - = Agenda Display -- Robert
> There are ongoing problems, related to hav= ing fragile code

And the tools-discuss list=C2=A0=20 https://mailarchive.ietf.org/arch/search/?email_list= =3Dtools-discuss&q=3Dfragile only uses the word in the context of a 2006 Apache race condition.

Nonetheless, fragile appeared on last month's agenda wit= h respect to the mail list system (and the notes indicate nothing was said = about it on that call.)

Tools call - 6 Mar 2018
> 4= . Server Infrastructure
>=C2=A0 =C2=A0=C2=A0 -- Mail list system is t= oo fragile.=C2=A0 What can be done?

Now, I didn't pic= k the systems, I just run them, so I am absolutely not taking this personal= ly nor am I emotionally invested in Mailman in any way.

B= ut could someone please point me to any discussions that I must have missed= that indicated that the list system is fragile?=C2=A0 I'd appreciate b= ackground on this.

I think that, despite being open-sourc= e software with somewhat random maintenance release scheduling, our mail li= st system itself is *far* from fragile.

We run Postfix in= to Amavis (including SpamAssassin and ClamAV), into Henrik's own Postco= nfirm system, into Mailman.=C2=A0=C2=A0 I myself have operated this system = for us for, well, over 10 years now, more recently with the assistance of a= n IT team... and my impression has been that it works remarkably well.=C2= =A0 I can't remember the last time we were "down" (a rhetoric= al statement voting confidence in the system overall, and ignoring teething= problems with upgrades, not a request for a date), and it seems to me that= the system "just works".=C2=A0=C2=A0

And since my sleep (literally) depends on the system continuing to "= ;just work", I am *very* interested in learning about, and correcting,= any fragility.=C2=A0 But I don't think we can answer the question &quo= t;what can be done" until we understand "what the problem (if any= ) is."

All that said, I think that, if there *is* an= y fragility, it might be grounded in our rather unique approach to the hand= ling of community requests.=C2=A0=C2=A0 We tend to take individual communit= y member requests far more seriously than most other organizations do, and = we love to add moving parts and complexity in order to respond to the reque= sts that come in.=C2=A0=C2=A0=C2=A0 Notwithstanding Henrik's excellent = Postconfirm system (which is invisible to most of you but a huge godsend to= me) - if I might quote "Mr. Scott" from Star Trek [ https://www.youtube.com/watch= ?v=3DT2NsTi_43g4 ] :

The more they overthink the plum= bing, the easier it is to stop up the drain.

So, speaking= only as a vendor, but in this case also the manager of the team who runs t= his stuff...

1. Can someone please clarify the fragility= ?

2. Perhaps one thing that "can be done" would= be mindfulness of complexity as we rush to add new features.=C2=A0

tl;dr Restraint.

Thanks and sorry,

<= div>Glen
--

Glen Barney

IT Director

AMS (IETF Secretariat)

<= /div>

--94eb2c06b27aa9763805696e3c64-- From nobody Mon Apr 9 11:33:36 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD1C12E883 for ; Mon, 9 Apr 2018 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIn3LvINJ1o3 for ; Mon, 9 Apr 2018 11:33:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC0C12DDD2 for ; Mon, 9 Apr 2018 11:33:30 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:62590 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f5bbX-00029x-7V; Mon, 09 Apr 2018 11:33:27 -0700 To: Glen , IETF Tools Development References: <3B3B00B1-B13C-4ADE-86F2-867FDEA589E2@vigilsec.com> <502E45C8-B071-4BA7-991C-04CDEB00A4E6@vigilsec.com> From: Henrik Levkowetz Message-ID: Date: Mon, 9 Apr 2018 20:33:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kW8fRIMiUoaUbKlhvwECda6984VKpWOpf" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, glen@amsl.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 10 April 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 18:33:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kW8fRIMiUoaUbKlhvwECda6984VKpWOpf Content-Type: multipart/mixed; boundary="qck0XdglscXci8M6r1D0NSuQFu4JIBadD"; protected-headers="v1" From: Henrik Levkowetz To: Glen , IETF Tools Development Message-ID: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 10 April 2018 at 1:00 Eastern References: <3B3B00B1-B13C-4ADE-86F2-867FDEA589E2@vigilsec.com> <502E45C8-B071-4BA7-991C-04CDEB00A4E6@vigilsec.com> In-Reply-To: --qck0XdglscXci8M6r1D0NSuQFu4JIBadD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Glen, On 2018-04-09 20:04, Glen wrote: > Some pre-discussion for the call tomorrow... >=20 > I note this on the agenda: >=20 > On Mon, Apr 9, 2018 at 10:35 AM, Russ Housley wr= ote: >> Here is the updated agenda for tomorrow. It includes the additional i= tem > requested by Henrik. >> 4. Server Infrastructure >> - IESG discussions of DMARC -- Henrik and Alexey >> -- Mail list system is too fragile. What can be done? I believe this is simply in response to the issues we had with installati= on of the dmarc-workaround, and refers to the complexity of the setup, with both public and custom tools interconnected in a fairly unique setup. I'm sure Russ will provide more background. Best regards, Henrik >=20 > A search here: > https://mailarchive.ietf.org/arch/search/?email_list=3Dtools-developmen= t&q=3Dfragile >=20 > Yields 12 messages, with only 3 salient results. The word "fragile" > appeared in 2011... >=20 > Tools call - 14 Dec 2011 >> 5. NomCom Tools >> TH: HL was last to touch them for NomCom11. Has proposals that are sti= ll > in work. >> RH: tools are fairly fragile? >=20 > and in 2014... >=20 > Tools call - 11 Dec 2014 >> - Agenda Display -- Robert >> There are ongoing problems, related to having fragile code >=20 > And the tools-discuss list > https://mailarchive.ietf.org/arch/search/?email_list=3Dtools-discuss&q=3D= fragile > only uses the word in the context of a 2006 Apache race condition. >=20 > Nonetheless, fragile appeared on last month's agenda with respect to th= e > mail list system (and the notes indicate nothing was said about it on t= hat > call.) >=20 > Tools call - 6 Mar 2018 >> 4. Server Infrastructure >> -- Mail list system is too fragile. What can be done? >=20 > Now, I didn't pick the systems, I just run them, so I am absolutely not= > taking this personally nor am I emotionally invested in Mailman in any = way. >=20 > But could someone please point me to any discussions that I must have > missed that indicated that the list system is fragile? I'd appreciate > background on this. >=20 > I think that, despite being open-source software with somewhat random > maintenance release scheduling, our mail list system itself is *far* fr= om > fragile. >=20 > We run Postfix into Amavis (including SpamAssassin and ClamAV), into > Henrik's own Postconfirm system, into Mailman. I myself have operated= > this system for us for, well, over 10 years now, more recently with the= > assistance of an IT team... and my impression has been that it works > remarkably well. I can't remember the last time we were "down" (a > rhetorical statement voting confidence in the system overall, and ignor= ing > teething problems with upgrades, not a request for a date), and it seem= s to > me that the system "just works". >=20 > And since my sleep (literally) depends on the system continuing to "jus= t > work", I am *very* interested in learning about, and correcting, any > fragility. But I don't think we can answer the question "what can be d= one" > until we understand "what the problem (if any) is." >=20 > All that said, I think that, if there *is* any fragility, it might be > grounded in our rather unique approach to the handling of community > requests. We tend to take individual community member requests far mo= re > seriously than most other organizations do, and we love to add moving p= arts > and complexity in order to respond to the requests that come in. > Notwithstanding Henrik's excellent Postconfirm system (which is invisib= le > to most of you but a huge godsend to me) - if I might quote "Mr. Scott"= > from Star Trek [ https://www.youtube.com/watch?v=3DT2NsTi_43g4 ] : >=20 > The more they overthink the plumbing, the easier it is to stop up the d= rain. >=20 > So, speaking only as a vendor, but in this case also the manager of the= > team who runs this stuff... >=20 > 1. Can someone please clarify the fragility? >=20 > 2. Perhaps one thing that "can be done" would be mindfulness of complex= ity > as we rush to add new features. >=20 > tl;dr Restraint. >=20 > Thanks and sorry, > Glen > -- > Glen Barney > IT Director > AMS (IETF Secretariat) >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --qck0XdglscXci8M6r1D0NSuQFu4JIBadD-- --kW8fRIMiUoaUbKlhvwECda6984VKpWOpf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlrLsegACgkQTptXS4+7 Fxrfnw//b2Dh2AgGQspIjO9aciVPIIqWETzn0WGppgd+R3r/yK9ZehPorXaOcxD2 H7q3WTVJOsmEhmWjsQP0yjpSTNi2VyDAWmnj1hvMNPwYHjI1KZJbDOG//HhY1BhS 8Xd4PnzNfyzmfMpUrEJrB2JlzY6DksOcFy+XsRBoFbB9kdnfsBLDhSdK4zo3Z6Pu cxwTrxCxkvDolqnxrmv8Y/0hBvMNI06USYg+N8brbFobI3+EBLNHqVnKnhuAdBjo BdBcuPiqByt5Y4tBlDD37l8W8crQKeo4JhGFq42LNv1SIC/MkebV+KOeaUrrgfFn /ke3jhxVWPLgwFEg7Kkpe3OMOxHl9ztgOovHfuW7kWbmGGcJ0XtVwjFcDlTntQHg sNyPbz56uZSBtaeykLobM/9lOcEtcNiTWqR42o/mrI+rwGQGI0dMkp5v3k4ysdDA fjsgl0dcwIQ4vXp7rIeDCr6GAeTkrMi55xTdwPCCm6VQX+50NI0bcKJSzBbbODiD SKRVU0X/iXxNp8EJDUu/CFvuXsSBDzX1qf0oK9owXEOZrWyFnjndMUaeesPoQaFk K9i5M89gw0ZlqdHdKAD+g3cgXc8QAs3L3+ZJDLAELn1X8Vup2hpe/sroOljG4frK VDMH7hlBz96rXEjRHnAWglZ35b3rkv42BnCyuBDY6Afu19DCRUg= =QEKk -----END PGP SIGNATURE----- --kW8fRIMiUoaUbKlhvwECda6984VKpWOpf-- From nobody Mon Apr 9 11:37:27 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2FD12D778 for ; Mon, 9 Apr 2018 11:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9m1rWVCkapvy for ; Mon, 9 Apr 2018 11:37:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B821273B1 for ; Mon, 9 Apr 2018 11:37:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8F415300670 for ; Mon, 9 Apr 2018 14:37:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yOJ2_ucMQSit for ; Mon, 9 Apr 2018 14:37:20 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5C70E3002C7; Mon, 9 Apr 2018 14:37:20 -0400 (EDT) From: Russ Housley Message-Id: <0B9A6710-DF10-4AD1-A2E3-0FE0A96EC683@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_714BAF10-856A-4A94-9B99-288CF9ECA5C7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 9 Apr 2018 14:37:22 -0400 In-Reply-To: Cc: IETF Tools Development To: Glen Barney References: <3B3B00B1-B13C-4ADE-86F2-867FDEA589E2@vigilsec.com> <502E45C8-B071-4BA7-991C-04CDEB00A4E6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 10 April 2018 at 1:00 Eastern X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 18:37:26 -0000 --Apple-Mail=_714BAF10-856A-4A94-9B99-288CF9ECA5C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 9, 2018, at 2:04 PM, Glen wrote: >=20 > > 4. Server Infrastructure > > - IESG discussions of DMARC -- Henrik and Alexey > > -- Mail list system is too fragile.. What can be done? >=20 > A search here: = https://mailarchive.ietf.org/arch/search/?email_list=3Dtools-development&q= =3Dfragile = >=20 > Yields 12 messages, with only 3 salient results. The word "fragile" = appeared in 2011... >=20 > Tools call - 14 Dec 2011 > > 5. NomCom Tools > > TH: HL was last to touch them for NomCom11. Has proposals that are = still in work. =20 > > RH: tools are fairly fragile? >=20 > and in 2014... >=20 > Tools call - 11 Dec 2014 > > - Agenda Display -- Robert > > There are ongoing problems, related to having fragile code >=20 > And the tools-discuss list = https://mailarchive.ietf.org/arch/search/?email_list=3Dtools-discuss&q=3Df= ragile = only uses the word in the context of a 2006 Apache race = condition. >=20 > Nonetheless, fragile appeared on last month's agenda with respect to = the mail list system (and the notes indicate nothing was said about it = on that call.) The notes say that we should discuss it when more people are able to = make the call. Hopefully that will be tomorrow. Russ --Apple-Mail=_714BAF10-856A-4A94-9B99-288CF9ECA5C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 9, 2018, at 2:04 PM, Glen <glen@amsl.com> = wrote:

> 4. Server Infrastructure
> = - IESG discussions of DMARC -- Henrik and Alexey
> = -- Mail list system is too fragile.. What can = be done?

A search = here: https://mailarchive.ietf.org/arch/search/?email_list=3Dtools-de= velopment&q=3Dfragile

Yields 12 messages, with only 3 salient results. The = word "fragile" appeared in 2011...
Tools call - 14 Dec 2011
> 5. NomCom = Tools
> TH: HL was last to touch them for NomCom11. Has = proposals that are still in work.
> RH: tools = are fairly fragile?

and= in 2014...

Tools call - 11 Dec 2014
> - Agenda Display = -- Robert
> There are ongoing problems, related to = having fragile code

And the tools-discuss = list https://mailarchive.ietf.org/arch/search/?email_list=3Dtools-di= scuss&q=3Dfragile only uses the word in the = context of a 2006 Apache race condition.

Nonetheless, fragile = appeared on last month's agenda with respect to the mail list system = (and the notes indicate nothing was said about it on that = call.)

The = notes say that we should discuss it when more people are able to make = the call. Hopefully that will be tomorrow.

Russ

= --Apple-Mail=_714BAF10-856A-4A94-9B99-288CF9ECA5C7-- From nobody Tue Apr 10 10:40:50 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A212DB71 for ; Tue, 10 Apr 2018 10:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1Gr5JSOVNeZ for ; Tue, 10 Apr 2018 10:40:45 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA48812DA1D for ; Tue, 10 Apr 2018 10:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9AA051C9EF7 for ; Tue, 10 Apr 2018 10:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv-p_k-G28vT for ; Tue, 10 Apr 2018 10:40:06 -0700 (PDT) Received: from [64.170.98.176] (unknown [64.170.98.176]) by c8a.amsl.com (Postfix) with ESMTPSA id 7FCFD1C9E84 for ; Tue, 10 Apr 2018 10:40:06 -0700 (PDT) From: Liz Flynn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 10 Apr 2018 10:40:41 -0700 To: IETF Tools Development X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TOOLS-DEVELOPMENT] Tools Call Notes - 2018-04-10 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 17:40:48 -0000 1. Datatracker Projects - Expected Datatracker Releases -- Robert and Henrik -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan Henrik and Robert will make sure enhancement tickets get created for the = new IRTF requests. Nothing to highlight in the merge plan.=20 2. Community & Other Projects - Discontinue MonArch email archives -- Robert -- Community clearly still likes MonArch speed Ryan has been working on some ways to make the mail archive tool more = responsive.=20 There are two other changes to improve performance: Cloudflare to cache = static pages locally,=20 also migrating to elastic search for back end. This has a dependency on = Torchbox.=20 Russ advises looping in Greg Wood to help with Torchbox.=20 The update that uses the static pages should be ready in 2-4 weeks. 3. RFC Services Projects - RFC Format Contracts -- Heather and Robert -- IDnits -- Publication Formatter -- Text Submission -- RFClint -- SVGcheck -- XMLdiff Robert: Nothing to add to what Heather sent in via email. 4. Server Infrastructure - IESG discussions of DMARC -- Henrik and Alexey -- Deployed for volunteer WGs. Are they happy? Alexey: The only feedback I received was some duplicate = messages, which Henrik is investigating.=20 I haven=E2=80=99t seen any complaints from moderators of the = lists. For the most part, seems to be working as intended.=20 Alexey will reach out to John Levine and ask if he=E2=80=99s = done any testing. -- Mail list system is too fragile. What can be done? Henrik: There are many working parts and it=E2=80=99s hard to = realize all the effects of changing anything. This fragility is a matter = of a fragility in changing and modifying things, not fragile in handling = email - the complexity of the system coupled with how hard it is to have = a mental model of everything that happens with a message. I wrote a = little script that ran through and tested some of the assumptions in the = system before and after we made a change, in order to verify that some = of the things that we=E2=80=99d seen go bad in the past hadn=E2=80=99t = happened during this change. That script seems worthwhile to continue to = build on. I don=E2=80=99t know if there=E2=80=99s anything to do about = the complexity because we asked for it to be complex. Backing out DMARC will be easier than turning on. Before we started = making any changes Glen made a backup so we can always go back to that. = Putting in the new ARC will of course run into many of the same = potential pitfalls as we ran into this time. I suggest we start to try = it out on the sandbox.=20 Russ: I=E2=80=99d like to get the current system out and then once = that=E2=80=99s behind us, take a look at how to do the ARC replacement.=20= 5. Parking Lot - Prepare the RFC Production Center code for publication 6. AOB IESG selected Ekr as new liaison to the Tools team. Welcome Ekr! From nobody Wed Apr 11 12:11:19 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8F1271FD for ; Wed, 11 Apr 2018 12:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_LOTTO=1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv8VvT0aEbFN for ; Wed, 11 Apr 2018 12:11:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EA112DB6C for ; Wed, 11 Apr 2018 12:11:12 -0700 (PDT) Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BJB6jY013643 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 14:11:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local To: Henrik Levkowetz , Alexey Melnikov , IETF Tools Development Cc: Allison Mankin References: <1523277501.1497918.1331474032.6685152E@webmail.messagingengine.com> From: Robert Sparks Message-ID: <072e4e11-779f-8cf5-a783-0e9a4c4083e2@nostrum.com> Date: Wed, 11 Apr 2018 14:11:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------812325D7758D83C91860C34B" Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Datatracker improvement requests from IRTF X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:11:14 -0000 This is a multi-part message in MIME format. --------------812325D7758D83C91860C34B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm trying to turn these into tickets and am having some difficulty with #2 below. I agree that it needs more explanation. The png Alexey sent does not demonstrate the "not useful"ness of the results without more explanation. That result page is showing the existing states, as all search results do. Is it that there aren't enough hints as to where each bit of state is coming from? Or something else that's making the result not what you want? RjS On 4/9/18 8:33 AM, Henrik Levkowetz wrote: > Hi Alexey, Allison, > > Some comments inline as to the functionality. Scheduling and such is a > matter for the TMC and possibly IAOC, where it's a matter of substantially > new functionality. > > On 2018-04-09 14:38, Alexey Melnikov wrote: >> Dear tools team, >> I am forwarding datatracker improvement requests from IRTF. >> >>> 1. Need to be able to do a datatracker search by IRTF state - currently >>> these are not available terms in the advanced search State pulldown > Fixed by Mat Ford, will be available in the next release (expected > tomorrow Tuesday April 9th). > >>> 2. Rationalize the datatracker view when one searches "irtf" - some of >>> the documents are labeled "IRTF RFC Stream," others "Active RG Document" >>> - these aren't useful as is (see attached PNG)... > This needs more explanation. The first of these indicates that the > document is with the RFC Editor, the second that it is with the RG; > In other words, these are very different states. Collapsing them to > one doesn't seem to make sense. What is the actual need here? > >>> 3. Datatracker view when one searches "irtf" or looks at any IRTF >>> document needs to show both the IRTF State and the Tags for the state - >>> the tags are missing now > Ack on this for the search results. There is limited room in the search > results list; would it be meaningful to replace the intended status with > the tags, to save space? > > With respect to showing tags on the individual document pages, they are > shown below the IESG status already, see attached screenshot (from a > development server where I set the 'Waiting for Dependency...' tag on a > document). > >>> 4. Create an online ballot for the IRSG Poll for IRTF documents. >>> Functions - >>> >>> 4a. Create IRSG Poll ballot (IRTF Chair only) >> This is basically similar to IESG telechat ballot. >> >>> 4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse - (all IRSG >>> members) >>> >>> 4c. Enter comments - one kind only, no Discuss - (all IRSG members) >>> >>> 4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG >>> Chair of group, document authors, and RG list >>> >>> 4e. Mark ballot complete (IRTF Chair only) - not automatic since we >>> have a looser definition than IESG's >>> >>> 4f. Once ballot is marked complete, IRTF Chair can request conflict >>> review. Need to be able to do a datatracker search by IRSG state - >>> currently these are not available terms in the State pulldown > Ok, seems clear on first view. I assume the functionality will parallel > that of the IESG ballots where not otherwise specified. > >>> 5. Conflict Review fixes needed: >>> >>> 5a. Currently the conflict review request by IRTF Chair does not include >>> enough notifications - email to IRTF Chair, IRSG, RG Chairs of group, >>> document authors, and RG list > Seems clear enough, and should be straightforward. > >>> 5b. Currently a conflict review automatically assigns the document to >>> the IETF Chair and sets it into the next telechat agenda. The IETF >>> Chair manually changes both of these, and we need notifications when the >>> new AD assignment occurs and when the telechat agenda date is set: same >>> set as line above > Seems clear enough. > > > Best regards, > > Henrik > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development --------------812325D7758D83C91860C34B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I'm trying to turn these into tickets and am having some difficulty with #2 below. I agree that it needs more explanation. The png Alexey sent does not demonstrate the "not useful"ness of the results without more explanation. That result page is showing the existing states, as all search results do. Is it that there aren't enough hints as to where each bit of state is coming from? Or something else that's making the result not what you want?

RjS

On 4/9/18 8:33 AM, Henrik Levkowetz wrote:

Hi Alexey, Allison,

Some comments inline as to the functionality.  Scheduling and such is a
matter for the TMC and possibly IAOC, where it's a matter of substantially
new functionality.

On 2018-04-09 14:38, Alexey Melnikov wrote:

Dear tools team,
I am forwarding datatracker improvement requests from IRTF.

1. Need to be able to do a datatracker search by IRTF state - currently
these are not available terms in the  advanced search State pulldown

Fixed by Mat Ford, will be available in the next release (expected
tomorrow Tuesday April 9th).

2. Rationalize the datatracker view when one searches "irtf" - some of
the documents are labeled "IRTF RFC Stream," others "Active RG Document"
- these aren't  useful as is (see attached PNG)...

This needs more explanation.  The first of these indicates that the
document is with the RFC Editor, the second that it is with the RG;
In other words, these are very different states.  Collapsing them to
one doesn't seem to make sense.  What is the actual need here?

3. Datatracker view when one searches "irtf" or looks at any IRTF
document needs to show both the IRTF State and the Tags for the state -
the tags are missing now

Ack on this for the search results.  There is limited room in the search
results list; would it be meaningful to replace the intended status with
the tags, to save space?

With respect to showing tags on the individual document pages, they are
shown below the IESG status already, see attached screenshot (from a
development server where I set the 'Waiting for Dependency...' tag on a
document).

4. Create an online ballot for the IRSG Poll for IRTF documents. 
Functions -
  
4a. Create IRSG Poll ballot (IRTF Chair only)

This is basically similar to IESG telechat ballot.

4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse - (all IRSG
members)

4c. Enter comments - one kind only, no Discuss - (all IRSG members)

4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG
Chair of group, document authors, and RG list

 4e. Mark ballot complete (IRTF Chair only) - not automatic since we
have a looser definition than IESG's

 4f. Once ballot is marked complete, IRTF Chair can request conflict
review. Need to be able to do a datatracker search by IRSG state -
currently these are not available terms in the State pulldown

Ok, seems clear on first view.  I assume the functionality will parallel
that of the IESG ballots where not otherwise specified.

5. Conflict Review fixes needed:

5a. Currently the conflict review request by IRTF Chair does not include
enough notifications - email to IRTF Chair, IRSG, RG Chairs of group,
document authors, and RG list

Seems clear enough, and should be straightforward.

5b. Currently a conflict review automatically assigns the document to
the IETF Chair and sets it into the next telechat agenda.  The IETF
Chair manually changes both of these, and we need notifications when the
new AD assignment occurs and when the telechat agenda date is set:  same
set as line above

Seems clear enough.


Best regards,

	Henrik

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

--------------812325D7758D83C91860C34B-- From nobody Wed Apr 11 12:39:59 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34712AAB6 for ; Wed, 11 Apr 2018 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_LOTTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhZLdoLq7bN6 for ; Wed, 11 Apr 2018 12:39:55 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A311271FD for ; Wed, 11 Apr 2018 12:39:55 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id a39-v6so2129650pla.10 for ; Wed, 11 Apr 2018 12:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=38hFNdozhJ/XwzGy9Fm+W5spswdZ9Zz4cEDbPF6XYvk=; b=RChkjBgRbSgHmdRli9vYvKbiPSJq7PAv9khGX3nVJwco0alYlCGSqVWITduYiZuf7g NsutN1slXc90H5FamKi+6mxVOLM1G4d4fOnmjcfrgs9W/6PDKDXC7KQT6Z+icx3qHBuv rrWh91MrWTRLaRwapOa1hm8HY6FDIob3LpqgYladORPUvkh/yai9TWVgQl7k+c8xTKje eVE20Qi3259zotbWhSaZkan8CkvzLKw1aUUG+9tZ8Ho5QaXBwDQn65f8BSkxnzI1ge+b P4+bxOTCkTFQgdkmb/GiYPO1pu2Hz9drMjqzZbWlCClCjFAMKWAYQEk/6iOpBqV7+5X5 KkaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=38hFNdozhJ/XwzGy9Fm+W5spswdZ9Zz4cEDbPF6XYvk=; b=ioY/ZYB9PIukjTdIyn+/+04nZhPka1B7WrIQKg1HiwqeU6eexfdASEijQ8DVxNPjNZ o2Gw1APZkwpj67jEMmhB7rA9ex+BrMQwlJvNttA3MxV6aKJH1rG5nbkiV790grk67k/X Fs3kHeAE+vPw394K52pFJzD/tZUX2eHl3prCFlEu0ZXw9nvIOhQZeu9Y+SLdWig4N9Gp HITjBNsiNuNYhmMCSb6aP+GVph3xxPHokliimL69/HlNNqllpG0oir+OAbbyI6Euvyrj ZOd4JIUiK3KoUJB+NLpq4KcS9G+if5WHo2qB3Hi0XNXNW3f6Lm7oKmgV35SKdi1W85By UYtg== X-Gm-Message-State: ALQs6tDrd5JZrhYc9bpqtAVy/qcVY5mqg8RHWps1wt5FNOXZTEO392wv lvzxuW0JXu7/PBznmonmy9DiomsWiXTYb9sjY0E= X-Google-Smtp-Source: AIpwx49MFd+KLbUY800mWOuDPXhiU/RWnTzeaVIlBc3NiQ2ybPxg90diqDL5l8KvZsTLhQymR7SxPQavzDF/7+PVOTk= X-Received: by 2002:a17:902:2941:: with SMTP id g59-v6mr6467894plb.55.1523475595188; Wed, 11 Apr 2018 12:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.229.130 with HTTP; Wed, 11 Apr 2018 12:39:54 -0700 (PDT) In-Reply-To: <072e4e11-779f-8cf5-a783-0e9a4c4083e2@nostrum.com> References: <1523277501.1497918.1331474032.6685152E@webmail.messagingengine.com> <072e4e11-779f-8cf5-a783-0e9a4c4083e2@nostrum.com> From: Allison Mankin Date: Wed, 11 Apr 2018 15:39:54 -0400 Message-ID: To: Robert Sparks Cc: Henrik Levkowetz , Alexey Melnikov , IETF Tools Development , Matthew Ford Content-Type: multipart/alternative; boundary="000000000000acdf5a056997cddc" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Datatracker improvement requests from IRTF X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:39:59 -0000 --000000000000acdf5a056997cddc Content-Type: text/plain; charset="UTF-8" Hi, Robert, Henrik, Thanks for the feedback. Also I'm very pleased by the IRTF States search in Advanced search, so thanks for taking that in! 2. Rationalize the datatracker view when one searches "irtf" - some of > the documents are labeled "IRTF RFC Stream," others "Active RG Document" > - these aren't useful as is (see attached PNG)... > > This needs more explanation. The first of these indicates that the > document is with the RFC Editor, the second that it is with the RG; > In other words, these are very different states. Collapsing them to > one doesn't seem to make sense. What is the actual need here? > > The IRTF RFC Stream tags are not actually indicators that the document is with the RFC Editor, that's the problem. Here are three documents that all should both be "Active RG Document" but one is listed as "IRTF RFC Stream" instead: draft-irtf-hrpc-anonymity.00.txt -IRTF RFC Stream draft-irtf-icnrg-mapme-00.txt - IRTF RFC Stream draft-irtf-icnrg-flic-01.txt - Active RG Document Possibly RG Chairs have some pilot errors, but I don't know what causes it to be set. We have a state Sent to the RFC Editor which is probably good enough, and I'd reserve the IRTF RFC Stream for a future use, not settable by the RG Chairs. Hopefully this is clear enough for a ticket. Let me know. 3. Datatracker view when one searches "irtf" or looks at any IRTF > document needs to show both the IRTF State and the Tags for the state - > the tags are missing now > > Ack on this for the search results. There is limited room in the search > results list; would it be meaningful to replace the intended status with > the tags, to save space? > > With respect to showing tags on the individual document pages, they are > shown below the IESG status already, see attached screenshot (from a > development server where I set the 'Waiting for Dependency...' tag on a > document). > > > I'd be fine with Intended status not being there in this search result - having the tags visible helps with tracking status, and that is the more pressing need. Allison On 11 April 2018 at 15:11, Robert Sparks wrote: > I'm trying to turn these into tickets and am having some difficulty with > #2 below. I agree that it needs more explanation. The png Alexey sent does > not demonstrate the "not useful"ness of the results without more > explanation. That result page is showing the existing states, as all search > results do. Is it that there aren't enough hints as to where each bit of > state is coming from? Or something else that's making the result not what > you want? > > RjS > > On 4/9/18 8:33 AM, Henrik Levkowetz wrote: > > Hi Alexey, Allison, > > Some comments inline as to the functionality. Scheduling and such is a > matter for the TMC and possibly IAOC, where it's a matter of substantially > new functionality. > > On 2018-04-09 14:38, Alexey Melnikov wrote: > > Dear tools team, > I am forwarding datatracker improvement requests from IRTF. > > > 1. Need to be able to do a datatracker search by IRTF state - currently > these are not available terms in the advanced search State pulldown > > Fixed by Mat Ford, will be available in the next release (expected > tomorrow Tuesday April 9th). > > > 2. Rationalize the datatracker view when one searches "irtf" - some of > the documents are labeled "IRTF RFC Stream," others "Active RG Document" > - these aren't useful as is (see attached PNG)... > > This needs more explanation. The first of these indicates that the > document is with the RFC Editor, the second that it is with the RG; > In other words, these are very different states. Collapsing them to > one doesn't seem to make sense. What is the actual need here? > > > 3. Datatracker view when one searches "irtf" or looks at any IRTF > document needs to show both the IRTF State and the Tags for the state - > the tags are missing now > > Ack on this for the search results. There is limited room in the search > results list; would it be meaningful to replace the intended status with > the tags, to save space? > > With respect to showing tags on the individual document pages, they are > shown below the IESG status already, see attached screenshot (from a > development server where I set the 'Waiting for Dependency...' tag on a > document). > > > 4. Create an online ballot for the IRSG Poll for IRTF documents. > Functions - > > 4a. Create IRSG Poll ballot (IRTF Chair only) > > This is basically similar to IESG telechat ballot. > > > 4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse - (all IRSG > members) > > 4c. Enter comments - one kind only, no Discuss - (all IRSG members) > > 4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG > Chair of group, document authors, and RG list > > 4e. Mark ballot complete (IRTF Chair only) - not automatic since we > have a looser definition than IESG's > > 4f. Once ballot is marked complete, IRTF Chair can request conflict > review. Need to be able to do a datatracker search by IRSG state - > currently these are not available terms in the State pulldown > > Ok, seems clear on first view. I assume the functionality will parallel > that of the IESG ballots where not otherwise specified. > > > 5. Conflict Review fixes needed: > > 5a. Currently the conflict review request by IRTF Chair does not include > enough notifications - email to IRTF Chair, IRSG, RG Chairs of group, > document authors, and RG list > > Seems clear enough, and should be straightforward. > > > 5b. Currently a conflict review automatically assigns the document to > the IETF Chair and sets it into the next telechat agenda. The IETF > Chair manually changes both of these, and we need notifications when the > new AD assignment occurs and when the telechat agenda date is set: same > set as line above > > Seems clear enough. > > > Best regards, > > Henrik > > > > > _______________________________________________ > TOOLS-DEVELOPMENT mailing listTOOLS-DEVELOPMENT@ietf.orghttps://www.ietf.org/mailman/listinfo/tools-development > > > --000000000000acdf5a056997cddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi, Robert, Henrik,

Thanks for the feed= back.=C2=A0 Also I'm very pleased by the IRTF States search in Advanced= search, so thanks for taking

that in!

2. Rationa=
lize the datatracker view when one searches "irtf" - some of
the documents are labeled "IRTF RFC Stream," others "Active =
RG Document"
- these aren't  useful as is (see attached PNG)...

This ne=
eds more explanation.  The first of these indicates that the
document is with the RFC Editor, the second that it is with the RG;
In other words, these are very different states.  Collapsing them to
one doesn't seem to make sense.  What is the actual need here?

The IRTF RFC Stream tags are not act= ually indicators that the document is with the RFC
Editor, that's t= he problem.=C2=A0 Here are three documents that all should both be "Ac= tive RG Document" but one is listed

as "IRTF RFC St= ream" instead:

draft-irtf-hrpc-anonymity.00.txt -IRT= F RFC Stream

draft-irtf-icnrg-mapme-00.txt - IRTF RFC Stream<= br>

draft-irtf-icnrg-flic-01.txt - Active RG Document

=20 =20

Possibly RG Chairs hav= e some pilot errors, but I don't know what causes it to be set.=C2=A0 W= e have a state

Sent to the RFC Editor which is probably good= enough, and I'd reserve the IRTF RFC Stream for a future use, not
<= /div>

settable by the RG Chairs.

Hopefully this is cl= ear enough for a ticket.=C2=A0 Let me know.

3. Datatra=
cker view when one searches "irtf" or looks at any IRTF
document needs to show both the IRTF State and the Tags for the state -
the tags are missing now

Ack on =
this for the search results.  There is limited room in the search
results list; would it be meaningful to replace the intended status with
the tags, to save space?

With respect to showing tags on the individual document pages, they are
shown below the IESG status already, see attached screenshot (from a
development server where I set the 'Waiting for Dependency...' tag =
on a
document).

I'd be fine with Intended status not being there in = this search result - having the tags visible helps with tracking status, an= d

that is the more pressing need.

Allison
<= /div>

On 11 April 2018 at 15:11, Robert Sparks <rjsparks@nostrum.com> wrote:

=20 =20 =20

I'm trying to turn these into tickets and am having some difficulty with #2 below. I agree that it needs more explanation. The png Alexey sent does not demonstrate the "not useful"ne= ss of the results without more explanation. That result page is showing the existing states, as all search results do. Is it that there aren't enough hints as to where each bit of state is coming from? Or something else that's making the result not what you want?

RjS

On 4/9/18 8:33 AM,= Henrik Levkowetz wrote:

Hi Alexey, Allison, Some comments inline as to the functionality. Scheduling and such is a matter for the TMC and possibly IAOC, where it's a matter of substantia= lly new functionality. On 2018-04-09 14:38, Alexey Melnikov wrote:

Dear tools team, I am forwarding datatracker improvement requests from IRTF.

1. Need to be able to do a datatracker search by IRTF state = - currently these are not available terms in the advanced search State pulldown

Fixed by Mat Ford, will be available in the next release = (expected tomorrow Tuesday April 9th).

2. Rationalize the datatracker view when one searches "= irtf" - some of the documents are labeled "IRTF RFC Stream," others "Active = RG Document" - these aren't useful as is (see attached PNG)...

This needs more explanation. The first of these indicate= s that the document is with the RFC Editor, the second that it is with the RG; In other words, these are very different states. Collapsing them to one doesn't seem to make sense. What is the actual need here?

3. Datatracker view when one searches "irtf" or lo= oks at any IRTF document needs to show both the IRTF State and the Tags for the state - the tags are missing now

Ack on this for the search results. There is limited roo= m in the search results list; would it be meaningful to replace the intended status with the tags, to save space? With respect to showing tags on the individual document pages, they are shown below the IESG status already, see attached screenshot (from a development server where I set the 'Waiting for Dependency...' tag = on a document).

4. Create an online ballot for the IRSG Poll for IRTF docume= nts.=20 Functions - =20 4a. Create IRSG Poll ballot (IRTF Chair only)

This is basically similar to IESG telechat ballot.

4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse= - (all IRSG members) 4c. Enter comments - one kind only, no Discuss - (all IRSG members) 4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG Chair of group, document authors, and RG list 4e. Mark ballot complete (IRTF Chair only) - not automatic since we have a looser definition than IESG's 4f. Once ballot is marked complete, IRTF Chair can request conflict review. Need to be able to do a datatracker search by IRSG state - currently these are not available terms in the State pulldown

Ok, seems clear on first view. I assume the functionalit= y will parallel that of the IESG ballots where not otherwise specified.

5. Conflict Review fixes needed: 5a. Currently the conflict review request by IRTF Chair does not include enough notifications - email to IRTF Chair, IRSG, RG Chairs of group, document authors, and RG list

Seems clear enough, and should be straightforward.

5b. Currently a conflict review automatically assigns the do= cument to the IETF Chair and sets it into the next telechat agenda. The IETF Chair manually changes both of these, and we need notifications when the new AD assignment occurs and when the telechat agenda date is set: same set as line above

Seems clear enough. Best regards, Henrik

_______________________________________________ TOOLS-DEVELOPMENT mailing list TOOLS-DEVELOPMENT@ietf.org https://ww= w.ietf.org/mailman/listinfo/tools-development

--000000000000acdf5a056997cddc-- From nobody Wed Apr 11 12:55:39 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF5129C56 for ; Wed, 11 Apr 2018 12:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_LOTTO=1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FsOHym3UtRt for ; Wed, 11 Apr 2018 12:55:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E551271FD for ; Wed, 11 Apr 2018 12:55:34 -0700 (PDT) Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BJtSZf021218 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 14:55:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local To: Allison Mankin Cc: Henrik Levkowetz , Alexey Melnikov , IETF Tools Development , Matthew Ford References: <1523277501.1497918.1331474032.6685152E@webmail.messagingengine.com> <072e4e11-779f-8cf5-a783-0e9a4c4083e2@nostrum.com> From: Robert Sparks Message-ID: Date: Wed, 11 Apr 2018 14:55:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------19F77D09C9052527FECE1463" Content-Language: en-US Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Datatracker improvement requests from IRTF X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:55:37 -0000 This is a multi-part message in MIME format. --------------19F77D09C9052527FECE1463 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/11/18 2:39 PM, Allison Mankin wrote: > Hi, Robert, Henrik, > > Thanks for the feedback. Also I'm very pleased by the IRTF States > search in Advanced search, so thanks for taking > that in! > >>> 2. Rationalize the datatracker view when one searches "irtf" - some of >>> the documents are labeled "IRTF RFC Stream," others "Active RG Document" >>> - these aren't useful as is (see attached PNG)... >>> > This needs more explanation. The first of these indicates that the > document is with the RFC Editor, the second that it is with the RG; > In other words, these are very different states. Collapsing them to > one doesn't seem to make sense. What is the actual need here? > > > The IRTF RFC Stream tags are not actually indicators that the document > is with the RFC > Editor, that's the problem. Here are three documents that all should > both be "Active RG Document" but one is listed > as "IRTF RFC Stream" instead: > > draft-irtf-hrpc-anonymity.00.txt -IRTF RFC Stream > draft-irtf-icnrg-mapme-00.txt - IRTF RFC Stream > draft-irtf-icnrg-flic-01.txt - Active RG Document The top two documents do not currently have any IRTF state. The search results view shows the stream when there's no state to show for the stream. The "IRTF RFC Stream" comes from the stream description (I'll dig into the code to see exactly where it comes from), not from a state in the IRTF state machine. > > > > > > > Possibly RG Chairs have some pilot errors, but I don't know what > causes it to be set. We have a state > Sent to the RFC Editor which is probably good enough, and I'd reserve > the IRTF RFC Stream for a future use, not > settable by the RG Chairs. > > Hopefully this is clear enough for a ticket. Let me know. > > >>> 3. Datatracker view when one searches "irtf" or looks at any IRTF >>> document needs to show both the IRTF State and the Tags for the state - >>> the tags are missing now >>> > Ack on this for the search results. There is limited room in the search > results list; would it be meaningful to replace the intended status with > the tags, to save space? > > With respect to showing tags on the individual document pages, they are > shown below the IESG status already, see attached screenshot (from a > development server where I set the 'Waiting for Dependency...' tag on a > document). > > I'd be fine with Intended status not being there in this search result > - having the tags visible helps with tracking status, and > that is the more pressing need. > > Allison > > > On 11 April 2018 at 15:11, Robert Sparks > wrote: > > I'm trying to turn these into tickets and am having some > difficulty with #2 below. I agree that it needs more explanation. > The png Alexey sent does not demonstrate the "not useful"ness of > the results without more explanation. That result page is showing > the existing states, as all search results do. Is it that there > aren't enough hints as to where each bit of state is coming from? > Or something else that's making the result not what you want? > > RjS > > > On 4/9/18 8:33 AM, Henrik Levkowetz wrote: >> Hi Alexey, Allison, >> >> Some comments inline as to the functionality. Scheduling and such is a >> matter for the TMC and possibly IAOC, where it's a matter of substantially >> new functionality. >> >> On 2018-04-09 14:38, Alexey Melnikov wrote: >>> Dear tools team, >>> I am forwarding datatracker improvement requests from IRTF. >>> >>>> 1. Need to be able to do a datatracker search by IRTF state - currently >>>> these are not available terms in the advanced search State pulldown >> Fixed by Mat Ford, will be available in the next release (expected >> tomorrow Tuesday April 9th). >> >>>> 2. Rationalize the datatracker view when one searches "irtf" - some of >>>> the documents are labeled "IRTF RFC Stream," others "Active RG Document" >>>> - these aren't useful as is (see attached PNG)... >> This needs more explanation. The first of these indicates that the >> document is with the RFC Editor, the second that it is with the RG; >> In other words, these are very different states. Collapsing them to >> one doesn't seem to make sense. What is the actual need here? >> >>>> 3. Datatracker view when one searches "irtf" or looks at any IRTF >>>> document needs to show both the IRTF State and the Tags for the state - >>>> the tags are missing now >> Ack on this for the search results. There is limited room in the search >> results list; would it be meaningful to replace the intended status with >> the tags, to save space? >> >> With respect to showing tags on the individual document pages, they are >> shown below the IESG status already, see attached screenshot (from a >> development server where I set the 'Waiting for Dependency...' tag on a >> document). >> >>>> 4. Create an online ballot for the IRSG Poll for IRTF documents. >>>> Functions - >>>> >>>> 4a. Create IRSG Poll ballot (IRTF Chair only) >>> This is basically similar to IESG telechat ballot. >>> >>>> 4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse - (all IRSG >>>> members) >>>> >>>> 4c. Enter comments - one kind only, no Discuss - (all IRSG members) >>>> >>>> 4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG >>>> Chair of group, document authors, and RG list >>>> >>>> 4e. Mark ballot complete (IRTF Chair only) - not automatic since we >>>> have a looser definition than IESG's >>>> >>>> 4f. Once ballot is marked complete, IRTF Chair can request conflict >>>> review. Need to be able to do a datatracker search by IRSG state - >>>> currently these are not available terms in the State pulldown >> Ok, seems clear on first view. I assume the functionality will parallel >> that of the IESG ballots where not otherwise specified. >> >>>> 5. Conflict Review fixes needed: >>>> >>>> 5a. Currently the conflict review request by IRTF Chair does not include >>>> enough notifications - email to IRTF Chair, IRSG, RG Chairs of group, >>>> document authors, and RG list >> Seems clear enough, and should be straightforward. >> >>>> 5b. Currently a conflict review automatically assigns the document to >>>> the IETF Chair and sets it into the next telechat agenda. The IETF >>>> Chair manually changes both of these, and we need notifications when the >>>> new AD assignment occurs and when the telechat agenda date is set: same >>>> set as line above >> Seems clear enough. >> >> >> Best regards, >> >> Henrik >> >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >> > > --------------19F77D09C9052527FECE1463 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 4/11/18 2:39 PM, Allison Mankin wrote:

Hi, Robert, Henrik,

Thanks for the feedback. Also I'm very pleased by the IRTF States search in Advanced search, so thanks for taking

that in!
2. Rationalize the datatracker view when one searches "irtf" - some of the documents are labeled "IRTF RFC Stream," others "Active RG Document" - these aren't useful as is (see attached PNG)...
This needs more explanation.  The first of these indicates that the
document is with the RFC Editor, the second that it is with the RG;
In other words, these are very different states.  Collapsing them to
one doesn't seem to make sense.  What is the actual need here?
The IRTF RFC Stream tags are not actually indicators that the document is with the RFC
Editor, that's the problem. Here are three documents that all should both be "Active RG Document" but one is listed

as "IRTF RFC Stream" instead:

draft-irtf-hrpc-anonymity.00.txt -IRTF RFC Stream

draft-irtf-icnrg-mapme-00.txt - IRTF RFC Stream

draft-irtf-icnrg-flic-01.txt - Active RG Document

The top two documents do not currently have any IRTF state. The search results view shows the stream when there's no state to show for the stream. The "IRTF RFC Stream" comes from the stream description (I'll dig into the code to see exactly where it comes from), not from a state in the IRTF state machine.

Possibly RG Chairs have some pilot errors, but I don't know what causes it to be set. We have a state

Sent to the RFC Editor which is probably good enough, and I'd reserve the IRTF RFC Stream for a future use, not

settable by the RG Chairs.

Hopefully this is clear enough for a ticket. Let me know.

3. Datatracker view when one searches "irtf" or looks at any IRTF
document needs to show both the IRTF State and the Tags for the state -
the tags are missing now

Ack on this for the search results.  There is limited room in the search
results list; would it be meaningful to replace the intended status with
the tags, to save space?

With respect to showing tags on the individual document pages, they are
shown below the IESG status already, see attached screenshot (from a
development server where I set the 'Waiting for Dependency...' tag on a
document).

I'd be fine with Intended status not being there in this search result - having the tags visible helps with tracking status, and

that is the more pressing need.

Allison

On 11 April 2018 at 15:11, Robert Sparks <rjsparks@nostrum.com> wrote:

RjS

On 4/9/18 8:33 AM, Henrik Levkowetz wrote:

Hi Alexey, Allison,

Some comments inline as to the functionality.  Scheduling and such is a
matter for the TMC and possibly IAOC, where it's a matter of substantially
new functionality.

On 2018-04-09 14:38, Alexey Melnikov wrote:

Dear tools team,
I am forwarding datatracker improvement requests from IRTF.

1. Need to be able to do a datatracker search by IRTF state - currently
these are not available terms in the  advanced search State pulldown

Fixed by Mat Ford, will be available in the next release (expected
tomorrow Tuesday April 9th).

2. Rationalize the datatracker view when one searches "irtf" - some of
the documents are labeled "IRTF RFC Stream," others "Active RG Document"
- these aren't  useful as is (see attached PNG)...

This needs more explanation.  The first of these indicates that the
document is with the RFC Editor, the second that it is with the RG;
In other words, these are very different states.  Collapsing them to
one doesn't seem to make sense.  What is the actual need here?

3. Datatracker view when one searches "irtf" or looks at any IRTF
document needs to show both the IRTF State and the Tags for the state -
the tags are missing now

Ack on this for the search results.  There is limited room in the search
results list; would it be meaningful to replace the intended status with
the tags, to save space?

With respect to showing tags on the individual document pages, they are
shown below the IESG status already, see attached screenshot (from a
development server where I set the 'Waiting for Dependency...' tag on a
document).

4. Create an online ballot for the IRSG Poll for IRTF documents. 
Functions -
  
4a. Create IRSG Poll ballot (IRTF Chair only)

This is basically similar to IESG telechat ballot.

4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse - (all IRSG
members)

4c. Enter comments - one kind only, no Discuss - (all IRSG members)

4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG
Chair of group, document authors, and RG list

 4e. Mark ballot complete (IRTF Chair only) - not automatic since we
have a looser definition than IESG's

 4f. Once ballot is marked complete, IRTF Chair can request conflict
review. Need to be able to do a datatracker search by IRSG state -
currently these are not available terms in the State pulldown

Ok, seems clear on first view.  I assume the functionality will parallel
that of the IESG ballots where not otherwise specified.

5. Conflict Review fixes needed:

5a. Currently the conflict review request by IRTF Chair does not include
enough notifications - email to IRTF Chair, IRSG, RG Chairs of group,
document authors, and RG list

Seems clear enough, and should be straightforward.

5b. Currently a conflict review automatically assigns the document to
the IETF Chair and sets it into the next telechat agenda.  The IETF
Chair manually changes both of these, and we need notifications when the
new AD assignment occurs and when the telechat agenda date is set:  same
set as line above

Seems clear enough.


Best regards,

	Henrik

_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DEVELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development

--------------19F77D09C9052527FECE1463-- From nobody Wed Apr 11 12:59:38 2018 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9E012AAB6 for ; Wed, 11 Apr 2018 12:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_LOTTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7Ub2FgWt_0Q for ; Wed, 11 Apr 2018 12:59:33 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC311271FD for ; Wed, 11 Apr 2018 12:59:33 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id b6-v6so2162605pla.11 for ; Wed, 11 Apr 2018 12:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1eJ6G8X2KEQPx3qN5zSXDK4nYV/qlPZ6oeeGtb2diXU=; b=N3vTV21ghM5Ji7QVt2+4+uJYKfv8qNsCb5Q3Yc+GP3YmteQz5oXp6Y25tviWILeJmJ wozHC9xq/+wk+bAU8NEFQ5eyHpDAQ0pTtkw8W5n9MrPN9ds4MaUm24XONwgtepfvnMmv 3KB3kEfoM9246oxToU5ssHk5EaZb3hnKdzuRTj6Lf0kjn8124KKjupONQnxpNWB3qXRR LDmj0axa/U8SM8Qu008Wt0uG8RdPzAL6SJVxrhAp4FfbzI/j82SoUjVRLkEI7w/Jel8Q pbsWxiodTILmd/MBfghuD0lOsBw/I3b1z95NlMjaUouCizKVbrBayFFtZzHsDjI0vK48 uTuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1eJ6G8X2KEQPx3qN5zSXDK4nYV/qlPZ6oeeGtb2diXU=; b=N2P7JMD0YxwaVdtKX0yB9EQOk7MkUZpib4Dz4wTiZIbkfN4iA92x4ULQmnKOrVAXy2 IWPm0q2BhJNTC2FGebEB8RIsmcAC2ao1HNGZ7kXxc0IYUVKY/vSYDdUr1CHw6e100oOh F+mnf8mK+6aAZDnuN6PfM23HuwEbSjJJ+9N69HN/2JOTzOIm3xLs1oeMZie4U05wPBAM bBXb6Sx5xx8k2vqHvZIYTLdJB517Q9v79j28HYObl/hGz7oHDVILhtNklgYmMR/8FPWU XUyvabcH219mX1Tl42tgHq4DF1GF13g67D9Nk1L7P349ALSH4NSrwIJ27EjOvte0rs+N B5fQ== X-Gm-Message-State: ALQs6tBNXEjP4RYjI8+KMegGr3Ejpc+n4mkfvAj1O8ZeXE/PiowkOg+g OZhstmmrr54D1gkZ+43kc0dJinq8UF1tstHITKo= X-Google-Smtp-Source: AIpwx49iIsNPCF8NEq783/Cg17N11popq4VegN6bOGXubXeWtzwyUAsvTpUIAGPaFNnqoGRRXhlGwpdCzBIXnYoHjsY= X-Received: by 2002:a17:902:43:: with SMTP id 61-v6mr6664238pla.259.1523476772824; Wed, 11 Apr 2018 12:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.229.130 with HTTP; Wed, 11 Apr 2018 12:59:32 -0700 (PDT) In-Reply-To: References: <1523277501.1497918.1331474032.6685152E@webmail.messagingengine.com> <072e4e11-779f-8cf5-a783-0e9a4c4083e2@nostrum.com>

From: Allison Mankin Date: Wed, 11 Apr 2018 15:59:32 -0400 Message-ID: To: Robert Sparks Cc: Henrik Levkowetz , Alexey Melnikov , IETF Tools Development , Matthew Ford Content-Type: multipart/alternative; boundary="000000000000de2a0f056998132b" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Datatracker improvement requests from IRTF X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:59:36 -0000 --000000000000de2a0f056998132b Content-Type: text/plain; charset="UTF-8" Heh. That is interesting. So I will ask the RG Chairs to put in an Active RG Document state when they adopt a document, but it would be good to have No State there until there's a state. On 11 April 2018 at 15:55, Robert Sparks wrote: > > > On 4/11/18 2:39 PM, Allison Mankin wrote: > > Hi, Robert, Henrik, > > Thanks for the feedback. Also I'm very pleased by the IRTF States search > in Advanced search, so thanks for taking > that in! > > 2. Rationalize the datatracker view when one searches "irtf" - some of >> the documents are labeled "IRTF RFC Stream," others "Active RG Document" >> - these aren't useful as is (see attached PNG)... >> >> This needs more explanation. The first of these indicates that the >> document is with the RFC Editor, the second that it is with the RG; >> In other words, these are very different states. Collapsing them to >> one doesn't seem to make sense. What is the actual need here? >> >> > The IRTF RFC Stream tags are not actually indicators that the document is > with the RFC > Editor, that's the problem. Here are three documents that all should both > be "Active RG Document" but one is listed > as "IRTF RFC Stream" instead: > > draft-irtf-hrpc-anonymity.00.txt -IRTF RFC Stream > draft-irtf-icnrg-mapme-00.txt - IRTF RFC Stream > draft-irtf-icnrg-flic-01.txt - Active RG Document > > The top two documents do not currently have any IRTF state. The search > results view shows the stream when there's no state to show for the stream. > The "IRTF RFC Stream" comes from the stream description (I'll dig into the > code to see exactly where it comes from), not from a state in the IRTF > state machine. > > > > > > > > Possibly RG Chairs have some pilot errors, but I don't know what causes it > to be set. We have a state > Sent to the RFC Editor which is probably good enough, and I'd reserve the > IRTF RFC Stream for a future use, not > settable by the RG Chairs. > > Hopefully this is clear enough for a ticket. Let me know. > > > 3. Datatracker view when one searches "irtf" or looks at any IRTF >> document needs to show both the IRTF State and the Tags for the state - >> the tags are missing now >> >> Ack on this for the search results. There is limited room in the search >> results list; would it be meaningful to replace the intended status with >> the tags, to save space? >> >> With respect to showing tags on the individual document pages, they are >> shown below the IESG status already, see attached screenshot (from a >> development server where I set the 'Waiting for Dependency...' tag on a >> document). >> >> >> I'd be fine with Intended status not being there in this search result - > having the tags visible helps with tracking status, and > that is the more pressing need. > > Allison > > > On 11 April 2018 at 15:11, Robert Sparks wrote: > >> I'm trying to turn these into tickets and am having some difficulty with >> #2 below. I agree that it needs more explanation. The png Alexey sent does >> not demonstrate the "not useful"ness of the results without more >> explanation. That result page is showing the existing states, as all search >> results do. Is it that there aren't enough hints as to where each bit of >> state is coming from? Or something else that's making the result not what >> you want? >> >> RjS >> >> On 4/9/18 8:33 AM, Henrik Levkowetz wrote: >> >> Hi Alexey, Allison, >> >> Some comments inline as to the functionality. Scheduling and such is a >> matter for the TMC and possibly IAOC, where it's a matter of substantially >> new functionality. >> >> On 2018-04-09 14:38, Alexey Melnikov wrote: >> >> Dear tools team, >> I am forwarding datatracker improvement requests from IRTF. >> >> >> 1. Need to be able to do a datatracker search by IRTF state - currently >> these are not available terms in the advanced search State pulldown >> >> Fixed by Mat Ford, will be available in the next release (expected >> tomorrow Tuesday April 9th). >> >> >> 2. Rationalize the datatracker view when one searches "irtf" - some of >> the documents are labeled "IRTF RFC Stream," others "Active RG Document" >> - these aren't useful as is (see attached PNG)... >> >> This needs more explanation. The first of these indicates that the >> document is with the RFC Editor, the second that it is with the RG; >> In other words, these are very different states. Collapsing them to >> one doesn't seem to make sense. What is the actual need here? >> >> >> 3. Datatracker view when one searches "irtf" or looks at any IRTF >> document needs to show both the IRTF State and the Tags for the state - >> the tags are missing now >> >> Ack on this for the search results. There is limited room in the search >> results list; would it be meaningful to replace the intended status with >> the tags, to save space? >> >> With respect to showing tags on the individual document pages, they are >> shown below the IESG status already, see attached screenshot (from a >> development server where I set the 'Waiting for Dependency...' tag on a >> document). >> >> >> 4. Create an online ballot for the IRSG Poll for IRTF documents. >> Functions - >> >> 4a. Create IRSG Poll ballot (IRTF Chair only) >> >> This is basically similar to IESG telechat ballot. >> >> >> 4b. Enter ballot position, Yes/No Objection/Not Ready/Recuse - (all IRSG >> members) >> >> 4c. Enter comments - one kind only, no Discuss - (all IRSG members) >> >> 4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG >> Chair of group, document authors, and RG list >> >> 4e. Mark ballot complete (IRTF Chair only) - not automatic since we >> have a looser definition than IESG's >> >> 4f. Once ballot is marked complete, IRTF Chair can request conflict >> review. Need to be able to do a datatracker search by IRSG state - >> currently these are not available terms in the State pulldown >> >> Ok, seems clear on first view. I assume the functionality will parallel >> that of the IESG ballots where not otherwise specified. >> >> >> 5. Conflict Review fixes needed: >> >> 5a. Currently the conflict review request by IRTF Chair does not include >> enough notifications - email to IRTF Chair, IRSG, RG Chairs of group, >> document authors, and RG list >> >> Seems clear enough, and should be straightforward. >> >> >> 5b. Currently a conflict review automatically assigns the document to >> the IETF Chair and sets it into the next telechat agenda. The IETF >> Chair manually changes both of these, and we need notifications when the >> new AD assignment occurs and when the telechat agenda date is set: same >> set as line above >> >> Seems clear enough. >> >> >> Best regards, >> >> Henrik >> >> >> >> >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing listTOOLS-DEVELOPMENT@ietf.orghttps://www.ietf.org/mailman/listinfo/tools-development >> >> >> > > --000000000000de2a0f056998132b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Heh.=C2=A0 That is interesting.=C2=A0 So I will ask the= RG Chairs to put in an Active RG Document state when they adopt a document= , but it would be good to have No State there until there's a state.

On 11 April 2018 at 15:55, Robert Sparks <= ;rjsparks@nostrum= .com> wrote:

=20 =20 =20
On 4/11/18 2:39 PM,= Allison Mankin wrote:

Hi, Robert, Henrik,

Thanks for the feedback.=C2=A0 Also I'm very pleased by the IRTF States sear= ch in Advanced search, so thanks for taking

that in!

2. Rationalize the datatracker view when one searche= s "irtf" - some of the documents are labeled "IRTF RFC Stream," others "Active = RG Document" - these aren't useful as is (see attached PNG)...

This needs more explanation. The first of these indicates= that the document is with the RFC Editor, the second that it is with the RG; In other words, these are very different states. Collapsing them to one doesn't seem to make sense. What is the actual need here?

The IRTF RFC Stream tags are not actually indicators that the document is with the RFC
Editor, that's the problem.=C2=A0 Here are three documents = that all should both be "Active RG Document" but one is li= sted

as "IRTF RFC Stream" instead:

draft-irtf-hrpc-anonymity.00.txt -IRTF RFC Stream

draft-irtf-icnrg-mapme-00.txt - IRTF RFC Stream

draft-irtf-icnrg-flic-01.txt - Active RG Document

The top two documents do not currently have any IRTF state. The search results view shows the stream when there's no state to show for the stream. The "IRTF RFC Stream" comes from the stream description (I'll dig into the code to see exactly where it comes from), not from a state in the IRTF state machine.
Possibly RG Chairs have some pilot errors, but I don't know what causes it to be set.=C2=A0 We have a state

Sent to the RFC Editor which is probably good enough, and I'd reserve the IRTF RFC Stream for a future use, not

settable by the RG Chairs.

Hopefully this is clear enough for a ticket.=C2=A0 Let me know.

3. Datatracker view when one searches "irtf&quo= t; or looks at any IRTF document needs to show both the IRTF State and the Tags for the state - the tags are missing now
Ack on this for the search results.  There is limited room=
 in the search
results list; would it be meaningful to replace the intended status with
the tags, to save space?

With respect to showing tags on the individual document pages, they are
shown below the IESG status already, see attached screenshot (from a
development server where I set the 'Waiting for Dependency...' tag =
on a
document).
I'd be fine with Intended status not being there in this search result - having the tags visible helps with tracking status, and
that is the more pressing need.

Allison
On 11 April 2018 at 15:11, Robert Sparks <rjsparks@nostrum.com> wrote:
I'm trying to turn these into tickets and am having some difficulty with #2 below. I agree that it needs more explanation. The png Alexey sent does not demonstrate the "not useful"ness of the results w= ithout more explanation. That result page is showing the existing states, as all search results do. Is it that there aren't enough hints as to where each bit of state is coming from? Or something else that's making the result not what you want?

RjS

On 4/9/18 8:33 AM, Henrik Levkowetz wrote:
Hi Alexey, Allison,

Some comments inline as to the functionality.  Scheduling and such is a
matter for the TMC and possibly IAOC, where it's a matter of substantia=
lly
new functionality.

On 2018-04-09 14:38, Alexey Melnikov wrote:
Dear tools team, I am forwarding datatracker improvement requests from IRTF.

1. Need to be able to do a datatracker search by= IRTF state - currently these are not available terms in the advanced search State pulldown
Fixed by Mat Ford, will be available in the next relea=
se (expected
tomorrow Tuesday April 9th).
2. Rationalize the datatracker view when one sea= rches "irtf" - some of the documents are labeled "IRTF RFC Stream," others "Active = RG Document" - these aren't useful as is (see attached PNG)...
This needs more explanation.  The first of these indic=
ates that the
document is with the RFC Editor, the second that it is with the RG;
In other words, these are very different states.  Collapsing them to
one doesn't seem to make sense.  What is the actual need here?
3. Datatracker view when one searches "irtf= " or looks at any IRTF document needs to show both the IRTF State and the Tags for the state - the tags are missing now
Ack on this for the search results.  There is limited =
room in the search
results list; would it be meaningful to replace the intended status with
the tags, to save space?

With respect to showing tags on the individual document pages, they are
shown below the IESG status already, see attached screenshot (from a
development server where I set the 'Waiting for Dependency...' tag =
on a
document).
4. Create an online ballot for the IRSG Poll for= IRTF documents.=20 Functions - =20 4a. Create IRSG Poll ballot (IRTF Chair only)

This is basically similar to IESG telechat ballot.

4b. Enter ballot position, Yes/No Objection/Not = Ready/Recuse - (all IRSG members) 4c. Enter comments - one kind only, no Discuss - (all IRSG members) 4d. Comments and ballot position get emailed to IRTF Chair, IRSG, RG Chair of group, document authors, and RG list 4e. Mark ballot complete (IRTF Chair only) - not automatic since we have a looser definition than IESG's 4f. Once ballot is marked complete, IRTF Chair can request conflict review. Need to be able to do a datatracker search by IRSG state - currently these are not available terms in the State pulldown
Ok, seems clear on first view.  I assume the functiona=
lity will parallel
that of the IESG ballots where not otherwise specified.
5. Conflict Review fixes needed: 5a. Currently the conflict review request by IRTF Chair does not include enough notifications - email to IRTF Chair, IRSG, RG Chairs of group, document authors, and RG list
Seems clear enough, and should be straightforward.
5b. Currently a conflict review automatically as= signs the document to the IETF Chair and sets it into the next telechat agenda. The IETF Chair manually changes both of these, and we need notifications when the new AD assignment occurs and when the telechat agenda date is set: same set as line above
Seems clear enough.


Best regards,

	Henrik
_______________________________________________
TOOLS-DEVELOPMENT mailing list
TOOLS-DE=
VELOPMENT@ietf.org
https://www.ietf.org/mailman/listinfo/tools-development