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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2022 12:19:24 -0700

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: [email-masked]
Resent-To: [email-masked], [email-masked], [email-masked]
Date: Sat, 26 Feb 2022 12:42:12 -0500
From: John C Klensin <[email-masked]>
To: Pete Resnick <resnick=[email-masked]>, Martin Dürst 
<[email-masked]>
CC: [email-masked], [email-masked], 
[email-masked], [email-masked]

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.

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.

     john

[1]
https://mailarchive.ietf.org/arch/msg/i18ndir/gpAMRVpH3x6cJcTTlDkWCsMWdeI

--On Friday, February 25, 2022 13:01 -0800 Pete Resnick
<resnick=[email-masked]> wrote:

> On 25 Feb 2022, at 4:21, Martin Dürst via Datatracker wrote:
> 
>> I have contributed to the IAB's RFC Editor Future Development
>> Program  (sorry,
>> that's the official title) and therefore to this document.
>> I'm not  sure why
>> Pete Resnik picked me as the reviewer
> 
> The only reason I picked you was because you were next on my
> list; I hadn't checked the acknowledgements to see if you were
> a contributor. A good reminder to me to do so in the future.
> Thanks for doing the review anyway.
> 
> pr
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2022 17:02:59 -0700

> with i18n issues in the 5+ years since RFC 1997 was completed.

That's good to know.

> offering advice to the ART ADs and not to the wider community

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

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 2 Mar 2022 10:54:20 +0900

Hello Peter, others,

>        and structured content such as YANG modules [RFC 7950].

This looks like a very good direction. However, I'm slightly concerned 
that this includes "or helping to define policies for the Series". I 
think the RPC should reach out to all the help it thinks it needs or can 
benefit from. What I would definitely want to avoid is to create the 
impression that input on I18N,... to the policy definition process has 
to come, or is mainly coming, via the RPC.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Mar 2022 22:48:05 -0500

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
<[email-masked]> 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.
> 
>      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:
> 

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.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Mar 2022 06:55:36 +0100

On 02.03.22 01:02, Peter Saint-Andre wrote:
> (For instance, another example might be YANG modules, which AIUI in 
> the past have caused some adjustments to the editorial process.)
>

That is one reason to have an RSCE.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2022 08:14:11 -0700

> That is one reason to have an RSCE.

True, although we might not be able to assume that the RSCE will have 
knowledge of or expertise on any given topic, although they might have 
insights based on their experience.

We could say "with relevant experts, which might include the RSCE, ..."

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2022 08:19:42 -0700

> to come, or is mainly coming, via the RPC.

Oh, that's certainly not the intent.

Perhaps "when publishing RFCs or contributing to the work of the RSWG".

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2022 14:51:21 -0700

On 3/1/22 8:48 PM, John C Klensin wrote:
> discussed on this list. 

Sorry about that - I forwarded the whole thing to get your feedback 
about internationalization on the record, but could have been more 
careful about removing matters related to operation of the i18ndir.

<snip/>

> <[email-masked]> wrote:

<snip/>

> fees to get the advice they need, 

The text I proposed didn't say anything about paid consulting.

> nothing prevents them from

My personal opinion (no document editor hat on) is that anyone should be 
able to talk with anyone they feel they need to talk with in order to 
Get Things Done around here. If RPC folks feel that it'd be helpful to 
have a chat with someone in or out of the "RFC community" about 
internationalization or SVG or whatever so that they can make informed 
decisions or contributions, then have at it. Perhaps we don't need to 
say that explicitly (and it's kind of sad if we think we need to), but I 
would not want to end up in a place where RPC folks think their hands or 
tongues are tied. They're the one who have to implement this stuff, 
after all!

> 	relevant experts as needed."

Something like that seems appropriate, and closer to what I had in mind.

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Mar 2022 18:54:05 -0500

--On Wednesday, March 2, 2022 14:51 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> organized and how well it is working rather than anything
>> being discussed on this list. 
> 
> Sorry about that - I forwarded the whole thing to get your
> feedback about internationalization on the record, but could
> have been more careful about removing matters related to
> operation of the i18ndir.

No problem.   I've done worse --it was really about just keeping
the noise down.

>...

>> 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, 
> 

I noticed.  I just wanted to be sure there was nothing in the
document that would exclude that in the unlikely even that it
should, in the RPC's judgment and without any ceremony other
than sorting out money and contracts with the LLC, be necessary.
IMO, if we can do small things that, without creating serious
ambiguity, make this document even a bit more future-proof, that
is worthwhile.  Some of what followed were other examples of
that.
 
> My personal opinion (no document editor hat on) is that anyone
> should be able to talk with anyone they feel they need to talk
> with in order to Get Things Done around here. If RPC folks
> feel that it'd be helpful to have a chat with someone in or
> out of the "RFC community" about internationalization or SVG
> or whatever so that they can make informed decisions or
> contributions, then have at it.

Agreed and I've been trying to say similar things throughout
this process.

> Perhaps we don't need to say
> that explicitly (and it's kind of sad if we think we need to),
> but I would not want to end up in a place where RPC folks
> think their hands or tongues are tied. They're the one who
> have to implement this stuff, after all!

Exactly (and concur about the sadness but I'm a tad concerned
about a control freak or two getting involved in the RSWG and
tying things in knots.  So the closer we can get to letting the
RPC do their jobs -- again, talking with anyone they need to --
and without saying anything that encourages the RSWG (or RSAB)
to meddle into anything but broad principles or otherwise
attempt micromanagement, the happier I'll be.

>...

Good.  And unless you or others (particularly Jay) think
otherwise, I think that is sufficient to let us omit specific
mention of paid consulting or the LLC out -- IMO, that just
follows naturally from something like the above.

  -john

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 3 Mar 2022 09:17:54 +0900

Hello Peter,

On 2022-03-03 00:19, Peter Saint-Andre wrote:
>>> 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.)
>>>
>> think the RPC should reach out to all the help it thinks it needs or 
>> can benefit from. What I would definitely want to avoid is to create 
>> the impression that input on I18N,... to the policy definition process 
>> has to come, or is mainly coming, via the RPC.
> 

That would be fine with me.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Mar 2022 23:07:55 -0500

--On Wednesday, March 2, 2022 06:55 +0100 Eliot Lear
<[email-masked]> wrote:

>> something more generally.  (For instance, another example
>> might be YANG modules, which AIUI in  the past have caused
>> some adjustments to the editorial process.)
>> 
>>    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]. 
> 
> 

Independent of the other issues and text -- which I think is now
under control...

While I agree that it is a reason to have an RSCE, assuming the
RSCE will have even moderate levels of knowledge in one, much
less several, of those very specialized areas calls for a much
more in-depth description of requirements for the RSCE position
than is in the draft and that I think was the plan the last time
this was discussed.

best,
   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 Mar 2022 08:54:10 -0700

On 3/2/22 5:17 PM, Martin J. Dürst wrote:
>>>> This could be defined in a new RPC responsibility within section 
>>>> 4.3, such as:
>>>>
>>>> 7966],
>>> This looks like a very good direction. However, I'm slightly 
>>> concerned that this includes "or helping to define policies for the 
>>> Series". I think the RPC should reach out to all the help it thinks 
>>> it needs or can benefit from. What I would definitely want to avoid 
>>> is to create the impression that input on I18N,... to the policy 
>>> definition process has to come, or is mainly coming, via the RPC.
>>

Elsewhere in this thread, John Klensin suggested:

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

Would that meet your needs?

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 Mar 2022 09:08:35 -0700

> is worthwhile.  Some of what followed were other examples of

If I recall correctly, in past threads Jay Daley has cautioned against 
saying too much about contracting matters in this document. That said, I 
don't see anything here that would prevent the RPC or IETF LLC from 
paying consultants to assist in various ways.

> follows naturally from something like the above.

Agreed. Thanks!

Peter