On Wed, Feb 06, 2002 at 02:52:49PM -0800, Jerome M Berkman wrote:
> 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).
All right, to prove my point, I have now surveyed the 49 flagship state
universities other than Berkeley, and collected information about their
directory entries and namespace. The results are at
<http://beef.berkeley.edu/report/survey.html>. 42 of the 49 list top-level
or near-equivalent addresses (like u.washington.edu) in their directories.
Any randomly-selected group of private universities shows similar
tendencies.
Self-selection is the dominant choice among those universities, with
over half appearing to use self-selection.
So, not only am I confident that "most" is better than "many," but I think
I'm going to strengthen the wording and provide some statistics.
> paragraph 2: I'd start the first sentence "Berkeley has not yet made ..."
> The history is irrelevant.
I disagree. I think a natural question someone reading this report would
ask is, "if everyone else does it, and it's not expensive, why haven't
we done it?"
> I'm also not convinced of the second sentence; I'd replace "they often"
> by "many" or delete the sentence.
I'm comfortable with it as-is.
> 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.
The reference to e-Berkeley is there as a funding hook. I think e-Berkeley
is ill-defined enough that it can be (and has been) invoked at any time
in support of just about anything. (The list of projects requesting
e-Berkeley funding was all over the map).
What do other people think?
> 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>.
Interesting. Fixed. (Mozilla didn't display the error).
> 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.
(I discarded USC and CUS as acronyms first...)
I think your paragraph above is fine, but using "socrates/uclink/CalNet
namespace" every time later on gets pretty klunky. What do people think?
> 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.
This is related to the question Jacqueline asked about what "deprecated"
means, and I'm working on that. I've just added a footnote which might
make it more comprehensible.
I agree that we don't want to turn over names as rapidly as CalNet does.
What we had discussed was that as long as we reserve the name, we should
provide some service to it. A deprecated address might not forward
mail, instead bouncing back a message to the sender saying "this person
has left the university, his last known forwarding address is...".
The crux of the recommendation is that if we're going to reserve the
name, we shouldn't just bounce mail with "user unknown".
> 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.
The online alumni community will have its own mail forwarding service,
with its own namespace issues. They could move someone's berkeley.edu
name over, maybe by putting a graduation year after it.
I don't think our recommendation is very strong, since we don't have a good
idea of the constraints of the OAC service.
> 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.
Who would it be confusing to? The CalNet name is supposed to be private.
> 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.
I don't really have the mindset of someone who would want this to be an
opt-in service, but really how would it be any different if they suddenly
had a tholub@berkeley.edu address that forwarded to uclink, as opposed to a
tholub@berkeley.edu which pointed to uclink? I don't think most users
would notice the technical difference. If they'd object to the one why
wouldn't they object to the other?
I've added a reference to the 8-character problem.
> 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.
I disagree with this last. Where the e-mail forwards, and what a user wants
his published directory address to be, are two different pieces of data.
john@math might want to publish his john@berkeley.edu address, and jane@math
might want to publish her jane@math.berkeley.edu address; it should be
a matter of choice, and you can't do that with just one field.
Unless you're suggesting that people's @berkeley.edu addresses should be the
only thing published in the campus directory. I don't think that would make
sense for an opt-in service, because it could provide a disincentive.
I'm not clear on your first point. There are definitely two items
talked about in that bullet point; the LDAP database and the web interface
to it. What separate recommendations do you see for those two areas?
They seem rather conflated to me.
> In the next paragraph, I don't know what "off the above page" refers to.
Fixed, with links.
> 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.
I thought we had pretty strong consensus on this idea when it was
discussed.
> 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"
I just put that in there to see if people were really reading it.
(Actually I was updating it due to JC's comments, and got distracted
halfway through).
> 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.
I think it's useful to have a link to a page which explains the mail relay
issue to those who may not understand it (which probably includes much of
ITAC). Do you have a different page you'd prefer? Or would you like to
write something up?
> 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.
I've added a paragraph about this possibility.
> Spam - unless we have some idea of a solution, I would leave this out.
We'd be negligent to not mention spam; it seems like the top concern
of users these days, and we will surely be asked "will this service
increase the amount of spam I get?"
> 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, ...
Done.
> BEEF: Expenses and Workload Issues page:
>
> If 2 boxes are used, what decides which gets mail? That needs to be
> addressed.
Does it need to be addressed by BEEF? It seems more like an implementor's
decision to me. Round-robin DNS and MX records are two obvious solutions,
but I don't have any real idea what I'd recommend.
> 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.
Lucia?
> 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.
I see a number of problems with direct LDAP lookups. For one thing, the
potential load on the LDAP server could be orders of magnitude higher than
what it's handling now. This is especially bad because our LDAP server
architecture is likely to not be as scalable as our Berkeley.EDU server
architecture; as we get more Berkeley.EDU servers, they could combine to
beat the LDAP server into submission. It also would make the LDAP server a
very large, looming, single point of failure. With a distributed
architecture and batch updates of an alias file, the LDAP server going down
isn't a big deal, mail continues to flow. (And you can lose all of your
distributed servers except one, and mail will continue to flow). If you
direct-lookup to LDAP, when the LDAP server goes down, mail would stop for
everyone using the service. That could be a huge problem; I don't think the
current LDAP service is designed with that level of mission-criticality in
mind.
What do other people think?
> Under ongoing workload, I would separate system management from
> postmaster/consultant, and split the FTE.
Do you have a guess for what the split would be?
-- Tom Holub (tom_holub@LS.Berkeley.EDU, 510-642-9069) College of Letters & Science 249 Campbell Hall
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 16:29:59 PST