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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 01 Sep 2015 07:42:12 -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:
----------------------------------------------------------------------

[Edit: I asked a question below about what happens if you dereference a
block, and find the URL points to something other than what you expected.
On reflection, I should expand that  to ask how dereferencing errors
should be handled in general.] 

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.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 1 Sep 2015 10:01:11 -0700

Hi Ben,

Thanks for your comments. One note below.

> On Sep 1, 2015, at 7:42 AM, Ben Campbell <[email-masked]> wrote:
> 

I asked about this in my AD review and I believe Marc did these after submitting the write-up and the write-up did not then get updated. Marc is on vacation this week so he may not be able to confirm until he gets back.

Alissa

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 01 Sep 2015 12:04:23 -0500

On 1 Sep 2015, at 12:01, Alissa Cooper wrote:

>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> I asked about this in my AD review and I believe Marc did these after 
> submitting the write-up and the write-up did not then get updated. 
> Marc is on vacation this week so he may not be able to confirm until 
> he gets back.
>

On digging through old email, I see evidence that he did that for the 
XML parts. Do you know if there was a MIME media type review? I guess 
IANA will kick off a final review before registration?

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Sep 2015 16:49:47 -0400

> On digging through old email, I see evidence that he did that for the XML
> parts. Do you know if there was a MIME media type review? I guess IANA will
> kick off a final review before registration?

No, they won't.  Media types in IETF Standards Track documents no
longer need expert review.  I've been reviewing this document today
(will post my comments soon), and find the media type registrations to
be mostly OK (I have to check on character encoding things).  If I had
questions, I'd ask someone to post to the media-types list for review
there... which is recommended, but not required.  I don't have
questions, so I'm not going to push for that.

Barry

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 01 Sep 2015 15:57:25 -0500

On 1 Sep 2015, at 15:49, Barry Leiba wrote:

>> XML

Okay, I didn't realize we had changed that requirement. For the record, 
I didn't find anything in the media-type registrations that raised 
questions.

Ben.

---

From: Randall Gellens <[email-masked]>
Date: Sun, 13 Sep 2015 16:51:26 -0700

Sorry for the delay, I am back at work and working through my email.

Thanks, Ben, for your detailed review and comments; I appreciate it. 
Please see in-line.

>  https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

In general, since this is an emergency call, we want the call to go 
through even if there are errors.  It's better that the call go 
through with some data blocks missing or unusable than for the call 
to fail.

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

Hannes extracted the XML schemas and examples and validated them.  As 
a result, a number of fixes were made a few months back.  The draft 
was updated to add Appendix B ("XML Validation") to mention a few 
issues that may commonly arise when extracting XML examples or 
schema, and to note that extracted schemas are available temporarily 
at a URL, to be replaced with IANA's repository after publication.

>  paragraph stating it explicitly.

The Introduction says:

    This document extends the basic set of data communicated with an IP-
    based emergency call, as described in [RFC6443] and [RFC6881]

Both those RFCs are explicitly SIP-based.  However, I'd be happy to 
change the text from "IP-based" to "SIP-based" if people feel it 
would add clarity.  E.g., to:

    This document extends the basic set of data communicated with a SIP-
    based emergency call, as described in [RFC6443] and [RFC6881]

Or perhaps to:

    This document extends the basic set of data communicated with a
    Session Initiation Protocol (SIP) based emergency call, as
    described in [RFC6443] and [RFC6881]

Let me know if you feel this change would be helpful.

>  be unlikely to be registered with NENA, but it would be worth saying

Such calls are possible and would be supported and can be done in 
compliance with the document.  The originating device adds a device 
info and provider info block (the latter with device owner 
information, as per the document).  Since there would be no further 
service providers, no additional blocks would be added.

The document even explicitly mentions this case in Section 5 bullet 2:

    The device MUST provide one if it knows no service
    provider is in the path of the call.  The device MAY insert one if it
    uses a service provider.

>  about "prexisting relationship" and "privacy issues addressed".

The reason for that text is to permit re-use of the mechanisms within 
private telematics calls between a vehicle and a telematics service 
center (which in turn simplifies the use of the mechanisms when such 
calls are emergency calls from the telematics service center to a 
PSAP).  The text appears as an exception to a ban on using the 
mechanisms outside of an emergency call, so without it, such use 
would be violating the RFC.  I thought the text was pretty 
restrictive, since it says:

    certain private-use situations where the endpoints
    have a preexisting relationship and privacy issues are addressed
    within the relationship or do not apply because of it

If you still feel this text is a "license for abuse" I'd be open to 
tightening it, but it seems pretty limited to me.

>  the same time"? Does that mean for the same call? Occurring in some

