<chair hat off, also trying to emulate "fresh eyes">

I've done a NITS review of the usecases-requirements documents, my
comments are as follows:

Generally, the draft is well written, and looks ready for publication
request, given that the following small issues are resolved:

- Terminology & Capitalization: I understand the document specifies
additional terminology in Section 1 with a capitalized initial letter
(as many other IETF documents do). However, subsequently those terms are
mostly referenced with lowercased initial letters, which could make
readers assume that those terms do not refer to the terminology
definition.

Suche terms include "registry", "public identifier", "registrant",
"destination group" and many others. This also includes cross-references
within the Terminology section itself.

Additionally, the term "public identity" and "lookup key" are used
throughout the document, but not defined anywhere. Those should be
defined, although i assume that "public identity" is identical to
"public identifier".

- "TN Range" Definition: I don't understand that implications of the
part "whose SED can be looked up", as i don't see the defining effect of
this here. What would probably work is "with identical SED" (?), but it
might very well work to leave that text out. "contiguos set.... of
telephone numbers." works well for me.

- The abbreviation for "local data repositories" (LDR) should be added
after the first instance in the draft (page 5). The legend of Figure 2
would then be redundant.

(The first paragraph on page 6 contains many un-capitalized terminology
terms!)

- The names of some of the boxes in Figure 2 are partly "ALL CAPS". Is
there a particular reason for that?

- Data Relations on page 8: Given that a TN Range object can only be
contained in exactly one Destination Group, can there be several TN
Range objects that overlap? There might be scenarios where several
Registrars "claim" a TN Range, for example in cases where several
transit SSPs provision into a Registry..

- Same for Public Identifiers and DGs.

(UC PROV #3: Note that there's text that actually requires the recent
change about atomic transactions in the protocol document, where
currently both "atomic" and "stop of first error" are allowed [but will
be changed as agreed in Quebec])

- UC SED EXCHANGE  #4 refers to "this protocol" (at the end of the use
case). It is unclear what this refers to, since the document does not
specify a protocol. "out of scope of this use case" might work.

- UC DATA #3: I had to re-read this use case several times before i
understood it (again ;), particularly because the text is quite similar
to UC DATA #2. Is there any way to simplify UC DATA #3?

- Section 3.6.: It is unclear what a "lookup key" is. I understand it's
an instance of a Public Identifier for which information is sought in
some way (being used in a "lookup")? A definition would be good.

- UC LOOKUP #6  contains "public identity". Is that supposed to be a
"public identifier"?

- The acronym "SS7" in UC MISC #1 should be expanded.

- Same for "PBX" in UC MISC #3. "Which is where" sounds funny to me as a
non-native speaker - could a native speaker please re-read that
paragraph?

- Section 4: "must support these requirements" - isn't that supposed to
be a "MUST"?

- REQ-LOOKUP-3 sort of defines "Lookup Key". However, the semantics seem
to be slightly different from the corresponding "lookup" use cases. A
common definition would be beneficial.

- REQ-LOOKUP-4 talks about provisioning of "lookup keys", although my
impression was they were strictly limited to the "lookup side"? I don't
see where "lookup keys" can be "moved to a different Destination
Group"..

-tia

Alex