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

[Peter Saint-Andre <[e-mail]>]

On 3/1/22 12:19 PM, Peter Saint-Andre wrote:
> This message didn't make it to the Program list...
> 
> 
> -------- Forwarded Message --------
> Subject: Re: [I18ndir] I18ndir last call review of 
> draft-iab-rfcefdp-rfced-model-11
> Resent-Date: Sat, 26 Feb 2022 09:42:26 -0800 (PST)
> Resent-From: [e-mail]
> Resent-To: [e-mail], [e-mail], [e-mail]
> Date: Sat, 26 Feb 2022 12:42:12 -0500
> From: John C Klensin <[e-mail]>
> To: Pete Resnick <resnick=[e-mail]>, Martin Dürst 
> <[e-mail]>
> CC: [e-mail], [e-mail], 
> [e-mail], [e-mail]
> 
> Pete,
> 
> As another acknowledged contributor, I would presumably also be
> exempt even if it were not for your policy of excluding me from
> Directorate reviews.
> That said, an addition to Martin's comments on the i18n-specific
> issues [1]:
> 
> Just as we have seen i18n-related progress within the series,
> with RFC 7997 and elsewhere, as he points out, there have been
> some notable surprises and glitches (one could use stronger
> words) arising at least partially from lack of in-depth i18n
> (and non-Roman script and rendering) knowledge within the RFC
> Editor Function.  Under the system of the last few decades (for
> which I feel less nostalgia than some messages I've received
> seem to assume) the RSE and RPC at least knew were to look for
> help and advice.  Under the proposed new one, the boundaries
> about the level of detail in which the RSWG and RSAB can and
> should get involved is unclear although probably there are
> enough checks built in and that trying to specify that further
> would just lead to prospective micro-management if not madness.
> I also think that provisions about having the RPC represented in
> the RSWG and on the RSAB will probably be sufficient to catch
> obvious difficulties, especially in the light of RPC experience
> with i18n issues in the 5+ years since RFC 1997 was completed.

That's good to know.

> However, I wonder if there should be a formal or informal
> provision for i18n-specific review of proposed actions by the
> RSWG/RSAB that might involve non-ASCII (and, more specifically,
> non-Latin-derived) writing systems.  While solutions may not be
> easy, the important thing is to spot possible issues and spot
> them early.  Martin and I both follow a non-IETF WG and mailing
> list that has recently been forced into a whole new collection
> of issues about markup and embedded text directionality.
> Dealing well with those issues requires either significant
> expertise (which might translate into additional resource
> requirements for the RPC) or a decision that some languages,
> writing systems, and cultures are just less important than
> others (a decision that should not be made casually, much less
> by accident).
> 
> 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).

###

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.)

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].

Peter