Re: [ccnso-members] RE: [ccTLDcommunity] [Cctldworld] IAP DT Template - ccTLD list only
Respectfully, RFC 1591 uses the exact words (stepping in, substantial misbehavior, etc.). That¹s really not an issue of interpretation as it is the text itself. The FOIWG interpreted those phrases very narrowly, to involve behavior that threatened the stability and security of the DNS and profound failures to provide basic services. The narrow interpretation was specifically used to reflect the group¹s agreement with the principle that disagreements regarding ccTLDs should generally be resolved locally. Sovereignty issues are very important, but where an operator¹s behavior creates a serious threat to the stability of the DNS, the IANA operator must have some ability to respond. Prior to the formation of the FOIWG, the ccNSO and GAC had a ³Delegation and Redelegation Working Group² that looked at the IANA operator¹s handling of ccTLD revocation and delegation issues over time and that identified incidents when the IANA Operator did far more than offer valuable advice. Concern about those findings, as well as concerns about the subtle approach changes introduced by the IANA operator over time (for example, changes in language that over time created a lot of ambiguity and latitude) was really the starting point for the FOI. The FOI is not new policy, it is a very careful attempt to provide a principled basis for the IANA operator¹s application of existing policy. It is the product of years of careful, thoughtful work and is intended to help us all get on the same page and stay there unless and until new policy is developed through the appropriate processes. As such, I do not think it ³burdens² the IANA transition. Rather, it is a critical input to the transition, designed - among other things - to protect the rights of governments to act in accordance with the rule of law to resolve local disputes about the operation of the ccTLD corresponding to its country or territory. Additionally, I agree with Keith, Chris etc. that it is out of scope for the CWG to design any mechanism for challenging revocations, delegations, and transfers. Becky J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz On 3/5/15, 3:57 AM, "ALI Hadji Mmadi" <alihadji@comorestelecom.km> wrote:
Dear all, I came late in the debate and sometimes we say that the retarding is wrong. Could have your indulgent! I jump on this email to +1 with Demi when He suggets IANA Operator.
In addition, as part of the interpretation, I do not agree with 4.2 said 4.2. The FOIWG interprets RFC1591 to permit the IANA Operator to revoke a ccTLD delegation in appropriate circumstances where the manager has substantially misbehaved (section 3.4 of RFC1591).
I thing the national sovereignty must be preserved and IANA comply with the decision given by the competent national authority that we can define.
Do not forget that we do not have the same concepts and management rules. Some Countries dont have legal framework in their managements ccTLDs, yet we must walk together. It is the strength of this community. Regards. Hadji -----Message d'origine----- De : cctldcommunity-bounces@cctld-managers.org [mailto:cctldcommunity-bounces@cctld-managers.org] De la part de Patricio Poblete Envoyé : mardi 3 mars 2015 17:30 À : Demi Getschko Cc : ccTLD Community List; ccNSO Council; ccNSO Members; cctldworld@icann.org Objet : Re: [ccTLDcommunity] [Cctldworld] IAP DT Template - ccTLD list only
Demi,
Yours is a very interesting point of view, coming from a former ICANN Board member.
I understand that with regards to "stepping in" and "revocation", you propose that wherever it says "the IANA" in RFC1591 or "the IANA Operator" in the FOI report, we should read "ICANN" instead.
I wonder what my colleagues, especially the members of the FOI WG, think about this.
Patricio
On Tue, Mar 3, 2015 at 11:23 AM, Demi Getschko <demi@nic.br> wrote:
Patricio, my understanding (vis-a-vis with what GAC and ICANN was doing since 2000) is that when IANA "steps in" is just to provide valuable information for a fair proceedings... This information and positioning helps and informs the process to come to a conclusion... I really think it would be important for the easy transition not to overload IANA with police or deciding topics - keeping IANA just as an operational body... But may be I'm missing something best demi PS. RFC1591 is older than ICANN... With ICANN's inception we assumed in some way that the final decision about redelegations, originally in IANA, transited to ICANN, keeping IANA "funcion" just operational and informative...
On 03/02/2015 11:09 PM, Patricio Poblete wrote:
I agree that the task of designing an appropriate appeals mechanism for ccTLD managers that have been subject to a revocation should be handled through a PDP in an appropriate time frame.
However, I cannot agree with Demi that IANA has no role in redelegations (except implementing what has been decided elsewhere). For instance, RFC1591 says
The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially mis-behaved would the IANA step in.
So, the IANA has the power to "step in" in cases of "substantial mis-behavior". The FOI report says
4.2. The FOIWG interprets RFC1591 to permit the IANA Operator to revoke a ccTLD delegation in appropriate circumstances where the manager has substantially misbehaved (section 3.4 of RFC1591).
4.3. The FOIWG interprets ³misbehaviour² (section 3.4 of RFC1591) in this context to refer to conduct involving the failure of a manager to (i) carry out the necessary responsibilities of that role, or (ii) carry out those responsibilities in the manner required by RFC1591.
4.4. The FOIWG interprets substantial misbehaviour (section 3.4 of RFC1591) to involve misbehaviour (as defined above) that is either egregious or persistent and may include performing the necessary responsibilities of a manager in a manner that imposes serious harm or has a substantial adverse impact on the Internet community by posing a threat to the stability and security of the DNS.
4.5. The FOIWG interprets RFC1591 to limit the IANA Operator¹s authority to step-in to situations where substantial misbehaviour by the ccTLD manager (a) poses a risk to the security and stability of the DNS or (b) involves the manager's failure, after notice and a reasonable opportunity to cure, to perform the objective requirements (i.e., to be on the Internet, maintain IP and email connectivity, identify a technical contact and to identify an in-country administrative contact).
4.6. The FOIWG interprets RFC1591 to mean that the IANA Operator should not step in regarding issues of equity, justice, honesty, or except insofar as it compromises the stability and security of the DNS competency, and that such issues would be better resolved locally.
This is the FOI WG's interpretation of current policy. Are we going to change it as part of the stewardship transition process?
Patricio
On Mon, Mar 2, 2015 at 8:01 PM, Demi Getschko <demi@nic.br <mailto: demi@nic.br>> wrote:
I think that the issue of delegations and redelegations is not related to IANA context. IANA just have to implement, in a right way, what it is decided in other police arenas... Better not to mix this issue with IANA oversight transition, in my view... Best demi
On 03/02/2015 07:34 PM, Keith Davidson wrote:
Hi all,
I would have thought the appropriate CWG action for this would be to recognise that RFC1591 recommends an appeals mechanism for delegations and redelegations, as highlighted by the FOI final report, and then call on the ccNSO and the ccTLD community to address this issue within a reasonable timeframe, recognising there is insufficient time to build an appropriate mechanism prior to the IANA transition.
To me, it is a waste of time and energy, as well as being out of scope, for the CWG to be addressing this issue. As ICANN contracted parties, the gTLD community is far removed from the issues surrounding RFC1591 and delegations and redelegations of ccTLDs. There is no commonality, and ccTLD delegations and redelegations is the sole property of the ccTLD community to resolve.
Cheers
Keith
On 3/03/2015 10:41 a.m., Chris Disspain wrote:
Jay, All,
Just for clarity, I am not saying that there shouldn't be a mechanism. Indeed as a member of the FoI WG I agreed with the report recommending that there should.
My point is simply that work on such a mechanism is for the ccTLDs to undertake and not within the remit of the CWG and not something that must be done prior to transition since such a mechanism, would need to be created within a PDP. Please tell me if that is wrong headed of me.
Cheers,
Chris Disspain | Chief Executive Officer .au Domain Administration Ltd T: +61 3 8341 4111 <tel:%2B61%203%208341%204111> | F: +61 3 8341 4112 <tel:%2B61%203%208341%204112> E: ceo@auda.org.au <mailto:ceo@auda.org.au> | W: www.auda.org.au <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.auda.org.au&d=A wIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDk Mr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa2Ba1fkCcg0&s=GD6LuHGfIh7OF9gx8XA XbvzNxsS-kYyMcfpdyv_nCkE&e= > auDA Australia¹s Domain Name Administrator
Important Notice - This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. Please consider the environment before printing this email.
On 3 Mar 2015, at 08:01 , Jay Daley <jay@nzrs.net.nz <mailto:jay@nzrs.net.nz>> wrote:
Eberhard
It would be very helpful if we could separate out the two different points you are making as they are getting confused.
Your first point, that only the ccTLD manager should have the ability to object/appeal/etc is well understood and there is no consensus for anything different from that. Let's keep that separate from the second point.
Your second point that you don't want an independent appeal mechanism but would rather have a mechanism to fix the board is surprising. Weren't you a member and active participant in the FOI WG that produced the report that Patricio quoted?
4.8. Note: The FOIWG believes it is consistent with RFC1591 (section 3.4) and the duty to act fairly to recognize the manager has the right to appeal a notice of revocation by the IANA Operator to an independent body.
Have you now changed your mind?
best Jay
On 3/03/2015, at 9:54 am, Dr Eberhard W Lisse <el@lisse.na <mailto:el@lisse.na>> wrote:
Jay,
you might want to read up on what a tort is.
But, the point I have been trying to make in Singapore is still pertinent, if something is wrong with the Board, we need to fix the Board not add more layers which later will need fixing.
We need to go much deeper than that, we need to figure out what a ccTLD is and what the relation of a ccTLD manager to the IANA Function Manager is.
Acknowledging that an appeal mechanism of any sort has input on a ccTLD would be contrary to my position.
With regards to what is wrong with the Board, interesting what the Malaysians say now about the .ML repatriation from in-country to abroad...
There can be 252 ccTLD Managers screaming, raving and ranting, about the 253rd but it doesn't matter, only what the 253rd (incumbent) manager says is relevant for that ccTLD.
el -- Sent from Dr Lisse's iPad mini
-- Jay Daley Chief Executive NZRS Ltd desk: +64 4 931 6977 <tel:%2B64%204%20931%206977> mobile: +64 21 678840 <tel:%2B64%2021%20678840> linkedin: www.linkedin.com/in/jaydaley
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in _jaydaley&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDm rxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa2Ba1fkCcg0&s=HUDXEj rr1g-glP5AKfrZOT4u1h8nrH-n05c45VBQS9I&e= >
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org <mailto:ccTLDcommunity@cctld-managers.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dma nagers.org_mailman_listinfo_&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOi fzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa 2Ba1fkCcg0&s=TwPJzF0Hidj6-VV9RcqOdUGlw7DoZTUc38ff7_fUg4Q&e= cctldcommunity
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org
<mailto:ccTLDcommunity-unsubscribe@lists.cctld-managers.org>
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org <mailto:ccTLDcommunity@cctld-managers.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dma nagers.org_mailman_listinfo_&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOi fzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa 2Ba1fkCcg0&s=TwPJzF0Hidj6-VV9RcqOdUGlw7DoZTUc38ff7_fUg4Q&e= cctldcommunity
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org <mailto:ccTLDcommunity-unsubscribe@lists.cctld-managers.org>
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org <mailto:ccTLDcommunity@cctld-managers.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dma nagers.org_mailman_listinfo_cctldcommunity&d=AwIDaQ&c=MOptNlVtIETeDALC_l ULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4Kr Yk6IVkIdYaIJLa2Ba1fkCcg0&s=90JxhSunInmXgtuTn8tOJ9_BFLZeEb_hZjf4uHGjJkU&e =
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org <mailto:ccTLDcommunity-unsubscribe@lists.cctld-managers.org>
_______________________________________________ Cctldworld mailing list Cctldworld@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_cctldworld&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_G Rlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa2Ba1fkC cg0&s=QTyWvz10YKxEje_7cHP-wyrFzT_C94u5MM3nG_E8SPI&e=
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dmana gers.org_mailman_listinfo_cctldcommunity&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw &r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVk IdYaIJLa2Ba1fkCcg0&s=90JxhSunInmXgtuTn8tOJ9_BFLZeEb_hZjf4uHGjJkU&e=
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org
May be I expressed myself poorly, may be I was misunderstood or may be I'm just wrong, but IMHO we are dealing with just the oversight transition on IANA... If this includes the discussion in how an eventual redelegation's decisions will be dealt in the new IANA' transition scope, I'm afraid we will not see this transition from NTIA's oversight in our life span... best demi On 03/05/2015 12:22 PM, Burr, Becky wrote:
Respectfully, RFC 1591 uses the exact words (stepping in, substantial misbehavior, etc.). That¹s really not an issue of interpretation as it is the text itself. The FOIWG interpreted those phrases very narrowly, to involve behavior that threatened the stability and security of the DNS and profound failures to provide basic services. The narrow interpretation was specifically used to reflect the group¹s agreement with the principle that disagreements regarding ccTLDs should generally be resolved locally. Sovereignty issues are very important, but where an operator¹s behavior creates a serious threat to the stability of the DNS, the IANA operator must have some ability to respond.
Prior to the formation of the FOIWG, the ccNSO and GAC had a ³Delegation and Redelegation Working Group² that looked at the IANA operator¹s handling of ccTLD revocation and delegation issues over time and that identified incidents when the IANA Operator did far more than offer valuable advice. Concern about those findings, as well as concerns about the subtle approach changes introduced by the IANA operator over time (for example, changes in language that over time created a lot of ambiguity and latitude) was really the starting point for the FOI.
The FOI is not new policy, it is a very careful attempt to provide a principled basis for the IANA operator¹s application of existing policy. It is the product of years of careful, thoughtful work and is intended to help us all get on the same page and stay there unless and until new policy is developed through the appropriate processes. As such, I do not think it ³burdens² the IANA transition. Rather, it is a critical input to the transition, designed - among other things - to protect the rights of governments to act in accordance with the rule of law to resolve local disputes about the operation of the ccTLD corresponding to its country or territory.
Additionally, I agree with Keith, Chris etc. that it is out of scope for the CWG to design any mechanism for challenging revocations, delegations, and transfers.
Becky
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz
On 3/5/15, 3:57 AM, "ALI Hadji Mmadi" <alihadji@comorestelecom.km> wrote:
Dear all, I came late in the debate and sometimes we say that the retarding is wrong. Could have your indulgent! I jump on this email to +1 with Demi when He suggets IANA Operator.
In addition, as part of the interpretation, I do not agree with 4.2 said 4.2. The FOIWG interprets RFC1591 to permit the IANA Operator to revoke a ccTLD delegation in appropriate circumstances where the manager has substantially misbehaved (section 3.4 of RFC1591).
I thing the national sovereignty must be preserved and IANA comply with the decision given by the competent national authority that we can define.
Do not forget that we do not have the same concepts and management rules. Some Countries dont have legal framework in their managements ccTLDs, yet we must walk together. It is the strength of this community. Regards. Hadji -----Message d'origine----- De : cctldcommunity-bounces@cctld-managers.org [mailto:cctldcommunity-bounces@cctld-managers.org] De la part de Patricio Poblete Envoyé : mardi 3 mars 2015 17:30 À : Demi Getschko Cc : ccTLD Community List; ccNSO Council; ccNSO Members; cctldworld@icann.org Objet : Re: [ccTLDcommunity] [Cctldworld] IAP DT Template - ccTLD list only
Demi,
Yours is a very interesting point of view, coming from a former ICANN Board member.
I understand that with regards to "stepping in" and "revocation", you propose that wherever it says "the IANA" in RFC1591 or "the IANA Operator" in the FOI report, we should read "ICANN" instead.
I wonder what my colleagues, especially the members of the FOI WG, think about this.
Patricio
On Tue, Mar 3, 2015 at 11:23 AM, Demi Getschko <demi@nic.br> wrote:
Patricio, my understanding (vis-a-vis with what GAC and ICANN was doing since 2000) is that when IANA "steps in" is just to provide valuable information for a fair proceedings... This information and positioning helps and informs the process to come to a conclusion... I really think it would be important for the easy transition not to overload IANA with police or deciding topics - keeping IANA just as an operational body... But may be I'm missing something best demi PS. RFC1591 is older than ICANN... With ICANN's inception we assumed in some way that the final decision about redelegations, originally in IANA, transited to ICANN, keeping IANA "funcion" just operational and informative...
On 03/02/2015 11:09 PM, Patricio Poblete wrote:
I agree that the task of designing an appropriate appeals mechanism for ccTLD managers that have been subject to a revocation should be handled through a PDP in an appropriate time frame.
However, I cannot agree with Demi that IANA has no role in redelegations (except implementing what has been decided elsewhere). For instance, RFC1591 says
The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially mis-behaved would the IANA step in.
So, the IANA has the power to "step in" in cases of "substantial mis-behavior". The FOI report says
4.2. The FOIWG interprets RFC1591 to permit the IANA Operator to revoke a ccTLD delegation in appropriate circumstances where the manager has substantially misbehaved (section 3.4 of RFC1591).
4.3. The FOIWG interprets ³misbehaviour² (section 3.4 of RFC1591) in this context to refer to conduct involving the failure of a manager to (i) carry out the necessary responsibilities of that role, or (ii) carry out those responsibilities in the manner required by RFC1591.
4.4. The FOIWG interprets substantial misbehaviour (section 3.4 of RFC1591) to involve misbehaviour (as defined above) that is either egregious or persistent and may include performing the necessary responsibilities of a manager in a manner that imposes serious harm or has a substantial adverse impact on the Internet community by posing a threat to the stability and security of the DNS.
4.5. The FOIWG interprets RFC1591 to limit the IANA Operator¹s authority to step-in to situations where substantial misbehaviour by the ccTLD manager (a) poses a risk to the security and stability of the DNS or (b) involves the manager's failure, after notice and a reasonable opportunity to cure, to perform the objective requirements (i.e., to be on the Internet, maintain IP and email connectivity, identify a technical contact and to identify an in-country administrative contact).
4.6. The FOIWG interprets RFC1591 to mean that the IANA Operator should not step in regarding issues of equity, justice, honesty, or except insofar as it compromises the stability and security of the DNS competency, and that such issues would be better resolved locally.
This is the FOI WG's interpretation of current policy. Are we going to change it as part of the stewardship transition process?
Patricio
On Mon, Mar 2, 2015 at 8:01 PM, Demi Getschko <demi@nic.br <mailto: demi@nic.br>> wrote:
I think that the issue of delegations and redelegations is not related to IANA context. IANA just have to implement, in a right way, what it is decided in other police arenas... Better not to mix this issue with IANA oversight transition, in my view... Best demi
On 03/02/2015 07:34 PM, Keith Davidson wrote:
Hi all,
I would have thought the appropriate CWG action for this would be to recognise that RFC1591 recommends an appeals mechanism for delegations and redelegations, as highlighted by the FOI final report, and then call on the ccNSO and the ccTLD community to address this issue within a reasonable timeframe, recognising there is insufficient time to build an appropriate mechanism prior to the IANA transition.
To me, it is a waste of time and energy, as well as being out of scope, for the CWG to be addressing this issue. As ICANN contracted parties, the gTLD community is far removed from the issues surrounding RFC1591 and delegations and redelegations of ccTLDs. There is no commonality, and ccTLD delegations and redelegations is the sole property of the ccTLD community to resolve.
Cheers
Keith
On 3/03/2015 10:41 a.m., Chris Disspain wrote:
Jay, All,
Just for clarity, I am not saying that there shouldn't be a mechanism. Indeed as a member of the FoI WG I agreed with the report recommending that there should.
My point is simply that work on such a mechanism is for the ccTLDs to undertake and not within the remit of the CWG and not something that must be done prior to transition since such a mechanism, would need to be created within a PDP. Please tell me if that is wrong headed of me.
Cheers,
Chris Disspain | Chief Executive Officer .au Domain Administration Ltd T: +61 3 8341 4111 <tel:%2B61%203%208341%204111> | F: +61 3 8341 4112 <tel:%2B61%203%208341%204112> E: ceo@auda.org.au <mailto:ceo@auda.org.au> | W: www.auda.org.au <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.auda.org.au&d=A wIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDk Mr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa2Ba1fkCcg0&s=GD6LuHGfIh7OF9gx8XA XbvzNxsS-kYyMcfpdyv_nCkE&e= > auDA Australia¹s Domain Name Administrator
Important Notice - This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. Please consider the environment before printing this email.
On 3 Mar 2015, at 08:01 , Jay Daley <jay@nzrs.net.nz <mailto:jay@nzrs.net.nz>> wrote:
Eberhard
It would be very helpful if we could separate out the two different points you are making as they are getting confused.
Your first point, that only the ccTLD manager should have the ability to object/appeal/etc is well understood and there is no consensus for anything different from that. Let's keep that separate from the second point.
Your second point that you don't want an independent appeal mechanism but would rather have a mechanism to fix the board is surprising. Weren't you a member and active participant in the FOI WG that produced the report that Patricio quoted?
4.8. Note: The FOIWG believes it is consistent with RFC1591 (section 3.4) and the duty to act fairly to recognize the manager has the right to appeal a notice of revocation by the IANA Operator to an independent body.
Have you now changed your mind?
best Jay
On 3/03/2015, at 9:54 am, Dr Eberhard W Lisse <el@lisse.na <mailto:el@lisse.na>> wrote:
Jay,
you might want to read up on what a tort is.
But, the point I have been trying to make in Singapore is still pertinent, if something is wrong with the Board, we need to fix the Board not add more layers which later will need fixing.
We need to go much deeper than that, we need to figure out what a ccTLD is and what the relation of a ccTLD manager to the IANA Function Manager is.
Acknowledging that an appeal mechanism of any sort has input on a ccTLD would be contrary to my position.
With regards to what is wrong with the Board, interesting what the Malaysians say now about the .ML repatriation from in-country to abroad...
There can be 252 ccTLD Managers screaming, raving and ranting, about the 253rd but it doesn't matter, only what the 253rd (incumbent) manager says is relevant for that ccTLD.
el -- Sent from Dr Lisse's iPad mini
-- Jay Daley Chief Executive NZRS Ltd desk: +64 4 931 6977 <tel:%2B64%204%20931%206977> mobile: +64 21 678840 <tel:%2B64%2021%20678840> linkedin: www.linkedin.com/in/jaydaley
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in _jaydaley&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDm rxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa2Ba1fkCcg0&s=HUDXEj rr1g-glP5AKfrZOT4u1h8nrH-n05c45VBQS9I&e= >
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org <mailto:ccTLDcommunity@cctld-managers.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dma nagers.org_mailman_listinfo_&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOi fzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa 2Ba1fkCcg0&s=TwPJzF0Hidj6-VV9RcqOdUGlw7DoZTUc38ff7_fUg4Q&e= cctldcommunity
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org
<mailto:ccTLDcommunity-unsubscribe@lists.cctld-managers.org>
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org <mailto:ccTLDcommunity@cctld-managers.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dma nagers.org_mailman_listinfo_&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOi fzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa 2Ba1fkCcg0&s=TwPJzF0Hidj6-VV9RcqOdUGlw7DoZTUc38ff7_fUg4Q&e= cctldcommunity
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org <mailto:ccTLDcommunity-unsubscribe@lists.cctld-managers.org>
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org <mailto:ccTLDcommunity@cctld-managers.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dma nagers.org_mailman_listinfo_cctldcommunity&d=AwIDaQ&c=MOptNlVtIETeDALC_l ULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4Kr Yk6IVkIdYaIJLa2Ba1fkCcg0&s=90JxhSunInmXgtuTn8tOJ9_BFLZeEb_hZjf4uHGjJkU&e =
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org <mailto:ccTLDcommunity-unsubscribe@lists.cctld-managers.org>
_______________________________________________ Cctldworld mailing list Cctldworld@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_cctldworld&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_G Rlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVkIdYaIJLa2Ba1fkC cg0&s=QTyWvz10YKxEje_7cHP-wyrFzT_C94u5MM3nG_E8SPI&e=
_______________________________________________ ccTLDcommunity mailing list ccTLDcommunity@cctld-managers.org https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cctld-2Dmana gers.org_mailman_listinfo_cctldcommunity&d=AwIDaQ&c=MOptNlVtIETeDALC_lULrw &r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=gyJVMvHRKSUPFsKW4KrYk6IVk IdYaIJLa2Ba1fkCcg0&s=90JxhSunInmXgtuTn8tOJ9_BFLZeEb_hZjf4uHGjJkU&e=
To unsubscribe please send a blank email to ccTLDcommunity-unsubscribe@lists.cctld-managers.org
participants (2)
-
Burr, Becky -
Demi Getschko