This is a good question and I can see a use for some clarification 
here.  What this is trying to say is that when a service provider 
processes a call it adds various blocks, all of which are linked by 
having the same <DataProviderReference> value.  There may be 
situations where the same provider processes a call more than once 
(possibly in different roles), and in those cases, each time it 
processes the call, it would add a set of bocks with a new 
<DataProviderReference> value.

I've added the following text for clarification:

    (In certain situations, the same provider might process a call more
    than once, likely in different roles, and in such cases, each time it
    processes the call, it adds a new set of bocks with a new
    <DataProviderReference> value.)

>  services in multiple categories,  would they create multiple instances?

A provider is limited to identifying itself as one type, but if it 
processes a call more than once (e.g., in different roles), it adds a 
set of blocks each time, and so would likely use a different value 
each time.  But in most cases, each provider touches a call just 
once, with one value.  It would pick the most appropriate value.

>  Do you intend 24x7 support to be a prerequisite to be a data

It's not within scope of the IETF to make this requirement, but the 
expectation is that calls will be processed by mainstream providers 
who have 24/7 support for PSAPs.

>  receiver should only look at the first entry why are multiple entries

I think these are SHOULD rather than MUST because it won't break 
anything if they are violated, and there might be weird edge cases we 
aren't thinking about.

>  purpose and might still have privacy implications. Do we really need

The text does not mandate which fields to send.  It encourages 
sending all fields because there are some unusual circumstances where 
a seemingly irrelevant field might be useful to a call-taker (e.g., 
anniversary might conceivably be useful with a suicidal caller) and 
suggests a minimum set.

>  handset connected to a wired Internet service count as wireless? How

Good point.  I changed the text to be more clear:

       Because the usefulness is unknown (and less clear)
       for cellular, this element is OPTIONAL for commercial mobile radio
       services (e.g., cellular) and REQUIRED otherwise.

>  -Can the list of wireless types change over time?

The range of services included in "wireless" will expand over time, 
e.g., when 5G is deployed it will count.

>  -I don't understand the full definition of "temp". Are these terms

These are common industry terms, although in many cases these are 
specific to wireline service, so "temp" will become less common.   In 
high-turnover situations such as college dorms, wireline providers 
often put service into this state when one person moves out.  It 
allows a new person to move in, plug in a phone, and establish 
service in an automated way via the phone.  Similarly, if a wireline 
provider suspends service due to non-payment, they may leave the 
service in this state.

>  -Is VoIP intentionally limited to OTT services?

I think we do want POTS but I changed VOIP to OTT to be more clear, 
and added "digital" for non-POTS, non-OTT wireline service.

>  What if the device model designation is not a number?

It's fine if it contains non-digit characters (which is fairly common 
for model numbers of all sorts of devices).  The XML schema defines 
it as a string.

>  What happens if the URL points to something other than the indicated

Then the PSAP doesn't get what it expects, and likely will ignore the 
retrieved data, and the call will be processed as if the block wasn't 
provided at all.  The PSAP will likely file a discrepancy report with 
the provider, which is done out of band.  If the information in the 
block is potentially urgent for handling the call, the call-taker or 
a supervisor might contact the provider's PSAP support line.

>  you have detailed procedures later. Please consider moving 2119 language

To do that, I'd have to add it to both 5.2 ("Transmitting Blocks by 
Reference using the <provided-by> Element") and 5.3 ("	Transmitting 
Blocks by Value using the <provided-by> Element"), which seems 
awkward.  I think it's better to have the normative language in one 
common place.

>  language sounds like it should be normative.)

There's no requirement or expectation for run-time checks of the 
registry, because applications will only access those blocks they are 
interested in.  It's likely that software updates for PSAP and 
responder equipment will add support for any blocks defined since the 
previous release, and as matter of local configuration (e.g., policy 
establishment), individual PSAPs and responders will select those 
supported blocks that they are interested in.

>  value starting with 'EmergencyCallData' can be expected, but at least
>  one

The scope of the document is explicitly restricted to emergency calls 
in section 3 ("Document Scope").

The device may not know, in which case it needs to include one.  I've 
reworded the text to be:

    The device MUST provide one unless it knows that a service
    provider is in the path of the call.  The device MAY insert one if it
    uses a service provider.  Each service provider in the path of an
    emergency call MUST insert its own.

>  information when dereferencing a URL.

If an element in the call path is compromised and under the control 
of an attacker, it can wreak havoc, but this is generally true for 
any system that isn't using end-to-end protection, and even then is 
true if an endpoint is compromised.  I'm not sure what would be 
helpful to say about this in the Security Considerations section.

>  please say that explicitly.

The intent is to require that HTTPS with a client-side certificate be 
used.  I've added text to say so.

>  When might they not? What if they don't?

I think the problem is simply that the IETF lacks scope to dictate to 
PSAPs and responder agencies outside the use of the mechanisms 
defined here, so I reworded this from "SHOULD" to "are strongly 
advised to".

