[Internal-cg] combined proposal assessment

joseph alhadeff joseph.alhadeff at oracle.com
Tue Jul 14 16:08:28 UTC 2015


Colleagues:

Sorry to be late for the party...  I attach my version of the combined 
proposal assessment and pasted it below.

I'll be offline for next hour and a half and be back online later...

Joe

A. Compatibility and interoperability: Do the proposals work together in 
a single proposal? Do they suggest any incompatible arrangements where 
compatibility appears to be required? Is the handling of any conflicting 
overlaps between the functions resolved in a workable manner?

The Communities by and large operate in a coordinated, yet mostly 
independent manner which is reflected in the fact that there are few 
dependencies or inconsistencies across the proposals.One issue which has 
come to light involves the IANA trademark, its ownership and use.IETF 
and RIRs seem to have a path forward on resolution though some details 
on timing may still need to be worked out. While use of the mark seems 
easy to resolve, its ownership may have further external 
dependencies.The Names proposal, as drafted, creates limited potential 
for incompatibility based on possible future actions; it specifically 
outlines:

The IETF, through its responsibilities for developing the underlying DNS 
protocol and its extensions, could designate parts of the domain name 
space for particular protocol-related purposes that may overlap with 
usages assigned through ICANN policies. It may also designate portions 
of the namespace as invalid, illegal, or reserved based on the evolution 
of the underlying DNS protocol and its extensions. It may also expand 
the scope of namespace to be managed through such changes.

However, while addressing all required elements, the names proposal is 
not a final proposal as it has significant dependencies on the external 
work on ICANN Accountability Mechanisms; most importantly, the creation 
and operation of the PTI. Without knowing the final outcome and detail 
of that proposal and the finalization of the names proposal it is 
impossible to answer this question with finality at present.If the 
proposal remains unchanged after finalization there should be 
compatibility assuming the trademark issue, highlighted above, is 
appropriately resolved.

B. Accountability: Do the proposals together include appropriate and 
properly supported independent accountability mechanisms for running the 
IANA function? Are there any gaps in overall accountability under the 
single proposal?

RIRs and IETF have long operated under mostly existing accountability 
mechanisms which are well documented and operationally effective.The 
proposals build on those accountability functions.

The Names proposal provides very detailed elements of accountability 
that are only proposed, as opposed to final, because of their dependency 
on the CCWG accountability work, which is still in process.While the 
elements described seem to provide appropriate accountability 
safeguards, the external dependencies make it impossible to conclude on 
this issue.

C. Workability: Do the results of any tests or evaluations of 
workability that were included in the component proposals conflict with 
each other or raise possible concerns when considered in combination?

The proposals as combined create an unwieldy document that is not easily 
accessible for the non-initiate.That being said, any attempt to edit the 
community consensus proposals into a combined proposal would require us 
to revert to the operational communities and cause significant and 
unacceptable delay. We may wish to address this, and why we have not 
developed a more streamlined version, in our companion materials.

The RIRs have indicated in their proposal the ability to change 
operators as part of overall accountability.The issue was raised as a 
concern in our discussion of the proposal (also in direct e-mail 
exchanges), that multiple operators (as the contract seemed to imply the 
potential for multiple operators) might raise a greater potential for 
friction or fragmentation that was not fully addressed. Changing the 
operator, while a step that should not be taken lightly, would not 
necessarily impact the functionality or stability of operations where 
only one operator was being considered.Multiple operators may likewise 
be workable, but there was little demonstration that the scenarios had 
been appropriately considered as to issues it might raise and possible 
needed safeguards whether contractual or operational.I thought this had 
been addressed, but some recent exchanges seemed to have indicated this 
was still a possibility? I raise this as an issue for consideration. If 
collectively we feel that this eventuality would not create these 
issues, I will defer to the greater technical expertise of the group.

The Names proposal may well raise the most issues of workability as it 
depends on entities and operational functions not yet in existence.The 
proposal does provide some aspects of scenario analysis related to 
workability, but again this is based on the proposal as it exists, which 
is not assured.



On 7/14/2015 10:42 AM, Milton L Mueller wrote:
>
>> -----Original Message-----
>> Wouldn't this then mean in consequence that for the contractual
>> relationship of the SLAs no real alternative is given rather than a subcontract
>> with the PTI?
> Well, for the short term all 3 OCs have agreed to use the status quo IANA for their part of the functions. It's just that the status quo IANA is becoming PTI. So if you contract with ICANN, yes, you are required to contract with either PTI or to contract with ICANN which will subcontract or assign the contract to PTI.
>
> But in the future, all OCs do have, and should have, "a real alternative" in the sense that they can switch providers according to the procedures set out in their proposals. So when you say there is "no real alternative" I assume you just mean in the initial setup period of the transition.
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at mm.ianacg.org
> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150714/20ab72f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JHA proposal review.doc
Type: application/msword
Size: 31744 bytes
Desc: not available
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150714/20ab72f1/attachment.doc>


More information about the Internal-cg mailing list