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

[Russ Housley <[e-mail]>]

Jim:

The 'default view' seems like a very different thing, and composing that
from a list of lists seems even more ugly than the current datatracker.

My comment was about the notifications list.  I accept that there is a
need for two different things here.

Russ

On 12/9/2010 3:15 AM, Jim Schaad wrote:
> 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:[e-mail]]
>> Sent: Wednesday, December 08, 2010 2:35 PM
>> To: Jim Schaad
>> Cc: [e-mail]
>> 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: [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
>>>
>>>
> 
>