- If we introduce protocol-based QoS, won’t this provide any application using the protocol access to a differentiated QoS? I sense that QoS can be applied in a very granular fashion, but do I really want to turn my entire team of network specialists into QoS specialists? (From an operational perspective, I know I can’t afford to!)
- When is the right time to introduce QoS? Users are clamoring for QoS ASAP, as it’s often perceived as a panacea – a panacea that often masks the root cause of what really ails them … From a routing and switching perspective, do we wait for tangible signs of congestion, before implementing QoS? I certainly have the impression that others managing Campus as well as regional networks plan to do this.
- And what about standards? QoS isn’t baked into IPv4, but there are some implementations that promote interoperability between vendors. Should MPLS, used frequently in service providers’ networks, be employed as a vehicle for QoS in the Campus network context?
- QoS presupposes that use is to be made of an existing network. Completely segmenting networks, i.e., dedicating a network to a VoIP deployment, is also an option. An option that has the potential to bypass the need for QoS.
- Lifting a heavy prop awkwardly at our annual Mardi Gras event. I felt a twinge of pain, and suspect that this predisposed my back towards injury.
- Attempting to leave a leg-press machine before completely releasing the 220 lbs of weight that I, back included, was still supporting.
- Finished reading Seymour Schulich’s Get Smarter
- Devoured a few Greg Iles novels
- Devoured Rules for Renegades – The free resources at the book’s Web site are terrific, but you’ll definitely want to read the book as well
- Reviewed a book on BES installation and administration
- Am reviewing a book on the GWT
- Started and gave up on (after 50 or so pages) Jack Welch’s Straight From The Gut – I’m a little embarrassed to admit this, but I suppose it just didn’t resonate with me in my delicate state …
- Started reading Thomas Friedman’s The World Is Flat – I’m only on page 77, but I’m seriously hooked. More on this soon (I hope).
- Provided feedback on a scientific research manuscript on which I’m a co-author
- Thumbed various magazines
I fretted. About work – not being there, work piling up, etc. And about my exercise routine – that picked me up, and then knocked me down! I communed with my family – when they weren’t making up for my shortfalls – and with our pets (three cats and an obnoxiously vocal husky).
… unique business model allows [them] to bring [us] more focused information, giving [us] more of what [we] need to know, and less of what [we] don’t.
- Chapter 1 places the BlackBerry Enterprise Server (BES) in the broader context of Research In Motion’s (RIM) BlackBerry universe. In addition to itemizing relevant components, an introduction to the BlackBerry’s push model, security and Internet connectivity is provided.
- Though brief, Chapter 2 runs deep in addressing BES architecture and implementation planning. For example, we learn that the BES employs a modular architecture comprising over a dozen components. After succinctly enumerating the components and their function, BES requirements and prerequisites are identified. In addition to hardware and software requirements, recommendations are made with respect to networking your BES (e.g., firewall and/or proxy considerations) and providing it with a database. Easy to gloss over on first read are thoughtful recommendations on sizing the BES (including pointers to resources from RIM) and the database for the anticipated user load.
- Before BES components can be installed and enabled, the messaging environment and database server need to be configured. This is the subject of Chapter 3. Both local and remote database instances receive attention. Because each step is well illustrated, the book delivers on its intended purpose of serving as a solution guide.
- The installation of the BES is a multistep process enabled via a wizard. As in the previous chapter, in Chapter 4 the authors guide the reader through this process making appropriate use of illustrations. They interject appropriate commentary, and are clear on out-of-scope topics. The early emphasis on delineating BES architecture (Chapter 1) is realized as the authors transition the reader through the BES installation.
- Of course, installing the BES is just the beginning, and therefore the next few chapters focus on the additional tasks required to operationally deliver this service to its users. After introducing the six permissible levels of administrative role on the BES, attention shifts in Chapter 5 to the matter of provisioning users, groups and devices. And with respect to devices, wireline and wireless options for provisioning are given consideration.
- The BES ships with over 200 policies that can be applied variously to users, groups and devices. Also covered in Chapter 6 is the topic of provisioning software from RIM and third parties. Of particular value is the authors’ example of a software bundle targeted to a particular BlackBerry model. The ability to administer users, groups and devices with respect to policies (including software), from a single point of control (i.e., the BES server), speaks volumes to the appeal and value that this offering can deliver to corporate enterprise environments. This Chapter’s treatment of policies and software provisioning serves as an excellent introduction to topics BES administrators will return to repeatedly, and likely with increasing degrees of sophistication.
- Unlike many of the other chapters, Chapter 7 provides only an overview of multitiered administration – i.e., properties and tasks relating to users, groups, (BlackBerry) domains and servers. This enumeration of possibilities, presented in context, works effectively.
- A deeper discussion on security is the focus of the first part of the final chapter (Chapter 8). Encryption and authorization, both of which receive detailed consideration, amplify the value of the BES and its context in the overall BlackBerry universe for corporate enterprises. An unanticipated treatment of disaster recovery closes Chapter 8. In sufficient detail to enable a solution, the authors discuss in turn the measures needed to ensure that both the server (the BES) and its data (housed by the BES’s local or remote database) are readied for a disaster situation.
Earlier this week, I participated in the Net@EDU Annual Meeting 2008: The Next 10 Years. For me, the key takeaways are:
- The Internet can be improved. IP, its transport protocols (RTP, SIP, TCP and UDP), and especially HTTP, are stifling innovation at the edges – everything (device-oriented) on IP and everything (application-oriented) on the Web. There are a number of initiatives that seek to improve the situation. One of these, with tangible outcomes, is the Stanford Clean Slate Internet Design Program.
- Researchers and IT organizations need to be reunited. In the 1970s and 1980s, these demographics worked closely together and delivered a number of significant outcomes. Beyond the 1990s, these group remain separate and distinct. This separation has not benefited either group. As the manager of a team focused on operation of a campus network who still manages to conduct a modest amount of research, this takeaway resonates particularly strongly with me.
- DNSSEC is worth investigating now. DNS is a mission-critical service. It is often, however, an orphaned service in many IT organizations. DNSSEC is comprised of four standards that extend the original concept in security-savvy ways – e.g., they will harden your DNS infrastructure against DNS-targeted attacks. Although production implementation remains a future, the time is now to get involved.
- The US is lagging behind in the case of broadband. An EDUCAUSE blueprint details the current situation, and offers a prescription for rectifying it. As a Canadian, it is noteworthy that Canada’s progress in this area is exceptional, even though it is regarded as a much-more rural nation than the US. The key to the Canadian success, and a key component of the blueprint’s prescription, is the funding model that shares costs evenly between two levels of government (federal and provincial) as well as the network builder/owner.
- Provisioning communications infrastructures for emergency situations is a sobering task. Virginia Tech experienced 100-3000% increases in the demands on their communications infrastructure as a consequence of their April 16, 2007 event. Such stress factors are exceedingly difficult to estimate and account for. In some cases, responding in real time allowed for adequate provisioning through a tremendous amount of collaboration. Mass notification remains a challenge.
- Today’s and tomorrow’s students are different from yesterday’s. Although this may sound obvious, the details are interesting. Ultimately, this difference derives from the fact that today’s and tomorrow’s students have more intimately integrated technology into their lives from a very young age.
- Cyberinfrastructure remains a focus. EDUCAUSE has a Campus Cyberinfrastructure Working Group. Some of their deliverables are soon to include a CI digest, plus contributions from their Framing and Information Management Focus Groups. In addition to the working-group session, Don Middleton of NCAR discussed the role of CI in the atmospheric sciences. I was particularly pleased that Middleton made a point of showcasing semantic aspects of virtual observatories such as the Virtual Solar-Terrestrial Observatory (VSTO).
- The Tempe Mission Palms Hotel is an outstanding venue for a conference. Net@EDU has themed its annual meetings around this hotel, Tempe, Arizona and the month of February. This strategic choice is delivered in spades by the venue. From individual rooms to conference food and logistics to the mini gym and pool, The Tempe Mission Palms Hotel delivers.