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

[Loa Andersson <[e-mail]>]

MSK,

Please see some inline for some comments on comments

On 2014-12-03 10:45, Murray S. Kucherawy wrote:
> On Thu, Jun 12, 2014 at 6:26 AM, The IESG <[e-mail]
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]> mailing lists by 2014-07-10.
>     Exceptionally, comments may be
>     sent to [e-mail] <mailto:[e-mail]> 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 think there is a slight creep in meaning from "functions that are
best performed by secretaries" to "how secretaries best perform these
funtions".

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

Looking at the wg chair - it is not only possible to delegate, but
sometimes close to required. Me and my co-chair once had a document
where we were both co-authors, in that case all the chair task were
delegated to a Shepherd (who in that case also were the responsible AD).
The pwe3 wg delegated Shepherding (including calling consensus and
requesting publication) for a document that "every one" were
co-authoring.

I think that the way of reading this document for this type of delegtion
is that being a secretary it orthogonal, it is not delegated to you
*because* you are a wg secreatry, nor does it disqualify for such
delegation.
>
> 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?

No - see above!

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

Well - the tool team has to answer about their plans, but does hardly
effect progressing this document.

Things like "delegation" are captured in the datatracker, and that is
what the document says: a lot of things are, some of them can only be
done by intervention of an AD or the Secreatariat or a combination
thereof. This document is not the place to describe the dynamics.

>
> 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 [e-mail]
> <mailto:[e-mail]>, 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.

Maybe, but not urgent.

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

Sure, how do you define commonplace, the document is written by folks
that are very experienced working a secretaries for big working groups.

>
> 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 don't see the problem?

>
> 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 read the "Security COnsideration" section more or less as that there
are no issues that will have an impact on the Internet, and making this
clear while explaining what is effected.
>
> I think that's all I have.  Thanks for putting this together.
>
> -MSK

/Loa

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]