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

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

Hi Loa,

There are clearly bigger fish to fry now, but in reply to a couple of your
points:

On Tue, Dec 2, 2014 at 9:20 PM, Loa Andersson <[e-mail]> wrote:

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

Right, I think that's what I was noticing as well.

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

I agree that's probably what was intended.  I just think the way it's
expressed has gotten a bit muddy (as the rest of this thread now suggests).


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

Sure.  I just wonder what the authors thought, or what the community
thinks, about documents like this that talk about what the tracker can do
when that can change easily in the not-too-distant future.  It might be
better to talk about things in the abstract rather than being as specific
as we are here.


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

I definitely agree with that last part.


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

Same point though.


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

Right, but I also run a big working group that hasn't availed itself of a
secretary (though we do delegate shepherding to various non-chair people
often).  I have no idea how many WGs have secretaries, now or historically,
nor what functions are commonly delegated.

Basically, I feel that if delegation is anything more than infrequent, we
should be looking at doing this as an update to RFC2418.


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

There might not be.  I just wanted to make sure someone working on this
document had actually confirmed this, since draft-leiba-extended-doc-shepherd
actually says quite a bit about shepherding.  Specifically, that document
not only says that the shepherd might best be appointed early on in the
document's life cycle, but that it might be appointed to the secretary
(hence my overlap question) or some other non-chair participant.  It might
be useful to cite that document as an interesting informative reference,
although I also admit that its path to publication is presently unknown.


>
>  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 those two points are separable (see my other note from this
morning).

-MSK