Subject: Re: Last Call: <draft-ietf-iasa2-rfc7437bis-07.txt> (IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees) to Best Current Practice

From: S Moonesamy <[email-masked]>
Date: Tue, 25 Jun 2019 00:18:32 -0700

Hello,
At 12:46 PM 07-06-2019, The IESG wrote:
>The IESG has received a request from the IETF Administrative Support Activity
>2 WG (iasa2) to consider the following document: - 'IAB, IESG, IETF Trust and
>IETF LLC Selection, Confirmation, and Recall
>    Process: Operation of the IETF Nominating and Recall Committees'
>   <draft-ietf-iasa2-rfc7437bis-07.txt> as Best Current Practice
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2019-06-21. Exceptionally, comments may be

There wasn't any proclamation (Section 4.4) during the last plenary 
session [1].  Did the IASA 2.0 Working Group discuss that?

Section 7.1.1 of the draft specifies that a recall petition as a 
"Community Petition".  However, it does not provide any rationale for 
restricting signatories to "members of the IETF community" who can 
afford to attend IETF meetings.  Why are there two classes of members 
in the IETF?

The above-mentioned restriction is contrary to one of the goals of 
the Internet Standards Process, which is fairness.  Unfairness is not 
be usually considered as a "Best Common Practice" and yet this draft 
intends to "standardize" it.  It would be quite unfortunate if the 
members of the IESG condoned the procedure specified in Section 7.1.1.

Regards,
S. Moonesamy

1. 
https://datatracker.ietf.org/meeting/104/materials/minutes-104-ietf-201903271710-00

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 26 Jun 2019 13:56:11 -0400

Hi SM,

> On Jun 25, 2019, at 3:18 AM, S Moonesamy <[email-masked]> wrote:
> 
> Hello,
> There wasn't any proclamation (Section 4.4) during the last plenary session [1].  Did the IASA 2.0 Working Group discuss that?

No. Implementation of the processes described in this document is a matter for individual nomcoms.

> 
> Section 7.1.1 of the draft specifies that a recall petition as a "Community Petition".  However, it does not provide any rationale for restricting signatories to "members of the IETF community" who can afford to attend IETF meetings.  Why are there two classes of members in the IETF?
> 
> The above-mentioned restriction is contrary to one of the goals of the Internet Standards Process, which is fairness.  Unfairness is not be usually considered as a "Best Common Practice" and yet this draft intends to "standardize" it.  It would be quite unfortunate if the members of the IESG condoned the procedure specified in Section 7.1.1.

In response to the Gen-ART review and follow-on discussion, the following sentence has been added to the -08 version of the document:

"This revision addresses only the changes required for IASA 2.0; should the community agree on other changes, they will be addressed in future documents."

Best,
Alissa

> 
> Regards,
> S. Moonesamy
> 
> 1. https://datatracker.ietf.org/meeting/104/materials/minutes-104-ietf-201903271710-00

---

From: S Moonesamy <[email-masked]>
Date: Wed, 26 Jun 2019 12:11:37 -0700

Hi Alissa,
At 10:56 AM 26-06-2019, Alissa Cooper wrote:
> "Community Petition".  However, it does not provide any rationale 
> for restricting signatories to "members of the IETF community" who 
> can afford to attend IETF meetings.  Why are there two classes of 
> members in the IETF?
> >
> > The above-mentioned restriction is contrary to one of the goals 
> of the Internet Standards Process, which is fairness.  Unfairness 
> is not be usually considered as a "Best Common Practice" and yet 
> this draft intends to "standardize" it.  It would be quite 
> unfortunate if the members of the IESG condoned the procedure 
> specified in Section 7.1.1.
>
>In response to the Gen-ART review and follow-on discussion, the 
>following sentence has been added to the -08 version of the document:
>
>"This revision addresses only the changes required for IASA 2.0; 
>should the community agree on other changes, they will be addressed 
>in future documents."

If I am not mistaken, the process for this Last Call is based on BCP 
9.  The proposed sentence unfortunately does not address the comments 
which I sent on the Last Call.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2019 11:18:03 +1200

Hi SM,

below...

> which I sent on the Last Call.

