[Ecrit] draft-rosen-ecrit-emergency-registries-00

[Randall Gellens <[e-mail]>]

[[[ My apologies -- this is part of an in-depth review I had been doing 
last ear but interrupted and didn't get back to. It covers up to section 
4.5.2.1. Many of these comments apply to the later registries as well. 
]]]

Global question:

In Section 1 and throughout the document there is use of the term "area" 
(e.g., "registry area"). This doesn't seem to be a defined IANA term and 
doesn't seem to be used elsewhere. In my experience, what you mean has 
most often been referred to as registries or top-level registries and 
sub-registries; i.e., creating a new registry into which all existing 
registries related to emergency services are to be moved as 
sub-registries. Please consider using the term "registry" or "top-level 
registry" instead of "area" and state that existing and new registries 
are to be sub-registries within it (e.g., change <<establish a new 
registry area called "Emergency" and to create a set of registries 
within that area>> to <<establish a new registry called "Emergency" and 
to create a set of sub-registries within that registry>>). I did note 
that RFC 8126 (Section 2.1) mentions that the terminology has been 
inconsistent:

    Unfortunately, we have been inconsistent in how we refer to these
    entities.  The group names, as they are referred to here, have been
    variously called "protocol category groups", "groups", "top-level
    registries", or just "registries".  The registries under them have
    been called "registries" or "sub-registries".

Text change requests:

(1) Abstract, first sentence:

I suggest changing "developing standards" to "developing 
specifications".

(2) Same place:

I suggest changing "emergency call standards and other IETF protocols" 
to emergency call and other IETF protocols"

(3) Abstract, second sentence:

I think a comma would be good following "common registries".

(4) The Abstract uses "worldwide" while Section 1 uses "world-wide".

(5) In Section 1, I think a comma would go well after "handling 
emergency calls".

(6) In Section 1, penultimate sentence, I suggest changing "describe 
initial contents" to "provide initial contents".

(7) Section 1.1 seems redundant with Section 3, I suggest deleting 
Section 1.1.

(8) At the end of Section 3, consider adding "and similar programs in 
other regions" or similar wording at the end of the last sentence.

(9) Section 4.1.5, second sentence, I suggest adding "Although" in front 
of "most" (and downcasing "Most").

(10) Same place, I suggest deleting "used" in "used within".

(11) Also in 4.1.5, I recommend enclosing the URN snippets in double 
quotes (change <<in urn:nena will be replaced by identifiers in 
urn:emergency>> with <<in "urn:nena" will be replaced by identifiers in 
"urn:emergency">>).

(12) Please expand "nid" in its first use, which is in this section.

(13) Consider replacing all instanced of "nid" in lower case with "NID" 
in upper case, as RFC 6061 and others do

(14) Also in 4.1.5, I suggest changing "like NENA" to "such as NENA".

(15) Also in 4.1.5, there's a missing "be" in "primarily specified".

(16) Section 4.1.6, the syntax ":<:extended>" looks like it will produce 
double colons. Perhaps delete the colon following the opening angle 
bracket? Or perhaps you want to use ABNF or another syntax notation to 
indicate zero or more occurrences of ":<extended>"?

(17) In 4.1.6, you might consider changing "non-case sensitive" to "case 
insensitive".

(18) In 4.1.7, I think it would read better to change "are defined in 
the document" to "are as specified in the document" (it avoid two 
instances of "define" right next to each other).

(19) Typo in 4.1.8: "consierations" should be "considerations".

(20) Also in 4.1.8, consider changing "Each top level class, in its 
defining document MUST" to be "The document defining a top level class 
MUST".

(21) In 4.1.8, would "Encryption of the communications that contain the 
identifier in classes defined in this document is REQUIRED" be more 
clearly expressed as "When identifiers defined in this document are 
conveyed in protocol exchanges, such exchanges MUST be encrypted" or 
perhaps "When identifiers defined in this document are conveyed in 
protocol exchanges, such exchanges MUST be done using encrypted 
transport"?

(22) Same place, I assume the document is mandating encryption during 
transport and not in storage; otherwise, please state this.

(23) Same place, should the document permit fail-back to unencrypted? 
Either way, this should be stated for clarity.

(24) Same place, since the statement is restricted to "identifiers 
defined in this document", there should be text clarifying any 
requirement for identifiers defined in other documents. Perhaps "The 
document defining a top level class MUST state if transport encryption 
is required when conveying the identifiers it defines."

