CWG response on .ARPA (Fwd: Re: [NRO-IANAXFER] Questions from the ICG)
Dear all, Some time ago, I was saying that responding to the ICG question related to .ARPA in the manner we did may not be appropriate. Below is a draft response of CRISP that clearly prefers that it's related .ARPA strings be immune of CSC/IFR processes. Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. ---------- Forwarded message ---------- From: "Izumi Okutani" <izumi@nic.ad.jp> Date: 7 Oct 2015 23:02 Subject: Re: [NRO-IANAXFER] Questions from the ICG To: <ianaxfer@nro.net> Cc: Dear Alissa, Thank you and the ICG for your efforts in reviewing the public comments and the continued work on the combined proposal, as well as on the overall process. Please see below the draft response from the CRISP Team. We will have the CRISP Team call at UTC13:00 8th Oct to make a final confirmation, and will get back to you by UTC23:59 9th Oct, in case we indentify any changes needed. The responses are based on the Number Community proposal and the CRISP Team submission during public comment of the CWG-Stewardship proposal, therefore we wouldn't expect fundamental changes but there may be some additional points. 1) Yes we are willing to commit to coordinate with the other communities, as we have expressed in the Number Community Proposal: III.A. "the Internet Number Community wishes to emphasize the importance of communication and coordination between these communities to ensure the stability of the IANA services. Such communication and coordination would be especially vital should the three communities reach different decisions regarding the identity of the IANA Functions Operator after the transition. Efforts to facilitate this communication and coordination should be undertaken by the affected communities via processes distinct from this stewardship transition process." The Number Community is willing to talk to the other communities about what coordination mechanisms, existing or new ones, that will be necessary for this. 2) Any of the elements managed by the RIRs and covered by the Number Community Proposal, including the "in-addr.arpa" and "ip6.arpa" should be managed and reviewed according to the Number Community proposal. The Number Community has its own review processes for this. As described in I.D of the Number Community proposal, "in-addr.arpa" and "ip6.arpa" are delegated to the IANA by the Internet Architecture Board (IAB) and “sub-delegations within this hierarchy are undertaken in accordance with the IANA’s address allocation practices” (RFC 3172). The Internet Corporation for Assigned Names and Numbers (ICANN), in its role as the IANA Numbering Services Operator, administers these zones as “agreed technical work items” per the IETF-IANA MoU. This work is outside the scope of the National Telecommunications and Information Administration (NTIA) contract. We should not make changes to this existing arrangements, which are not a part of the NTIA contract. Further, Provision of reverse DNS services in the IN-ADDR.ARPA and IP6.ARPA domains may also require interaction with the .ARPA registry. Collectively these registries are referred to as the IANA Number Registries.According to our understanding the CSC and IFR processes has its scope focused on the names related function. Therefore, we strongly believe that "in-addr.arpa" and "ip6.arpa" are to be excluded from the CSC and IFR processes. As such, the Number Community does not see a need to participate in the CSC and IFR. Izumi and Nurani on behalf of the CRISP Team On 2015/09/25 7:04, Alissa Cooper wrote:
Dear CRISP team,
Based on comments received during the ICG’s public comment period, the ICG has a number of questions for the CRISP team. We are requesting responses to these questions ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the CRISP team requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.
The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal in response to the answers that the CRISP team may provide. While the ICG reserves the right to seek further public comment if we receive extensive amendments from any of the operational communities, we do not expect to do so at this time.
1) The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the numbers operational community provide such a commitment? I f so, t he ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.
2) Please could you say whether or not the numbers community intends to participate in the CSC and IFR processes proposed by the names community. If the numbers community will participate, then will the participation be limited to the .ARPA domain name, or will it be broader? If the .ARPA domain name is excluded from the CSC and IFR processes, would that affect whether or not the numbers community participates?
Please let us know if any of our questions require clarification.
Thanks,
Alissa Cooper on behalf of the ICG
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
Ah! So the DNS would be included and the reverse DNS would be excluded. Great! The CRISP position is not an issue from my point of view: I have repeatedly warned against Separation, Separability or Dis-aggregation of the IANA functions. Verb Sap. CW On 08 Oct 2015, at 08:37, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Dear all,
Some time ago, I was saying that responding to the ICG question related to .ARPA in the manner we did may not be appropriate. Below is a draft response of CRISP that clearly prefers that it's related .ARPA strings be immune of CSC/IFR processes.
Regards
Sent from my Asus Zenfone2 Kindly excuse brevity and typos.
---------- Forwarded message ---------- From: "Izumi Okutani" <izumi@nic.ad.jp> Date: 7 Oct 2015 23:02 Subject: Re: [NRO-IANAXFER] Questions from the ICG To: <ianaxfer@nro.net> Cc:
Dear Alissa,
Thank you and the ICG for your efforts in reviewing the public comments and the continued work on the combined proposal, as well as on the overall process.
Please see below the draft response from the CRISP Team. We will have the CRISP Team call at UTC13:00 8th Oct to make a final confirmation, and will get back to you by UTC23:59 9th Oct, in case we indentify any changes needed. The responses are based on the Number Community proposal and the CRISP Team submission during public comment of the CWG-Stewardship proposal, therefore we wouldn't expect fundamental changes but there may be some additional points.
1) Yes we are willing to commit to coordinate with the other communities, as we have expressed in the Number Community Proposal:
III.A. "the Internet Number Community wishes to emphasize the importance of communication and coordination between these communities to ensure the stability of the IANA services. Such communication and coordination would be especially vital should the three communities reach different decisions regarding the identity of the IANA Functions Operator after the transition. Efforts to facilitate this communication and coordination should be undertaken by the affected communities via processes distinct from this stewardship transition process."
The Number Community is willing to talk to the other communities about what coordination mechanisms, existing or new ones, that will be necessary for this.
2) Any of the elements managed by the RIRs and covered by the Number Community Proposal, including the "in-addr.arpa" and "ip6.arpa" should be managed and reviewed according to the Number Community proposal. The Number Community has its own review processes for this.
As described in I.D of the Number Community proposal, "in-addr.arpa" and "ip6.arpa" are delegated to the IANA by the Internet Architecture Board (IAB) and “sub-delegations within this hierarchy are undertaken in accordance with the IANA’s address allocation practices” (RFC 3172). The Internet Corporation for Assigned Names and Numbers (ICANN), in its role as the IANA Numbering Services Operator, administers these zones as “agreed technical work items” per the IETF-IANA MoU. This work is outside the scope of the National Telecommunications and Information Administration (NTIA) contract. We should not make changes to this existing arrangements, which are not a part of the NTIA contract. Further, Provision of reverse DNS services in the IN-ADDR.ARPA and IP6.ARPA domains may also require interaction with the .ARPA registry. Collectively these registries are referred to as the IANA Number Registries.According to our understanding the CSC and IFR processes has its scope focused on the names related function. Therefore, we strongly believe that "in-addr.arpa" and "ip6.arpa" are to be excluded from the CSC and IFR processes. As such, the Number Community does not see a need to participate in the CSC and IFR.
Izumi and Nurani on behalf of the CRISP Team
On 2015/09/25 7:04, Alissa Cooper wrote:
Dear CRISP team,
Based on comments received during the ICG’s public comment period, the ICG has a number of questions for the CRISP team. We are requesting responses to these questions ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the CRISP team requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.
The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal in response to the answers that the CRISP team may provide. While the ICG reserves the right to seek further public comment if we receive extensive amendments from any of the operational communities, we do not expect to do so at this time.
1) The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the numbers operational community provide such a commitment? I f so, t he ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.
2) Please could you say whether or not the numbers community intends to participate in the CSC and IFR processes proposed by the names community. If the numbers community will participate, then will the participation be limited to the .ARPA domain name, or will it be broader? If the .ARPA domain name is excluded from the CSC and IFR processes, would that affect whether or not the numbers community participates?
Please let us know if any of our questions require clarification.
Thanks,
Alissa Cooper on behalf of the ICG
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Seun, Since we say only that participation is an option, it does not seem to me that there is any contradiction between the draft response from the numbers community and our response. We could possibly have improved on our response, but as constructed, it seems to be satisfactory. Do you agree? Thanks. Jonathan From: Seun Ojedeji [mailto:seun.ojedeji@gmail.com] Sent: 08 October 2015 07:37 To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] CWG response on .ARPA (Fwd: Re: [NRO-IANAXFER] Questions from the ICG) Dear all, Some time ago, I was saying that responding to the ICG question related to .ARPA in the manner we did may not be appropriate. Below is a draft response of CRISP that clearly prefers that it's related .ARPA strings be immune of CSC/IFR processes. Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. ---------- Forwarded message ---------- From: "Izumi Okutani" <izumi@nic.ad.jp <mailto:izumi@nic.ad.jp> > Date: 7 Oct 2015 23:02 Subject: Re: [NRO-IANAXFER] Questions from the ICG To: <ianaxfer@nro.net <mailto:ianaxfer@nro.net> > Cc: Dear Alissa, Thank you and the ICG for your efforts in reviewing the public comments and the continued work on the combined proposal, as well as on the overall process. Please see below the draft response from the CRISP Team. We will have the CRISP Team call at UTC13:00 8th Oct to make a final confirmation, and will get back to you by UTC23:59 9th Oct, in case we indentify any changes needed. The responses are based on the Number Community proposal and the CRISP Team submission during public comment of the CWG-Stewardship proposal, therefore we wouldn't expect fundamental changes but there may be some additional points. 1) Yes we are willing to commit to coordinate with the other communities, as we have expressed in the Number Community Proposal: III.A. "the Internet Number Community wishes to emphasize the importance of communication and coordination between these communities to ensure the stability of the IANA services. Such communication and coordination would be especially vital should the three communities reach different decisions regarding the identity of the IANA Functions Operator after the transition. Efforts to facilitate this communication and coordination should be undertaken by the affected communities via processes distinct from this stewardship transition process." The Number Community is willing to talk to the other communities about what coordination mechanisms, existing or new ones, that will be necessary for this. 2) Any of the elements managed by the RIRs and covered by the Number Community Proposal, including the "in-addr.arpa" and "ip6.arpa" should be managed and reviewed according to the Number Community proposal. The Number Community has its own review processes for this. As described in I.D of the Number Community proposal, "in-addr.arpa" and "ip6.arpa" are delegated to the IANA by the Internet Architecture Board (IAB) and “sub-delegations within this hierarchy are undertaken in accordance with the IANA’s address allocation practices” (RFC 3172). The Internet Corporation for Assigned Names and Numbers (ICANN), in its role as the IANA Numbering Services Operator, administers these zones as “agreed technical work items” per the IETF-IANA MoU. This work is outside the scope of the National Telecommunications and Information Administration (NTIA) contract. We should not make changes to this existing arrangements, which are not a part of the NTIA contract. Further, Provision of reverse DNS services in the IN-ADDR.ARPA and IP6.ARPA domains may also require interaction with the .ARPA registry. Collectively these registries are referred to as the IANA Number Registries.According to our understanding the CSC and IFR processes has its scope focused on the names related function. Therefore, we strongly believe that "in-addr.arpa" and "ip6.arpa" are to be excluded from the CSC and IFR processes. As such, the Number Community does not see a need to participate in the CSC and IFR. Izumi and Nurani on behalf of the CRISP Team On 2015/09/25 7:04, Alissa Cooper wrote:
Dear CRISP team,
Based on comments received during the ICG’s public comment period, the ICG has a number of questions for the CRISP team. We are requesting responses to these questions ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the CRISP team requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.
The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal in response to the answers that the CRISP team may provide. While the ICG reserves the right to seek further public comment if we receive extensive amendments from any of the operational communities, we do not expect to do so at this time.
1) The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the numbers operational community provide such a commitment? I f so, t he ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.
2) Please could you say whether or not the numbers community intends to participate in the CSC and IFR processes proposed by the names community. If the numbers community will participate, then will the participation be limited to the .ARPA domain name, or will it be broader? If the .ARPA domain name is excluded from the CSC and IFR processes, would that affect whether or not the numbers community participates?
Please let us know if any of our questions require clarification.
Thanks,
Alissa Cooper on behalf of the ICG
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net <mailto:ianaxfer@nro.net> https://www.nro.net/mailman/listinfo/ianaxfer
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net <mailto:ianaxfer@nro.net> https://www.nro.net/mailman/listinfo/ianaxfer
Hello Jonathan, Our response did not specifically indicate that .ARPA is excluded from CSC/IFR processes. It instead indicated that an optional seat will be available should IAB or any representative of .ARPA is interested in participating in CSC/IFR processes. It therefore seem we did not address the specific function but the composition of the proposed teams. Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 8 Oct 2015 08:40, "Jonathan Robinson" <jrobinson@afilias.info> wrote:
Seun,
Since we say only that participation is an option, it does not seem to me that there is any contradiction between the draft response from the numbers community and our response.
We could possibly have improved on our response, but as constructed, it seems to be satisfactory. Do you agree?
Thanks.
Jonathan
*From:* Seun Ojedeji [mailto:seun.ojedeji@gmail.com] *Sent:* 08 October 2015 07:37 *To:* cwg-stewardship@icann.org *Subject:* [CWG-Stewardship] CWG response on .ARPA (Fwd: Re: [NRO-IANAXFER] Questions from the ICG)
Dear all,
Some time ago, I was saying that responding to the ICG question related to .ARPA in the manner we did may not be appropriate. Below is a draft response of CRISP that clearly prefers that it's related .ARPA strings be immune of CSC/IFR processes.
Regards
Sent from my Asus Zenfone2 Kindly excuse brevity and typos.
---------- Forwarded message ---------- From: "Izumi Okutani" <izumi@nic.ad.jp> Date: 7 Oct 2015 23:02 Subject: Re: [NRO-IANAXFER] Questions from the ICG To: <ianaxfer@nro.net> Cc:
Dear Alissa,
Thank you and the ICG for your efforts in reviewing the public comments and the continued work on the combined proposal, as well as on the overall process.
Please see below the draft response from the CRISP Team. We will have the CRISP Team call at UTC13:00 8th Oct to make a final confirmation, and will get back to you by UTC23:59 9th Oct, in case we indentify any changes needed. The responses are based on the Number Community proposal and the CRISP Team submission during public comment of the CWG-Stewardship proposal, therefore we wouldn't expect fundamental changes but there may be some additional points.
1) Yes we are willing to commit to coordinate with the other communities, as we have expressed in the Number Community Proposal:
III.A. "the Internet Number Community wishes to emphasize the importance of communication and coordination between these communities to ensure the stability of the IANA services. Such communication and coordination would be especially vital should the three communities reach different decisions regarding the identity of the IANA Functions Operator after the transition. Efforts to facilitate this communication and coordination should be undertaken by the affected communities via processes distinct from this stewardship transition process."
The Number Community is willing to talk to the other communities about what coordination mechanisms, existing or new ones, that will be necessary for this.
2) Any of the elements managed by the RIRs and covered by the Number Community Proposal, including the "in-addr.arpa" and "ip6.arpa" should be managed and reviewed according to the Number Community proposal. The Number Community has its own review processes for this.
As described in I.D of the Number Community proposal, "in-addr.arpa" and "ip6.arpa" are delegated to the IANA by the Internet Architecture Board (IAB) and “sub-delegations within this hierarchy are undertaken in accordance with the IANA’s address allocation practices” (RFC 3172). The Internet Corporation for Assigned Names and Numbers (ICANN), in its role as the IANA Numbering Services Operator, administers these zones as “agreed technical work items” per the IETF-IANA MoU. This work is outside the scope of the National Telecommunications and Information Administration (NTIA) contract. We should not make changes to this existing arrangements, which are not a part of the NTIA contract. Further, Provision of reverse DNS services in the IN-ADDR.ARPA and IP6.ARPA domains may also require interaction with the .ARPA registry. Collectively these registries are referred to as the IANA Number Registries.According to our understanding the CSC and IFR processes has its scope focused on the names related function. Therefore, we strongly believe that "in-addr.arpa" and "ip6.arpa" are to be excluded from the CSC and IFR processes. As such, the Number Community does not see a need to participate in the CSC and IFR.
Izumi and Nurani on behalf of the CRISP Team
On 2015/09/25 7:04, Alissa Cooper wrote:
Dear CRISP team,
Based on comments received during the ICG’s public comment period, the ICG has a number of questions for the CRISP team. We are requesting responses to these questions ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the CRISP team requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.
The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal in response to the answers that the CRISP team may provide. While the ICG reserves the right to seek further public comment if we receive extensive amendments from any of the operational communities, we do not expect to do so at this time.
1) The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the numbers operational community provide such a commitment? I f so, t he ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.
2) Please could you say whether or not the numbers community intends to participate in the CSC and IFR processes proposed by the names community. If the numbers community will participate, then will the participation be limited to the .ARPA domain name, or will it be broader? If the .ARPA domain name is excluded from the CSC and IFR processes, would that affect whether or not the numbers community participates?
Please let us know if any of our questions require clarification.
Thanks,
Alissa Cooper on behalf of the ICG
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
On Thu, Oct 08, 2015 at 07:37:27AM +0100, Seun Ojedeji wrote:
Some time ago, I was saying that responding to the ICG question related to .ARPA in the manner we did may not be appropriate. Below is a draft response of CRISP that clearly prefers that it's related .ARPA strings be immune of CSC/IFR processes.
The CRISP proposal is not about ARPA but about IN-ADDR.ARPA and IP6.ARPA. Those are different zones. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Well I did not say its all about .ARPA as i correlated my statement with "related strings" but does your statement removes the fact that IP6.ARPA or URN.ARPA are second level string (domains) of .ARPA (which is the first level domain). What happens to IP6.ARPA if .ARPA is no longer in existence due to whatever decision that is made by CSC/IFR? Regards On Thu, Oct 8, 2015 at 2:20 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Thu, Oct 08, 2015 at 07:37:27AM +0100, Seun Ojedeji wrote:
Some time ago, I was saying that responding to the ICG question related to .ARPA in the manner we did may not be appropriate. Below is a draft response of CRISP that clearly prefers that it's related .ARPA strings be immune of CSC/IFR processes.
The CRISP proposal is not about ARPA but about IN-ADDR.ARPA and IP6.ARPA. Those are different zones.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* Bringing another down does not take you up - think about your action!
On Thu, Oct 08, 2015 at 02:39:18PM +0100, Seun Ojedeji wrote:
Well I did not say its all about .ARPA as i correlated my statement with "related strings" but does your statement removes the fact that IP6.ARPA or URN.ARPA are second level string (domains) of .ARPA (which is the first level domain). What happens to IP6.ARPA if .ARPA is no longer in existence due to whatever decision that is made by CSC/IFR?
I agree that would be very bad. The IAB has already pointed out, however, that the IFR language needs to be adjusted so that it is does not apply to IETF decisions. Anyway, if the CSC or IFR actually made a decision that removed arpa, I think we'd be in a crisis of such epic proportions that the problems resulting from the missing reverse mappings would look tiny. (After all, reverse mappings are badly maintained on the Internet generally anyway -- the RIRs do a good job but lots of other people blow it.) I think if we get to that stage, the very idea of "co-ordination" would have broken down so badly that the entire oversight model would be in question. Indeed, it's hard to imagine an arpa change of the sort you are talking about that wouldn't result in a speedy global abandoning of the IANA root in favour of some other, sanely-operated root. DNSSEC makes that painful, but not impossible. People keep approaching these issues as though there is real power to enforce illegitimate decisions. But the Internet doesn't work that way, and if we do things that are sufficiently bone-headed we will find ourselves irrelevant in short order. In my opinion, that's a good thing. It's that technical feature -- permissionless innovation at the edge -- that's got us this far. A -- Andrew Sullivan ajs@anvilwalrusden.com
On Thu, Oct 8, 2015 at 2:59 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Thu, Oct 08, 2015 at 02:39:18PM +0100, Seun Ojedeji wrote:
Well I did not say its all about .ARPA as i correlated my statement with "related strings" but does your statement removes the fact that IP6.ARPA or URN.ARPA are second level string (domains) of .ARPA (which is the first level domain). What happens to IP6.ARPA if .ARPA is no longer in existence due to whatever decision that is made by CSC/IFR?
I agree that would be very bad. The IAB has already pointed out, however, that the IFR language needs to be adjusted so that it is does not apply to IETF decisions.
Well we are discussing the CWG's response to ICG on .ARPA and it will be good for CWG to acknowledge such statement from IAB in her response. Otherwise it will just be an act of going round in circles.
Anyway, if the CSC or IFR actually made a decision that removed arpa, I think we'd be in a crisis of such epic proportions that the problems resulting from the missing reverse mappings would look tiny. (After all, reverse mappings are badly maintained on the Internet generally anyway -- the RIRs do a good job but lots of other people blow it.) I think if we get to that stage, the very idea of "co-ordination" would have broken down so badly that the entire oversight model would be in question. Indeed, it's hard to imagine an arpa change of the sort you are talking about that wouldn't result in a speedy global abandoning of the IANA root in favour of some other, sanely-operated root. DNSSEC makes that painful, but not impossible.
I agree that a lot will have gone bad bad and really there may be little or no major impact for a while if such happens. Nevertheless we have set ourselves on the part of "wild" and unbelievable scenarios (which is one of the basis for the CWG proposal) in this process so its on that basis that I am responding as well.
People keep approaching these issues as though there is real power to enforce illegitimate decisions. But the Internet doesn't work that way, and if we do things that are sufficiently bone-headed we will find ourselves irrelevant in short order. In my opinion, that's a good thing. It's that technical feature -- permissionless innovation at the edge -- that's got us this far.
I agree but the approach we have gone through in this transition doesn't seem as such. You may one to peep in the ccwg to have a hint (CWG was perhaps bearable) Regards
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* Bringing another down does not take you up - think about your action!
Is there any reason to believe, even in a wild scenario, that the CSC or an IFR has the remit, authority or jurisdiction to remove (or even recommend the removal) of a TLD (.ARPA or otherwise) from the root? On Thu, Oct 8, 2015 at 10:14 AM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On Thu, Oct 8, 2015 at 2:59 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Thu, Oct 08, 2015 at 02:39:18PM +0100, Seun Ojedeji wrote:
Well I did not say its all about .ARPA as i correlated my statement with "related strings" but does your statement removes the fact that IP6.ARPA or URN.ARPA are second level string (domains) of .ARPA (which is the first level domain). What happens to IP6.ARPA if .ARPA is no longer in existence due to whatever decision that is made by CSC/IFR?
I agree that would be very bad. The IAB has already pointed out, however, that the IFR language needs to be adjusted so that it is does not apply to IETF decisions.
Well we are discussing the CWG's response to ICG on .ARPA and it will be good for CWG to acknowledge such statement from IAB in her response. Otherwise it will just be an act of going round in circles.
Anyway, if the CSC or IFR actually made a decision that removed arpa, I think we'd be in a crisis of such epic proportions that the problems resulting from the missing reverse mappings would look tiny. (After all, reverse mappings are badly maintained on the Internet generally anyway -- the RIRs do a good job but lots of other people blow it.) I think if we get to that stage, the very idea of "co-ordination" would have broken down so badly that the entire oversight model would be in question. Indeed, it's hard to imagine an arpa change of the sort you are talking about that wouldn't result in a speedy global abandoning of the IANA root in favour of some other, sanely-operated root. DNSSEC makes that painful, but not impossible.
I agree that a lot will have gone bad bad and really there may be little or no major impact for a while if such happens. Nevertheless we have set ourselves on the part of "wild" and unbelievable scenarios (which is one of the basis for the CWG proposal) in this process so its on that basis that I am responding as well.
People keep approaching these issues as though there is real power to enforce illegitimate decisions. But the Internet doesn't work that way, and if we do things that are sufficiently bone-headed we will find ourselves irrelevant in short order. In my opinion, that's a good thing. It's that technical feature -- permissionless innovation at the edge -- that's got us this far.
I agree but the approach we have gone through in this transition doesn't seem as such. You may one to peep in the ccwg to have a hint (CWG was perhaps bearable)
Regards
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------
*Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
Bringing another down does not take you up - think about your action!
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hello Greg, Out of existence is actually a phrase that first came to me, not that it's ever possible(but again how many of our scenarios are ever realistically possible). The main point however is whether CSC is a position to review performance of IANA as it concerns .ARPA and whether IFR decisions (including recommendations for separation and/or any other recommended action to be carried out on names TLDs) includes .ARPA. The current CWG response does not address that explicitly. The thing is we are entering into a future where clarity of role is important and ambiguity needs to be avoided as much as possible. Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 8 Oct 2015 17:12, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
Is there any reason to believe, even in a wild scenario, that the CSC or an IFR has the remit, authority or jurisdiction to remove (or even recommend the removal) of a TLD (.ARPA or otherwise) from the root?
On Thu, Oct 8, 2015 at 10:14 AM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On Thu, Oct 8, 2015 at 2:59 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Thu, Oct 08, 2015 at 02:39:18PM +0100, Seun Ojedeji wrote:
Well I did not say its all about .ARPA as i correlated my statement with "related strings" but does your statement removes the fact that IP6.ARPA or URN.ARPA are second level string (domains) of .ARPA (which is the first level domain). What happens to IP6.ARPA if .ARPA is no longer in existence due to whatever decision that is made by CSC/IFR?
I agree that would be very bad. The IAB has already pointed out, however, that the IFR language needs to be adjusted so that it is does not apply to IETF decisions.
Well we are discussing the CWG's response to ICG on .ARPA and it will be good for CWG to acknowledge such statement from IAB in her response. Otherwise it will just be an act of going round in circles.
Anyway, if the CSC or IFR actually made a decision that removed arpa, I think we'd be in a crisis of such epic proportions that the problems resulting from the missing reverse mappings would look tiny. (After all, reverse mappings are badly maintained on the Internet generally anyway -- the RIRs do a good job but lots of other people blow it.) I think if we get to that stage, the very idea of "co-ordination" would have broken down so badly that the entire oversight model would be in question. Indeed, it's hard to imagine an arpa change of the sort you are talking about that wouldn't result in a speedy global abandoning of the IANA root in favour of some other, sanely-operated root. DNSSEC makes that painful, but not impossible.
I agree that a lot will have gone bad bad and really there may be little or no major impact for a while if such happens. Nevertheless we have set ourselves on the part of "wild" and unbelievable scenarios (which is one of the basis for the CWG proposal) in this process so its on that basis that I am responding as well.
People keep approaching these issues as though there is real power to enforce illegitimate decisions. But the Internet doesn't work that way, and if we do things that are sufficiently bone-headed we will find ourselves irrelevant in short order. In my opinion, that's a good thing. It's that technical feature -- permissionless innovation at the edge -- that's got us this far.
I agree but the approach we have gone through in this transition doesn't seem as such. You may one to peep in the ccwg to have a hint (CWG was perhaps bearable)
Regards
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------
*Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
Bringing another down does not take you up - think about your action!
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Is there any reason to believe, even in a wild scenario, that the CSC or an IFR has the remit, authority or jurisdiction to remove (or even recommend the removal) of a TLD (.ARPA or otherwise) from the root? I assume that Greg at least understands the proposal well enough to pose this as a rhetorical question. But in case anyone else is confused, the answer is short and simple: No. The existence of a TLD in the root is a policy decision my within the ICANN or iETF processes, CSC and IFR review only the performance of the IANA in implementing those decisions. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology
For the record, I am not confused, don't know of others. You may want to read through the thread before concluding as such. Especially read my response to Greg where I actually referred to CSC/IFRT recommendations as a result of their performance review. Your response would most likely be rhetoric as well considering that you seem to be implying that IETF no longer carry out performance review of their IANA related function. On that same note you may also fault the CRISP opinion on how their second level domains in .ARPA. should be handled. Anyway this does not affect me and its just some inconsistency/ambiguity in the CWG response[1] that I thought I should flag especially based on recent CRISP response to ICG. You are ICG member, all the best in putting things together. Regards 1. You may want to look at the CWG response to the question below: Scope 13) The .ARPA domain is used for special purposes. Please could you clarify whether or not the .ARPA domain will be included in the CSC and IFR processes. Sent from my Asus Zenfone2 Kindly excuse brevity and typos. Is there any reason to believe, even in a wild scenario, that the CSC or an IFR has the remit, authority or jurisdiction to remove (or even recommend the removal) of a TLD (.ARPA or otherwise) from the root? I assume that Greg at least understands the proposal well enough to pose this as a rhetorical question. But in case anyone else is confused, the answer is short and simple: No. The existence of a TLD in the root is a policy decision my within the ICANN or iETF processes, CSC and IFR review only the performance of the IANA in implementing those decisions. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology
Milton, My point exactly. Greg On Thu, Oct 8, 2015 at 5:59 PM, Mueller, Milton L < milton.mueller@pubpolicy.gatech.edu> wrote:
Is there any reason to believe, even in a wild scenario, that the CSC or an IFR has the remit, authority or jurisdiction to remove (or even recommend the removal) of a TLD (.ARPA or otherwise) from the root?
I assume that Greg at least understands the proposal well enough to pose this as a rhetorical question.
But in case anyone else is confused, the answer is short and simple: No.
The existence of a TLD in the root is a policy decision my within the ICANN or iETF processes, CSC and IFR review only the performance of the IANA in implementing those decisions.
Dr. Milton L. Mueller
Professor, School of Public Policy
Georgia Institute of Technology
participants (6)
-
Andrew Sullivan -
Christopher Wilkinson -
Greg Shatan -
Jonathan Robinson -
Mueller, Milton L -
Seun Ojedeji