Re: comments on draft-giralt-schac-ns-00

Victoriano Giralt <victoriano@uma.es> Wed, 08 April 2009 00:20 UTC

Return-Path: <victoriano@uma.es>
X-Original-To: urn-nid@core3.amsl.com
Delivered-To: urn-nid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01DB3A6E1A for <urn-nid@core3.amsl.com>; Tue, 7 Apr 2009 17:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level:
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, MANGLED_LIST=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3KTwq7il8WW for <urn-nid@core3.amsl.com>; Tue, 7 Apr 2009 17:20:06 -0700 (PDT)
Received: from cartero1.sci.uma.es (cartero1.uma.es [150.214.47.225]) by core3.amsl.com (Postfix) with ESMTP id CE9A03A6DE3 for <urn-nid@ietf.org>; Tue, 7 Apr 2009 17:20:01 -0700 (PDT)
Received: from correo1.uma.es (vesta1.sci.uma.es [150.214.40.75]) by cartero1.sci.uma.es (Postfix) with ESMTP id 627F2101FF; Wed, 8 Apr 2009 02:21:06 +0200 (CEST)
Received: from atila.casa.gssi.es (251.Red-80-38-252.staticIP.rima-tde.net [80.38.252.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by correo1.uma.es (Postfix) with ESMTP id AAABD2244A8; Wed, 8 Apr 2009 02:20:59 +0200 (CEST)
Message-ID: <49DBEDEA.6080607@uma.es>
Date: Wed, 08 Apr 2009 02:20:58 +0200
From: Victoriano Giralt <victoriano@uma.es>
Organization: Universidad de Málaga
User-Agent: Thunderbird 2.0.0.19 (X11/20090107)
MIME-Version: 1.0
To: Alfred Hoenes <ah@tr-sys.de>
Subject: Re: comments on draft-giralt-schac-ns-00
References: <200903312207.AAA21466@TR-Sys.de>
In-Reply-To: <200903312207.AAA21466@TR-Sys.de>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: urn-nid@ietf.org, rodney.mcduff@uq.edu.au
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2009 00:20:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alfred Hoenes wrote:
| Hello,
Hello. Thanks for your time.

| after studying the Internet-Draft authored by you,
|             draft-giralt-schac-ns-00,
| I'd like to submit a few comments.
and comments

| After discussing the more significant issues I found in (A), the
| editorials in section (B) below are presented in textual order.
The editorials in section (B) has been dealt with, except (B.2). I'll try
to answer your comments. I have a version of the draft with the suggested
changes made. Shall I upload it right now or wait till we clear your concerns?

|
| (A)  Major issues
|
| (A.1)  target resources ?
|
| I did not understand from the draft text what kind of resources
| shall be assigned 'schac' URNs.  That needs to be much more explicit.
| Are that the abstract entities like schemas, object classes,
| attributes, or the like,
| or instances of persons, organizations, physical entities ?
Present use for most (if not all) SCHAC URNs are controlled vocabulary
values for attributes that will be granted to entities describing persons.
This is not to say that it will remain that way in the future, as we are
working in expanding SCHAC use for other entities (mostly research and
education related). The main driving principle behind the name space
delegation is to assign parts of the controlled vocabulary to the relevant
authority.

The attributes and object classes will use the modern OID base naming scheme.

| The applicable security considerations will -- to a large extent --
| depend on the kind and (e.g. legal, material) value of the resources.
Our intent is to verify the source of authority of a given URN value.

| One particularly critical and ambiguous phrase is
| "a common way for expressing personal data" (in Section 1, 1st para)
It is really scary seen alone. SCHAC, as other person schemas, is designed
to ease the sharing of information about a given individual between
parties, mostly, but not limited to, educational and research institutions.
The main aims of this sharing are: to provide resources to individuals and
to allow said individuals to move, virtually and physically, between such
institutions.

| (A.2)  Section 2, 'Syntactic structure' clause -- ABNF issue
This was due to "cutNpaste" syndrome.
| [ BTW: columnar alignment of the rules would enhance the readability! ]
Fully agreed.

| Thus, I suggest to use the following revised ABNF:
|
|             SCHAC-NSS    =   1*(subStChar) 0*(":" 1*(subStChar))
|
| |           subStChar    =   trans / "%" HEXDIG HEXDIG
|
| |           trans        =   ALPHA / DIGIT / other / reserved
|
| |           other        =   "(" / ")" / "+" / "," / "-" / "." / "="
| |                          / "@" / ";" / "$" / "_" / "!" / "*" / "'"
|
| |           reserved     =   "/" / "?" / "#"
Change accepted and applied.

| (A.3)  Section 2, 'Identifier resolution' clause, last para
|
| The draft says:
|
|       All registries MUST publish their URNs over an HTTPS link that
| |     presents a server certificate by a recognized CA, that does not
| |     produce an alert in the user's browser.
|
| What is a "recognized CA" ?   Don't touch a hornets nest!
Agreed. It is a hornets nest, but that paragraph conveys a lot of work done
in TERENA task forces behind it. The phrase came out by itself. Although
its removal would do no harm to the spirit of the document and might not be
relevant inside an NID definition.

| The requirement in the last phrase is in direct conflict to freedom
| in site/system local security policy.  This registration cannot
| enforce *any* CA certificate to be installed as 'silent' trust
| anchors, or some EE certificates to be accepted, by *all* browsers
| without user intervention; e.g. the secutity aware user might
| want to personally inspect all certificates.
There are two sides to that coin. TERENA has developed a service to provide
very cheap server certificates (actually free for most final users) to
educational and research institutions inside its members constituency. This
service was started after finding that the security pop-ups produced by
server certificates signed by authorities not included in the browsers,
served no other purpose other than annoying the mean user. Whilst security
conscious users, would anyway know how to find out the inspect a server's
certificate and will certainly do it.

|
| A reasonable requirement I could envision instead would be for
| TERENA to publish a list of qualified CA's and deemed as 'recognized'
| for the purpose of 'schac' URN resolution and the "security grade"
| required for the web server EE certificates, or for TERENA to maintain
| a public trust anchor repository that guarantee these properties.
Actually, TERENA already operates trust anchors for other services.

| (A.4)  Section 6 -- IANA Considerations
| Ooops!
| Isn't the main purpose of the draft to register an URN NID ??
Right. Newb error.

| |  In accordance wuth BCP 66 [11], IANA is asked to register the Formal
| |  URN Namespace 'schac' in the Registry of URN Namespaces, using the
| |  registration template presented in Section 2 of this document.
Change accepted and applied.


| (B.2)  Section 2, 'Identifier assignment' clause, 1st para
|
| The text talks about "entities of global international or
| European interest" and "multi-country organizations".
European (EU bound :eu:)
Global international (whole world :int:)
multi-country (EPI spans US, Canada and Australia, then
:educationalpolicy.org:)

|
| What is an "organizational Internet DNS name" for these (last line) ??
|
|   -  any domain name immediately below .INT , or
|   -  any domain name subordinated to   .INT , or
|   -  any domain name immediately below .EU , or
|   -  any domain name subordinated to   .EU , or
|   -  any domain name immediately below .ASIA , or
|   -  any domain name subordinated to   .ASIA , or
|   -  any domain name immediately below .ORG , or
|   -  any domain name subordinated to   .ORG , or
|   -  some selection, or
|   -  any of the above, or
|   -  ??
|
| Note: 9 lines down, "terena.org" appears in an example.
|
| Please be much more precise.
I'd say that all of the above, meaning that the organization's FQDN will be
used instead of a given Internet Country TLD or EU or INT, for those
organizations that comprise more than one country and are assigned
responsibility of a part of the name space.

| BTW: With regard to the expansion of "DNS": Domain Name System,
|      please avoid the troublesome self-replicating term "DNS name"
|      in favor of "Domain Name" or more precisely:
|      "FQDN" (Fully Qualified Domain Name).
Changes applied.

Kind and thankful regards, Victoriano.
- --
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFJ2+3oV6+mDjj1PTgRApJPAJ93f8A3XuWKjTuJyRH5mMFLxXpGEQCcCDKN
kfG5k/6ExKSj3dKZOIy640E=
=3RkD
-----END PGP SIGNATURE-----