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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Dec 2014 18:45:55 -0800

On Thu, Jun 12, 2014 at 6:26 AM, The IESG <[email-masked]> 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
> [email-masked] mailing lists by 2014-07-10. Exceptionally, comments may be
> sent to [email-masked] 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).

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?

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?

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?

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 [email-masked], 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.

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.

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 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 that's all I have.  Thanks for putting this together.

-MSK

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Dec 2014 13:20:58 +0800

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]> mailing lists by 2014-07-10.
>     Exceptionally, comments may be
>     sent to [email-masked] <mailto:[email-masked]> instead. In either
>     case, please retain the
> 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 [email-masked]
> <mailto:[email-masked]>, 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

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

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

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

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2014 11:06:37 -0000

> thereof. This document is not the place to describe the dynamics.

As AD I can see the place to make these changes in the data tracker. It's possible that the permissions are not set to allow chairs to make these changes.

datatracker
sign in
https://datatracker.ietf.org/wg/foowg/charter/
"Edit group"  <<< possibly this you don't have access to as a chair?
fill in the fields

Adrian

---

From: Robert Sparks <[email-masked]>
Date: Wed, 03 Dec 2014 08:26:50 -0600

>> effect progressing this document.
Exactly.
> As AD I can see the place to make these changes in the data tracker. It's possible that the permissions are not set to allow chairs to make these changes.
The ability for a chair to assign delegates has existed for a long time, 
but is currently broken (at least the navigation to it is broken).
We're tracking fixing it at 
<http://wiki.tools.ietf.org/tools/ietfdb/ticket/1546>.
Expect the ability to return to normal soon.

