Subject: [apps-discuss] APPSDIR review of draft-sparks-genarea-mailarch

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Aug 2012 18:14:39 -0700

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD (other than yourself) before posting a new version of the draft.

Document: draft-sparks-genarea-mailarch
Title: IETF Email List Archiving, Web-based Browsing and Search Tool
Requirements
Reviewer: Murray S. Kucherawy
 Review Date: August 17, 2012
IETF Last Call Date: Completed August 13, 2012
 IESG Telechat Date: August 30, 2012

Summary: This document proposes requirements for services that provide
web-based browsing and search of the archives of both private and
public IETF lists.

This draft is almost ready for publication as an Informational RFC but
has a few issues that should be fixed before publication.

MAJOR ISSUES:

Section 4: I think this is inadequate.  Certainly email archives have
little to do with Internet security, but there are indeed security
considerations with respect to this work in particular.  Specifically,
Section 2.1 discusses access control, and that should be at least
referenced here if not briefly discussed.  I also mention below some
things that need to be discussed in terms of what the results of a
permanent search URI would return over time as people's roles change.
We might also discuss that two different users using the same search
query might see different content depending on their respective
privileges.  I'm envisioning person X saying "As you can see from the
archive result at <URI>, A said B about C", while person Y says
"Funny, I don't see that."  Oops…  And I don't know if we need to get
into basic advice like "privileged communications can be revealed if
access controls are not properly checked and enforced", but it also
crossed my mind.  I'm glad, however, that this doesn't get into
prescribing specific authentication mechanisms.

MINOR ISSUES:

Section 2.1: Should the proposed system support threads that
migrate(d) among lists?

Section 2.1: The set of search properties in the fifth bullet should
probably include email address ("string occurring in sender name" to
me matches the display name specifically, not the address itself).

Section 2.1: As I mentioned above, the last bullet talks about access
restrictions.  It seems to me this is a bigger topic than just a
bullet.  For example, one's credentials change over time as one enters
and departs various roles.  That means a stable URI that represents a
thread could produce results that vary from one query to another or
one user to another (e.g., chunks of a thread or of a search result
could be present for one person but absent for another).  This might
be appropriately discussed in more length in Privacy Considerations or
Security Considerations, but it also bears discussion here.

Section 2.2: The reference to "mailman" is important, since I believe
whoever implements this stuff will be working with the mailman team to
implement or support it.  That is, this work will be the kind of thing
that would appropriately be developed in an open/free software kind of
way.  There might be some standardization work we want to do here to
make interfacing with other stuff easy in the future.  Just a note for
later, perhaps, but maybe something worth mentioning in this document.

Section 2.5: The fourth bullet is a bit cryptic to me.  Are you trying
to say the amount of traffic flying around to ensure replication
should be comparable to the amount of archive activity taking place?

NITS:

Section 1: The first paragraph is pretty big.  It could probably stand
to be broken up a bit.

Section 1: That last paragraph should be followed by an RFC Editor
note to delete it prior to publication.

Section 2.3: Last bullet is missing a trailing period.

Section 2.4: All bullets are missing trailing periods.

Section 2.5: Outermost bullet missing trailing period or colon.

Section 2.5: "Multiple active archive servers are not a requirement"
should be "Support for multiple active archive servers is not a
requirement".

Section 2.6: First and last bullets are missing trailing periods.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 20 Aug 2012 13:49:07 -0500

Thanks Murray -

Comments inline:

> prescribing specific authentication mechanisms.
We already call out that the results of a search can change over time with
this text:
>       -  The search may be re-executed when the URI is referenced.  It
>          is acceptable for the same URI to produce different results if
>          accessed at different times (reflecting additional messages
>          that may match the search criteria for example.)
I can expand this as follows:

       -  The search may be re-executed when the URI is referenced.  It
          is acceptable for the same URI to produce different results if
          accessed at different times or by different people (for example,
          by reflecting additional messages that may match the search
          criteria, or reflecting changes in access authorization to
          lists with restricted archives.)

> Section 2.1: Should the proposed system support threads that
We already require searching across multiple lists, and require browsing 
by thread.
To the extent that enough information is present to correlate the 
messages in threads
that hopped lists this ability should fall out of the requirements we 
already have.
> me matches the display name specifically, not the address itself).
I can s/sender name/email address or sender name/

> Security Considerations, but it also bears discussion here.
I think my suggestion above makes this clear. If you think more is still
needed, what additional discussion do you think would be useful for someone
putting this system together?
> later, perhaps, but maybe something worth mentioning in this document.
I'm not seeing an obvious place to call this aspect out. Are you ok with
keeping this in mind as a note for later as you suggest?
> should be comparable to the amount of archive activity taking place?
Yes. Would it help to
s/The amount of data replication between/The amount of data replicated 
between/
?

> Section 1: The first paragraph is pretty big.  It could probably stand
OK
> note to delete it prior to publication.
I'll delete it before it goes into the RFC Editor queue
> Section 2.5: Outermost bullet missing trailing period or colon.
I'll make all of these consistent
> should be "Support for multiple active archive servers is not a
ok
> Section 2.6: First and last bullets are missing trailing periods.
ack.

RjS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Aug 2012 11:29:04 -0700

>          lists with restricted archives.)

Yes, please.  Thanks!

> We already require searching across multiple lists, and require browsing by
> thread.
> To the extent that enough information is present to correlate the messages
> in threads

OK.  Just wanted to make sure it was considered.

> I can s/sender name/email address or sender name/

Great.

> putting this system together?

I think my remaining concern has to do with the fact that two
different users executing the same query URI get different views.  I
know you've pointed out that this can happen, but I imagine it would
be a good idea to require that the service show privileged users a
warning that their view might (or does) include content that others
won't see.

> keeping this in mind as a note for later as you suggest?

Yes, that was more of a stream-of-consciousness remark than an
actionable thing.  I don't know that we can require that our system be
produced open source in this document, though it would be nice.

> s/The amount of data replication between/The amount of data replicated

How about:

The amount of traffic generated to ensure data replicated between...?

-MSK