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

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Dec 2010 18:36:12 -0800

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.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 08 Dec 2010 11:25:50 +0100

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:
> _______________________________________________
> datatracker-rqmts mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/datatracker-rqmts
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 08 Dec 2010 14:09:22 -0500

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Dec 2010 14:15:59 -0800

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: [email-masked] [mailto:datatracker-rqmts-
> [email-masked]] On Behalf Of Russ Housley
> Sent: Wednesday, December 08, 2010 11:09 AM
> To: Henrik Levkowetz
> Cc: [email-masked]
> Subject: Re: [datatracker-rqmts] Publicly-readable and private/anonymous
lists
> I agree that lists of lists is causing more complexity than expected.  I
think that
> putting it aside for now is a good choice.
> 
> 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.
> 
> They are not shared, and they are owned by that user.  Each user gets one
and
> only one of them.
> > 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.
> >
> > (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
> >> 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
> >>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Dec 2010 14:14:37 -0800

>just require that I create multiple logins in order to get multiple lists.

Not necessarily. The design could be "multiple lists per login".

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Wed, 08 Dec 2010 17:35:01 -0500

For what gain?  It is the list of documents you want to receive
notifications of changes.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Dec 2010 23:56:53 -0800

Henrik,

I can definitely understand the desire to say all lists are non-public to
begin with (and they don't necessarily have good names).  I would like to
discuss more where you see the complexity as come from the ability to do
lists of lists.  I can see various problems that you might be looking at,
but could see different ways of solving the problem which might make things
easier but still keep some of the flexibility of having nested lists.

Problems that I can see:

1.  Looking for loops - This is always a problem and eliminating nesting
does solve this one.

2.  Making included lists "live" - One possible solution to this would be to
just make the computation of my query (i.e. build up the logic) from the
current state of the list I included, without actually letting me know or
doing a dynamic update if the list I include changes.  This makes loop
detection easier since it is done when I save my query, it allows me to
build up my query in pieces (which can be useful) and it allows me to look
at the pieces of my query later which can be nice because a total list which
sends me updates can be made up of smaller lists that I want to use for the
html view.   This does mean that changes made to child lists would not be
reflected up dynamically - although it is possible that the fact it has not
propagated is send out.

3.  The simple act of including a list - If we did a static build of the
query, this would not be any different from allowing me to build a complex
OR/AND statement.  If it is a dynamic query builder then yes it does add
significant complexity.

4.  The UI for managing the multitude of lists is complex.  I don't think
this would be any more complex than the ability to build a decent sized
query along the order of.  Show me "(All Security area documents in IETF
Lass call) OR (All PKIX documents) OR (All docs with "SMIME" in the document
name) OR (all documents written by "Schaad")

5.  Dealing with items that appear multiple times is going to have to be
dealt with if any sort of complex grammar is allowed - so I don't that that
would be an issue that is solved by eliminating embedded lists.

Jim

> [email-masked]] On Behalf Of Henrik Levkowetz
> Sent: Wednesday, December 08, 2010 2:26 AM
> To: Paul Hoffman
lists
> 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
> 
have told
> me that specifying how public lists are publicly-readable and how
in
cover the
> > 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?
> >
Friday,
great

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 9 Dec 2010 00:15:59 -0800

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

> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 2:35 PM
> To: Jim Schaad
lists
> For what gain?  It is the list of documents you want to receive
notifications of
> changes.
> > 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.
> >> with
> >> one
list.
> >> 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.
> >>>>
> >> consensus before the telechat, we can use that time to move on other
> >> open issues.
> >>>>
> >>>> --Paul Hoffman
> >>>>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 9 Dec 2010 10:58:57 +0200

> notifications of changes.

I for example do follow some working groups more often (once per week
for groups like ipsecme) and in some working groups I only go through
changes every now and then (usually before ietf meeting). I most
likely do not want to get any email notifications from any of those
lists, but only have a web page where I can go to check what changes
there has been, or what is the current status of the documents on that
list.

I.e. this would be more likely be something like the daily dose of the
IETF, but on the limited set of documents, and different time
interval.

Also I do think list of lists feature is quite important for getting
lists usable. I myself probably do not have time to keep up
maintaining lists of interesting documents myself, so would really
like to be able to reuse list created for example by IPsecME WG chairs
for documents which are interesting for ipsecme wg people. Then I
would like to combine it with some other list from some other wg
chair, and then combine them to one list which contains documents of
interest for me.

If we do not allow list of lists, then I need to combine lists myself,
or more likely I need to go through multiple lists manually. In this
manual process I most likely need to do manual duplicate elimination
too, and this would be done automatically for list of lists (i.e.
documents should appear on the resulting list only once, regardless
from how many different sublist it came out.

Loop detection etc is problem that can be solved. 
-- 
[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 09 Dec 2010 10:51:01 +0100

Hi Russ,

> one and only one of them.

I think this can be made to work in a good way, with little added
complexity; especially if we don't put too much into the specification
about multiple ways to name, hide, and password protect these.

(If we make the key to each list a user-configurable string, chosen when
the list is set up, with a default which is just a freshly generated
random string, the implementation will be the same for both kinds of
list.)

Best,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 09 Dec 2010 10:56:38 +0100

Jim,

> easier but still keep some of the flexibility of having nested lists.

It's not that these things can't be solved, it's more a matter of both
specification and implementation (*not* just the implementation) of this
particular feature becoming several times more complex for very little gain.

It's better to start out with something which will handle 90% of the needs
and is simple, and then see which itch is most urgent to scratch once that's
in place.

Regards,

	Henrik

---

From: Russ Housley <[email-masked]>
Date: Thu, 09 Dec 2010 09:34:23 -0500

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2010 19:22:02 -0800

This is a good discussion with lots of different views. After the telecon on Friday (would that be a voice-to-voice or v2v meeting?), I'll probably do an informal poll and see where we get.

As a lead-up, I want to reiterate that we all seem to be talking about having lists be created and edited by one person (for private/anonymous lists) and a very small number of known people for IETF-activity lists such as WGs and areas. What seems to be in question is what to do about the rest of the world being able to read those lists. Of course, IETF-activity lists only exist so that there can be readers, but there are differing views on whether the value of having private/anonymous lists outweighs the costs. A related idea is "not in the first round, but make them available later".

Wearing no hat: I think it is useful for me to be able to see someone else's list, for example when I'm starting up on a new topic that is not just a single WG. As an example, "Dan Wing's view of what is most interesting in v6 transition ideas" would be much more useful to me than "everything in BEHAVE". Also, there might be some good personal lists for topics in closed WGs, such as "Jim's view of ongoing work in S/MIME".

--Paul Hoffman, Director
--VPN Consortium