Pulling up to the spirit of the comment. I'm the assigned Gen-art 
reviewer for this document.
I don't remember seeing anything sticking out at me as requiring new 
tooling work beyond
our normal incremental style of improvement when I reviewed -06 last summer
  (see 
<https://mailarchive.ietf.org/arch/msg/gen-art/qUXolKK3UgJVX5xZMubFX36GgeU>).
That is, we can always make it _easier_ to do lots of these things.
And on a quick skim of -07, (I'll send a telechat review later),  I 
still don't see anything.

RjS

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 3 Dec 2014 15:27:06 +0100

Murray,

thank you for your review. Please see in-line.

-m

> functions (which I infer from the filename).

I like to view it as: "it is good if a secretary does all that"

> calls for document adoption?

In principle Chairs can delegate whatever they want.

> to the IESG for publication, or is that a reserved function for the

As far as I remember, a "Delegate", in the datatracker sense, can press 
the submit to IESG button.

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

> for example drop "tools." from the addresses.

I am sure readers will handle the situation where such aliases have changed.

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

> there being common ground here?

I doubt there is any conflict.

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

> I think that's all I have.  Thanks for putting this together.

Thank you for your appreciation.

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Dec 2014 09:40:16 -0500

Hi.

I imagine I'm wasting my time, but I want to at least reference
comments that I have made before about this document and that,
AFAICT, have not been responded to in any way.

Whether as BCP (worse) or Informational, this document reads in
many places as if it is extremely normative and factual.   It is
not the second and should not be the first.  Practices differ to
a very large degree among WGs, WG Chairs, Areas, and and
circumstances.  What works well in one situation may not work at
all well in others.  The IETF has succeeded in part, not only
because of the quality of our technical work but because we've
had, and carefully guarded, the ability to adjust procedures and
practices to meet circumstances rather than trying to force
everything into a "one size fits all" mold.   While I assume,
from some of the text, that is not the intention of the authors,
our increasingly-long history of having general guidance evolve
into rigid rules indicates that, if the document is published in
its current form, it will be only a matter of time before
someone complains about proposed publication of a document
because the WG did not have a secretary or someone else
complains that, as a WG Secretary, he or she has certain
entitlements.

Statements like the following illustrate the problem (I'm giving
only a few in the hope of keeping this short enough that people
will actually read it):

"this role has greatly evolved and increased both in value and
scope..." (Abstract).  True for some WGs, simply false for many
others, and we could have a long discussion about "value".  That
discussion, however, would be a waste of valuable time that
could better be spent on technical work.

"WG Secretary's role has greatly evolved to include a number of
additional delegated functions and responsibilities which are
critical to the smooth operation of IETF WGs." (Introduction)
"Critical to smooth operation" strongly implies that any WG that
does not have a Secretary is defective and, a priori, doesn't
operate well.

"Section 3 of this document gives detailed descriptive
information of the WG Secretary's functions, responsibilities,
and good practices." (Introduction) Strongly implies that all
Secretaries and their roles are the same, or should be.

"However, WG Chairs can delegate punctually or durably any of
their responsibilities to someone else." (Section 2).  I don't
know what that sentence means and have some claim to be a native
and literate speaker and reader of English.

"...lists a subset of WG Chairs' functions and responsibilities
which can typically be delegated to a WG Secretary." (Section 2)
Whether 2119 is invoked or not, that is normative language.  It
is also unclear what it means: "can typically be delegated"
requires clarification as to what the exceptions are.  Otherwise
they either "can be delegated" or they cannot; "typically can"
makes no sense.  

The following paragraph,
   "The framework and perimeter of action associated to the WG
   Secretary's role, depends on the WG Secretary and the
   Chairs, as well as on the professional relationship they
   establish. Therefore this document does not prescribe what
   must be performed, but lists what might be performed by a WG
   Secretary. Also, this list is intended to be as complete as
   possible, but it shall not be considered as exhaustive. This
   document is therefore not a rigid job description."
effectively contradicts what has come before, possibly to blunt
some of the type of the criticism I (and others) have voiced.
Its effect, however, is merely to contradict and create
confusion.

More examples on request.

This document is not ready for prime time in its current form.
It is part of a style of doing things by making more rules or
apparent rules that is actually hazardous to the further of the
IETF as anything but a traditional SDO that approves things on
the basis of procedure-conformance rather than thinking.  If
approved for publication at all, it should be approved only
after revision to make it very clear it is about suggestions
that might be applicable to some situations, with those
situations at WG Chair discretion.

    john

---

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Dec 2014 05:52:29 -0900

> situations at WG Chair discretion.

I'd like to echo what John said.  I'm somewhat concerned that
the growth of the wg secretary role has something to do with
an inability (or unwillingness) to deal directly with poor chair
performance.  Individual chairs may prefer to have the
assistance but I am truly sorry to see this becoming typical
working group practice.  "All problems can be solved by introducing
a layer of indirection" may be a slightly entertaining joke
about programming practice but it seems a woeful approach to
organizational problems.

Melinda

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Dec 2014 10:03:12 -0500

Martin,

This is slightly a follow-up to  the note I just posted, taking
Murray's comments up a level.

--On Wednesday, December 03, 2014 15:27 +0100 Martin Vigoureux
<[email-masked]> wrote:

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

And that is _very_ normative too.  IMO, a _good_ secretary does
whatever is assigned to him or her by the WG Chair and that will
help the WG progress its work.  Good secretaries might propose
additional things that could be done to aid with the work, but
does not make those decisions and MUST NOT be able to cite this
document as justification for expanding the role beyond what the
WG Chair(s) believe is appropriate for the WG.  

What is at issue here is not merely my general objection to
making more rules but the critical question of whether ADs, WG
participants, and the community in general can hold WG Chairs
accountable.   As soon as a Secretary can act independently of
WG Chairs because some RFC says "it is good if a secretary does
all that", Chair accountability is lost.

Make whatever suggestions for things a WG Secretary might be
assigned to do that you like.  Provide, as Murray suggests,
something of a tutorial about how to do those things (or at
least one or two ways to do them).  But let's not do or say
anything that appears to give Secretaries independent authority.

>...

Then say that and drop everything in this document that implies
functions that should be delegated to secretaries or that are
inherently delegated as the result of the claimed evolution the
role.

A different version of that comment is that it used to be
typical to have one WG Chair.  We've now evolved to the point
where co-chairs are the norm and single ones unusual.   This
document appears to be making the rule "two co-chairs and a
junior chair designated 'secretary'".   Adding in document
authors, we could evolve to the point that every active
participant in a WG, and some inactive ones, gets a title.  I
hope we don't.

>...
> Following discussions on 06 we have decided that this document
> would not update 2418. We have produced 07 in that sense.

But the changes you have made don't eliminate enough of the
normative/ updating text to make that clear.  The result is just
confusion.

Sorry, but, unlike Murray, I don't appreciate this document.  I
think it is a solution to a problem that doesn't need solving, a
step backward in process flexibility and clarity, and that the
two jobs it could usefully do --providing advice about things a
secretary MIGHT be asked to do and guidance about how to do
them-- are either absent or get lost in the normative-appearing
noise.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Dec 2014 10:26:27 -0500

--On Wednesday, December 03, 2014 05:52 -0900 Melinda Shore
<[email-masked]> wrote:

> an inability (or unwillingness) to deal directly with poor
> chair performance.  Individual chairs may prefer to have the
> working group practice.  "All problems can be solved by
> introducing a layer of indirection" may be a slightly
> entertaining joke about programming practice but it seems a
> woeful approach to organizational problems.

Melinda, 

Well put and thanks for getting to the core of the problem.   I
actually like having WG Secretaries for a few reasons that are
separate from the above (and largely separate from the
discussion in the document).  Used well, under the right
circumstances, and with appropriate care, the WG Secretary role
may be a good leadership development activity -- under some
circumstances, far more appropriate than appointing a junior or
inexperienced person as a co-chair who really shouldn't be
considered accountable for WG performance. 

For those who like structure and titles, perhaps we should
formally create an "Assistant Chair" or "Apprentice Chair" role,
give it a fancy title that would look good on CVs and to
corporate folks working on travel budgets, and downplay
"Secretary".  I hope I'm joking.

But, again, use of "WG Secretary" for leadership development is
an argument for flexibility with the title and role, not a
document that appears to suggest that all good WGs should have
secretaries and that good secretaries should do some particular
list of things.

That is the last from me on this topic, especially since the
tracker says "(Has enough positions to pass.)".   If true, that
leaves the appeals process (on the grounds that these issues
have been raised before, going back at least to August, and
never seriously addressed) and/or a discussion with the Nomcom
(on the grounds that the IESG is exercising bad judgment by
regularly putting these "more rules and more structure"
proposals in front of the community and the Nomcom is the only
realistic remedy for collective IESG bad judgment).

   john

---

From: Ralph Droms <[email-masked]>
Date: Wed, 3 Dec 2014 07:44:42 -0800

I agree with what John has written.

In pragmatic support of John's points, I am currently co-chair of one WG and interim co-chair of another.  The two WGs I currently co-chair simply don't involve enough operational overhead to warrant a secretary.  I don't see the need for (quoting John) a "document [that] reads in many places as if it is extremely normative and factual."

I will repeat my suggestions from the previous review cycle for this document:

Here are my opinions on how to proceed...

First, it's important that RFC 2418 be updated to allow for a WG
secretary to take on greater responsibilities, at the discretion of
the WG chairs.  It's also important that the update include formal
recognition that WG secretaries should be given access to WG support
tools.  Therefore, I recommend that RFC 2418 be updated with a short
RFC that expands the potential role for WG secretaries and that
formally grants permission for secretaries to have access to WG tools.

Second, because the [the document contains] a series of recommendations
that may not apply to all WGs and that may change over time, I
recommend that this very useful material be integrated into the IETF
wiki "Working Group Chairs' Page" <http://www.ietf.org/wg/chairs-page.html>

- Ralph

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2014 16:05:28 -0000

John,

I placed the document on the IESG telechat after a period of silence that
followed the publication of the -07 version of the document and an email
summarising the changes from the editor.

At the same time I sent an additional note to this list. I don't know (or care)
whether that is what triggered renewed conversations, but I welcome them. I
don't think you should take such a negative tone and assume that the no-one
wants to listen to your concerns. Let's see whether we can address them before
the telechat in just over two weeks' time.

I believe I see two issues raised by you and Melinda in this thread which I may
summarise as:
- This I-D needs to be clearer that it is not normative, not defining process, 
   and not directing WG chairs to use secretaries.
- The use of a WG secretary somewhat reflects an abdication of
  responsibility by a WG chair who was appointed to carry out these tasks.

Now, I think the first of these might be something we can address with some
careful text in the Abstract and Introduction. Would you agree? If so, I' m sure
we can work something out.

The second is more of a philosophical question. The chair is "contracted" to
deliver and given certain powers to achieve delivery. Can the chair delegate the
actions while supervising their implementation and carrying responsibility for
their correctness? This is maybe an issue we can address by making it clear who
carries responsibility  for actions carried out by a WG secretary and what the
complaint/appeals path is. 

But I would note for the second of these points that the WG secretary role
exists and there is also the concept of a "delegate". These ways of handling
IETF work are not introduced or made concrete by this document. We can't,
therefore, hold this document to account for the existence of things we don't
like. We can only ensure that the document accurately describes what exists.

Regards,
Adrian

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: 03 December 2014 15:26
> To: Melinda Shore; [email-masked]
> Subject: Re: Last Call: <draft-secretaries-good-practices-06.txt> (IETF
Working
> Groups' Secretaries) to Best Current Practice
> 
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Dec 2014 07:18:15 -0900

> like. We can only ensure that the document accurately describes what exists.

Absolutely, but what concerns me (I'm not going to try
to speak for John) is that this document appears to
normalize the secretarial role, rather than simply saying
that chairs are able to delegate various tasks.  There
appears to be a formal vesting of responsibility in working
group secretaries.

I like Ralph's proposal to update 2418 to allow for
wg secretary access to working group tools.  Otherwise
my preference would be to continue to keep the focus on
chair responsibilities, including chair delegation of
various tasks.  Secretaries are fine but I really
dislike seeing the role institutionalized.

Melinda

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2014 17:31:06 -0000

Hi Ralph,

> formally grants permission for secretaries to have access to WG tools.

I have not seen your draft revising RFC 2418. Did I miss it or are you
recommending that other people do work?

I'm sure that if you start this work others will send you their review comments.

> wiki "Working Group Chairs' Page" <http://www.ietf.org/wg/chairs-page.html>

The document even recommends doing that.

The authors, however, thought that just like the way the Tao evolved, there is
advantage in having community review and consensus of the starting text. This
can then be updated through the wiki as the situation evolves.

Does that community review and consensus need to be published through an RFC?
Probably not, but it is a convenient way to do so. 
Does publication as an Informational RFC somehow ossify the recommendations? I
don't think so.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2014 17:35:22 -0000

Melinda, 

Thanks for clarifying.

> ... but what concerns me is that this document appears to

I would love to work on the text that you feel normalising or formalising. My
reading doesn't convey that to me, and speaking with the authors it is not their
intention.

So it should be possible to reach agreement on text changes that would take this
tone out of your reading.

But, it is a little hard for those of us who don't see an issue with the text to
make suitable changes. Could you point us the sentences that are giving you a
problem and maybe suggest replacement words?

> wg secretary access to working group tools. 

That's good. I believe Ralph is looking for a co-author  :-)

> Otherwise

And again, there is no intention to institutionalise so can you help us remove
that tone from the document?

Thanks,
Adrian

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Dec 2014 12:37:04 -0500

--On Wednesday, December 03, 2014 16:05 +0000 Adrian Farrel
<[email-masked]> wrote:

> John,
> 
> I placed the document on the IESG telechat after a period of
> silence that followed the publication of the -07 version of
> the document and an email summarising the changes from the
> editor.
> 
> At the same time I sent an additional note to this list. I
> don't know (or care) whether that is what triggered renewed
> conversations, but I welcome them. I don't think you should
> take such a negative tone and assume that the no-one wants to
> listen to your concerns. Let's see whether we can address them
> before the telechat in just over two weeks' time.

Let me clarify my point of view and the source of that tone.  In
terms of value to the community, I welcome documents that
provide experience-based advice on how particular roles should
be carried out --whether via the Informational RFC process, by
updates to the Tao, or via the EDU team.  At the same time, I
see documents that seem to impose normative requirements or that
can readily be interpreted that way as a problem.  In this
particular case and independent of anything else, I don't think
the quality of work produced by the IETF or the efficiency with
which it can be produced is likely to be significantly enhanced
by the publication of this document _in any form_.  YMMD but it
makes me feel that I'm making a bad judgment by postponing IETF
technical work to review and re-review it and write comments. 

So, I said in August that I thought this was too normative and
prescriptive and that, while an advisory document would be fine,
this was something else.  A few others said much the same thing.
I (and I think we) saw that as a fundamental problem with the
document, not something that could be covered over by a
paragraph or two that amount to "regardless of what the rest of
this document says, it isn't really normative and doesn't really
constrain WG behavior".  My belief that comments of that sort
were not being treated in a serious way is based on the
evolution (or lack thereof) between the August versions and now.
It was strongly reinforced by Martin's "it is good if a
secretary does all that" response to Murray this morning:
whatever value the August comments and the new text may have, it
appears clear that he hasn't understood or accepted it.

So, independent of your summary below, I was disappointed that
the Last Call was reopened on the newer version.

However, part of what the community expects the IESG to do is to
make priority judgments about what is important and what isn't.
One has to hope those judgments reflect community consensus but,
if we stop trusting the IESG to be able to make them, we are,
IMO, basically finished.   So, when you and your colleagues
issue a Last Call on a document that falls even vaguely into my
area of competence, I need to take that as an instruction to
give it priority over IETF technical work that has not yet
reached Last Call.   If Pete and/or Barry don't agree that my
reading and responding to this document takes priority for my
IETF time over, e.g., PRECIS, IDNA, and URNBIS work for which
I'm temporarily in the critical path, then there is, from my
point of view, an intra-IESG discussion that needs to be held.
At the same time, _I_ can think that these priorities are bad
judgment even while I feel that the potential for harm from this
document is high enough that I need to spend the time.  And that
combination gives me a case of bad attitude, for which I
somewhat apologize.

> I believe I see two issues raised by you and Melinda in this
> thread which I may summarise as:

I disagree with your summary.  See below.

> - This I-D needs to be clearer that it is not normative, not
> defining process,     and not directing WG chairs to use
> secretaries.

Yes.  I would add some details to that list, but yes.

>   responsibility by a WG chair who was appointed to carry out

Not my point and maybe not quite Melinda's although I won't
presume to speak for her.  I think there are many good uses for
WG Secretaries and more than a few bad ones.  I think that
anything that reduces WG Chair accountability and responsibility
is a bad idea.  For that reason and absent unusual
circumstances, I'd rather not even see co-Chairs even though I
recognize that we are seeing circumstances I'd wish were less
common more often.   One result is that I don't want to see a
document or statement that implies "there should be a Secretary
and the Secretary should be doing these things", not because
that is an abdication of responsibility by a WG Chair but
because it makes the Secretary accountable for those tasks (it
is not clear to whom) and not the WG Chair.   As long as the
Chair is responsible and accountable, I don't care how work is
spread out or delegated within the WG.  If, as Melinda noted,
the WG Chair is not being effective and successful and a
Secretary is appointed to try to work around the problem, then
that is a problem... and more likely an abdication of
responsibility by the responsible AD than by the already-failing
WG Chair.

There is also a third point that, for me, is very much part of
this picture.  I spent years of my life working in SDOs which
had a large portfolio of procedures and review states and who
were de facto convinced that, if all of those procedures and
reviews were committed, the result was, by definition, a good
standard.   Most of my earlier work wasn't in networking, but I
suggest that model is exactly what brought us the wildly
successful OSI model and protocols.  I don't want to see the
IETF go (or go faster) in that direction and that makes me very
reluctant to see us move from the equivalent of "it is ok for
WGs to have Secretaries if the WG Chair(s) decide that is a good
idea on a case by case basis and such Secretaries serve at the
pleasure of the Chair(s) and do what they and the Chair(s)
jointly conclude is useful" toward "there should be Secretaries
for WGs and they should do these things".   

Coming back to Melinda's comment (at least as I understood it),
if we think we have an organizational or management problem,
let's figure out what it is and fix it, not slide in another
layer or management or indirection and hope that will solve
something.

Unless it is done _very_ carefully, there is only one step
between a document like this and an appeal that a particular WG
result was not fair because the WG didn't have a Secretary who
had the powers and responsibilities called for in the document.
I think that, and the alternative of every WG having a Secretary
to avoid doubt, would be bad.  I don't think the present
document is done well enough to avoid or minimize that risk.  It
isn't clear to me that the community investment needed to get it
to the point that it would be safe is worth the effort.

> Now, I think the first of these might be something we can
> address with some careful text in the Abstract and
> Introduction. Would you agree? If so, I' m sure we can work
> something out.

One of your IESG colleagues asked me almost the same question
off list.  He is welcome to share the rest of my response and
attempt at a constructive suggestion/offer with you as
appropriate but, briefly, no.  I think the authors tried that
with the first paragraphs of Section 2 and that the problem
isn't just placement.  The assumption that the document is and
should be normative -- that there should be secretaries and that
they should have certain authority and behave in certain ways --
is far too pervasive for a few sentences that say in essence "if
you read part of this as normative, never mind, it isn't really
intended that way".  It needs to be restructured and rewritten
and, fwiw, I don't see much hope for that in an individual
submission unless the authors understand and are signed up for
the difference in program.

> The second is more of a philosophical question. The chair is
> "contracted" to deliver and given certain powers to achieve
> delivery. Can the chair delegate the actions while supervising
> their implementation and carrying responsibility for their
> correctness? This is maybe an issue we can address by making
> it clear who carries responsibility  for actions carried out
> by a WG secretary and what the complaint/appeals path is. 

Yes, but see above and note that, from at least one point of
view, you are proposing to solve a problem I see as "trying to
create too many rules or too much uniform structure" with "more
rules and more structure".

> But I would note for the second of these points that the WG
> secretary role exists and there is also the concept of a
> "delegate". These ways of handling IETF work are not
> introduced or made concrete by this document. We can't,
> therefore, hold this document to account for the existence of
> things we don't like. 

Agreed.  On the other hand, if the document is, even in part, a
symptom of a problem, then we should be identifying the problem
and trying to fix it rather than documenting the symptom as
desirable practice.

> We can only ensure that the document 
> accurately describes what exists.

If that is your criterion, then the document fails it because it
describes one cluster of ways of using WG Secretaries (and then
strongly suggests it is the best one) but not all of the ways in
which Secretaries and or are not successfully used.  So it is
not an accurate description of what exists, only of one model,
and it isn't clear about that.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Dec 2014 12:45:43 -0500

--On Wednesday, December 03, 2014 07:44 -0800 Ralph Droms
<[email-masked]> wrote:

> First, it's important that RFC 2418 be updated to allow for a
> WG secretary to take on greater responsibilities, at the
> discretion of the WG chairs.  It's also important that the
> update include formal recognition that WG secretaries should
> be given access to WG support tools.  Therefore, I recommend
> that RFC 2418 be updated with a short RFC that expands the
> potential role for WG secretaries and that formally grants
> permission for secretaries to have access to WG tools.

I continue to hope that we have not gotten so procedurally
ossified that a decision to give Secretaries access to some
tools requires an update to RFC 2418 rather than a simple
announcement by the IESG to the community (or even case-by-case
decisions by a relevant AD).  But, if that is what it takes, I
like Ralph's suggestion which would be, at worst, harmless
clutter.

> Second, because the [the document contains] a series of
> recommendations that may not apply to all WGs and that may
> change over time, I recommend that this very useful material
> be integrated into the IETF wiki "Working Group Chairs' Page"
> <http://www.ietf.org/wg/chairs-page.html>

An excellent suggestion, IMO.   And, again, the observation that
this way suggested months ago and not responded to either in the
document or on-list is an example of what caused me to infer
that feedback was being ignored.

Last Calls of individual submissions of this sort of procedural
document are just too expensive for the community to do a second
one until and unless the authors have made a good-faith and
public effort to respond to legitimate comments from earlier
rounds.  If the authors and/or Shepherd don't feel that people
like Ralph or myself have sufficient experience for our comments
to be treated as legitimate and serious then they should say so
and we can all move on.

best,
   john

---

From: Melinda Shore <[email-masked]>
Date: Wed, 03 Dec 2014 08:48:34 -0900

> tone out of your reading.

I actually do not think that it should be published at all, as
I don't think it solves any problem that the IETF is currently
experiencing and I tend to think that it might lead to further
ossification of the organization.  That is to say, I think
that the cost/benefit balance does not work out in favor of
publication.

Melinda

---

From: Eric Burger <[email-masked]>
Date: Wed, 3 Dec 2014 13:31:19 -0500

Do we need to have the document to open the tracker to WG Secretary use? I would hope not, which means we do not need this document as it stands.

> On Dec 3, 2014, at 12:48 PM, Melinda Shore <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Dec 2014 14:54:18 -0500

FWIW, I concur.  A few more comments inline.

--On Wednesday, December 03, 2014 07:18 -0900 Melinda Shore
<[email-masked]> wrote:

>> things we don't like. We can only ensure that the document

Right.  And, as I said earlier, it also doesn't accurately
describe current practice because there are two many variations,
including "no secretary" that the document doesn't recognize (or
recognize as legitimate)..
 
> dislike seeing the role institutionalized.

Secretaries are fine but, if 2418 is changed, the change
shouldn't be to institutionalize Secretaries either.  It should:

(1) Make clear that the statements in 2418 about Secretaries are
to be taken as examples, not limits.

(2) Make clear that WG Chairs can, subject to review with/by the
relevant AD, delegate anything they like to anyone they like and
that such delegations should allow whatever access to tools,
etc., is needed to do the job... as long as such delegations do
no change the responsibility and accountability of the with WG
Chair.  If a WG Chair (after whatever consultation with the
relevant AD they consider appropriate) wants to delegate some
tasks to someone who is not an officially-designated WG
Secretary, we shouldn't have documents that accidentally get in
the way.

For the record, I'm not convinced that a change to 2418 is
needed for the above: the IESG has claimed, and gotten away
with, far more significant changes to procedures my means of
"statements" and the 2418 text does not appear to me to contain
any words that restrict access to tools that did not exist when
it was written.

    john

---

From: joel jaeggli <[email-masked]>
Date: Sun, 07 Dec 2014 13:31:54 -0800

> that the cost/benefit balance does not work out in favor of
+1

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Dec 2014 07:22:20 +0900

>> So it should be possible to reach agreement on text changes that
>> would take this tone out of your reading.
> 

i agree.  i will not add a bunch of sarcastic analogies about
more bureaucratic bumph we just don't need.

i also agree with your suspicion that this is an attept to patch
a chairing problem.  one suspects possible iesg unwillingness to
bite bullets.

rabdy

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 8 Dec 2014 02:51:34 +0000

> any words that restrict access to tools that did not exist when

++

---

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Dec 2014 11:53:05 +0200

> a chairing problem.  one suspects possible iesg unwillingness to

I agree.  The list of tasks assigned in this draft to the secretary should be done by the w.g. chairs.  If they can't do these tasks, then they shouldn't be chairs.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Mon, 8 Dec 2014 08:14:58 -0500

> I agree.  The list of tasks assigned in this draft to the secretary should be done by the w.g. chairs.  If they can't do these tasks, then they shouldn't be chairs.

I agree, as well.  I've come to agree that there's no need for an update to RFC 2418 and no need to publish this document.

Anecdotally, the two WGs I am currently administering do not generate enough admin work to warrant secretaries.

- Ralph

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Dec 2014 14:41:43 +0100

> I agree.  The list of tasks assigned in this draft to the secretary should be done by the w.g. chairs.  If they can't do these tasks, then they shouldn't be chairs.

OLD:

  Section 3  <http://tools.ietf.org/html/draft-secretaries-good-practices-07#section-3>  has listed the typical functions and responsibilities of WG
    Secretaries.

NEW:

  Section 3  <http://tools.ietf.org/html/draft-secretaries-good-practices-07#section-3>  has listed the functions and responsibilities of WG Chairs.

If not, what's left for the chairs? Just a title?
Exactly like having 3 WG chairs leads to dilution of responsibility, I fear that that same dilution of responsibility will apply here. At least with the way it's specified in this document, i.e, like a formal role.
Maybe it boils down to the fact that I have not seen a successful secretary in action.

+1 to no publishing this document.

Regards, Benoit

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Dec 2014 08:57:26 -0500

--On Monday, December 08, 2014 11:53 +0200 Bob Hinden
<[email-masked]> wrote:

>> i also agree with your suspicion that this is an attept to
>> patch a chairing problem.  one suspects possible iesg
>> unwillingness to bite bullets.

> I agree.  The list of tasks assigned in this draft to the
> secretary should be done by the w.g. chairs.  If they can't do
> these tasks, then they shouldn't be chairs.

Bob, while I agree with Melinda's concern and Randy's
bullet-biting one, I don't think we should go quite as far as
"...shouldn't be chairs".  We apparently do have a shortage of
people who will (or can) take on IETF leadership roles at a
variety of levels.  If someone can take on a Chair role, retain
responsibility and accountability, but spread the work around, I
think we should generally be in favor of that.  Both Secretary
roles and less personally time-consuming Chair roles can be
important tools for leadership development and training -- we do
too little of that, to, IMO, our considerable peril.

I don't think we want anything that looks like a set of rules
that say "there shall be Secretaries" or "the Secretary job
description is...".  Equally, I don't think we want anything
that says "there should not be Secretaries" or "Secretaries must
not get any of the following responsibilities...".  Instead...

(1) We leave 2418 alone.

(2) We continue doing what we have done in the IETF for as long
as I can remember: we give WG Chairs a lot of discretion about
how they get their work done and assume that the limits on that
discretion can, and should, be worked out between Chair and AD
on a case-by-case basis.

(3) We invite the authors of this draft, and others who are
interested, to extract the "if you are asked to do this task,
this is advice about how to do it" material from the draft and
add it to the WG Chair wiki, the Tao, or other sources of
general guidance, as may be appropriate.

    john

---

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Dec 2014 16:11:30 +0200

John,

You are right, I went a bit too far.  I hope I didn't offend anyone.

When I read the draft and saw the list of things proposed for Secretary, it was all of the things that I have do as a w.g. chair.  I don't think we need to formalize the Secretary role as this draft does.  If there are working groups where the chairs want and need this, they are free to do so.  

Bob

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 8 Dec 2014 15:35:58 +0100

Hello John,

> Its effect, however, is merely to contradict and create

This paragraph (minus few mods) has been in the draft since 00, while 
comments only came on 05/06. So, no, this paragraph is not here to blunt 
some of the type of criticism you and others have voice.

This is definitely not the spirit in which I and the other authors of 
this document have written it.

Best regards,
Martin

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Dec 2014 12:50:19 -0500

--On Monday, December 08, 2014 14:41 +0100 Benoit Claise
<[email-masked]> wrote:

> Exactly like having 3 WG chairs leads to dilution of
> responsibility, I fear that that same dilution of
> responsibility will apply here. At least with the way it's
> specified in this document, i.e, like a formal role.

yep.

> successful secretary in action.

I have and I've seen them be good for leadership development
too.  But the successful ones actually should be pretty
invisible from outside the WG -- helping with the Chair workload
but with no independently-specified responsibility or authority.

I like the idea of allowing secretaries.  I just don't think
that formalizing the role or creating IETF-wide role
descriptions is likely to be helpful.  Indeed, I think it could
cause significant harm.

    john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Dec 2014 10:17:03 -0800

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

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

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

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

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

> I doubt there is any conflict.

That makes it sound like you haven't checked... ;-)

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Dec 2014 10:30:33 -0800

Howdy Adrian,

>    and not directing WG chairs to use secretaries.

Agree.

>   responsibility by a WG chair who was appointed to carry out these tasks.

I think that's a bit more than what I was saying, at least.  Some WGs
become unwieldy because they end up taking on more documents or more people
than they had anticipated, or a co-chair's expected availability becomes
compromised.  In some cases it's appropriate to replace such a co-chair
with someone else that can handle the demand, and in others a WG secretary
might be all that's needed.  It's possible to delegate without abdicating,
where the delegated authority is merely to, for example, collect
information needed for the co-chair to make a decision; the co-chair
accepts responsibility for the collection and has the opportunity to verify
the input, even if she isn't the one actually doing the collection.

> complaint/appeals path is.

I think the answer to the question there is not only "yes", but that's
exactly what's expected if the chair exercises her prerogative to appoint a
secretary.  The proverbial "buck" still stops in the same place.  If that's
not written down, it ought to be.   (And yes, I'll offer to edit such a
document, though probably not until the new year.)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Dec 2014 11:32:19 -0800

Hi Loa,

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

> best performed by secretaries" to "how secretaries best perform these

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

> *because* you are a wg secreatry, nor does it disqualify for such

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

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

> thereof. This document is not the place to describe the dynamics.

I definitely agree with that last part.

>> for example drop "tools." from the addresses.

Same point though.

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

>> there being common ground here?

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.

> clear while explaining what is effected.

I think those two points are separable (see my other note from this
morning).

-MSK

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2014 08:54:43 +1300

> I agree.  The list of tasks assigned in this draft to the secretary should be done by the w.g. chairs.  If they can't do these tasks, then they shouldn't be chairs.

More generally, it needs to be clear that chairs MAY delegate
their routine tasks as they see fit, including these tasks,
but that doing so does not absolve them from any of their
responsibilities. That is not explicit in RFC 2418, and probably
should be.

Me, I'd probably put the material in this draft into the WG Chairs'
wiki: it's valuable material, but not a BCP.

    Brian

---

From: Melinda Shore <[email-masked]>
Date: Mon, 08 Dec 2014 11:23:12 -0900

On 12/8/14 10:54 AM, Brian E Carpenter wrote:
> responsibilities. 

That strikes me as the correct formulation.

Melinda

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Dec 2014 12:37:32 -0800

> That strikes me as the correct formulation.

Ditto.

-MSK

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 8 Dec 2014 21:44:42 +0100

Section 6:
    Nevertheless, while the WG Chairs may delegate a number of tasks to
    the Secretary, they maintain the overall responsibility and
    accountability over the WG and the decisions and actions that are
    taken.

Le 08/12/2014 21:37, Murray S. Kucherawy a écrit :
> On Mon, Dec 8, 2014 at 12:23 PM, Melinda Shore <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 8 Dec 2014 22:11:54 +0100

Murray,

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

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

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

>     Yet, if I remember correctly, once you have a secretary for your WG
>     you can delegate powers to that person from the datatracker.
>
>
> 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.
>
>     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.

>         draft-leiba-extended-doc-__shepherd (currently expired but not
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 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.
>
>
> 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.

-m

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Dec 2014 21:29:51 +0000

This isn't really a comment on the text of this draft but...

> of the authority dimension.

Here's a different (not better, different) perspective: what makes the
IETF the IETF is partly the volunteer work ethic - having chairs, ADs
etc do grunt work is arguably essential to that. From that perspective,
more and better-defined secretarial roles have a (not wholly, just
partly) negative aspect.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2014 10:51:59 +1300

>    accountability over the WG and the decisions and actions that are

Which is good stuff, like most of the content. I think the
argument is not about the quality of the draft, but about
whether it needs to be a BCP.

   Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Dec 2014 23:41:09 -0000

> whether it needs to be a BCP.

If only the "argument" was founded on reading the draft!

Network Working Group                                      M. Vigoureux
Internet Draft                                           Alcatel-Lucent
Intended status: Informational                                  D. King
Expires: May 2015                                    Old Dog Consulting
                                                           C. Pignataro
                                                    Cisco Systems, Inc.

                                                      November 11, 2014

                     IETF Working Groups' Secretaries
                    draft-secretaries-good-practices-07

Who is currently asking for this to be a BCP?
And why are we having that "argument"?

Adrian

---

From: Melinda Shore <[email-masked]>
Date: Mon, 08 Dec 2014 16:07:44 -0900

> If only the "argument" was founded on reading the draft!

Yes, and at the last IETF there was a non-working-group-forming
BOF in which they had a discussion about a potential charter.  I
am not fond of this sort of legalism - leave it to the ITU-T
and other such bodies.  It is clearly the case that this draft
is intended to describe practices, "best" or otherwise, and
changing the intended status doesn't really change the content.

Again, I do not think this draft addresses any actual problems
that the IETF is experiencing and risks codifying yet another
management layer (an unnecessary one).  I would regret seeing
it published.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2014 16:15:26 +1300

> If only the "argument" was founded on reading the draft!

No, founded on reading the subject line of the Last Call message.
It seems that I missed a "downgrade" of the Last Call.

I don't object to this as Informational.

  Brian