RE: [jig] REMINDER / JIG WG - 14 June at 1200 UTC

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

Hi Everyone,

 

Here is a brief proposed agenda for our call today:

 

1. Preparations for JIG session in Singapore (Mon, 20 June 2011 - 17:30 -
18:30 Room: Moor): http://singapore41.icann.org/node/24501

 

2. Liaison / Observer for VIP Study teams

 

3. Consideration of Questions for clarifications on Single Character IDN TLD
implementation (attached for easy reference)

 

4. IETF Requirements Document (attached brief explanation from Avri for easy
reference)

 

Talk to you all soon.

 

Edmon

 

 

 

From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Kristina
Nordstrom
Sent: June 13, 2011 3:37 PM
To: jig@xxxxxxxxx
Subject: [jig] REMINDER / JIG WG - 14 June at 1200 UTC

 

Dear All,

The next JIG Working Group teleconference is scheduled on Tuesday 14th June
2011 at 1200 UTC.

05:00 PDT, 08:00 EDT, 13:00 London, 14:00 CEST, 20:00 Beijing,  22:00 Sydney

For other places see:
http://www.timeanddate.com/worldclock/fixedform.html

Dial-in details are below:

If you require a dial-out, please let me know. I currently have the
following people on the list : 

*       Rafik Dammak 
*       Sarmad Hussain 


____________________________________________________________________________
Participant passcode: JIG

For security reasons, the passcode will be required to join the call.

____________________________________________________________________________
Dial in numbers:                               
Country                             Toll Numbers          Freephone/Toll
Free Number

ARGENTINA                                                   0800-777-0519
AUSTRALIA           ADELAIDE:      61-8-8121-4842           1-800-657-260
AUSTRALIA           BRISBANE:      61-7-3102-0944           1-800-657-260
AUSTRALIA           CANBERRA:      61-2-6100-1944           1-800-657-260
AUSTRALIA           MELBOURNE:     61-3-9010-7713           1-800-657-260
AUSTRALIA           PERTH:         61-8-9467-5223           1-800-657-260
AUSTRALIA           SYDNEY:        61-2-8205-8129           1-800-657-260
AUSTRIA                            43-1-92-81-113           0800-005-259
BELGIUM                            32-2-400-9861            0800-3-8795
BRAZIL                                                      0800-7610651
CHILE                                                       1230-020-2863
CHINA*                             86-400-810-4789          10800-712-1670
                                                            10800-120-1670
COLOMBIA                                                    01800-9-156474
CZECH REPUBLIC                     420-2-25-98-56-64        800-700-177
DENMARK                            45-7014-0284             8088-8324
ESTONIA                                                     800-011-1093
FINLAND             Land Line:     106-33-203               0-800-9-14610
FINLAND             Mobile:        09-106-33-203            0-800-9-14610
FRANCE              LYON:          33-4-26-69-12-85         080-511-1496
FRANCE              MARSEILLE:     33-4-86-06-00-85         080-511-1496
FRANCE              PARIS:         33-1-70-70-60-72         080-511-1496
GERMANY                            49-69-2222-20362         0800-664-4247
GREECE                             30-80-1-100-0687         00800-12-7312
HONG KONG                          852-3001-3863            800-962-856
HUNGARY                                                     06-800-12755
INDIA                                                       000-800-852-1268
INDONESIA                                                   001-803-011-3982
IRELAND                            353-1-246-7646           1800-992-368
ISRAEL                                                      1-80-9216162
ITALY                              39-02-3600-6007          800-986-383
JAPAN               OSAKA:         81-6-7739-4799           0066-33-132439
JAPAN               TOKYO:         81-3-5539-5191           0066-33-132439
LATVIA                                                      8000-3185
LUXEMBOURG                         352-27-000-1364          
MALAYSIA                                                    1-800-81-3065
MEXICO                                                      001-866-376-9696
NETHERLANDS                        31-20-718-8588           0800-023-4378
NEW ZEALAND                        64-9-970-4771            0800-447-722
NORWAY                             47-21-590-062            800-15157
PANAMA
011-001-800-5072065
PERU                                                        0800-53713
PHILIPPINES                        63-2-858-3716            
POLAND                                                      00-800-1212572
PORTUGAL                                                    8008-14052
RUSSIA
8-10-8002-0144011
SINGAPORE                          65-6883-9230             800-120-4663
SLOVAK REPUBLIC                    421-2-322-422-25         
SOUTH AFRICA                                                080-09-80414
SOUTH KOREA                        82-2-6744-1083           00798-14800-7352
SPAIN                              34-91-414-25-33          800-300-053
SWEDEN                             46-8-566-19-348          0200-884-622
SWITZERLAND                        41-44-580-6398           0800-120-032
TAIWAN                             886-2-2795-7379          00801-137-797
THAILAND
001-800-1206-66056
UNITED KINGDOM      BIRMINGHAM:    44-121-210-9025          0808-238-6029
UNITED KINGDOM      GLASGOW:       44-141-202-3225          0808-238-6029
UNITED KINGDOM      LEEDS:         44-113-301-2125          0808-238-6029
UNITED KINGDOM      LONDON:        44-20-7108-6370          0808-238-6029
UNITED KINGDOM      MANCHESTER:    44-161-601-1425          0808-238-6029
URUGUAY                                                     000-413-598-3421
USA                                1-517-345-9004           866-692-5726
VENEZUELA                                                   0800-1-00-3702


*Access to your conference call will be either of the numbers listed,
dependent on the participants' local telecom provider.


