[Ballot discuss]
The document is not clear which of the fields being added to the datatracker database are intended to be editable by the datatracker UI and code (beyond the code that imports data from the authoritative databases).

One interpretation (which seems consistent with conversations I've had with Sandy) is that the fields adding to the datatracker database will contain values that are _copies_ of authoritative values in other databases, and that the only way to modify those values is through the interface that brings those values in from the other databases.

That is, the datatracker UI will not be used to edit these values (particularly the states) - it will only display them.
The only way to change them is by changing them in the authoritative system.

However, section 2.3 of the document indicates that IANA should be able to edit the values in the datatracker instead of in their system. Can the document be more clear on why this is necessary. Would the ability to force any updates made in the IANA databases to be reflected in the tracker on IANA's demand cover the cases this section anticipates?

Are there really any values that the datatracker code (through automation or UI interaction) modify in the
datatracker database directly? Or should they all happen as part of a round trip as the information goes out to the
authoritative databases as described in sections 4.1 and 4.2 and back into the tracker through whatever copies
values from the authoritative databases?

For instance, it's not currently clear that when a new version of a document gets submitted, leading to the "Version Changed -- Review Needed" substate, whether this state information is set in the datatracker directly, or if the new version notification gets sent to IANA, and this state information comes back when IANA pushes information to the tracker. If it's set directly, there is danger of it getting out of sync, and even overwritten the next time information moves from the IANA databases to the datatracker database.

It's not clear from the text what state the "Version Changed -- Review needed" substate (and the other states called out in 2.1) belongs to. Are these states in a new state machine the tracker is going to represent, or substates of states in an existing machine?

[Ballot discuss]
This is a "discuss-discuss"; I expect to clear it during the IESG telechat.

I think it will be extremely useful to collect all the state changes in one place. However, given that the IANA and the RFC Editor are independent of the IETF, I worry that consolidating their state changes into the *IETF* Datatracker might raise concerns about undue influence by the IETF on their operation.

[Ballot comment]
Section 2.1

For the avoidance of doubt, you should change "Last Call" to "IETF
Last Call"

---

Section 2.1

  - IESG Review

      As not all documents receive a Last Call, this substate is

s/Review/Evaluation/                                                             
s/substate/state/

---
                                                                               
Section 2.1

Wouldn't it be wise to have "IANA Not OK" show as a graphic as well as
text on the agenda?

---

Section 3.1

It appears from the text that you do not intend to make the RFC Number
available in the data tracker until the RFC is published. However, by
following various links it will be possible to determine what number
has been reserved for an I-D as soon as it has been allocated.

Would it be worthwhile to make this number more explicit, but to also
indicate that it is preliminary?

[Ballot discuss]
I am very supportive of this work, but I have some questions I would like to explore before ballotting "yes".

Appologies are due: I should have caught these issues in IETF Last Call.

---

Section 2.1 has

>    5) Version Changed -- Review Needed
>
>        This substate will allow the community, Secretariat, and IANA
>        to easily track which documents have  been reviewed and
>        subsequently when a version of an Internet-Draft has changed,
>        therefore requiring a second review of the document by IANA to
>        ensure that either the IANA Considerations have not changed or
>        that any changes made to the document affecting IANA actions
>        are clear.  This substate applies to I-Ds that have previously
>        been marked as "IANA OK -- Action Needed" or "IANA Not OK".
>
>  Information providing the status of the IANA review (one of the 4
>  substates listed above) should be included as part of the evaluation
>  message (sent to the IESG) so that IANA can determine if and what
>  further action is required.

I have a couple of questions...

- Surely "Version Changed" applies in all cases except "IANA Review
  Needed" and "Version Changed". In particular, you seem to have left
  out "IANA OK -- No Actions Needed", but the new version might make
  a call for IANA action.

- Will the transition to this substate be automatic or only when there
  is a known change affecting IANA review?

- I fear this may be creating a large amount of extra work for IANA as
  I-Ds are sometimes revised many times along the path. At the moment
  such changes are caught during IANA action after IESG Approval unless
  explicitly flagged by the authors/ADs.

- Is there a plan to use the same trigger for RFC Editor Notes added
  during IESG Evaluation?

- The closing paragraph says "4 substates", but there are 5.

---

Section 2.2.

I think that ensuring Expert Review for IANA allocations is an important
feature we have been fumbling recently. The outcome of IANA's "process
of documenting how an expert review is conducted during the lifetime of
an Internet-Draft" could have significant effects on what is implemented
in support of this I-D. Is there any reason not to wait for the
completion of that task before completing this document?

Additionally, I note that Expert Review is already mentioned under
"IANA Not OK" in the "Last Call Comments" section.

---

Section 3.1

On rare occasions an RFC-to-be is pulled from the RFC Editor Queue and
returned to the IETF for processing (or abandoned). You will need to
decide what happens to the RFC Editor sub-states in that case, and in
the case where the document re-appears on the RFC Editor Queue at some
future time.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-genarea-datatracker-iana-rfced-extns-01.txt> (Datatracker Extensions to Include IANA and RFC Editor Processing Information) to Informational RFC


The IESG has received a request from the General Area Open Meeting WG
(genarea) to consider the following document:
- 'Datatracker Extensions to Include IANA and RFC Editor Processing
  Information'
  <draft-ietf-genarea-datatracker-iana-rfced-extns-01.txt> 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-05-02. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-iana-rfced-extns/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-iana-rfced-extns/

PROTO Write-Up for draft-ietf-genarea-datatracker-iana-rfced-extns

(1.a)  Who is the Document Shepherd for this document? 

  Russ Housley.  He has personally reviewed this version of the
  document and, in particular, he believes this version is ready
  for forwarding to the IESG for publication.

(1.b)  Has the document had adequate review both from key members of
    the interested community and others? 

  Some of the key members of the interested community have reviewed
  the document.  Last Call should create additional review.

  The Document Shepherd does not have any concerns about the depth
  or breadth of the reviews that have been performed to date.

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

  Some of the key members of the interested community have reviewed
  the document.  The Document Shepherd is unaware of any opposition.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarize the areas of conflict in
    separate email messages to the Responsible Area Director.

  No.

(1.g)  Has the Document Shepherd personally verified that the
    document satisfies all ID nits?  (See
    http://www.ietf.org/ID-Checklist.html 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? 

  Yes.

    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? 

  This document normatively references draft-hoffman-alt-streams-tracker,
  which is expected to be progressed on the Independent Stream.  It will
  not be a downref; both documents are informational.

(1.i)  Has the Document Shepherd verified that the document IANA
    consideration section exists and is consistent with the body of
    the document? 

  Yes; there are no registrations required.

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

  Yes; there are no formal languages within this document.

(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

    The IETF Datatracker will be enhanced to make it possible for the
    IANA and the RFC Editor to provide more transparency into status
    and progress of documents in their respective queues.

    This document captures the requirements for integrating IANA and
    RFC Editor state information into the Datatracker, providing the
    community with a unified tool to track the status of documents as
    they progress from Internet-Draft (I-D) version -00 to RFC.  One
    goal is to improve transparency to document authors and the whole
    Internet community.  Another goal is to increase automation
    between the Datatracker, IANA, and RFC Editor, thus reducing manual
    labor, processing errors, and potential delay. 

  Working Group Summary

    This document is not the product of an IETF WG.

  Document Quality

    The document was reviewed by Russ Housley for the IESG.

  Personnel

    Russ Housley is the Document Shepherd.