Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

هذا المحتوى متوفر فقط باللغة (أو اللغات)

  • English

Name: Werner Staub
Date: 21 Nov 2022
Affiliation: CORE Association
Please provide your feedback:
Additional concern or issue identified in Section 1. (Please describe further.)

If B, C, or D, please elaborate.

Please provide your feedback:
Section 3 does not accurately reflect the intent of the Registration Data Consensus Policy. (Please provide an explanation including Recommendations from the EPDP-TempSpec Phase 1 or Phase 2 Final Report where there are inconsistencies and the suggested change to make this section consistent.)

If B, C, or D, please elaborate.

Point 3.8 under Definitions has a grammatical/semantic error, implying that there could be such a thing as “a threat TO serious bodily injury” or “a threat TO child exploitation”. The clause "...an imminent threat to life, serious bodily injury, critical infrastructure, or child exploitation..." should contain the correct preposition for each enumerated item related to the word "threat". The corrected clause will then read as follows: "...an imminent threat to life, of serious bodily injury, to critical infrastructure or of child exploitation...".

Please provide your feedback:
Section 6 accurately reflects the policy recommendations; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

With respect to 6.5.1. Registrant Organization, the following note should be added: "In the absence of a separate dedicated field available for a unique Public Identifier, as in Section 4.8 of RFC 7483, for the unequivocal identification of the registrant, the registrar MUST allow the registrant to optionally append its public identifier to the Registrant Organization data element. It will then take the form of URI separated by a single space from the name. If a public identifier URI is added, it is regarded as an identity claim made in the registration." [URI name spaces appropriate to the identification of registrants include the Legal Entity Identifiers URN name space starting with 'urn:lei:' and the Global Location Identifiers URN name space starting with 'urn:epc:id:sgln:'. In future, Decentralized Identifiers whose URIs start with "did:" may gain acceptance as appropriate registrant identifiers. See https://www.rfc-editor.org/rfc/rfc7483#section-4.8 for publicId, https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml under LEI and RFC5134 for relevant URN name spaces and https://www.w3.org/TR/did-spec-registries/ for DID methods.]

Please provide your feedback:
Section 7 accurately reflects the policy recommendations; however, the following clarification(s) are suggested. (Please provide the suggested language change.)

If B, C, or D, please elaborate.

With respect 7.4.1. Registrant Organization, the following note should be added: "In the absence of a separate dedicated field available for a unique Public Identifier made available by the registry, as in Section 4.8 of RFC 7483, for the unequivocal identification of the registrant, the registrar MAY append the registrant's public identifier to the Registrant Organization data element. It will then take the form of URI separated by a single space from the name. If a public identifier URI is added, it is regarded as an identity claim made in the registration." [URI name spaces appropriate to the identification of registrants include the Legal Entity Identifiers URN name space starting with 'urn:lei:' and the Global Location Identifiers URN name space starting with 'urn:epc:id:sgln:'. In future, Decentralized Identifiers whose URIs start with "did:" may gain acceptance as appropriate registrant identifiers. See https://www.rfc-editor.org/rfc/rfc7483#section-4.8 for publicId, https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml under LEI and RFC5134 for relevant URN name spaces and https://www.w3.org/TR/did-spec-registries/ for DID methods.]

Summary of Submission

Regarding sections 6 and 7, there has been a lot of progress in governance and community institutions outside of ICANN multistakeholder process. These important achievements should not locked out of ICANN’s policies. Public identifiers are ways to improving the accountability of businesses while protecting the data of natural persons whose names should not be stored in corporate domain registration data. Even in the absence of a dedicated field for supplying a public identifier, the registrants should be allows to append a URI with their public identifier in the Registrant Organization field.

Public identifiers that are appropriate to identify corporate domain holders include among others:

(1) the Legal Entity Identifier (LEI). This is a process administered by https://gleif.org based on ISO 17442. See https://en.wikipedia.org/wiki/Legal_Entity_Identifier

(2) Global Location Number (GLN). This is a process administered by https://sg1.org based on ISO/IEC_6523. See https://en.wikipedia.org/wiki/Global_Location_Number

(3) SWIFT Business Identifier Code (BIC). This is a process administered by https://www.swift.com based  ISO_9362. See https://en.wikipedia.org/wiki/ISO_9362 .

(4) Decentralized Identifiers as described in the July 2022 W3C Recommendation https://www.w3.org/TR/did-core/ .

A minor suggestion for section 3 deals with a key clause that grammatically signifies the opposite if what is the intent; it can be corrected by adding the correct prepositions “to” or “of” for each of the enumerated items referred to by the word “threat”.