[Internal-cg] PTI Slide 2 action items
Alan Barrett
apb at cequrux.com
Wed Sep 23 05:52:32 UTC 2015
Russ Housley and Alan Barrett were asked "to do the next level filtering for PTI related issues listed in the PTI slide deck, review comments received, and make recommendations for ICG course of action (http://icgsec.asia/1FTPuNB)” for those items on slide 2.
Slide 2 contains the following text:
> CRISP / IANAPLAN - PTI
>
> B. (B. Carpenter-2, R. Dara-23, Google-31, Dyn-34, CONAC-50,
> ISPCP-64, IAB-72, J. Panday- 89, IA-103, F. Hopkinson-105,
> CDT-107, P. Nagaraj/G. Varma-113, NCSG-114, Access-116, ICANN
> Board-121, Intel-122, K. McCarthy-128, DSCI-130, CRISP-133)
>
> B1. Clarify that IETF and RIRs will contract with ICANN, not PTI
> B1a Affirmed by 72, 133
>
> B2. IETF and RIR MoUs/SLAs need to clarify that subcontracts are allowed
>
> B3. Details of subcontract(s) between ICANN and PTI for protocol
> parameters and numbers need to be worked out during proposal
> phase
>
> B6. Performance reviews of IFO; participation of OCs in IFR, CSC
>
> B6a. Proposal should clarify that IFR applies only to names (34, 72),
> CSC applies only to names (2)
>
> B6b. Numbers and protocol communities do not plan to participate
> in IFR or CSC (72, 133)
>
> B6d. Complying with IFR recommendations should be mandatory for PTI (80)
>
> B7. NRO/RIRs not capable of holding contract with ICANN (105)
>
> Clarification exists in comment 72 and 133, but question is whether:
> - Do 72 and 133 cover the issue?
> - Should text from 72 and 133 be included in ICG text?
> - Should text from 72 and 133 be part of the CRISP proposal?
Our comments are:
> B1. Clarify that IETF and RIRs will contract with ICANN, not PTI
> B1a Affirmed by 72, 133
The proposal from the IANAPLAN and CRISP groups were
clear that the IETF and RIRs will contract with ICANN.
This has also been confirmed in a comment from the IAB
(comment number 72), and in a draft SLA from the RIRs
<https://www.nro.net/wp-content/uploads/Numbers-SLA-2.0.pdf>,
and in question 8 of the ICG FAQ
<https://www.ianacg.org/iana-stewardship-transition-coordination-group-icg-faq/>
Proposed ICG action: No action needed.
> B2. IETF and RIR MoUs/SLAs need to clarify that subcontracts are allowed
The existing MoU/SLA between the IETF and ICANN
<https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-2000-03-01-en>
is silent about subcontracting, and
therefore implicitly allows subcontracting. The
draft contract/SLA between the RIRs and ICANN
<https://www.nro.net/wp-content/uploads/Numbers-SLA-2.0.pdf>
allows subcontracting with permission. Question 8 of the ICG FAQ
<https://www.ianacg.org/iana-stewardship-transition-coordination-group-icg-faq/>
also says that subcontracting is allowed.
Proposed ICG action: No action needed.
> B3. Details of subcontract(s) between ICANN and PTI for protocol
> parameters and numbers need to be worked out during proposal
> phase
This is an implementation issue. Any contract between ICANN and
PTI would need to satisfy the CWG-Stewardship requirements for the
names functions, and satisfy the IETF and RIRs’ contracts with
ICANN for the protocol parameters and numbers components.
Proposed ICG action: No action needed.
> B6. Performance reviews of IFO; participation of OCs in IFR, CSC
>
> B6a. Proposal should clarify that IFR applies only to names (34, 72),
> CSC applies only to names (2)
We agree that clarity is needed, and note that a similar issue
exists with the terms “IFO” and “IANA Functions Operator”
in the CWG-Stewardship proposal.
Proposed ICG action:
a: Ask CWG-Stewardship for confirmation that the terms “IFO”
and IANA Functions Operator” in the names proposal apply only to
the names part of the IANA functions;
b: ask CWG-Stewardship for confirmation that the CSC and IFR apply
only to the names part of the IANA functions;
c: edit the FAQ and part 0 of the combined proposal to provide clarity.
> B6b. Numbers and protocol communities do not plan to participate
> in IFR or CSC (72, 133)
The protocol parameters community has made it clear (see comment
72) that they do not intend to participate in committees related
to names functions. Alan Barrett thinks that the numbers
community indicated that, if they participated in these processes
at all, it would be only because the numbers community uses the
.ARPA domain name, but he was unable to find a clear statement of
that principle.
Proposed ICG action:
a: Ask CWG-Stewardship whether .ARPA is included in the CSC and IFR processes.
b: Ask CRISP whether the numbers community will participate in the
CSC and IFR processes, and whether the answer depends on whether
or .ARPA is included or excluded.
c: Edit the FAQ and part 0 of the combined proposal to provide clarity.
> B6d. Complying with IFR recommendations should be mandatory for PTI (80)
Comment 80 (the english translation) says “We suggest the
further clarification of whether the reviewing decisions or
comments from IFR and Special IFR are mandatory to PTI, and that
the manner in which to ensure that the reviewing comments from IFR
and Special IFR can be implemented be made clear.”
Proposed ICG action: Ask CWG-Stewardship for clarification
on whether PTI compliance 9s mandatory when decisions or
recommendations are made by IFR or special IFR.
> B7. NRO/RIRs not capable of holding contract with ICANN (105)
Comment 105 suggests that the NRO is not capable of contracting
with ICANN. This question is moot because the contract will be
between the 5 RIRs and ICANN, not between the NRO and ICANN.
Proposed ICG action: No action needed.
> Clarification exists in comment 72 and 133, but question is whether:
> - Do 72 and 133 cover the issue?
> - Should text from 72 and 133 be included in ICG text?
> - Should text from 72 and 133 be part of the CRISP proposal?
If the CRISP proposal is edited, then the numbers community is
likely to insist on an additional public comment period, so edits
to the CRISP proposal should be avoided if possible.
Edits to part 0 of the combined ICG proposal are somewhat easier.
Proposed ICG action: See the individual points above.
Alan Barrett and Russ Housley
More information about the Internal-cg
mailing list