(25) Same place, some explanatory text as to why encryption is a 
normative requirement when conveying URNs would be helpful. The URNs 
themselves, being published in an IANA registry, are obviously not 
secret.

(26) Same place, I'm not sure exactly what "TLS or an equally secure 
protocol" means or how that could be tested for compliance. Since this 
is a normative requirement, it should be clarified, dropped, or 
softened.

(27) In 4.1.9, please enclose <<urn:emergency>> and <<urn:nena>> in 
double quotes.

(28) Also in 4.1.9, consider rewording:

    NENA STA-010.3-2021 is the primary document that has this backwards 
compatibility requirement, as it defined most of the identifiers in 
urn:nena.

    To:

    NENA STA-010.3-2021 is the document that defined and uses most of 
the identifiers in "urn:nena"; a future revision is expected to address 
backwards compatibility requirements between "urn:emergency" and 
"urn:nena".

(29) Also in 4.1.9, consider changing "as identifiers" to "to 
identifiers" (making the construction "similar to" rather than "similar 
as").

(30) Typo in 4.2: "subregistrues" instead of "subregistries".

(31) Section 4.2 should be moved to 4.1, since it establishes the master 
registry (or registry grouping) into which the various subregistries are 
placed.

(32) Also section 4.2, consider rewording "that promulgates emergency 
services standards" to "in which emergency services are in scope".

(33) Same place, consider adding "in which emergency services are in 
scope" following "is a recognized standards organization" (making the 
text "that the organization defining the registry is a recognized 
standards organization in which emergency services are in scope").

(34) Section 4.2, second paragraph, consider changing "These registries 
are required to implement" to "These registries are needed in order to 
implement" (to clarify that the documents need the registries  rather 
than the registries being required to implement the documents).

