Re: [Rfced-future] Fwd: [I18ndir] I18ndir last call review of draft-iab-rfcefdp-rfced-model-11

John C Klensin <john-ietf@jck.com> Wed, 02 March 2022 03:48 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE03A0E06 for <rfced-future@ietfa.amsl.com>; Tue, 1 Mar 2022 19:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 3gsorShHG1FX for <rfced-future@ietfa.amsl.com>; Tue, 1 Mar 2022 19:48:13 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495FF3A0E03 for <rfced-future@iab.org>; Tue, 1 Mar 2022 19:48:13 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1nPFyF-000AFE-EN; Tue, 01 Mar 2022 22:48:11 -0500
Date: Tue, 01 Mar 2022 22:48:05 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, rfced-future@iab.org
Message-ID: <9B6987B47A244C8B58E76C0E@PSB>
In-Reply-To: <3c4497ed-d476-16bc-9aa1-354cd082830e@stpeter.im>
References: <5231BEDE2E5FB8C502855970@PSB> <46de5830-990a-30bf-57fb-ddbc78cbb1fc@stpeter.im> <3c4497ed-d476-16bc-9aa1-354cd082830e@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/XsBCCiXmbh6NDmifyJZq7U_Saa8>
Subject: Re: [Rfced-future] Fwd: [I18ndir] I18ndir last call review of draft-iab-rfcefdp-rfced-model-11
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2022 03:48:18 -0000

Peter,

My snarky comments, to which Pete responded, were not intended
for this list because they are about how that directorate is
organized and how well it is working rather than anything being
discussed on this list.  Those comments are not secret and I
have no objection to their being reposted (with or without
editing), but I have observed that the volume of comments on
this list -- and the amount of repetition, etc. -- are such that
I, and I suspect others, have not been able to follow things
carefully enough to either respond usefully to the many comments
or to get reviews of the three documents completed and posted. I
have been very reluctant to add to the noise with remarks that
are either off-topic or not well-reasoned.  The intrusion of the
Ukrainian invasion on other things I'm involved in -- and the
obvious need for it to take priority-- has made things even
worse.

More inline below, with text elided to prevent this posting from
being harder to follow and getting even longer.

--On Tuesday, March 1, 2022 17:02 -0700 Peter Saint-Andre
<stpeter@stpeter.im> wrote:

>> And, if such a review is appropriate -- even if it stays out
>> of the RFCEDDP documents and we trust that the RSWG and/or
>> RSAB will ask for one if needed-- where does it happen?  
>> This so-called Directorate may include the appropriate
>> people, but, as I understand the rules, it is currently
>> constrained to offering advice to the ART ADs and not to the
>> wider community the RFC Editor Function.
> 
> As Pete noted in his reply (also not sent to the Program list):
> 
>### 
> 
> That is not my reading of our charter:
> 
> https://datatracker.ietf.org/group/i18ndir/about/
> 
>      Advises Area Directors and other IETF stakeholders
> (including other directorates and review teams, such as the
> Security Directorate and ART Area Review Team) with regard to
> internationalization.
> 
> While the top line of our charter is certainly to "assist[]
> the Area Directors of the Applications and Real-Time Area with
> regard to internationalization", I do not see anything that
> prevents us from doing informal reviews for others. Of course,
> if we were to be doing formal review that would probably
> require a more formal role to be identified in the charter
> (and perhaps elsewhere in IETF procedures).
> 
>### 

Pete and I miscommunicated a bit.  My concern would apply had
the i18n directorate, as a directorate, spontaneously taken a
position on the I-D without any of: the request from Mirja, a
request from the ART ADs, or even an informal request from you
(as editor) or Eliot or Brian (about which I hope the ART ADs
would at least be informed)..  It certainly does not apply to
Martin's review.

> Although I agree that internationalization issues can be
> especially thorny, I wonder if this document should say
> something more generally. (For instance, another example might
> be YANG modules, which AIUI in the past have caused some
> adjustments to the editorial process.)

Agreed there is a potential issue.
 
> This could be defined in a new RPC responsibility within
> section 4.3, such as:
> 
>     8. Conferring with relevant experts regarding particular
> kinds of
>        content when publishing RFCs or helping to define
> policies for the
>        Series; such topics might include internationalization
> and
>        localization [RFC 7997], graphical formats such as SVG
> [RFC 7966],
>        and structured content such as YANG modules [RFC 7950].

That goes in a direction I would recommend against.  At present
(and under the "old" system) the can reach out to, or confer
with, just about anyone they decide they need to consult about
just about any issue (I can't think of exceptions, but there
might be some).  If they discover they need to pay consulting
fees to get the advice they need, nothing prevents them from
discussing that with the LLC and asking that the LLC initiate
whatever procedures are needed.  I can see nothing in the new
model that changes that except that, if the LLC were to decide
it needs additional substantive advice, the RSAG and/or RSWG
would be good places to start.

You mentioned YANG.  I suggest there might, in the future, be
issues with JSON and, if people decide they care under the new
model, subtle issues about accessibility.  Others may have other
examples.  As a very different example, I can also imagine the
RPC wanting to seek external expertise about some of the bullet
points under 4.3(17)

All of this works today because the RPC consists of people who
are highly skilled and professional experts in their work, with
broad perspective, and a great deal of good judgment and good
sense.  I hope and trust that will never change.  Should it do
so, we would have far greater problems than who they are allowed
to confer with and about what.  And it would be up to the LLC
--conferring with whomever it thought appropriate but presumably
including the RSAG and RSWG as needed-- to solve that problem.

So, while I think your proposed text is well-written enough,
particularly calling out i18n and the others just as example, to
be mostly harmless, I think making this a specific requirement
rather than an expectation that they will apply good judgment
and knowledge about what they do and do not know.  I fear even
that text could be problematic because it would add nothing
except the possibility of some future debate about whether the
RPC needs specific authorization in other areas.

If you think something more is needed in that rather long list
in Section 4.3, I'd recommend making it far more general.
Please rewrite what I'm about to say, but I'd think about
something like:

	"Identify topics and issues that they encounter while
	processing documents or carrying out other
	responsibilities on this list for which they lack
	sufficient expertise and identifying and conferring with
	relevant experts as needed."  

If we need to say more about the RPC than the document already
contains -- and I don't believe we do -- it should be stronger
language to reinforce the idea that they are not "just
contractors" and hence that replacing them with a collection of
low-bid junior copy editors would be a good (or acceptable)
idea.  But I think the responsibilities listed in that section
and text elsewhere make it clear that would not be an acceptable
idea.

best,
   john

p.s. separate note coming on Section 4.3.