Murray,
thank you for your review. Please see in-line.
-m
Le 03/12/2014 03:45, Murray S. Kucherawy a écrit :
On Thu, Jun 12, 2014 at 6:26 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org
<mailto:iesg-secretary(_at_)ietf(_dot_)org>> wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'IETF Working Groups' Secretaries'
<draft-secretaries-good-practices-06.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
ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org> mailing lists by
2014-07-10.
Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org <mailto:iesg(_at_)ietf(_dot_)org> instead.
In either
case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
The Working Group Secretary's role was succinctly defined in RFC
2418. However, this role has greatly evolved and increased both in
value and scope, since the writing of RFC 2418. This document
updates
RFC 2418 by providing a new definition of the Working Group
Secretary's role. This document also provides a compilation of good
practices and general guidelines regarding the fulfilment of the
role.
This document is intended for established Working Group Secretaries,
individuals motivated by taking up that role, or anyone else simply
interested in understanding better the Working Group Secretary's
role. This document may also be useful for Working Group Chairs to
better appreciate and help develop the value of Working Group
Secretaries.
This document would be published as part of BCP 25.
I've read this document and am generally in support of its progression.
However, I have a few questions and comments.
The filename portion of the document says "good practices". This is a
minor point since that name will vanish on publication, but since it
also does say it in the Abstract, I wonder if the original intent may
have gotten lost. This seems to be an accretion of possible functions
of a WG Secretary, but doesn't really explain how best to perform those
functions (which I infer from the filename).
I like to view it as: "it is good if a secretary does all that"
The document amounts to an enumeration of the functions of the WG
co-chair, minus the authority to make consensus calls and moderate the
mailing list. Could not the co-chair delegate at least the list
moderation function to a secretary? What about issuing and tracking
calls for document adoption?
In principle Chairs can delegate whatever they want.
Does ensuring documents are in the correct state include submitting them
to the IESG for publication, or is that a reserved function for the
co-chairs?
As far as I remember, a "Delegate", in the datatracker sense, can press
the submit to IESG button.
The document makes reference to several tools or components of tools
(the datatracker in particular) that I've never seen. That's not to say
they don't exist, but I haven't seen them and couldn't find them just
now, so it makes me wonder if the tools team would have to do a bunch of
work to get reality to match what's written here. For example, I just
went into the datatracker and as a working group co-chair I have
privileges in that system with respect to my working groups. However, I
didn't see anywhere in there that I can declare a WG Secretary or
delegate some or all of my powers to that person, despite the fact that
Section 4 says such things "shall" be done. Is this something that a
co-chair would have to request of the Secretariat directly or via a
sponsoring Area Director? If not, does the tools team intend to add that?
I am not sure to understand; which of the mentioned tools you do not know?
As said by Loa, an e-mail to the Secretariat does the trick.
Yet, if I remember correctly, once you have a secretary for your WG you
can delegate powers to that person from the datatracker.
Similarly, I'm a little concerned about writing something that
specifically calls out things in our tools that might change over time,
even over a short time if we so decide, rendering this text inaccurate.
For example, rather than referring to
wgname-chairs(_at_)tools(_dot_)ietf(_dot_)org
<mailto:wgname-chairs(_at_)tools(_dot_)ietf(_dot_)org>, it might be better to
say simply
"the working group chairs' mailing list" or suchlike, in case we were to
for example drop "tools." from the addresses.
I am sure readers will handle the situation where such aliases have changed.
I think that if appointment of WG Secretaries who do most or even some
of these functions has become commonplace, then this should officially
update RFC2418. What RFC2418 says now is a four-line section; if that's
obsolescent, we shouldn't leave it that way without at least offering a
pointer to the more current practice. More generally, if RFC2418 is
obsolescent, I think we should think about updating it in its entirety.
Following discussions on 06 we have decided that this document would not
update 2418. We have produced 07 in that sense.
The end of Section 3 might overlap or even conflict with
draft-leiba-extended-doc-shepherd (currently expired but not
forgotten). Is there a plan to reconcile these, or am I wrong about
there being common ground here?
I doubt there is any conflict.
I was under the impression that Security Considerations has to do with
impact on the Internet, not on our processes, and so the content of that
section isn't really needed (other than to point out what I just said),
but I could be wrong about that.
I think the content of that section is important, even if not relevant
to Internet, and it does not fit so badly in a section called Security
Considerations.
I think that's all I have. Thanks for putting this together.
Thank you for your appreciation.
-MSK