[DTM Escalation] Possible Use cases

[Gomes, Chuck]

Please see my responses below Avri.

Chuck

From: dt6-bounces at icann.org<mailto:dt6-bounces at icann.org> [mailto:dt6-bounces at icann.org] On Behalf Of Avri Doria
Sent: Friday, March 20, 2015 10:24 AM
To: dt6 at icann.org<mailto:dt6 at icann.org>
Subject: [DTM Escalation] Possible Use cases

Hi,

Sometimes I have to give up before the thoughts I need start coming to me.

Some possible cases.  Not sure about them all, but put out a call for suggestions on a couple of lists I am on.  I am still getting email and trying to pick the best offerings to pass on.

- One of the new TLDs, especially one in a 'critical' area, is not keeping up its TLD whois correctly and cannot be reached.  Do they need to go through ICANN compliance or can they go directly to IANA to complain.  And if they do go through complainace, does compliance have access to an escalation procedure.
[Chuck Gomes] Very good question. In the case of gTLDs, their contracts require them to do that so it is definitely a compliance issue.  But it seems to me that it is critical for root zone processes for the TLD operator to be reachable so I think it also would be an IANA issue at least the way I see it.  And I think a case like this would need faster response than compliance could deliver.


- IETF produces a new set of protocol elements  for TLDs and IANA has not implemented it. For example a new twist to DNSSEC, or a even replacement for DNSSEC.    Assume this is a change that registries are not fond of and IANA is not particularly interested in either.  Who do those affected, supposing it is not Registries but user communities, complain to?
[Chuck Gomes] We may need to first ask whether the new protocol elements are part of a standard that registries are required to implement; the answer may be different for ccTLDs than gTLDs.  This also raises another question in my mind: at what point is the IANA required to implement new protocol elements?


This begs the question: are IETF protocol changes mandatory on IANA if they affect the Namining community. Can the decision to implement new protocol elements in the DNS be subject to any ICANN policy process?  Who decides which protocols IANA implements and which options are made mandatory.
[Chuck Gomes] Good questions related to one I asked above.

- A security expert notices a new  threat in the IANA DNS implementation.   Can they notify IANA and escalate the issue?  Or is their only solution to either convince the SSAC or to write very visible articles?
[Chuck Gomes] In my opinion there should be a means of escalating the issue.

Speaking of the SSAC, or RSSAC for that matter,  if they notice that something needs fixing, who do they call?
[Chuck Gomes] The RSSAC or more probably a particular RSSAC operator probably wouldn’t see the problem until the change is made so I think they would contact IANA directly.  I suspect the SSAC would also not see it until after the fact but if they did I think they would need a way to communicate it.  If it is an emergency, they could use the emergency number.

- Minsistry A decides that a redelgation of their sovereign TLD was done without their approval (maybe Ministry B said it was ok.) How if this handled. Is there an escalation procedure?
[Chuck Gomes] I am going to punt on this one because it is a ccTLD issue.  Is this something that DT-B is looking at?  Should we send it to Allan as DT-B lead?

- A national user community objects to a re-delegation saying the RFC 1591 was not adhered to in granting the delegation to NewRegistry who is in bed with Minister A (figuratively, I assume).  Who do they take their case to and how do they escalate it if thy don't get satisfaction?
[Chuck Gomes] Same as previous response.

________________________________
[http://static.avast.com/emails/avast-mail-stamp.png]<http://www.avast.com/>


This email has been checked for viruses by Avast antivirus software.
www.avast.com<http://www.avast.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt6/attachments/20150322/81429291/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2908 bytes
Desc: image001.png
URL: <http://mm.icann.org/pipermail/dt6/attachments/20150322/81429291/image001.png>