Further subdivision of IANA constituencies?
In response to the ICANN enquiry, the NRO and IAB submitted comments to suggest the constituency-based approach to transition planning, with an assumption of 3 constituencies or communities of interest in IANA services, namely names, numbers and protocol parameters. Although the CG has not agreed as such, it seems that we are proceeding in this direction. I am wondering now whether this needs more work and refinement, as we discuss the (un)likelihood of consensus within one or more communities. I think the "3-legged stool" view of IANA is valid and useful for this exercise - because the 3 communities, while they share an interest in IANA, are customers of a set of services which are almost entirely independent. So, in theory at least, we can do our work independently without too much risk of conflict. But we discussed this is breaking down in connection with the “names community”, because, it seems to me, such a community really does not exist, and may not be viable due to fundamental differences. Is there a solution for us in subdividing the names community further into GNSO, CCs, and Registries, as in fact the CG constituencies reflect. My question is whether the transition plans of these groups actually do need to be shared, or if they can be asked to lay out their plans/requirements independently, for us to then reconcile. We may find that their differences can actually coexist in the final plan, without breaking anything. Thoughts? Paul. ________________________________________________________________________ Paul Wilson, Director-General, APNIC <dg@apnic.net> http://www.apnic.net +61 7 3858 3100 See you at APNIC 38! http://conference.apnic.net/38
An intriguing suggestion, Paul. This is the kind of question we need to be asking and considering in response to the special problems associated with the DNS IANA. Probably best done at the meeting. Bear in mind, however, that TLD registries are part of the GNSO, fully represented in it. Adding even more complexity, where does the GAC fit in? Is it considered part of the GNSO recommendation? Does it make a separate recommendation? Does it fit into one of the three communities? I think the CG should strongly discourage a silo'd approach to the GAC, it badly, badly needs to be in full, integrated communication with other stakeholder groups. -----Original Message----- Is there a solution for us in subdividing the names community further into GNSO, CCs, and Registries, as in fact the CG constituencies reflect. My question is whether the transition plans of these groups actually do need to be shared, or if they can be asked to lay out their plans/requirements independently, for us to then reconcile. We may find that their differences can actually coexist in the final plan, without breaking anything. Thoughts? Paul.
I think it is an interesting suggestion, and worth perhaps considering. Assuming, of course, that the various parts of the names community agree. From my non-expert understanding, it would seem that there are aspects that are clearly different (e.g., cc/g) and some that need to be shared (e.g., same root). Jari
On Jul 16, 2014, at 6:16 AM, Paul Wilson <pwilson@apnic.net> wrote: <snip>
But we discussed this is breaking down in connection with the “names community”, because, it seems to me, such a community really does not exist, and may not be viable due to fundamental differences.
Is there a solution for us in subdividing the names community further into GNSO, CCs, and Registries, as in fact the CG constituencies reflect. My question is whether the transition plans of these groups actually do need to be shared, or if they can be asked to lay out their plans/requirements independently, for us to then reconcile. We may find that their differences can actually coexist in the final plan, without breaking anything.
Thoughts?
Paul.
Hi Paul, all, I think this could be a good way to start (assuming the Names constituencies agree with the stated premise and they think this is a useful approach). The Names transition plan could then be built up reflecting points of commonality; where there are differences the Names community can then evaluate those for impact and/or necessity. Based on how the Protocol Parameters and Numbers groups manage these spaces (your Circle ID article was helpful here and I saw a lot of resonance with the Protocol Parameters space), it also seems there might be the base for an evaluation framework as well. Best, Lynn
participants (4)
-
Jari Arkko -
Lynn St.Amour -
Milton L Mueller -
Paul Wilson