The new text is:

    When information is provided by reference, HTTPS is REQUIRED for
    dereferencing, the requestor MUST use a client certificate to
    authenticate the HTTP request, and the provider of the information is
    REQUIRED to validate the credentials provided by the requester.
    While the creation of a public key infrastructure (PKI) that has
    global scope may be difficult, the alternatives to creating devices
    and services that can provide critical information securely are more
    daunting.  The provider of the information MAY enforce any policy it
    wishes to use, but PSAPs and responder agencies are strongly advised
    to deploy a PKI so that providers of additional data can check the
    certificate of the client (the requester) and decide the appropriate
    policy to enforce based on that certificate.

>  Can you elaborate on that or cite something?

Good catch; I added a reference to DANE (RFC 6698).

>  Seems like that should go in the privacy considerations. (And probably

This exact paragraph is already in the Introduction, and the Privacy 
Considerations section has words to the same effect but in somewhat 
more detail.  So, I just deleted the paragraph from the Security 
Considerations section.

>  reasonable expectations on the DEs? (I don't know the answer.)

I think so, because I think the designated expert will only reject a 
registration in very clear cases.

>  Current as of when?  I suggest "The initially valid entries are..."

This was changed recently (maybe in -33 or -34) to say "Currently, 
the only valid entries are...."  Is that OK?

>  "... it is known to be valuable."

I've reworded the text to:

       This is non-authoritative:
       There are situations where the service provider does not know the
       type of service (e.g., anonymous pre-paid service).  The type of
       service does not necessarily reflect the nature of the premises
       (e.g., a business line installed in a residence, or cellular
       service).  The registry does not contain all possible values for
       all situations.  Hence, this is at best advisory information, but
       since it mimics a similar capability in some current emergency
       calling systems (e.g., a field in the Automatic Location
       Information (ALI) information used with legacy North American
       wireline systems), it is known to be valuable to PSAPs.

>  something more distinctive than capital letters. Perhaps quotes, or even

Good point.  I reworded the text to be simpler:

       It is possible to
       receive two Device Information blocks, one provided by the device
       and one from the service provider.

>  -- 4.3.7: That seems odd for this to be a subsection of the device

On reflection, I agree.  I moved section 4.3.6 to be new top-level 
section 5, and section 4.3.7 to be new subsection 5.1, and added a 
reference in new section 5 to section 4.3.5.

>  paragraph. Please consider subsections.

I share your frustration, but unfortunately, if I switch to 
subsections the text that follows the section will be orphaned, since 
XML2RFC doesn't permit top-level text following a subsection.

>   I'm not sure I understand the meaning of "provision" in this

It just means providing the location (who provided it, etc.)

>  the start of the section.

OK, I moved this to be the third sentence in the section.

>  "by-reference" in 3204 or 3459. It might be worth re-citing 5621.

Good idea.  Added.

>  tables directly. It would be nice to be consistent, one way or the other.

I cleaned this up in -33 or -34 to move them all to be in the 
discussion sections, with the IANA section referencing them.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Television is simply automated day-dreaming.
       --Lee Lovinger, _Quote_, July 30, 1967

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Sep 2015 09:26:51 -0700

At 4:51 PM -0700 9/13/15, Randall Gellens wrote:

> subsections the text that follows the section will be orphaned, 
> since XML2RFC doesn't permit top-level text following a subsection.

It occurred to me after I replied that I can make pseudo paragraph 
breaks by using <vspace/>.  I've updated this text to do so and hence 
is easier to read.

-------------- Randomly selected tag: ---------------
I think we'd get fewer weird bug reports if we stopped selling our
software off planet.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Sep 2015 13:01:29 -0400

On 9/14/15 12:26 PM, Randall Gellens wrote:
> breaks by using <vspace/>.  I've updated this text to do so and hence is
> easier to read.

IIUC, the two list elements correspond 1:1 with the subsections 5.1 and 5.2.

Why can't you trim the list elements down to their first sentence. Then 
move the rest of the text into the corresponding subsection? Some minor 
rewording should make that work.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Sep 2015 18:39:05 -0700

At 1:01 PM -0400 9/14/15, Paul Kyzivat wrote:

>  Why can't you trim the list elements down to their first sentence. 
> Then move the rest of the text into the corresponding subsection? 
> Some minor rewording should make that work.

The two list elements provide an overview, with details in 5.1, 5.2, 
and 5.3, so it's not 1:1.  I think with the <vspace/> it looks much 
better.  have a look at -35 when it's uploaded and see if you still 
think the material needs to be reworded.

-------------- Randomly selected tag: ---------------
Ninety percent of the politicians give the other ten percent a bad name.
                                                      --Henry Kissinger