[Internal-cg] Further RFP revision

[Manal Ismail]

Dear All ..

I have inserted a few suggestions to v10 circulated earlier by Alissa ..
Suggestions are mainly on the below paragraph (also attached in track changes and loaded to the dropbox), where it now reads:

"During the development of their proposals, as the ICG is requiring proposals that have consensus support from a broad range of stakeholder groups, the operational communities are required to consult and work with other affected parties; likewise, in order to help ICG maintain its light coordination role, other affected parties are strongly encouraged to participate in community processes, where substantial discussions and decisions will be taking place.
Information on ongoing community processes can be found at <insert url where we can compile references to all ongoing processes and may add to it later if needed.>"

The main idea is to have more balanced and more convincing wording with respect to the 'other affected parties' .. I also believe that we should provide some guidance (one stop shop that includes gathered info) on where 'other affected parties' can participate ..

Hope this sounds reasonable ..

Kind Regards
--Manal 

-----Original Message-----
From: internal-cg-bounces at icann.org [mailto:internal-cg-bounces at icann.org] On Behalf Of Narelle Clark
Sent: Friday, August 22, 2014 4:33 AM
To: Alissa Cooper; joseph alhadeff; internal-cg at icann.org
Subject: Re: [Internal-cg] Further RFP revision

Other comments on the rest of the document likely to follow... but for now see below...

> -----Original Message-----
> From: internal-cg-bounces at icann.org 
> [mailto:internal-cg-bounces at icann.org] On Behalf Of Alissa Cooper
> Sent: Friday, 22 August 2014 10:40 AM
 
> I took one more stab at this — v10 attached and uploaded.
<snippage> 
> In section 4 I still think there are three bullet points that need 
> elaboration, of just one sentence each, because they are not clear on their face:
> 
> ·Continuity of service requirements
> ·Risks
> ·Service integration aspects
> 
> For example, “Risks” seems so vague that each community could write a 
> novel about them and not be complete. What are we really looking for 
> here?

[Narelle Clark] 

When I put these things in originally, the intention was to ensure communities had considered, and properly assessed, the real operational impact of any transition. It comes from years of experience writing (and receiving responses to) engineering tenders for services supply in telcos.

When something changes, it has to move from state A to state B, and hence continuing service may be interrupted. Stuff that literally cannot be shut off should be identified and a transition mapped. My view was that the communities should assess whether there were direct operational impacts like these to be considered. There may not be, but they should at least think about ensuring appropriate systems exist, or at least oversight of such processes where they do exist. The existing contract has a raft of stuff about very real operational matters. The trick is ensuring that we get back proposal wording at the 'meta-level' (meta-meta-level?), ie oversight, rather than the operational itself.

Service integration aspects likewise is one triggered from thinking about direct and functional operational issues. This is the "do you have an API in operation and if so where?" question. I'm not aware of any being in place in this system right now, but you never know... some sort of automated interface might be flushed out in this process of assessment! Again, the trick will be to ensure that we get back proposal wording at the 'meta-level' (meta-meta-level?), ie oversight, rather than the operational itself.

My thinking on risk was expressing a hope the communities would do a risk assessment of sorts. Preferably a formal one. We could therefore request a copy of any formal risk assessment process undertaken. [I would not want to prescribe one as that opens another array of assessment possibilities, and I understand from my standards work that the model for risk assessment is currently evolving to one better suited to complex systems, interdependency, and shades of probability, rather than direct likelihood and ratings.]

Otherwise it is potentially incumbent on us to trigger a risk assessment process.


Does that make these items clearer?


Narelle



_______________________________________________
Internal-cg mailing list
Internal-cg at icann.org
https://mm.icann.org/mailman/listinfo/internal-cg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IANA Transition RFP v10 (MI).docx
Type: application/octet-stream
Size: 38330 bytes
Desc: IANA Transition RFP v10 (MI).docx
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140822/88362d2f/IANATransitionRFPv10MI.docx>