[Internal-cg] OC roles during implementation phase

[Jari Arkko]

> I have a request to make as a follow-up to something I said on the recent call. I think it would be useful for the ICG to understand if the OCs have an idea of what they expect their role to be during the proposal implementation phase. If we could get that information from the OC reps before the F2F, I think it would help facilitate our discussion of what the ICG role should be, if any. So I’d like to ask Jari, Paul, Alan, Martin, Wolf-Ulrich, and Milton if you could provide whatever information is available along these lines from your respective OCs. I realize that on the one hand some implementation work is already ongoing and on the other hand the OCs may not have discussed their own roles much, so whatever information you feel is appropriate to provide would be appreciated.

I approached this question from my own perspective and with knowledge of ongoing activities, rather than, e.g., trying to establish an IETF our leadership team opinion on what the role of the OCs is. In other words, I’m speaking personally but with some visibility into how we generally approach things.

From my perspective our OC, IETF, feels responsibility for our part, protocol parameters, as a whole. That is, we want to be involved in the entire lifecycle, from early discussions to planning of changes to implementation to daily operations. Obviously not alone, working with IANA and others. For instance, when an operational issue comes up, such as an RFC disagrees with IANA registry, we dig through the issue with the help of our community and IANA, and fix the registry or the RFC or both. Working with you all on the transition planning. And so on.

Anyway, the IETF as a whole is similarly involved in the implementation phase of any changes from the transition, just like we’ve done with any previous changes. For instance, we would be a party in revisions to the yearly service level agreement that is from our perspective one implementation step for our part of the transition. ICANN would be the other party in this case, as soon as there’s a general go-ahead for for any changes (even if the changes to our service level agreement are not big, they are more akin to the kind of changes we’d be making operationally every year).

Similarly, the IETF would be a party to any IPR arrangements, along with the other OCs and ICANN. As noted there’s been discussions of that; work is ongoing.

So we would definitely be involved in all steps touching protocol parameters. But it is important to understand the division of work within the IETF organisation. We generally involve our community when there is a policy or high-level direction question. This is what we did with the overall transition plan. Not all questions go through IANAPLAN WG, however, some issues are just operational or legal arrangements and within the previously set direction. These are topics that the IAB, IAOC and the IETF Trust would handle within their respective roles. The IAOC, for instance, is ultimately responsible for approving contracts to be signed. The IESG also has much of the operational responsibility for resolving daily technical question marks.

Bigger changes - for instance, significant new arrangements with IETF Trust  - would certainly be confirmed with the community. We did that early on when we asked if our community would be OK with the arrangement suggested by the RIRs. Further checks may be needed as the matter progresses.

I don’t speak for the other communities, but I suspect their answers probably are similar. They need to be ultimately responsible for implementation steps and decisions on their side. The work is divided among the WGs created for the transition planning and the leadership teams and staff; the latter  needs to execute the instructions the community has provided in their plan.

Jari

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150916/25461494/attachment.asc>