Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker
RFC 6293

[Ballot comment]
I'm just wondering if there is any existing web technology that would allow someone to express an interest in a objects satisfying a certain criteria, and get updates, etc. accordingly. It seems funny that we need to build specific tools for our small database of drafts and tracker events. But what do I know, I'm just a poor little IP layer guy :-)

[Ballot comment]
I'm just wondering if there is any existing web technology that would allow someone to express an interest in objects, and get updates, etc. accordingly. It seems funny that we need to build specific tools for our small database of drafts and tracker events.

[Ballot comment]
I have no objection to the publication of this document.

There were three requirement-oriented thoughts I had on this most recent reading...

---

As a requirement for an implementor, I found 2.1.1. "Requirement:
Lists of I-Ds and RFCs can be large" to be too vague. Is it saying
that a hard coded limit is OK provided it supports "hundreds of I-Ds
and dozens of RFCs"?

Would it not be better to specifically reuqire "no implementation
limit" to list size?

---

I don't find 2.1.2 sufficiently clear. It says "Every Datatracker
user can create a list." It does not say whether the limit is one
list per user. I have no feeling either way, but I feel the document
should be clear as it will significantly impact implementation.

---

Did I miss notification of changes to a list (not of changes to I-Ds
in a list)? I can consider:
- I-D / RFC added to list
- I-D / RFC removed from list
- list deleted

[Ballot comment]
Sec 1: r/sixTestVM/six

Sec 2.3.1: I think "be" is missing from the following:

  In displays, a particular I-D or RFC should only *be* included once

Sec 2.3.3: r/changes/changed in:

  has not changes state

[Ballot comment]
Sec 1: r/sixTestVM/six

Sec 2.3.1: I think "be" is missing from the following:

In displays, a particular I-D or RFC should only included once
                                                              ^ be

Sec 2.3.3: r/changes/changed in:

has not changes state

[Ballot comment]
Sec 1: r/sixTestVM/six

Sec 2.3.1: I think "be" is missing from the following:

In displays, a particular I-D or RFC should only included once
                                                                          ^ be

Sec 2.3.3: r/changes/changed in:

has not changes state

[Ballot comment]
1. Section 1.1:

      This would include not
      only I-Ds that are in the many WGs that directly are changing the
      DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual
      submissions, IAB I-Ds, and even IRTF research.

s/IRTF research/IRTF I-Ds/

2. Section 1.2

      the ability to get notifications when individual I-Ds from a list
      changes state

s/changes/change/

3. Section 1.3

What is the difference between "Approved" and "Sent to the RFC Editor"?

4. Section 2.3.2

o  Associated WG or RG

I think this needs to be

o  Associated WG or RG or IAB or IES

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 Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC


The IESG has received a request from the General Area Open Meeting WG
(genarea) to consider the following document:
- 'Requirements for Internet-Draft Tracking by the IETF Community in the
  Datatracker'
  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-03-18. 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-community/

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