Restrictions may exist when accessing freephone/toll free numbers using a
mobile telephone.


Kind regards,
Kristina


______________
ccNSO Secretariat

--- Begin Message ---

• To: "Jian Zhang" <jian@xxxxxxxxx>, "Edmon Chung" <edmon@xxxxxxxxxxxxx>
• Subject: [jig] Questions for clarifications from ICANN staff re JIG Final Report
• From: "Bart Boswinkel" <bart.boswinkel@xxxxxxxxx>
• Date: Fri, 3 Jun 2011 16:32:10 +0800

Dear Jian, and Edmon,
At the request of Lesley Cowley, chair of the ccNSO, I forward you the
questions that initially have been send to the SSAC and later by ICANN staff
to both the GNSO and ccNSO with a request to send them to the JIG to provide
additional clarifications.  

Background
The Board has asked for additional information regarding the JIG report and
the included informal note / questions for clarifications has been send to
the SSAC by Kurt Pritz. In future there may be more questions that arise as
the report is further analysed.

Kind regards,
Bart 

Attachment: Note to SSAC - single-letter IDNS(ver2)[2].doc
Description:

--- End Message ---

--- Begin Message ---

• To: "jig" <jig@xxxxxxxxx>
• Subject: [jig] Some random note on draft-ietf-dnsext-aliasing-requirements-01.txt
• From: "Avri Doria" <avri@xxxxxxx>
• Date: Wed, 18 May 2011 00:34:49 +0800

Hi,

In re-reading the draft for the 16 May meeting I came up with a few
questions and comments which Edmon asked me to send to the list.  I want to
start though by saying I think it is a good draft and the first time i read
it I had no comments, and it offers a lot for us to think about.  I still
think it would be worth having Suzanne walk us through it during one of our
meetings.

I have copied Suzanne on this message and I hope she corrects any
misunderstanding I have, and especially any misstatements I make about the
draft.

1. It impressed me again that, at this point there is no technical solution
to the aliasing problem.  Not CNAME and not DNAME, though our crowd has
bandied those around as solutions.  People in this group and others focused
on the issue may know this already, but most people do not.  A lot of people
I talk to, just figure it has to be possible.

2. The draft talks about there being administrative methods that Registries
have for dealing with the problem: 

"there are also administrative mechanisms available for manipulating
   databases underlying the generation and resolution of DNS names.
   Registry operators have many mechanisms for working around DNS
   protocol in order to get behavior they want for names in DNS zones,
   and management of "aliases" is no exception.  However, it is not
   clear how much of the user and operator requirements for "aliases"
   can be met by mechanisms for provisioning DNS zones, at acceptable
   cost."

Perhaps it is just me, but I do not  understand how they do it.  While I can
figure out how it might be handled at the top level and even in second level
zone files, I have no clue what they do about the 3rd+ level. Is there a
centralized scalable process?  I.e. I do not know why we are saying that the
problem can be solved administratively and am not convinced that we can -
though we have ccTLDs now that are ostensibly doing so.  I think the
document says as much, but I may be reading more into it than is said.

3. The draft provides about a page of case studies (2.3.1), but this is the
shallowest part of the document.  I think the draft would benefit from some
serious case studies, the kind Dennis' group will be working on, before it
is published.  In so far as it has cases, it would probably benefit from JIG
and other group review of those cases.

4.  In talking to the IETF it is also important to remember something that
is mentioned in the draft.  The IETF looks at strings as having no meaning.
Just as it took me years to accept that there was something more to domain
names, from the policy and rights perspective,  than just a happy
coincidence if it was a word or a phrase, the IETF in its technical role
does not recognize the importance  of labels as having semantic importance
as words.  That difference in perspective can be important to establishing
requirements for aliasing and the priority of such work.

5. Some of the possible solutions are mentioned.  It is important to
remember that these have not been standardized and that without a coherent
set of requirements, it is not certain that these meet the requirements for
a  policy view for sameness.  It is also not enough to read this section to
understand what the possible solutions offer. (and that is not a requirement
for this draft.  But for example, I do understand how zone cloning deals
with varaince at all levels, and would each level need to cloned? This
question is not relevant to our discussions, but it is bugging me so I will
have to go research further.)

6. There are complexities in adding aliasing to DNSSEC, even in the
administrative solutions that I do not understand - I just beleive that
there are dragons in those waters.  I am actually not sure that the issue is
completely understood on a general level, but it might just be me.

7. One of the problems that impresses me most was that even if they could
develop a solution, what makes anyone think that it would be deployed widely
or soon enough for it to be useful?  There is a recognition of the
'maturity' of the DNS and the extreme care that much be taken in adding
things with backward compatability.  That plus the incentive to actually
support aliasing at all points in the network including resolvers and
applications is quite a project.

Finally as someone who is both of ICANN and of the IETF (with my roots being
in IETF), I do not think the draft should be published as an Informational
RFC until such time as we have managed to get both communities to understand
the requirements and to understand the same set of  requirements.  I expect
I will be making that point if/when the draft gets to IETF last call.  I
would also suggest that ICANN use its liaison function to make that point.
I will try to get myself to the next IETF meeting (a funding issue) and make
the point there as well, if I can get there.

On the other hand I do not suggest that we take our time in typical ICANN
fashion in understanding our requirements.  I am not convinced that we will
need to wait until the final report from Dennis' group to be able to
establish a good set of case descriptions or requirements.  Ie. I think we
need to work together, IETF and ICANN, in the near term to make sure this
requirements doc comes out right and does so this year.

That is about it for now.  

a.

--- End Message ---