Murray,
Le 08/12/2014 19:17, Murray S. Kucherawy a écrit :
On Wed, Dec 3, 2014 at 6:27 AM, Martin Vigoureux
<martin(_dot_)vigoureux(_at_)alcatel-lucent(_dot_)com
<mailto:martin(_dot_)vigoureux(_at_)alcatel-lucent(_dot_)com>> wrote:
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"
I didn't get that impression. I got the impression that it's a list of
things a secretary might do. If the goal is to encourage secretaries to
be assigned that do most or all of these things, then that's gotten lost.
This sentence has been misunderstood.
It never meant to say that, to be good, secretaries should/must do all
that. But rather, if my WG secretary was to do all that then I could
spend more time on more technical & productive type of work.
In any case this was my personal appreciation. Each chair is free to set
his/her own standard for "good" (from no secretary, to whatever he/she
delegates to the secretary)
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.
Yes, of course. I just noted that this was absent, and it can be a
pretty major thing to help the co-chairs.
If you refer to your second question above, then, up until 06 we had
some text which covered that:
o Doing "Chair-like" work
Depending on the established working relationship between the WG
Chairs and the Secretary, the latter could take actions, typically
under the direct responsibility of WG Chairs, such as to launch or
close WG document's adoption polls or WG Last Calls.
We decided to remove it.
Let me elaborate on why, IMHO:
From an helicopter view, I could classify the
tasks/functions/responsibilities of WG chairs in two buckets:
Those which are the expression of an authority and those which are not.
In the former bucket I would put all the actions pertaining to the
standardisation process (WG adoption, consensus evaluation, WG LCs, IESG
pub, but also technical guidance, WG steering, and so on). The list is
far from being precise nor exhaustive, but I hope you get the point. In
the latter bucket I would put most of the admin work (taking minutes,
running slides, uploading presentations, publishing minutes, pressing
buttons in the tracker, not forgetting something you said, ...).
I hope you see the distinction I am making between the two buckets.
For me what makes a chair a chair is the former, not the latter, because
of the authority dimension.
So, this is where Secretaries could come into the picture. If the admin
piece is too big or simply a pain for the chairs, then it could be
delegated to a helping hand ...
As a side point, most of the elements in the former bucket have an admin
part (send an e-mail, monitor answers, press buttons, ...) but splitting
these in two would really be unproductive.
So, to answer your question, in line with the above and because we
received comments calling out for clarifications, we removed the piece
of text I have cited.
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 experience of other WG chairs and ADs might be different, but it
seems to me there might be some functions like this one that really
should be restricted to the co-chairs since they're ultimately the ones
responsible for the document's handoff to the IESG. Otherwise, at that
point, why not just make the WG secretary into the chair?
I am not a Secretary/Delegate any more so I can't tell you if this is
effectively the case, but I agree with you.
There needs to be a demarcation between what a chair and a
secretary/delegate can/is allowed to do otherwise a secretary is a
chair. Note that this echoes what I have said above.
By the way, in the tracker Delegate and Chair do not have the same
rights. A Delegate can't update milestones for example.
On the other hand I do not expect that a Delegate would press the
"submit to the IESG" button without having received the approval from
the chairs.
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.
Maybe that's what's missing from my experience: The relationship isn't
created by any button I have access to now, but an email to the
Secretariat is needed to establish it. That's also something Robert
Sparks may have answered in that the current navigation to create a WG
secretary is broken but will be fixed.
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.
OK, then I suppose I disagree with that consensus. You're basically
trying to augment what little is in 2418, and it should be handled that way.
Even if versions 02 to 06 had the intent to update 2418, the original
(and current) intent was not to augment anything but simply to openly
share experiences of -and views on- WG Secretaries. Apparently this was
a mistake.
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.
That makes it sound like you haven't checked... ;-)
I did, even if not word by word.
The text so short and says so little that I do not see any possible
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.
BCP 72, which makes that section mandatory for protocols, doesn't say
anything about using that section to talk about "security" with respect
to our processes. I think, given that, the section is misnamed.
If it's not forbidden then it is allowed, no? :-)
I do not think it is harmful anyway.
-MSK
-m