Subject: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 31 Aug 2015 21:35:00 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-ecrit-additional-data-34: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This draft was clearly lots of work; thanks for making it happen.
However, I have a number of comments:

The shepherd’s writeup indicates that no XML or media type reviews were
required—but this document contains a lot of XML (examples and schema),
 and a number of media type registrations. Is that an error in the
writeup, 
or have those reviews been skipped?

This draft implicitly assumes that the emergency calls are signaled with
SIP. I don't dispute that assumption, but I think it should it's worth a
paragraph stating it explicitly.

-- section 2, 2nd paragraph:
Are there any considerations for services provided with no "company" or
"service provider" behind them? For example, lets say an individual
hosts
some VoIP related services for her own use (e.g. a SIP registrar, maybe
a
stun/turn server,etc) Are those in scope? I'm guessing not, since they
would
be unlikely to be registered with NENA, but it would be worth saying
that
explicitly.

-- 3: 
Is there a critical need for the bit about "certain private-use
situations"? That seems like license for abuse, without more elaboration
about "prexisting relationship" and "privacy issues addressed".

-- 4, third paragraph from end: 
Can you elaborate on what you mean by "at
the same time"? Does that mean for the same call? Occurring in some
interval
of time ?

-- 4.1.4 
Is a provider limited to one type? If the same provider provides
services in multiple categories,  would they create multiple instances?

-- 4.1.5: 
Do you intend 24x7 support to be a prerequisite to be a data
provider?

-- 4.1.7, Description: "Although multiple <vcard> elements may be
contained
in a structure only one <vcard> element SHOULD be provided.  If more
than
one appears, the first SHOULD be used."
When might it be reasonable to violate either of these SHOULDs? If the
receiver should only look at the first entry why are multiple entries
allowed at all?

Also, it seems like there are vcard fields that are not useful to this
purpose and might still have privacy implications. Do we really need
people
to send everything?

-- 4.2.1, How Used..., last sentence: 
The term "wireless "needs more
precision if you're going to use it in a 2119 expression. With a Wi-Fi
handset connected to a wired Internet service count as wireless? How
about a
cordless phone?

-- Figure 5: 
-Can the list of wireless types change over time? 
-I don't understand the full definition of "temp". Are these terms
defined somewhere?
-Do you really want "POTS" vs "PSTN"? 
-Is VoIP intentionally limited to OTT services?

-- 4.3.3: 
What if the device model designation is not a number?

-- 5, list item 1: "The "purpose" parameter also indicates the kind of
data
(by its MIME subtype) that is available at the URI" 
What happens if the URL points to something other than the indicated
thing?

- list item 2, last sentence: 
I gathered this section was an overview, since
you have detailed procedures later. Please consider moving 2119 language
to
that section.

-- Section 5, last paragraph: "only blocks in the registry are permitted
to
be sent using the mechanisms specified in this document"
Are implementations supposed to check the registry at run time? (Also,
that
language sounds like it should be normative.)

-- 5.1, last paragraph: "More than one Call-Info header field with a
purpose
value starting with ’EmergencyCallData’ can be expected, but at least
one
MUST be provided.  The device MUST provide one if it knows no service
provider is in the path of the call."
What's the scope of the first MUST? Emergency calls? Is it possible the
device doesn't know whether there is a service provider in the path?
Should
this say it MUST insert unless it knows there is a service provider in
tHe
path?

-- 8:
It might be worth discussing the potential harm done by a malicious
proxy
modifying a data element, or a compromised data source return incorrect
information when dereferencing a URL.

The first paragraph REQUIRES verification of requester credentials, but
does
specify the form of those credentials. Subsequent text talks about
client-certs and PKI verification. Are other forms of credentials
allows?
(HTTP-digest, application level logins, etc). If client-certs are
required,
please say that explicitly.

- "PSAPs and responder agencies SHOULD deploy a PKI " 
When might they not? What if they don't?

- "emergency services authorities could obtain a credential from the DNS
entry of the domain" 
Can you elaborate on that or cite something?

- paragraph starting with "Much of the information supplied by service
providers and devices is private and confidential":
Seems like that should go in the privacy considerations. (And probably
also
the intro.)

-- section 10: 
Many of the registry policies require experts to access
whether an organization might be "legitimate" or "relevant". Are these
reasonable expectations on the DEs? (I don't know the answer.)

Nits and Editorial Comments:

-- 4.2.1, Description: Currently, the only valid entries are...
Current as of when?  I suggest "The initially valid entries are..."

-- 4.2.1, How Used... : "... service provider does not know ..." 
Does not know...what?  (That's part of a long, convoluted sentence.
Please consider
breaking it into simpler sentences.)

"... it is known to be valuable." 
Known by whom?

-- 4.3.1, Description: "It is possible to receive two Additional Data
Associated with a Call data structures,..." (Occurs in several places.) 
The naming is confusing. It's easy to read "additional data associated
with..."
as it's plain English meaning, rather than as a name. I suggest doing
something more distinctive than capital letters. Perhaps quotes, or even
an
abbreviation.

-- 4.3.7: That seems odd for this to be a subsection of the device
information function.

-- section 5: 
It seems awkard to use a numbered list for elements that are
close to a page long each. This forces each to be a single, overlong
paragraph. Please consider subsections.

-- section 5, list item 2: "circumstances about the provision of the
location"
 I'm not sure I understand the meaning of "provision" in this
context. 
- Sentence starting with: "When the access network provider" 
This sentence provides context information that would have been useful to
have at
the start of the section.

-- 5.4, 2nd paragraph: 
I think people are going to be confused and look for
"by-reference" in 3204 or 3459. It might be worth re-citing 5621.

--10:

Some sections reference tables from other sections, and some include the
tables directly. It would be nice to be consistent, one way or the other.