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

[Alissa Cooper <[e-mail]>]

> On Jun 26, 2019, at 7:18 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Hi SM,
> 
> below...
> 
> On 27-Jun-19 07:11, S Moonesamy wrote:
>> Hi Alissa,
>> At 10:56 AM 26-06-2019, Alissa Cooper wrote:
>>>> 
>>>> 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."
>> 
>> 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.
> 
> 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.

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

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