Page History
...
Info |
---|
PROPOSED AGENDA
BACKGROUND DOCUMENTS |
Info | ||
---|---|---|
| ||
Mp3 GNSO transcripts are located on the GNSO Calendar |
Tip | ||
---|---|---|
| ||
Dial outs: Cheryl Langdon-Orr Apologies: Katrin Ohlmer, Malgorzata Pek, Heath Dixon |
Note |
---|
Notes/ Action Items Actions:
2.10.2.e.1.2: ACTION ITEM: Go back to the RrSG to ask them to clarify their answer. Notes:
1. Updates to Statements of Interest (SOIs): No updates provided. 2. Discussion of Public Comments a. 2.10.2: Registrar Non-Discrimination / Registry/Registrar Standardization:
2.10.2.c.1: Lines 4-6: Brand Registry Group, Neustar, RySG -- Agreement Line 6, RySG -- New Idea: In addition, the RySG believes that Registries should have the flexibility to register their own domains under certain circumstances, including where no registrar agrees to sell a Registry's TLDs. 2.10.2.e.1: LIne 8, Fairwinds -- See below for relevant sub-comments. Line 9, RySG: Explains the diversity of views within the RySG on the issue of vertical integration:. 2.10.2.e.1.1: Lines 11-14, Brands, Fairwinds, RySG, Google -- Agreement Line 15, RrSG -- Divergence (although notes instance where it could be permissable): Generally no. Only where the Brand is the registrant, tech, admin and billing contact for all domains and the domain is not allocated for the use by any third party, should it be possible for the registry to not use a registrar. 2.10.2.e.1.2: Line 17, Mark Monitor -- Agreement
Line 18, RrSG -- Agreement Concerns New Idea: Generally yes. But, assuming the Brand Owner is the registrant, admin, technical and billing contact and the sole beneficial user for all domains in its TLD, this question would not apply. Registry Operators of exempt TLDs must not allow third-parties to manage DNS at any level or otherwise control resolution for the SLDs. Essentially, ICANN must be aggressive in its management of TLDs to ensure that TLDs cannot be run as "effectively closed" TLDs. ACTION ITEM: Go back to the RrSG to ask for clarification. Line 19, Brand Registry Group -- New Idea (or rather, replying to question). Line 20, Fairwinds -- New Idea (or rather, replying to question) Line 21, RySG -- New Idea (or rather, replying to question): No, the RySG does not believe additional obligations are required for the reasons stated in 2.10.2.e.1.1
2.10.2.e.1.3: Line 23, Brand Registry Group: The BRG will be happy to contribute further if required. Line 24, RySG -- See above. 2.10.2.e.2: Line 26, RrSG: No -- New Idea (or rather, replying to question). 2.10.2.e.3: Line 28, RrSG -- Concerns New Idea: Exemptions should be requested, evaluated, and allowed/denied through community processes and with complete transparency. The RrSG Charter has been recently revised and this issue may no longer apply. Other Comments: Line 30, Christopher Wilkinson -- I would enter a general reservation about the neutrality of Registrars among Registries under current conditions of 'vertical integration'. I shall return to this issue when we have had an opportunity to see the CCT-RT final report. Line 31, Christopher Wilkinson -- Concerns: It would appear that the degree of concentration that has taken place in the DNS market was facilitated by the flawed decision in 2010 to rplace a policy favoring vertical integration between new independent Registries with a policy favoring cross-ownership between Registrars and Registries. The economic consequences of that decision may be qite far-reaching and should be reconsidered by ICANN. -- Think we can take his comment as is.
From the chat: Kristine Dorrain: On CW's comment: is he mixing up Ry/Rr integration with RY/RSP integration? I'm confused. Justine Chew: Do we want to ask Christopher Wilkinson to clarify his comment? b. 2.11.1: Registry System Testing: 2.11.1.c.1: Line 4, Brand Registry Group -- Agreement.
2.11.1.c.2: Line 6, Brand Registry Group -- Agreement. Line 7, ICANN Org -- Agreement New Idea: ICANN org agrees that removal of self-certifications in favor of operational testing where applicable would improve the effectiveness of Registry System Testing. However, it should be noted that some self-certifications, such as those related to load testing, should be retained as operational testing of load would be disruptive and not favorable, and it is important to do load testing to ensure that the infrastructure can handle expected traffic.. Line 8, RySG -- Agreement New Idea: removal of the self-certification assessment applies to established RO's who exhibit the exact same business rules across TLD. There is opposition within RySG for that viewpoing, believing it to be anti-competitive. At least one RySG member found little value of self-certification assessments in avoiding failures and supports this recommendation. From the chat: Steve Chan: @Michael, that is a common theme for the RySG comments. There is no single RySG position on nearly every response in this section.
2.11.1.c.3: Line 10, Brand Registry Group -- Agreement. Line 11, RySG -- Agreement Concerns (request for clarification) New Idea (suggestion for clarity, depending on the outcome of deliberations). Line 12, ICANN Org -- Concerns (or rather, clarification of the ICANN org comment). Line 13, SSAC -- Divergence: In general, it is preferable to discover major failures before delegation instead of after the TLD is in operation. Past performance is not a guarantee of future performance. 2.11.1.c.4: Lines 15 and 16, Brand Registry Group and Neustar -- Agreement. Line 17, RySG -- Agreement Concerns: The RySG believes that this should have been a reasonable thing to do during prior round. However, in practice, the PDT execution related to IDNs actually exceeded the stated boundaries in that the Testing Team both expanded the scope and inserted "judgement" into the expected results. Line 18, ICANN Org -- Concerns (or rather, clarification of the ICANN org comment). 2.11.1.c.5: Line 20, RySG -- Concerns New Idea.
2.11.1.c.6: Lines 22 and 23, Brand Registry Group and Neustar -- Agreement. Line 24, RySG -- New Idea (focuses on when the approved infrastructure is selected). 2.11.1.e.1: Line 26, RySG -- Agreement (e.g., supports adopting ICANN org proposal) Divergence (e.g., opposes adopting ICANN org proposals) |