Subject: Re: [Tools-discuss] Re: Vancouver IETF Code Sprint

From: "Bill Fenner" <[email-masked]>
Date: Thu, 8 Nov 2007 08:44:27 -0800

This is coming up quickly, so I'd like to get more discussion of
what's on the table.

There are a few possible work plans:

- Port password-protected tools from the perl CGI to the django framework

- Updates to existing django-based tools (e.g., more information on a
draft at https://datatracker.ietf.org/drafts/draft-name/, or similar)

- Completely new django-based tools (e.g., new atom feeds, completely
new views of the data)

- Updates to other pages, e.g., those at tools.ietf.org.  (This was
not envisioned when we announced the sprint, but nearly all of Lars'
suggestions are for the wg pages on tools.ietf.org)

Obviously, the ideas don't need to just come from those attending - if
you had a wish for the IETF web site, what would it be?

  Bill

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 18:27:08 +0100

Bill Fenner wrote:

> e.g., new atom feeds

If you're talking about feeds tracking drafts (outside of what the
tracker does after PubReq) some folks might like this.  Or rather
somebody asked me how to track what happens with a draft.  After I
let it expire for some weeks, waiting for new events on the Usefor
and 2822upd fronts.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Nov 2007 12:11:53 +0100

> - Port password-protected tools from the perl CGI to the django framework

How about (optionally) supporting OpenID for authentication?  Having a
password for each and every site gives a bad user experience.  If
developer time is the limiting factor, I would volunteer to integrate
it.  I would expect the existing approach to continue to work, for those
that doesn't want to use OpenID.

/Simon

---

From: =JeffH <[email-masked]>
Date: Fri, 09 Nov 2007 14:26:30 -0800

> that doesn't want to use OpenID.

well, one should really ask about whether to support some form(s) of Web SSO on 
the site rather than one particular protocol. And whether it's really 
necessary, e.g. due to browser username/password convenience features. And to 
uplevel even further, the discussion should really be what identity providers 
are considered as acceptable risks by the IETF/ISOC site admins? And then one 
works to support the protocol(s) wielded by those identity providers.

=JeffH