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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Thursday, June 27, 2019 02:37 -0700 S Moonesamy
<sm+ietf@xxxxxxxxxxxx> wrote:

> Hi Brian,
> At 04:18 PM 26-06-2019, Brian E Carpenter 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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux