# Andy Newton, ART AD, comments for draft-ietf-spice-glue-id-06
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spice-glue-id-06.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Many thanks to Patrik Fältström for the ARTART review and the discussion following on the art@ and various lists.

## Comments

I have read the mailing list discussions on new identifier systems restricting allowed characters to non-ASCII.
It is my opinion that the working group has established the reasons for this decision, and that changes to
this document to accommodate non-ASCII characters would require significant changes to this specification for
unknown benefit.

Thanks to Peter Yee for their secdir review.

Section 1.2, External Authority, Authority Identifier, External Identifier:  These definitions point to each other, making it very circular.  External Authority...'using the Authority Identifier'.  Authority Identifier.... 'Identifier for the External Authority'. External Identifier...'assigned by an External Authority'.  Given that the registry is for 'Authority Identifiers', perhaps make that the top of the pile?  And then reference Authority Identifier for both External Authority and External Authority Identifier?  

Section 5:  Add something here to explain why one needs Global Identifiers in this space.  What is the vulnerability created by having identifiers that are not globally unique?

Section 7:  Is there a requirement that the requester actually own or have control over the requested identifier?  Can anyone just email in to get 'look-a-like' identifiers?

Section 7, para 3, last sentence:  'Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing or architecturally dubious).'  What if the identifier is abusive in a different language or culture? Is declaring it to be frivolous a catch-all? Is there history for instructions to DEs that would give more precise guidance?

As this is far from area of expertise, I am ballot NoOjection but having two URI ("urn:lei:INR2EJN1ERAN0W5ZP974" and "urn:glue:lei:INR2EJN1ERAN0W5ZP974") to represent (cannot write identify!) the same 'thing' looks like looking for trouble.

I also fear that the designated experts will not have an easy task to review and approve.

Section 3, paragraph 3
>    authority-identifier = (ALPHA/DIGIT) *49( ALPHA / DIGIT / "+" / "-" /
>    "." )

What happens if an enterprise wants to use a sub-namespace within the namespace identified for them?
Can they do that?

Section 5, paragraph 1
>    There are no additional security considerations beyond those already
>    inherent to using URNs.  Security considerations for URNs can be
>    found in [RFC2141].

   The document defers to [RFC2141] for URN security considerations. 
   RFC 2141 has been obsoleted by RFC 8141 (URN Syntax). RFC 8141 
   includes a Security Considerations section. Consider referencing 
   RFC 8141 instead of (or in addition to) RFC 2141.

Section 7.1.1, paragraph 0
>    Authority Identifier:  identifier for the External Authority
>       responsible for assigning the External Identifier used in GLUE
>       URIs.  This identifier is not case sensitive and any letters MUST
>       be expressed in lowercase characters.  It MUST consist of a
>       sequence of characters with a mazimum length of 50, beginning with
>       a letter and followed by any combination of letters, digits, plus
>       ("+"), period ("."), or hyphen ("-").

In Section 3 and the ABNF, an Authority Identifier may start with a letter or digit. 
The document history for -05 says “The first character of the Authority Identifier may be a digit.” 
However, Section 7.1.1 (Registration Template) still says the identifier must be 
“beginning with a letter”. That contradicts Section 3 and the -05 change.
Recommendation: In 7.1.1, change “beginning with a letter” to “beginning with a letter or digit” 
so it matches Section 3 and the ABNF.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[draft-zundel-spice-glue-id-02].

Possible DOWNREF from this Standards Track doc to [LEI]. If so, the IESG needs
to approve it.

Possible DOWNREF from this Standards Track doc to [ISO6523]. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to [DUNS]. If so, the IESG needs
to approve it.

Possible DOWNREF from this Standards Track doc to [GLN]. If so, the IESG needs
to approve it.

Possible DOWNREF from this Standards Track doc to [PEN]. If so, the IESG needs
to approve it.

Possible DOWNREF from this Standards Track doc to [LEI-IANA]. If so, the IESG
needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [RFC2141] to RFC2141, which was obsoleted by RFC8141 (this may be on
purpose).

These URLs in the document did not return content:

 * https://www.ietf.org/mailman/listinfo/spice/
 * https://www.iana.org/assignments/glue-identifiers/
 * https://www.gs1.org/standards/id-
 * https://www.dnb.com/duns.html

Section 4, paragraph 2
> y Identifier. Implementations and relying parties MUST NOT assume equivalenc
>                                   ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 4, paragraph 2
> ed as URNs in at least two ways. Therefore there is an equivalence between a
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 4, paragraph 3
>  equivalence between a GLUE URI with an "lei" Authority Identifier and an LE
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 7, paragraph 9
> E URIs. This identifier is not case sensitive and any letters MUST be express
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

# IESG review of draft-ietf-spice-glue-id-06

CC @MikeBishop

## Comments

### Section 4.1.1, paragraph 2

This is the identifier for Microsoft. Is there an LEI reserved for
examples, as recommended by the IESG Statement on Assignable Codepoints for
Examples in IETF Specifications?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC2141]` to `RFC2141`, which was obsoleted by `RFC8141` (this may
be on purpose).

### Grammar/style

#### Section 4, paragraph 2
```
ed as URNs in at least two ways. Therefore there is an equivalence between a
                                 ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 7, paragraph 9
```
E URIs. This identifier is not case sensitive and any letters MUST be express
                               ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

Hi Brent, Pamela, and Mike, 

Thank you for the work put into this specification. The document is clear and well-written.

Please find below few comments. I have some very minor edits that I will send to the authors in a PR.

# Neutral Naming 

CURRENT:
   A business entity can be identified by multiple GLUE URIs, but each
   GLUE URI can only refer to a single business entity.

Unless I missed something subtle, this is applicable to any type of administrative entities. For example, I don’t consider a university as a business entity.

I see that you are using “organizational entity” in some parts of the text, which is much more better.

Can we please consider using a more neutral term through the document? 

# Unicity Scope

CURRENT:
  The combination of the namespacing and the authority MUST result in
  a unique Authority Identifier.

Can we please be explicit about the unicity scope here? 

# ABNF

The narrative text is clear about the structure the identifiers. 

I think that I would move RFC5234 to be listed as normative as that is needed to check that the various ABNF rules match the narrative text.

Cheers,
Med

# Internet AD comments for draft-ietf-spice-glue-id-05
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4.1.1

* Consider fully expanding LEI on first use (Legal Entity Identifier?).

  (I don't it listed in https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list)

### S7

* Seems like there might some guidance around making sure the authority
  registry value requestor is in fact associated with the authority, and
  that the published external authority specification is as well.