Maybe it was a bit too summarised, but the scope of *this* update to
the NomCom process was (according to the charter of the IASA2 WG in general)
to make the changes required by the creation of IETF LLC and the closing
of the IAOC. So I think the response is correct: state this scope restriction
in the document and move on.

The whole NomCom process probably does need a re-examination; the issue
of how to enfranchise remote attendees is only part of it, I think, and
there may be even more fundamental issues. But I think that should be a
separate process (probably starting by somebody building a list of perceived
problems). It will take some time, and approving the essential changes due
to IETF LLC is somewhat urgent.

Regards
    Brian

---

From: S Moonesamy <[email-masked]>
Date: Thu, 27 Jun 2019 02:37:36 -0700

Hi Brian,
>to IETF LLC is somewhat urgent.

My Last Call comment was about Section 7.1.1 of RFC 7437.  It was not 
about a list of perceived problems with the NomCom process.  It is 
not clear what the fundamental issues (mentioned above) are.  Are 
those issues related to RFC 7704?

Regards,
S. Moonesamy

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 27 Jun 2019 11:44:57 -0400

> On Jun 26, 2019, at 7:18 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi SM,
> 
> below...
> 

Yes. This document does not provide a rationale for how it defines nomcom-eligibility because RFC 7437 does not provide such a rationale. Providing such a rationale or changing the definition of nomcom-eligibility are not changes required for IASA 2.0, so they are not in scope for this document.

Thanks,
Alissa

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Jun 2019 16:19:37 -0400

--On Thursday, June 27, 2019 02:37 -0700 S Moonesamy
<[email-masked]> wrote:

>> The whole NomCom process probably does need a re-examination;
>> the issue of how to enfranchise remote attendees is only part
>> of it, I think, and there may be even more fundamental
>> issues. But I think that should be a separate process
>> (probably starting by somebody building a list of perceived
>> problems). It will take some time, and approving the
>> essential changes due to IETF LLC is somewhat urgent.
> 
> My Last Call comment was about Section 7.1.1 of RFC 7437.  It
> was not about a list of perceived problems with the NomCom
> process.  It is not clear what the fundamental issues
> (mentioned above) are.  Are those issues related to RFC 7704?

Subramanian,

As you know, I'd like to see the issues with different treatment
for remote participants and f2f meeting attendees who make
equivalent contributions to the IETF (in whatever reasonable way
that is measured) resolved, resolved soon, and resolved in favor
of maximizing fairness, openness, and balance.   I also think
that is long overdue and that every month the IETF allows to go
by without addressing it reduces that IETF's credibility as
representing and including a broad sample of the experts in the
network engineering and protocol design communities.

I have serious misgivings about replacing older documents with
new ones that do not resolve all known outstanding issues.  You
will recall that was my core argument for moving toward
draft-ietf-iasa2-consolidated-upd and away from replacing a slew
of documents and that I would have preferred to eliminate
7437bis in favor of a list of changes there.  However, it seems
to me that the WG, with significant input from the responsible
AD, decided to keep this one separate and replace the core
document.  That decision went hand-in-hand with decisions to
interpret the WG's scope very narrowly and exclude changes to
other documents that would have had the effect of patching known
problems, even to apply patches for which it seemed fairly clear
that there was consensus in the community.   I don't need to
like those decisions (and you don't either), but I think we need
to recognize that insisting that everything be addressed and
fixed leads to madness and hence that some judgment calls about
scope, ordering, and priorities are needed.

I think adding an explicit scope statement (as Barry has done)
is appropriate and necessary.   Given how important decisions
about scope have been to the work and progress of the WG, I hope
that the WG, document authors, and the IESG can review other WG
documents -- even those already approved and in the publication
queue-- to see if those documents would appropriately get
similar disclaimers.  But I don't see trying to hold this (or
other) documents up until those issues are resolved helps the WG
or the IETF.

That said, I think that, if WG Chairs or an AD take the position
that an issue that arises in the natural course of editing or
review of a document is out of scope -- essentially that the
community is not allowed to discuss or act on it in that
context-- they take on some obligation to be sure that there is
a forum for the discussion and facilitating that discussion as
well as to being absolutely consistent about what is or is not
out of scope.  I think we are doing fairly well about the latter
(with not including Barry's clarification as  good example).  I
can only hope that we will do equally well at the former but
have seen no evidence that won't happen if appropriate requests
are made.

best,
   john