Re: [datatracker-rqmts] Publicly-readable and private/anonymous lists

Russ Housley <housley@vigilsec.com> Wed, 08 December 2010 19:07 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: datatracker-rqmts@core3.amsl.com
Delivered-To: datatracker-rqmts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5FE3A6993 for <datatracker-rqmts@core3.amsl.com>; Wed, 8 Dec 2010 11:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.436
X-Spam-Level:
X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdMsDiM-l37C for <datatracker-rqmts@core3.amsl.com>; Wed, 8 Dec 2010 11:07:52 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 0FBB13A686A for <datatracker-rqmts@ietf.org>; Wed, 8 Dec 2010 11:07:50 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 886E69A47A8; Wed, 8 Dec 2010 14:09:42 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 9rQttmaY6NvG; Wed, 8 Dec 2010 14:09:04 -0500 (EST)
Received: from [128.31.34.232] (31-34-232.wireless.csail.mit.edu [128.31.34.232]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2BC809A47A6; Wed, 8 Dec 2010 14:09:41 -0500 (EST)
Message-ID: <4CFFD7E2.7060307@vigilsec.com>
Date: Wed, 08 Dec 2010 14:09:22 -0500
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Henrik Levkowetz <henrik@levkowetz.com>
References: <p0624081bc9249d506bb8@[10.20.30.150]> <4CFF5D2E.1080507@levkowetz.com>
In-Reply-To: <4CFF5D2E.1080507@levkowetz.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: datatracker-rqmts@ietf.org
Subject: Re: [datatracker-rqmts] Publicly-readable and private/anonymous lists
X-BeenThere: datatracker-rqmts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <datatracker-rqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/datatracker-rqmts>, <mailto:datatracker-rqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/datatracker-rqmts>
List-Post: <mailto:datatracker-rqmts@ietf.org>
List-Help: <mailto:datatracker-rqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/datatracker-rqmts>, <mailto:datatracker-rqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 19:07:55 -0000

Henrik:

I agree that lists of lists is causing more complexity than expected.  I
think that putting it aside for now is a good choice.

I wonder if it would be easier to start with two kinds of lists:
  --  public-and-published
  --  private-and-unpublished

The public-and-published are used to follow the documents associated
with a particular topic.  They have a public owner that has agreed to
add and remove documents as appropriate.  This is like the web page that
shows the possible WG and non-WG mail lists that are available to IETF
participants.

The private-and-unpublished are part of a single user's preferences.
They are not shared, and they are owned by that user.  Each user gets
one and only one of them.

Russ

On 12/8/2010 5:25 AM, Henrik Levkowetz wrote:
> Hi Paul,
> 
> Looking this over, both specification and implementation of these
> notification specifications ('lists') seems to becoming more and
> more complex, and I'm not convinced that the complexity buys us a
> lot.  The whole issue comes about because of the decision that
> people should be able to include another list in their notification
> list.
> 
> I would like to do away with the whole complexity of this by saying
> (at least for this round -- we can always re-open this again when
> we have some practical experience with the first implementation) --
> by saying that lists can't include other lists, and all lists are
> anonymous and unpublished.
> 
> 
> Regards,
> 
> 	Henrik
> 
> On 2010-12-08 03:36 Paul Hoffman said:
>> Greetings again. It's time to spin up this list again, and a few people have told me that specifying how public lists are publicly-readable and how private/anonymous lists are created and managed will unblock a bunch of other open issues. There was a lot of interest in these topics at the mic in Beijing.
>>
>> The current text is below. This is just starting text, and it doesn't cover the idea that some private/anonymous lists might have publicly-readable counterparts if the list owner wants.
>>
>> So, please say what you think should be done here. Do you have a preference between private and anonymous? Do you have ideas for public lists?
>>
>> To facilitate the discussion, there will be a WebEx-based telechat on Friday, December 17. Information on that comes in the next message. If we have great consensus before the telechat, we can use that time to move on other open issues.
>>
>> --Paul Hoffman
>>
>> ======================================
>>
>> 2.1.3.  Requirement: Some lists must be able to be private or anonymous
>>
>>    Seeing a list of drafts that covers multiple areas of interest can
>>    tell you something about the person who created the list.  For
>>    example, you might be able to guess that they might be looking for a
>>    job in a different field by looking at their list of drafts of
>>    interest.  Of course, anyone can follow individual drafts today
>>    without having that be exposed; however, following a particular group
>>    of drafts can reveal information about a person.
>>
>>    There is a open issue about whether lists should be default be
>>    private/anonymous or public, and how that default should be manifest
>>    in the eventual UI for creating lists.
>>
>>    The first proposed methods that might keep lists private/anonymous
>>    are:
>>
>>    o  Private lists might only be available using passwords or some
>>       other common authentication mechanism.  This would require that
>>       the Datatracker have a subscription process for users that could
>>       assign passwords, and a per-user process for adding lists to a
>>       user account.  (If the current Datatracker username and login
>>       scheme is used, the interface needs to be improved so that getting
>>       a new login, and changing one's password, are significantly
>>       easier.)
>>    o  Anonymous lists might be assigned random URLs from a very large
>>       (2^128) namespace, and the user who creates a list does not tell
>>       others the assigned URL.  This method makes it impossible for
>>       someone to search the entire set of assigned lists.  Given that
>>       the URLs for lists are most likely going to be copy-and-pasted
>>       anyway, having long random strings in the list's URL is not an
>>       impediment.
>>
>> 2.1.4.  Requirement: It must be easy for IETF leadership and individuals
>>         to make lists they create publicly-readable
>>
>>    Private or anonymous lists are fine for individuals, but publicly-
>>    readable lists can magnify the value to the whole community.  In
>>    fact, some early commenters on this document emphasized that
>>    publicly-readable lists will be more valuable to the IETF than
>>    helping individuals track documents that are only of interest to
>>    them.
>>
>>    Probably the easiest method to implement publicly-readable lists is
>>    to make them read-only aliases for private or anonymous lists.  This
>>    would allow the list originators to control the contents of the list
>>    as normal, but also allow anyone to view the results in the
>>    Datatracker and/or subscribe to notifications.  There may be other
>>    methods that would also make sense, and this section might change in
>>    the future.
>>
>>    Publicly-readable lists should have short URLs that can be
>>    transcribed without relying on copy-and-paste.  The names in the URLs
>>    for lists that are associated with IETF activities (initially, the
>>    lists created by WG chairs and ADs) can be mnemonic, but other public
>>    lists should have names that are not mnemonic in order to prevent
>>    name-squatting.
>>
>>    It is important to note that publicly-readable lists can only be
>>    changed by the owners.  Allowing many people to change the contents
>>    of a list would probably lead to lists that are not very useful to
>>    typical users.
>>
>>    Proposed later requirements include having the Datatracker list all
>>    of the publicly-readable lists (or certainly at least the ones
>>    associated with IETF activities), and having links from WG pages in
>>    Datatracker to the publicly-readable lists maintained by the WG
>>    chairs.
>> _______________________________________________
>> datatracker-rqmts mailing list
>> datatracker-rqmts@ietf.org
>> https://www.ietf.org/mailman/listinfo/datatracker-rqmts
>>
> _______________________________________________
> datatracker-rqmts mailing list
> datatracker-rqmts@ietf.org
> https://www.ietf.org/mailman/listinfo/datatracker-rqmts
>