[ALAC] Where is ALAC on the TAS problem?

Thu Apr 19 07:03:19 UTC 2012

*I agree with Carlton that we can/should wait until the next (hopefully
conclusive) statement by the COO.*
*
*
*That being said, Beau makes several good points:*
*- this does seem to have the potential of impacting the user community,
but also of harming user trust in ICANN;*
*- we require a thorough account of what went wrong, in order to understand
whether the design was faulty, or the implementation;*
*- and yes, within ALAC and At-Large we should be mindful of the context in
which this incident is taking place: NTIA sending ICANN back to the drawing
board to better claim the IANA contract, a period of expectation before the
nomination of the next CEO, an overall sense of uncertainty regarding the
capability to receive numerous applications for new gTLDs and to process
them correctly.*
*
*
*So, if ICANN's report in the next few days does not properly address the
TAS problems, I think the ALAC should be prepared to voice its concern and
offer recommendations where necessary.*
*
*
*In light of this, may I suggest that Beau, Carlton and a handful of
volunteers if required, make a note of what an ALAC statement would have to
include, in terse prose? As to the most efficient delivery, I would suggest
a letter from the ALAC Chair to the Chair of the Board (we did this a few
months ago, and it did have an impact), which could also be posted on a
couple of influential sites.*
*
*
*Best regards,*
*Jean-Jacques.
*
Le 19 avril 2012 07:16, Carlton Samuels <carlton.samuels at gmail.com> a écrit
:

> Beau:
> Yes,  I do agree that there is a PI angle here.  And the ALAC has a duty of
> care.
>
> I have been following the updates from both thru my 'watcher' on the
> Announcements page as well as the Skype chat.  Those of us with some
> technical skills do indeed have worries; Dev, for one, has privately shared
> a few, in fact in line with some of the questions you raised.
>
> I've run a few operating support systems for a living so I confess some
> sympathy here.  In my view, Akram's statement should give us pause; we now
> have a proximate cause, a better understanding of the risk profile but less
> than useful hard facts on impact or origination/initiation. So, let's keep
> our powder dry and wait till we see what they come with in the promised
> 'details' on Friday.
>
> - Carlton
>
> ==============================
> Carlton A Samuels
> Mobile: 876-818-1799
> *Strategy, Planning, Governance, Assessment & Turnaround*
> =============================
>
>
> On Wed, Apr 18, 2012 at 1:34 PM, Beau Brendler
> <beaubrendler at earthlink.net>wrote:
>
> > Greetings, colleagues.
> >
> > Some discussions are taking place on the NCSG list about the TAS problem
> > and the way ICANN is handling it. I do not see similar discussions taking
> > place among the at-large. Pardon me if I have missed them. Indeed, I
> > believe some have raised the issue in the skype chat of the TAS SNAFU
> (or,
> > as my English relatives would call it, monumental cock-up), but with the
> > opinion that end-users are not affected, so it's not worth worrying
> about.
> >
> > In my opinion the situation has become worse, to the degree I beg to
> > differ -- the public interest is indeed affected. Note the most current
> > communique from ICANN staff April 17:
> > ---------------------------------------------------
> > TAS Interruption - Update (17 April 2012)
> > Statement by Akram Atallah, COO
> > 17 April 2012
> > ICANN's review of the technical glitch that resulted in the TLD
> > application system being taken offline indicates that the issue stems
> > from a problem in the way the system handled interrupted deletions of
> > file attachments. This resulted in some applicants being able to see
> > some other applicants' file names and user names.
> > As reported yesterday, we are seeking confirmation that the solution we
> > have implemented for this issue is effective.
> > We are also conducting research to determine which applicants' file
> > names and user names were potentially viewable, as well as which
> > applicants had the ability to see them.
> > Many organizations are seeking information on whether we will proceed
> > with the planned publication of applied-for domain names on 30 April. We
> > will update the target date for publication as part of our update on the
> > timing of the reopening, no later than Friday, 20 April at 23.59 UTC.
> > ---------------------------------------------------------------
> > Note that ICANN was aware of this "glitch" almost a month previously, but
> > apparently took no action. In my opinion (and others), this situation is
> > going to escalate. Certainly it is in the public interest, even beyond
> the
> > obvious issue that there may be problems with applications from would-be
> > public-interest gTLD sponsors.
> >
> > * Is it not within the public interest to demand a full accounting of
> what
> > went wrong with an integral system, indeed, the first "system," to be
> > publicly rolled out in the "mechanical" application process for new
> gTLDs?
> >
> > * Was the TAS hacked? Coded incorrectly? Who performed the work? Who
> > reviewed it? Can ICANN as an organization address the credibility problem
> > created by this? How can the public expect that the safety, stability and
> > security of the Internet will be safeguarded by ICANN, if at the first
> > phase of the process the organization cannot field a working system for
> > gTLD applications?
> >
> > * Is ICANN aware, regardless of the bureaucratic or technical processes
> > involved, that together with the temporary loss of the IANA contract, the
> > back-and-forth of the IOC/RC process, and now the TAS problem, an
> observer
> > may conclude that the organization can't fulfill its mandate?
> >
> > What should the ALAC do (in my opinion)?
> >
> > * Call for a full, independent review of the TAS process from soup to
> > nuts. Why was the technical problem not acted upon sooner? What emergency
> > response protocols are in place? Any?
> > * Offer to coordinate candidate selection for such a review, to help
> > ensure the same people who made the mistakes are not reviewing their own
> > work.
> > * Determine what organizational problems within ICANN led to this
> failure.
> > * Undertake an analysis of those problems to address whether such
> > incompetence could spill over into the actual process of bringing new
> gTLDs
> > online, vis-a-vis the stability, safety and security of the Internet.
> Make
> > that analysis comprehensive and, most important, public.
> > * Undertake a review to determine if ICANN does, in fact, have the
> > technical and organizational capabilities to actually execute its
> mission,
> > and if not, fess up and hire some people who know what they are doing.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > ALAC mailing list
> > ALAC at atlarge-lists.icann.org
> > https://atlarge-lists.icann.org/mailman/listinfo/alac
> >
> > At-Large Online: http://www.atlarge.icann.org
> > ALAC Working Wiki:
> >
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
> >
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>