Tom,
Here are my comments.
Beef homepage:
Replace "Most universities" by "Many universities". I haven't
seen any documentation that most, especially most large universities
do this, and many (most?) of such services at large universities
are much different than what is proposed here (e.g., no self-selection).
paragraph 2: I'd start the first sentence "Berkeley has not yet made ..."
The history is irrelevant.
I'm also not convinced of the second sentence; I'd replace "they often"
by "many" or delete the sentence.
paragraph 3: I don't believe there is an "implication of factionalism"
if a user has a @uclink.berkeley.edu or @library.berkeley.edu or
@ls.berkeley.edu address. I think people think of email addresses as
bizarre, meaningless strings. I think this should be deleted.
paragraph 4: I think this is the primary motivation. I would move
it up and leave off "in addition".
paragraph 6: I followed the e-berkeley link, and don't see the
relationship of the philosophy expressed there to BEEF; unless I'm
missing something obvious, I'd leave out the reference to e-berkeley.
Expenses and Workload: In Netscape, everything from here to the end
is underlined, but not in IE. I think the problem is an <a> after
"Workload" when it should be "</a>.
Namespace page:
I'd rather not invent an acronym, especially one with potential
negative connotations, for something which appears only three or four
times. Instead, how about:
The service should join the existing socrates/uclink/CalNet
namespace. A user who owns a name in the namespace should be
the only person who can register that name as an @Berkeley.EDU
address. Conversely, a person who has registered an @Berkeley.EDU
address should be the only one allowed to select that name on
uclink, socrates or CalNet.
Let's specify maximum length of names to be that allowed by the
namespace, which is 40 or 50, rather than what is "technically
reasonable".
I do not agree with the Name retention and reservation paragraphs.
I believe the name should be reserved for the owner for one or several
years after they leave the campus in case they return. Many students,
faculty, and staff leave for a year or two and then do return.
The name should be made available immediately if the user cancels
the service. Then there is the question of whether the previous name
should become available after a change of @berkeley.edu address.
I don't know what the following implies:
It might be attractive to transfer @Berkeley.EDU names into
the Online Alumni Community when students graduate.
I'd like to find out before we recommend it.
With respect to the "First-come-first-served names, with no restrictions."
section, I would also mention it would be confusing if "john@berkeley.edu"
was not the same as the owner of the CalNet "john" name.
I think the "pointing to UCLink" paragraph doesn't reflect the
reasons that option was rejected. The main reasons were that
UCLink currently has an 8 character limit on names and that
people did not want to coordinate with the name space.
As for "optin", my concern was automatically creating a .berkeley.edu
name for someone who didn't realize it was created. That would not
be an issue if UCLink were used. This paragraph needs rewriting.
The BEEF process page:
The paragraph titled
"CalNet Directory should be the primary interface ..."
discusses LDAP, not the interface. It is a separate recommendation
and should be a separate bullet. I would like to recommend adding
only one field to CalNet, the use's @berkeley.edu address, and having
the mail delivered to their already listed address.
In the next paragraph, I don't know what "off the above page" refers to.
And delete "SUC".
In the BILink section, I'd like to see a mock up of the page before
endorsing the design in the last sentences. I think it would be better
to leave this up to the Jacqueline, who supervises the BILink site.
In the last paragraph, "Current policy discussions", I can't figure out
the sentence including:
"students must maintain their current proposing is considering a scheme"
The BEEF Technical Recommendations page:
The "mail relaying" link goes off to Paul Vixie's site. I don't really
want to endorse that site. Let's just delete the link.
The second relaying paragraph ignores the possibility that other
Berkeley servers may allow users to use their @berkeley.edu address,
which would mitigate the problem cited.
Spam - unless we have some idea of a solution, I would leave this out.
I'd change:
The service will be easily scalable if it is implemented using slim,
...
to:
The service needs to be easily scalable. One way is to implement it
using slim, ...
BEEF: Expenses and Workload Issues page:
If 2 boxes are used, what decides which gets mail? That needs to be
addressed.
I'd suggest asking the CalNet team how much work this would take before
including a time estimate. I also don't see why two fields are needed.
Implementing the core service: I would like to see any changes take
place immediately, so having sendmail look up the address in the LDAP
directory would be my preferred solution.
Under ongoing workload, I would separate system management from
postmaster/consultant, and split the FTE.
On Tue, 5 Feb 2002, Tom Holub wrote:
> I've finished a draft of the proposal:
> <http://beef.berkeley.edu/report/>.
>
> One page that needs to be added is "Signatories and possibly
> Contributors"--we can talk about that at our meeting on Monday.
>
> Do you think we need a separate "Rationale" page about why it's a good idea?
> I have some rationale on the index page; do you think we need to sell it
> more?
>
> At what point should we send the draft out to a larger group, and what
> larger group should that be?
>
> Let me know if you have any comments.
>
> --
> Tom Holub (tom_holub@LS.Berkeley.EDU, 510-642-9069)
> College of Letters & Science
> 249 Campbell Hall
>
This archive was generated by hypermail 2b29 : Wed Feb 06 2002 - 14:52:52 PST