(35) Consider adding a new paragraph to 4.2 to clarify if registries are 
identifiable as being within the "Emergency" area or not (e.g., if a 
registry that starts with the letters "Emergency" is assumed to be part 
of this master registry or if that's just current convenience).

(36) Consider adding a new subsection of 4.3 that removes the “Data 
About” column of the “Emergency Call Data Types” registry, e.g.,

    This document updates RFC 7852 to remove the “Data About” column 
of the “Emergency Call Data Types” registry. IANA is requested to 
add a reference to THIS DOCUMENT this registry, and to delete this 
column.

(37) Section 4.4.3, I think you need an "and" before "if the registering 
organization is not the IETF", but more broadly, the criteria is 
confusing when written as  single sentence (e.g., as written, one might 
think verification that the "purpose adequately describes the new class" 
is only required for non-IETF documents). I suggest rewriting the 
criteria as a set of bullet points, e.g.,:

   The expert must confirm:
   - the requested class is appropriate for emergency services
   - if the registering organization is not the IETF, that it is an 
appropriate organization to define the class
   - that the purpose adequately describes the new class
   - the reference leads to a document that clearly describes the use of 
the class

(38) In 4.4.5, what's the reason for emergency services SDOs other than 
NENA to define entries in "urn:nena"? ("IETF and emergency service 
standards organizations MAY define subregistries of urn:nena.")

(39) Typo in 4.4.5.1: "Esternal" instead of "External"

(40) Please consider adding "to or" before "within" in the first 
sentence of the second paragraph of 4.4.5.1 (i.e., from "routed within" 
to "routed to or within")

(41) In 4.4.5.1.3, please revise the duties of the expert as for comment 
(36) for Section 4.4.3.

(42) In 4.4.5.2, an "an" is missing in "and entry" (should be "and an 
entry").

(43) In 4.4.5.2.3, please revise the duties of the expert as for comment 
(36) for Section 4.4.3.

(44) In 4.4.5.3, consider adding "from outside an ESInet" and changing 
"directed" to "routed" in "Test calls are directed to". i.e., change:

    Test calls are directed to "urn:service:test.sos"

To:

    Test calls from outside an ESInet are routed using 
"urn:service:test.sos"

(45) Also in 4.4.5.3, I suggest changing "similar" to "corresponding" to 
show that the levels and identifiers should be the same .

(46) In 4.4.5.4, it might be more clear to change "other contexts" to 
"contexts besides routing where LoST queries are used".

(47) In 4.4.5.5.3, it might be helpful to clarify or explain how the 
expert should go about trying to minimize the number of entries.

(48) In 4.4.5.6, this sentence doesn't seem to make sense:

    This is distinct from the parent subregistry, "police.federal", is 
the police.federal subregistry includes the names for specific federal 
agencies, as opposed to the "responder.police" subregistry which 
indicated the agency TYPE (police).

(49) In 4.4.5.6.2, please clarify what "short and long forms" means, 
e.g., change "Short and long forms of the entry" to something such as "A 
short form of the agency name (often an abbreviation) and the full 
agency name".

(50) Typo in 4.4.5.6.3: missing "each" in "that entry" ("that each 
entry").

(51) In 4.4.5.6.4, should the registry have a column that specifies one 
or more language subtags for each name? Should there be a column listing 
one or more country codes per name indicating where the name is in use?

(52) In 4.4.5.7, I suggest changing "has similar purposes" to "has a 
similar purpose".

(53) Also in 4.4.5.7, I suggest changing "except for types of fire 
response agencies" to "differentiating among types of fire response 
agencies."

(54) Typo in 4.4.5.7.3: "varies" should be "vary" in "The names used for 
various kinds of fire departments varies from country to country."

(55) Also in 4.4.5.7.3, same request as in (46).

(56) In 4.4.5.7.4, same questions as in (50).

(57) In 4.4.5.8, same issue as (52).

(58) In 4.4.5.8.3, same issue as (46).

(59) In 4.4.5.8.4, same questions as (50).

(60) In 4.4.5.9, I suggest rewording:

    The ESInet will connect to many services and public safety
    agencies. A directory ("white pages" and "yellow pages") of
    agencies, together with key information about the service or
    agency, is the function of the Service/Agency Locator.

    To:

    Agencies connected to an ESInet need to connect to various
    services and public safety agencies. A service called the
    Service/Agency Locator provides a directory ("white pages") of
    agencies, together with key information about the service or
    agency.

(61) In the last sentence of 4.4.5.9, I suggest changing "urns" to 
"URNs".

(62) I suggest fixing the typo in 4.4.5.9 and also change “with” to 
“in”: “witha” should be “in a”.

(63) Also in 4.4.5.9, consider changing “that service” to “a 
service” or “a specific service”.

(64) In 4.4.5.9.3, should this be restricted to a NENA specification, or 
a specification published by an SDO with responsibility for emergency 
services?

(65) Same place, should the expert verify that the entry has a 1:1 
mapping with a Service/Agency Locator service/agency?

(66) Same place, typo: missing “the” in “that entry” (should be 
“that the entry”).

(67) In 4.4.5.10, I suggest changing “knowing what type of identifier 
is helpful” to “knowing the type of an identifier is helpful”.

(68) Same place, change “uid” to “UID”.

(69) Should 4.4.5.10.2 say "the document" rather than "a document" (can 
there be multiple documents specifying a value)?

(70) 4.4.5.10.3 is missing "the" in front of "entry".

(71) Same place, should it be the document that specifies the structure?

(72) In 4.4.5.11, is it true that media features with limited use are 
not appropriate in the SIP Media Feature Tag Registry? There's a risk of 
duplication or unawareness when the values are split between registries. 
Other registries have a way to indicate if a value is for general or 
limited use (e.g., MIME media types).

(73) In 4.4.5.11.3, typo "that entry" should be "that the entry".

(74) Same place, "and specifies how it is used" should be "and that the 
referenced specification adequately describes how it is used".

(75) Typo in 4.5: "/>" appears in text.

(76) I suggest replacing the text in 4.5.1 with something such as the 
following:

    A variety of services are used during the processing of emergency
    calls. These services are deployed within an ESInet and are
    discoverable using the LoST [RFC5222] protocol or a discovery
    service known as the Service/Agency Locator (SAL). Standardized
    query terms are needed for both discovery mechanisms to work.
    When querying LoST, the service URNs in section 4.4.5.1.
    "urn:emergency:service" Subregistry are used. When querying the
    SAL, service names from the registry defined in this section are
    used. IANA is requested to create the ServiceNames subregistry in
    the Emergency registry.

(77) In 4.5.1.3, typo "that entry" should be "that the entry".

(78) Same place, suggestion: the expert should verify "that the entry is 
for a new service that is defined in a standard produced by an SDO with 
emergency services expertise".

(79) In 4.5.1.4, I suggest making the columns/fields more explicitly 
named:
    - An ASCII "Short Service Name" of the service (e.g., "ADR")
    - An ASCII "Long Service Name" of the service (e.g., "Additional 
Data Repository")
    - A "Reference", a URI to the document that defines the service.

(80) In 4.5.2.1, I think the name should be "serviceState" or 
"serviceStates" (plural), not "serviceNames".


--Randall