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

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

 



Murray,

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





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