Requirements for a Working Group Milestones Tool
draft-ietf-genarea-milestones-tool-06

[Ballot comment]
Thanks for addressing my Discuss.

I have moved this item from my Discuss. I understand that the WG chairs were not comfortable with the idea, and will leave it at that. I hope that the tool will be developed to allow working group secretaries to use the tool in the future if the position changes.

[Ballot comment]
Like Adrian, I would like WG secretaries to be able to also perform the same tasks as chairs, but I think the document is fine if it does not contain this feature.

[Ballot discuss]
Apologies for catching this so late, but a point came up during testing of the charter tracking tool that probably should be clarified in this set of requirements. Paul - please wait for some discussion before updating the document to reflect
any of this.

We often want to see the milestones associated with the charter for a new group, and a recharter that's a significant
rewrite for consideration as part of the approval process.

When a group is active, and a recharter is being considered, the set of milestones the group is currently operating against (those associated with the currently approved charter) need to be editable separately from any milestones associated with a proposed recharter.

The majority of the requirements in this document apply to maintaining milestones associated with a currently approved
charter. I suggest stating explicitly that's the only data the tool being considered maintains.

I propose that the set of milestones associated with a new unapproved charter for consideration or for a recharter be kept separately - we do not need the approval/reminder mechanics in the document for these. We could extend the (re)chartering tracking tool to carry the proposed milestones as a separate field, and can discuss (outside the context
of this document) how we make sure they get applied to a newly approved charter at approval time.

[Ballot comment]
One minor comment:

"The IETF Secretariat needs to be able to perform the same tasks as
the WG chairs and ADs in order to fix problems or to make emergency
changes."

Surely it is simpler to say that the Secretariat should be able to
perform the same tasks as the ADs (since WGC privs are a subset of
AD privs).

[Ballot comment]
Section 1 second paragrpah read oddly:
                                                 
  Today, the tasks associated with creating and updating WG milestones
  are performed manually.  Normally, WG chairs send email to their AD
  requesting that milestones be created or updated, or saying that one
  or more milestone has been met.  These messages used to come as part
  of charter creation or updating, but will be a separate tool after
  the requirements in this document and in [RFC6292] are met.  WG
  chairs sometimes send mail directly to the IETF Secretariat to make a
  change to the database of milestones, such as to change the dates for
  milestones or to say that they are completed.  When a WG chair sends
  email to the Secretariat, the Secretariat must obtain the approval of
  the AD before taking the requested action.

I'm also not sure that "milestone met" has involved the AD approval for
a long  time. The chairs have simply communicated to the Secretariat
direct.

How about:

  Today, the tasks associated with creating and updating WG milestones
  are performed manually by the Secretariat.  Normally, WG chairs send
  email to their AD requesting that milestones be created or updated,
  or direct to the Secretariat saying that one or more milestone has
  been met.  Apart from during WG creation, these updates will be made
  through a separate tool after the requirements in this document and
  in [RFC6292] are met.

---
                                                                                     
Section 1

  This document is intended to bring that discussion to a general
  consensus among WG chairs and ADs for the requirements for the
  eventual tool.

Since this went to IETF last call, I think you could add
"and the wider IETF community"

---

Section 3

There seems to be some duplication between the paragraphs.

---

Section 4
                                 
  Once a day, the Datatracker will look for changes to the milestones
  for a WG.  If changes to milestones have been made in the past 24
  hours, the Datatracker will send one message to the WG listing all
  the changes from that period.

I don't really care, but this seems more work than just sending an email
when the change is made. The purpose is to avoid swamping the WG when
multipe changes are made?

[Ballot discuss]
Thanks for the work. I have a number of points that I hope are
relatively easy to handle.

---

This document also updates RFC 6293 (see Section 7)

---

Section 2

Sorry if I missed this in the discussion before: did we make an
active decision that working group secretaries will not allowed to
use the tool?

---

Section 3

  The chair
  also needs to be able to delete existing milestones.

This has worried me for a while. By "deleting" a milestone we might
infer that all record is lost. I should not like that. Maybe "abort"
would be a better word so that the milestone no longer remains something
that the WG is trying to achieve, but the record remains in the
database.

(obvious ripples into the rest of the document)

---

Did I miss it? I don't see any discussion of how the AD approves changes
that need AD approval. Obviously, a mechanism must be supplied.

---

Section 6

  The Datatracker needs to have a method for ADs and the Secretariat to
  see all the milestones that are pending approval.

Although this list is probably short, it would be nice to be able to
filter the list by AD and by Area.

BTW This paragraph belongs in Section 4, not Section 6.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <>
Reply-To: ietf@ietf.org
Subject: Last Call:  (Requirements for a Working Group Milestones Tool) to Informational RFC


The IESG has received a request from the General Area Open Meeting WG
(genarea) to consider the following document:
- 'Requirements for a Working Group Milestones Tool'
  as an Informational RFC

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
ietf@ietf.org mailing lists by 2011-09-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IETF intends to provide a new tool to Working Group chairs and
  Area Directors for the creation and updating of milestones for
  Working Group charters.  This document describes the requirements for
  the proposed new tool, and it is intended as input to a later
  activity for the design and development of such a tool.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-genarea-milestones-tool/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-genarea-milestones-tool/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the document
      and, in particular, does he or she believe this version is ready
      for forwarding to the IESG for publication?

None; write-up provided by document author

(1.b) Has the document had adequate review both from key members of
      the interested community and others? Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

Yes; no

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?

No

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he or
      she is uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it. In any event, if
      the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

No

(1.e) How solid is the consensus of the interested community behind
      this document? Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

The agreement seemed fairly solid across the IESG and WG chairs

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
      enough; this check needs to be thorough. Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?

Yes

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
      If such normative references exist, what is the strategy for their
      completion? Are there normative references that are downward
      references, as described in [RFC3967]? If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].

Yes

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document? If the document specifies protocol extensions, are
      reservations requested in appropriate IANA registries? Are the
      IANA registries clearly identified? If the document creates a new
      registry, does it define the proposed initial contents of the
      registry and an allocation procedure for future registrations?
      Does it suggested a reasonable name for the new registry? See
      [I-D.narten-iana-considerations-rfc2434bis]. If the document
      describes an Expert Review process has Shepherd conferred with the
      Responsible Area Director so that the IESG can appoint the needed
      Expert during the IESG Evaluation?

Yes

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

No formal languages used

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Writeup? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

  Technical Summary

    This document describes the requirements for a proposed new
    tool Working Group chairs and Area Directors for the creation
    and updating of milestones for Working Groups. This document
    describes the requirements for the proposed new tool, and it is
    intended as input to a later activity for the design and
    development of such a tool.

  Working Group Summary

    There was no WG, but it was extensively discussed on the WG
    chairs mailing list and in a face-to-face meeting in Quebec.

  Document Quality   

    The requirements listed were extensively discussed on the
    WG chairs mailing list and in a face-to-face meeting in Quebec.