Re: Last Call: <draft-secretaries-good-practices-06.txt> (IETF Working Groups' Secretaries) to Best Current Practice

[Martin Vigoureux <[e-mail]>]

Murray,

Le 08/12/2014 19:17, Murray S. Kucherawy a écrit :
> On Wed, Dec 3, 2014 at 6:27 AM, Martin Vigoureux
> <[e-mail]
> <mailto:[e-mail]>> 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