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

"Jim Schaad" <ietf@augustcellars.com> Thu, 09 December 2010 07:59 UTC

Return-Path: <ietf@augustcellars.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 6D36C3A6A6E for <datatracker-rqmts@core3.amsl.com>; Wed, 8 Dec 2010 23:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.41
X-Spam-Level:
X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
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 ExoWlhki-3Ky for <datatracker-rqmts@core3.amsl.com>; Wed, 8 Dec 2010 23:59:36 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 595CA3A6A57 for <datatracker-rqmts@ietf.org>; Wed, 8 Dec 2010 23:59:36 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 5FEBB6EF38; Thu, 9 Dec 2010 00:01:04 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
References: <p0624081bc9249d506bb8@[10.20.30.150]> <4CFF5D2E.1080507@levkowetz.com> <4CFFD7E2.7060307@vigilsec.com> <015d01cb9725$7fba21c0$7f2e6540$@augustcellars.com> <4D000815.5090707@vigilsec.com>
In-Reply-To: <4D000815.5090707@vigilsec.com>
Date: Thu, 09 Dec 2010 00:15:59 -0800
Message-ID: <017b01cb9779$51052600$f30f7200$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ260A0gDDsotZc4IfkOuXcUkJNOQFJSwvjAsZA1kwA6z2zYQFuwimRkg3PXHA=
Content-Language: en-us
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: Thu, 09 Dec 2010 07:59:37 -0000

Russ,

This is not only a list of documents I want notifications for, but a list of
documents that I want to be able to view status using an HTML view a la the
current data tracker.  Trying to dig through a large number of documents
here would be troublesome, even if a single list was all that provided
notifications to me.

Jim


> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Wednesday, December 08, 2010 2:35 PM
> To: Jim Schaad
> Cc: datatracker-rqmts@ietf.org
> Subject: Re: [datatracker-rqmts] Publicly-readable and private/anonymous
lists
> 
> For what gain?  It is the list of documents you want to receive
notifications of
> changes.
> 
> Russ
> 
> On 12/8/2010 5:15 PM, Jim Schaad wrote:
> > Russ,
> >
> > I don't think you really want to restrict me to a single list.  This
> > would just require that I create multiple logins in order to get
multiple lists.
> >
> > Jim
> >
> >
> >> -----Original Message-----
> >> From: datatracker-rqmts-bounces@ietf.org [mailto:datatracker-rqmts-
> >> bounces@ietf.org] On Behalf Of Russ Housley
> >> Sent: Wednesday, December 08, 2010 11:09 AM
> >> To: Henrik Levkowetz
> >> Cc: datatracker-rqmts@ietf.org
> >> Subject: Re: [datatracker-rqmts] Publicly-readable and
> >> private/anonymous
> > lists
> >>
> >> 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
> >>>
> >> _______________________________________________
> >> datatracker-rqmts mailing list
> >> datatracker-rqmts@ietf.org
> >> https://www.ietf.org/mailman/listinfo/datatracker-rqmts
> >
> >