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

["Jim Schaad" <[e-mail]>]

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: [e-mail] [mailto:datatracker-rqmts-
> [e-mail]] On Behalf Of Russ Housley
> Sent: Wednesday, December 08, 2010 11:09 AM
> To: Henrik Levkowetz
> Cc: [e-mail]
> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/datatracker-rqmts
> >>
> > _______________________________________________
> > datatracker-rqmts mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/datatracker-rqmts
> >
> _______________________________________________
> datatracker-rqmts mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/datatracker-rqmts