Skip to main content

قضايا حماية البيانات / الخصوصية: اختتام اجتماع ICANN63 والخطوات التالية

Gdpr icann63 wrap up 3125x1771 08nov18 en

في ختام ICANN 63، أود أن أغتنم هذه الفرصة لتقديم نظرة عامة حول بعض المناقشات المهمة والملاحظات التي تلقيناها في الاجتماع. كما أود أن أطلعكم على بعض الخطوات التالية لارتباطها بالعمل المستمر قصد الإرشاد والتوضيح لإمكانية التوصل إلى نموذج وصول موحد موجه للأطراف الثالثة ذات المصالح المشروعة لطلب بيانات التسجيل غير العامة وتلقيها. كما نتطلع إلى مشاركة الخطوات التالية بشأن تشكيل مجموعة دراسة فنية لاستكشاف كيفية تفعيل نموذج الوصول المحتمل. ستكون هذه المدخلات أساسية لمواصلة المحادثات مع المفوضية الأوروبية والسلطات الأوروبية لحماية البيانات (DPAs)، حيث نسعى إلى تقليل المخاطر القانونية المرتبطة بتنظيم حماية البيانات العامة للاتحاد الأوروبي (GDPR) للأطراف المتعاقدة مع ICANN.

لكن، وقبل تقديم هذه التحديثات، أريد أن أشكر المجتمع على ملاحظاته ومدخلاته البناءة خلال اجتماع ICANN 63 في برشلونة عبر مراسلات متعددة، والمنتديين العامين والعديد من الجلسات الأخرى. أعرب العديد منكم عن دعمه مع استمرار ICANN في استكشاف إمكانية التوصل إلى نموذج وصول موحد، مع هدف محدد يتمثل في تقليل المخاطر القانونية للأطراف المتعاقدة. وقد استمعنا خصوصا لقبول عام وهدف مشترك يبين أن هناك فائدة لجميع أصحاب المصلحة لتحديد ما إذا كان النموذج ممكنًا أم لا، مع تقليل المخاطر القانونية للأطراف المتعاقدة. تتمثل خطتنا في بناء نموذج محتمل يأخذ بعين الاعتبار ملاحظات المجتمع من أجل مواصلة مناقشاتنا مع DPAs وضمان أن أي نموذج يتوافق مع القانون. سنواصل التعامل مع مجلس حماية البيانات الأوروبي (EDPB) للحصول على التوجيه والوضوح. من المهم أيضًا ملاحظة أن هذا العمل لا يهدف إلى استبدال عملية تطوير سياسة أصحاب المصلحة المتعددين، ولكن لإبلاغه.

مع تقدم المجتمع في مناقشته، فإننا نتقدم أيضًا بفكرة قمت بإثارتها خلال المنتدى العام الأولفي ICANN63. لقد طلبت من رام موهان، بصفته منسق اللجنة الاستشارية للأمن والاستقرار السابق إلى مجلس إدارة ICANN، تنسيق مجموعة دراسة فنية تركز على استكشاف الحلول التقنية لتوفير الوصول إلى بيانات التسجيل غير العامة. سيتم دعم المجموعة من قبل جون كرين، مسؤول الأمن والاستقرار والمرونة في ICANN، وفرانسيسكو أرياس، المدير الأول للخدمات الفنية لأقسام النطاقات العالمية (GDD). ستتم دعوة الممثلين التقنيين من السجلات والمسجلين ذوي الخبرة في RDAP وتقنيات المصادقة / الترخيص للمشاركة. سوف نشارك المزيد من المعلومات حول هذه المجموعة عندما تشكل.

وسيساعد عمل هذه المجموعة على إعلام مناقشاتنا المستمرة مع DPAs الأوروبية، بما في ذلك EDPB. كما نخطط لمواصلة هذا الحوار بهدف تحديد ما إذا كانت أي من الحلول التقنية المقترحة تتماشى مع اللائحة العامة لحماية البيانات.

وأخيرًا، أود الإشارة أنه في 6 نوفمبر، قام مجلس ICANN بإعادة التأكيدعلى المواصفات المؤقتة لبيانات تسجيل gTLD لمدة 90 يومًا أخرى من 21 نوفمبر 2018، بما يتماشى مع إجراءات السياسات المؤقتة كما هو موضح في اتفاقية السجلواتفاقية اعتماد المسجل. ستظل المواصفات المؤقتة سارية إلى أن تنظر اللجنة في إعادة تأكيدها مرة أخرى.

وكالعادة، تسرني دعوتكم إلى مواصلة المشاركة في المحادثة حول هذه القضايا المهمة. لا تترددوا في مشاركة أفكاركم أو أسئلتكم معنا على gdpr@icann.orgولمتابعة أحدث التطورات في صفحة "حماية البيانات / الخصوصية".

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."