I generally support this kind of introduction text. Although I think we may need to adjust the language a little. But I'd suggest leaving that until later, since perfecting the introduction is less important than simply having one for context for those in the community that will read this document. One recommendation I'd make that we could introduce straight away is replacing the last paragraph with the following text which regularly appears in ICANN policy introductions (I make no claims of originality):

-The terms "MAY", "MUST", "MUST NOT", "REQUIRED", "SHOULD NOT" and "SHOULD" are used to indicate the requirement level in accordance with RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt

Also please note my apologies for tonight. I will attend next week's meeting if we choose to have it (noting that it is a week before ICANN 57).

Kal Feher

Neustar Inc. / Enterprise Architect
Level 8, 10 Queens Road, Melbourne, Australia VIC 3004

Office +61 3 9866 3710 / kal.feher@neustar.biz / www.neustar.biz

Follow Neustar: Facebook LinkedIn Twitter

The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.

From: <idngwg-bounces@icann.org> on behalf of Mats Dufberg <mats.dufberg@iis.se>
Date: Thursday, 20 October 2016 at 21:20
To: Sarmad Hussain <sarmad.hussain@icann.org>, "idngwg@icann.org" <idngwg@icann.org>
Subject: Re: [Idngwg] Meeting notes from 13 October

This is my contribution for item 1 (Update the Introduction section to include more context for the reader for the document to be more self-explanatory):

>>>

This Guidlines is about the implementation if Internationalized Domains Names (IDN) under Internet domains. IDN is standardized by IETF as an extension to DNS (RFC 5890).

The main target of this document are registries of TLDs that offer or plan to offer registrations of IDN domain names on second level. If the Registry Agreement between ICANN and the Registry Operator for the specific TLD says so, this document is binding for that TLD. For other TLDs this document is the best current practice. This document is also valuable for Registrars offering registration of IDN domain names and domain name owners adding IDN names under its domain.

This document consists of a number of recommendations. If it is stated in the recommendations that a certain choice "must" be taken, then there is there is no option to implementing that recommendation. If it states "should" then the registry must have good reason not to implement it.

<<<

Yours,

Mats

---

Mats Dufberg

DNS Specialist, IIS

Mobile: +46 73 065 3899

https://www.iis.se/en/

From: <idngwg-bounces@icann.org> on behalf of Sarmad Hussain <sarmad.hussain@icann.org>
Date: Thursday 13 October 2016 at 19:50
To: idngwg <idngwg@icann.org>
Subject: [Idngwg] Meeting notes from 13 October

Dear All,

Kindly note that we have moved to a weekly schedule during October 2016.

Please find attached the summary of our meeting on 13 October 2016. Please let me know in case of any changes.

We have the following action items:

S. No.	Action Items	Owner
1	Update the Introduction section to include more context for the reader for the document to be more self-explanatory	MD
2	Draft a new requirement which requires all variants to be allocated to the same registrant, with a “must”	EC
3	Update the terminology list to include the terms identified, and add relevant definitions from existing documents	SH

The attached notes and the recording of the meeting will soon be available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines.

Next meeting will be on 20 October, 11am UTC.

Regards,

Sarmad