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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Dec 3, 2014 at 6:27 AM, Martin Vigoureux <
[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.


>
>  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.


>
>  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?


>  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.


>  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 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.

-MSK