comments on draft-giralt-schac-ns-00

[Alfred Hönes <[e-mail]>]

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

After discussing the more significant issues I found in (A), the
editorials in section (B) below are presented in textual order.

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.


(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 ?

The applicable security considerations will -- to a large extent --
depend on the kind and (e.g. legal, material) value of the resources.

One particularly critical and ambiguous phrase is
"a common way for expressing personal data" (in Section 1, 1st para)


(A.2)  Section 2, 'Syntactic structure' clause -- ABNF issue

The draft defines the syntax as:

            SCHAC-NSS    =   1*(subStChar) 0*(":" 1*(subStChar))

|           subStChar       =   trans / "%" HEXDIG HEXDIG

            trans                =   ALPHA / DIGIT / other / reserved

            other                =   "(" / ")" / "+" / "," / "-" / "." /
                                         "=" / "@" / ";" / "$" /
                                         "_" / "!" / "*" / "'"

|           reserved           =   "%" / "/" / "?" / "#"

[ BTW: columnar alignment of the rules would enhance the readability! ]

For <subStChar>,  "%" plays the role of a Reserved character used to
introduce the hex encoded 'escape sequences'.
But <trans> allows <reserved>, which in turn admits "%".

Thus way, the syntax is highly ambiguous.

I would reasonably expect the requirement to escape a literal "%"
as "%25", and to not admit "%" in <reserved>.

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     =   "/" / "?" / "#"




(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!

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.

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.


(A.4)  Section 6 -- IANA Considerations

The draft says:

|  This document makes no request of IANA.
|
|  Note to RFC Editor: this section may be removed on publication as an
|  RFC.

Ooops!
Isn't the main purpose of the draft to register an URN NID ??

For simplicity, please think of IANA as a clerical robot reading the
instructions in the IANA Considerations section and performing the
tasks described there during the RFC publication process.
The purpose of this section is to give IANA a starting point for
operating on a draft, whithout having to read the whoel document
(cf. RFC 5226).

Please replace the above nonsensical text by a concise clause,
for instance:

|  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.



(B)  editorial linear walk-through

(B.1)  Section 1.1, 1st para

In the last line, please correct:

|  input from all participants national person schemas.[3]
---                           v                        v   v
|  input from all participants' national person schemas [3].


(B.2)  Section 2, 'Identifier assignment' clause, 1st para

The text talks about "entities of global international or
European interest" and "multi-country organizations".

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.

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).

(B.3)  Section 2, 'Identifier assignment' clause, 2nd para

s/such as any string can convey/such that any string can convey/   ?
       ^^                            ^^^^


(B.4)  Section 2, 'Identifier assignment' clause, 4th para

o    s/this namespaces/these namespaces/
         ^^              ^^^

o    s/the requestors [...] domain/the requestor's [...] domain/


(B.5)  Section 2, 'Validation mechanism' clause

Please insert the missing trailing full-stop (period) at the end
of the first sentence, in front of "Presence".


(B.6)  Section 4, last para

s/This values/These values/
    ^^          ^^^

(B.7)  Section 7

The updated IANA Considerations -- see (A.4) above -- make normative
use of RFC 3406.  Therefore, ref. entry [11] in Section 7.2 needs
to be promoted to Normative and hence moved into Section 7.1.


Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+