Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching
RFC 6778

[Ballot comment]
Please enhance Section 5 to include a discussion of the way this new feature could be used as an attack vector on the archive server and the mail archive itself.

---

Section 2.1

  o  When the system requires credentials, it must use the
      datatracker's authentication system.

      -  While the vast majority of archived lists have an open access
        policy, some archived lists have restricted archives

Isn't it the case that restricted archives are accessed using
credentials per mailing list and that those are not necessarily the
datatracker credentials?

[Ballot comment]
Moving my discusses here for the record:

1) s2.6 2nd bullet: Maybe I just haven't thought about this correctly, but under what circumstances would we *not* want the deletion of a message logged?

I was convince we're good to go on this.  We're just providing a mechanism to respond to court order removals.

2) Where are the requirements for the archive administrator?  Must they be logged in with credentials before mucking with lists?

I'll trust Robert to fix this up.

Comments:

1) s2.1: Do we need to make the following more specific:
  - string occurring in sender name or email address

maybe it's string occurring in "to, from, cc, bcc, sender"?  Or is that addressed by the later header bullet?

[Ballot comment]
I agree with Pete's comments and with Sean's second DISCUSS point.

With Adrian's DoS DISCUSS point, I think I disagree.  Any service can be subject to a DoS attack, and I don't think we need to say that in every document.  Is there anything specific to *these requirements* that we could say about DoS attacks?  I'm not sure there is.

[Ballot discuss]
I am sorry to have two Discuss points on this document that I would otherwise like to support. Hopefully we can resolve them simply.

---

Section 2.2

[Grumble-alert]

      -  Lists hosted at other organizations may use other packages.

Why do we persist in attempting to support lists hosted outside the
IETF? Can we please stop this nonsense! I suggest the resolution is to
explicitly exclude all extrnally hosted lists from this document.

(Note, the stuff in 2.3 is fine.)

---

Section 5

What is written is true.
However, there are implications for the security of the mail archives.
And more importantly, there are implications for DoSing the archive
servers.
These surely need to be discussed.

[Ballot comment]
Section 2.1

  o  When the system requires credentials, it must use the
      datatracker's authentication system.

      -  While the vast majority of archived lists have an open access
        policy, some archived lists have restricted archives

Isn't it the case that restricted archives are accessed using
credentials per mailing list and that those are not necessarily the
datatracker credentials?

[Ballot comment]
This is a good document, but I think the notion of sorting or browsing by thread could be made more clear since this is done in different ways.  For instance, threads can be sorted alphabetically or chronologically.  I think we'd like both of those possibilities, and that distinction isn't captured by the simple requirement to sort by thread.  So, I believe the changes should be:

Original:
  o  The system must allow browsing the entire archive of a given list
      by thread or by date.

  o  The system must allow browsing the results of a search by thread
      or by date.

To:
  o  The system must allow browsing the entire archive of a given list
      with messages sorted by message date, thread title, or thread
      original message date.

  o  The system must allow browsing the results of a search by message
      date, thread title, or thread original message date.

[Ballot discuss]
1) s2.6 2nd bullet: Maybe I just haven't thought about this correctly, but under what circumstances would we *not* want the deletion of a message logged?

2) Where are the requirements for the archive administrator?  Must they be logged in with credentials before mucking with lists?

[Ballot comment]
1) s2.1: Do we need to make the following more specific:
  - string occurring in sender name or email address

maybe it's string occurring in "to, from, cc, bcc, sender"?  Or is that addressed by the later header bullet?

[Ballot comment]
Looks fine. Two small comments:

2.4: I believe that the archive is supposed to be *user* exportable to different formats. That's not clear from this section. I, as a user of the archiving system, want to be able to save some messages in, e.g., mbox format. It shouldn't just be an admin function.

4: Do you want the reference to be only informative? If so, at least add something to the effect of, "The archiving system will be expected to integrate with IMAP access and therefore hooks for an IMAP system will be necessary."

[Ballot comment]

- Possible addition to the last bullet in 2.1: "search results from
restricted archives should expose as little potentially sensitive
content as possible (e.g. perhaps don't include subject line)." You
might want to generalise that somewhere (e.g. section 5) and/or say
the same kind of thing elsewhere.

- 2.3, typo s/on-message-per-file/one-message-per-file/

- 2.3, is "lossless" really fully possible? Might be better to say
"as close to lossless as achieveable" or somesuch. (I've never
gotten 100% in doing this myself.)

IANA has reviewed draft-sparks-genarea-mailarch-05, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IETF Email List Archiving, Web-based Browsing and Search Tool Requirements) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'IETF Email List Archiving, Web-based Browsing and Search Tool
  Requirements'
  as 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 2012-08-13. 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 makes heavy use of email lists to conduct its work.
  Participants frequently need to search and browse the archives of
  these lists, and have asked for improved search capabilities.  The
  current archive mechanism could also be made more efficient.  This
  memo captures the requirements for improved email list archiving and
  searching systems.




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

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


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